  |
はてなキーワード: Pythonとは
そういう原理的にどうかという話ではなくて、単にC#とかJavaとかだと何するにもまずclass宣言から入らないといけなくて、初心者的にはなんだよそれってなると思うという程度の話。
python(LL)ならクラスも使えるけど(便利な関数のついた)Cっぽくも書けるわけだし、型付けとか煩わしいことも少なくていいじゃんという程度。
Javascriptって触ったことないけど、むしろ関数型だと聞いたんだけどどうなのかね。pythonもかなり関数型っぽいけど。
ただまぁVBはねーだろって思う。
Action Script は 3 からかなりしっかりしたクラスベースの OO だよ。
JS も馬鹿みたいな使い方しないでちゃんとしたスタイルで使えば OO だし、全てがハッシュというオブジェクトだし、関数もオブジェクトだしその辺わからないと JS をつかっててもコピペプログラミングに終始して面白くないから結局 OO 理解しないといけない。prototype.js や jQuery やの中身とか読んで理解できるくらいになるには。
Perl だって悪しき過去の遺産が残ってるから OO じゃないイメージが一部にあるけど、モダンな Perl は OO だよ。CPAN にあがってるまともなモジュールは殆ど OO スタイルだし、もっとモダンなスタイルの環境でもいける。モダン Perl や Moose あたりで検索してみるといい。今からやるなら OO しかないけど、初心者は昔のうんこを踏みがちだよね。JS も同じ事が言えるけど。
JS や Perl というゆるい LL は OO を理解していなくても一応使えるってだけで、それじゃマスターには程遠い。あと言語仕様でやっちゃいけないことを縛っていないから、しっかりした開発をやるには 規約もしっかりしないといけない。 初心者は最初からいい出会いをするわけじゃないから、誤解が多いのかもしれない。
JS と Perl はレガシースタイルが残ってる例としてあげたけど、LL でも Python や Ruby はもともと OO スタイルしかない。だから、自分でやってることを理解してないと過去のうんこを踏む可能性のあるゆるい LL よりは、どうやっても綺麗にしかかけない Python は初心者向けだと思う。知り合いが何でも良いからプログラミングやってみたいと言い出したら GAE で Python 弄らせる。
ぶっちゃけ LL でもいまどき OO を避けて通るなんて無理。
プログラミングスキルは、本質的には言語に依存しない。 (よほど糞な言語を使うのでなければだが) OO への理解やアルゴリズムの理解ってのは LL か巨大な言語かに依存しない。絵を描くのに道具によって慣れの差はあっても画力は道具を変えても持ち越せる共通した力だというのに似ている。一つの言語をちゃんとある程度マスターすれば、他の言語の習得はとても早い。たとえ最初にやる言語が LL でもね。別の言語をやるときに壁になるのは関数型かそうでないかくらいのパラダイムの差がある場合だけど、JS や Perl でさえ 関数型で使うようなテクニック を実装できるし使いどころがあるから、やっぱり共通点はあって、～だから～を学ばなくていい、なんてのは上達したいなら殆どない気がする。
違うけど。
printf("Hello World!!\n");
の先にあるんだ。
データ処理をしたい、ユーザーに選択させたい、次のステップに進むとき、マイクロソフト系は環境を用意しやすいんだよ。
データベースアクセスだって、ＶＢならアクセスライクのＤＢでＳＱＬを疑似体験できる。
ここのステップを超えられないと、プログラムで「何が出来るか」に気付けずに、「つまんない」で終わっちゃうんだよ。
正味な話、PHPとかpythonって、初心者に「次」を用意するのがしんどいんだよ。
プログラミングは静的言語(C/C++,Java,C#など)と動的言語(rubyとかpythonとかperlとかいわゆるスクリプト言語)と関数型(lispとかF#とかhaskellとか)を一つずつくらい眺めた方がいいと思う。
どれか一個くらい自分に合ってるのが見つかるかも。
やりたいことにどの実装系が一番適しているかを考えるべきで、実装系を目的に合わせるべきじゃない。
そういう考えでいると、PHPで何でもやる奴とか出てきて迷惑なんだ。
そもそものロジック構築などは、ターゲットには依存しても、言語にはほとんど依存しない。
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
上位レイヤーの話はしてないんだけどね。
「Python」でも良いし、「JRE」でも良いし、「HSP」でも良いよ。
「正しい申告」と言うのは、自身が必要とする実行環境についての、正しい申告。（リビジョンとかね）
「すべてのアプリが、自身が必要とする実行環境を必ず用意する」方が、一般市民御用達のWindowsではユーザーにやさしい。
配布サイトが変わる実行環境やライブラリって結構あるが、それは「アプリが独自に解決」すべきなのか。
それとも、それらの実行環境を配布する人は、逐一公的な実行環境としてマイクロソフトに報告しなきゃならなんのか。
１年前の記事がリンクすべて死んでるとかざらにある。
って言うようなパッケージは、自力で解決しろよ、と思うんだが？
ここがどういうことを言ってるのかちょっとよくわからないんだけど、
アプリ間の依存関係はまぁそれほど問題にならないからどうでもいいかな。
下位レイヤがほんと酷い。
dllだのランタイムライブラリだの、スクリプト言語の実行環境だの何だの
パッケージ単位で全部解決させようとするからどのインストーラにもいちいちpythonとか入ってやがる。
逆にその辺がまとまってないソフトを入れようとすると、依存関係を自分で解決する必要があって大体ハマる。
管理システムへの登録スクリプト環境をきちんとしとけば（例えばmacのhomebrewはrubyに統一されてる）、
あれって、HTML4の代わりに標準になったら「知らなきゃいけない必須項目」であって、投資するかどうか悩む選択項目じゃないと思うんだが。
プログラマに「アルゴリズムに投資するか、.NET開発環境に投資するか」と問いかけるくらいバカバカしい。
その上で、今あるFlashの仕事をどうするかって話で、「Flashへの投資」は「COBOLへの投資」とか「ネイティブＣへの投資」とかと同義。
もちろん人によっては「FlashはPHPだよ」とか「FlashはPythonだよ」って人も居るだろう。
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
RubyのSymbolと文字列の違いを研究室の輪講用に書いたのですが，折角なので公開したいと思います．
元々学部生に対する輪講用に書いた物なので，若干上から目線ですがご了承ください．
文字列とSymbolはよく似ています．プログラマから見ればどちらも文字列です．違いを一言で説明すると『プログラムが扱う』文字列か，『プログラマが見る』文字列かの違いです．例えば変数名は『文字列』ですが，rubyのオブジェクトである『文字列』ではないですよね？
例えば，今あなたがC言語でお絵描きライブラリを作っているとしましょう．その中に，色で塗りつぶすfillという関数があり，色を青・赤・緑の3色から選べ，fillの引数でそれを指定できるとしましょう．
fillの引数の設定方法として一番単純なのが，0を青，1を赤，2を緑として，0〜2で選択させる方法でしょう．しかし，それでは，どの数値が何色か覚えないといけないし，fill関数を知らない人から見れば，どういう意味の引数かすらさっぱり分かりません．
ではどうするかと言えば，普通はBLUE = 0, RED = 1, GREEN = 2と適当に定数を設定して，その定数を引数で指定させますよね．
こうして，fill関数の引数が意味の無い数値から意味のある文字列に変わったことによってプログラムが分かりやすい物となります．さて，ここで注意してほしいのは，ここで言う文字列はプログラムが扱うオブジェクトとしての文字列では無いということです．fill関数の引数として，"BLUE"，"RED"， "GREEN"などとC言語の文字列を渡すということは普通しませんよね．それは，ここで言う文字列は，あくまでプログラマがプログラムコードを分かりやすくするために必要な文字列であって，プログラムがオブジェクトとして扱う（例えば，長さを求めるとかする）文字列ではないからです．
分かってきたでしょうか？
プログラムコード上では（つまりプログラマから見れば）どちらも同じ文字列（文字の列という意味で）ですが，実際に動くプログラムから見れば単なる数値と本物の文字列という大きな違いです．結局，fill関数の引数の具体的な値は何でもいいわけです．プログラマから見て文字列であればそれだけでよく，プログラムが動くときの実際のその中身は何でもいいわけです．これのために存在するのが，Symbolであり，:fooとひとたびSymbolを作成すれば:fooの実態は適当な数値となります．（この数値がいくらかなんていうことはもちろん気にする必要はありません）
そして，もちろん同じプログラム上では:foo == :fooはちゃんと成り立ちます．もうここまでくれば，Hashのkeyとして文字列でなくSymbolを使う理由が分かりますね．Hashのkeyはあくまで，プログラマが見る（プログラムコードを分かりやすくするための）文字列であってプログラムが扱うオブジェクトとしての文字列では無くて，keyの実際の値は何でもいい，からですね．（特別な場合を除いて）Hashのkeyに対してrubyのStringのメソッドを使うなんてことは無いですよね．
しかし，他の軽量言語ではSymbolなどなくHashのkeyとして普通に文字列を使うことが多いです．では，なぜrubyだけSymbolを使うのでしょうか．
その答えは一言でいうと，rubyの（プログラムコード上に直接書かれた，つまりリテラルの）文字列は他の言語と違いimmutable(不変)でない，からです．実際，pythonやjavascriptの文字列(リテラル)は破壊的に変更することはできませんが，rubyの文字列は破壊的に変更することができます． （'abc'.concat('d')の様に）
これがどういう違いを生むかというと，コード上に直接現れる文字列がimmutable(不変)であるならば，実行時に一つだけそのオブジェクトを作成し，後はそれを使いまわすという最適化ができます．
そうした時，Hashのkeyの様なプログラマから見た文字列というのは，プログラムコード上のリテラルとして現れるわけですが，これらは実行時に一つだけオブジェクトが作成され（特にコード上に現れる同じ文字列は全て一つのオブジェクトにまとめると），それらの比較はそれらに対する参照（そしてこれは大抵メモリのアドレスなど単なる数値）の比較で済むので，結局Symbolと同じ様な働きをするわけです．
本当はプログラマが見るためだけの文字列だけど，それをオブジェクトとしての文字列としても，Symbolと同じ様な働き，パフォーマンスが得られるならば，別にオブジェクトとしての文字列であってもいいわけです．
繰り返しになりますが，プログラマが見るためだけの文字列は，その中身・実態は何でもいいわけですが，その実態がオブジェクトとしての文字列でも十分なパフォーマンスが得られるならば，別にオブジェクトとしての文字列でもいいわけです．
さて，rubyに話を戻しますと，rubyはコード上に現れる文字列であっても，実行時にそのコードを通る度に毎回新たな文字列オブジェクトを作成します．
（以下のプログラムを動かすことで確認できる．）
def foo 'foo'.object_id end p foo, foo
つまり，rubyでは文字列が可変であるため，先に述べたような最適化ができない（または難しい）ので毎回新たな文字列オブジェクトが作成されるのです．
こうなると，先ほどの話とはうってかわって，プログラマが見る文字列はその実態は何でもいいのに，それを文字列リテラル（rubyのオブジェクトとしての文字列）にしてしまうと，毎回毎回文字列オブジェクトが作成されてしまうという非常にばかばかしい状況になってしまいます．我々はそれらの文字列オブジェクトに文字列としての操作は一切施さないのにも関わらず，です．
こういうわけで，rubyではプログラマが見るためだけの文字列にSymbolというruby特有のものを使うのです．
もちろん，プログラマが見るためだけの文字列を全て定数として（そしてもちろん中身は適当な値で）定義しても構わないわけですが，Hashのkeyとかで数多くのプログラマが見るためだけの文字列が現れることを考えると，とてもじゃないですけどそんなことは面倒でやってられないですよね．ですので，実行時に自動で適当な値にしてくれるSymbolというものが存在するのです．
以上で，Symbolについての説明を終えます．以下は蛇足です．
最初の方で出てきたfill関数をrubyで実装しようとしたとき，青・赤・緑の各色はその実際の値はなんでもいいのでrubyのSymbolを使って:blue, :red, :greenとしてもいいのですが，ライブラリとかでは大抵ちゃんと定数として定義されていることが多いです．
これは恐らく，定数として明示的に定義することで値の存在を明示でき，ドキュメント化の際にも役立つことによっているのでしょう．
しかし，あくまでこれは外部に公開するようなライブラリでの話であって，自分が使うちょっとしたプログラムならこういう場面でも精力的にSymbolを使っていってもいいと思います．ちなみに，僕ならSymbolを使います．
Symbolだと定義もいりませんし，定数は大文字ですから打つのが面倒ですし，あまりソースに大文字が入ると見た目がすっきりしません（主観）．
Symbolは非常に便利なものですので，その意義・用途を十分に理解して，Hashのkeyにとどまらず様々な所で使えるようになりましょう．
カーネルコミッターでも、処理系実装者でも無さそうな人達が、「Cは滅びず！」と叫んでいる不思議な光景。
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5545216280/c
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5603961294/c
Linuxカーネル（せめてPOSIX互換品)を手前が思う言語にさっさと移植すれ。さすればCを滅ぼせん。（ちなみに高機能アセンブラの最適解がCとは俺も思っちゃいない。）
最後のＣの牙城、Linux（ＵＮＩＸ）をＪａｖａなり何なりベターな言語にさくっと移植してくれ。それともgoogleビッグブラザー様がクラウドでＵＮＩX鯖を駆逐してくれるのを祈ってればいいのか？
JavaもC#も，それにPerlもRubyもPythonも，実行環境自体はCで書かれている件。コンピューターが「シリコンを基材としたチューリングマシン」であるかぎり，アセンブラとCは滅びない。
はてな匿名ダイアリーを見て思った、最速でプログラミング言語を覚える為の10か条。
最初に覚える言語は、目的が明確でない場合はJavaかPythonを推奨する。言語仕様が簡潔で、資料が豊富で、応用範囲が比較的広い。
最近、Scala信者が増えたが、Scala、Groovy、Clojureで仕事している人はいるのだろうか？
Javaと比較してライブラリが増えるわけでもなく、応用分野が増えるわけでもなく、良さが理解できない。
| 検索順位 | 人気順位 | 言語名 | 登場年 | 特徴 |
|---|---|---|---|---|
| 1位 | 95位 | Scala | 2003年 | Javaに関数型言語の特徴を組み込んだ。 |
| 2位 | 71位 | Groovy | 2003年 | Javaより少ない記述量が特徴。 |
| 3位 | - | Jython | 1997年 | Python 2系のポーティング。 |
| 4位 | - | JRuby | 2001年 | Rubyのポーティング。 |
| 5位 | - | Clojure | 2007年 | Lispの方言、つまり関数型言語。 |
| 6位 | 75位 | JavaFX Script | 2008年 | JavaFXを残して廃棄処分。 |
●JAVA J2EEやらJ2SEやら色々あって良く分からない。 オブジェクト指向言語ということだけは知っている。 クラスしかりの設計や、型の変換/比較が面倒くさいので続ける気が起きない。 ●Perl ちょっと書き方間違っただけですぐに「Internal Server Error」になるので飽きる。 perlの案件があるんだけど…と聞かれると「いやー作れるんですけど、しばらく触ってないから」とか言って逃げる。 ●Ruby 使ってるやつの大半はナルシスト。「はぁ、Rubyのコードふつくしい…」とか言ってるのを見ると虫酸が走る。 言語作者もPHPをすぐdisるので嫌い。案件少ないくせに調子乗ってるグループに属する。 ●C言語 LSIC試食版で遊んでみるも、黒いコンソール画面に文字が出るだけなので飽きる。 ガリガリ書ける人は天才に見える。 ●Javascript 変数名の頭に$をつけてよくエラー起こしてしまう言語。 「OFFにしてるブラウザも多いっすよ？」を武器に戦うもAJAXブームに押され仕方なく書いてる。 ●Python PHPより歴史が古いのに、なぜか新参者という扱いになっている。
プログラミング言語ヒエラルキーにおける罵倒 http://anond.hatelabo.jp/20070502200124
phpのいやなところ / perlのいやなところ http://anond.hatelabo.jp/20070522174725
LL編プログラミング言語ヒエラルキーにおける罵倒 http://anond.hatelabo.jp/20070503000905
1年くらい前にKENTWEBでCGIを覚えた私はどれくらい時代にとり残されているんだろう http://anond.hatelabo.jp/20070427114039
PHPで自称ギークとかアホか。 http://anond.hatelabo.jp/20080527201030
文系の大学出身の人が気軽にプログラマになることはお勧めしません。 http://anond.hatelabo.jp/20080830010043
[Perl][PHP][Python][Ruby] 無題 http://anond.hatelabo.jp/20080731154801
プログラミング始めてみた(笑) http://anond.hatelabo.jp/20080201185253
日本が誇るスゴ腕geekの紹介 http://anond.hatelabo.jp/20090102145542
PHPの比較の素晴らしさ加減は正常 http://anond.hatelabo.jp/20090617130518
言語による分野の住み分けがすでにできてるんだよ http://anond.hatelabo.jp/20110220120714
なぜJavaの求人が多いのか考えよう。 http://anond.hatelabo.jp/20110220101806
LL言語が後退局面に差し掛かっている件 http://anond.hatelabo.jp/20110210084023
これからweb開発に携わりたいと考えている人にお勧めの言語 http://beta.anond.hatelabo.jp/20110220013933
凍ったニシキヘビと凍えた番人 http://anond.hatelabo.jp/20120122211537
webフレームワークの王道としての役目を終えつつあるRails http://anond.hatelabo.jp/20130302013734
ついに顕在化しはじめた「Perlリスク」 http://anond.hatelabo.jp/20130228002211
なぜ国内でPerlが急速に萎んだのか http://anond.hatelabo.jp/20130307004741
※はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ http://anond.hatelabo.jp/20100827202157
俺もそう思った。
だからIDEうんぬん関係なく、PythonやJavascriptはすごく強力な言語だと思う。
けどPHP。お前だけはだめだ。
仰る通り、ハードウェアアーキテクチャについては知らないですね（スタックやヒープがどうとかは表面上わかりますが）。
というのはズバリそこが非常に嫌い（肌に合わない）で、意図的に避けてるからです…。アセンブラの本とかも持ってますが、どうにも読めないですね…。
当然Cは嫌いです…。C++がギリで、できればRやpythonレベルの抽象度で全部済ませたい派です。が、さっきも書いたようにちょっと踏み込むとすぐ低レベルの話が出てきますね…。
最近はGPUだの並列化だのを使いこなさないと生きていけない感じですし。
関数型言語くらい抽象化して数学っぽい雰囲気になってると個人的には嬉しいですねw
プログラム自体を好きになって、好きを原動力に色々やれるのが一番理想的なんですけどねえ。
原理原則系の本は、SICPを途中まで読んだとか、コードコンプリートとか、アーキテクチャ系だとCODEとかの啓蒙書に近いのを読んだくらいですかね…。
あとオブジェクト指向の本は結構読みましたね。デザパタを暗記するとかは無理ですが、原理的なところはだいぶ理解してると思います。
（言語仕様とかと違って、ある程度抽象的なので理解しやすいですね。使う頻度が高いというのもありますが）
他にも細かい勉強は色々齧ってますが（プログラミング言語を作る、という本で再帰下降パーサの辺りまでやったりとか）、いかんせん根本的に興味がないのですぐ忘れますね…。
文字列処理云々も、K&Rとか読んだときに一通り勉強してるはずですが、すぐ忘れます。
上っ面だけでなく原理が重要というのはある意味その通りだと思いますが、自分にとっては上っ面の細かい仕様とかが一番苦痛なのが辛いところです。
結局実務では上っ面が必要ですからね。できればpython辺りで全て済ませたいですが、すぐ処理効率だのなんだのといった面倒な話になりますね。
生きるの辛いです。
いや、えーと、この話に関しては、ガチプログラマの方々がどういう価値観で人を判断するのかとかが良くわかってとても為になってます。
ほんと、分散環境で大規模データ処理だの、高速ネットワーク通信だの、ガチプログラマが大活躍のこのご時勢、当分続きそうだと思ってます。
時代の流れ、ニーズの変化に応じて柔軟に対応できるのが本当に優秀な人なんだろうと思いますが、自分にはなかなか難しいですね…。
そりゃあ、やろうと思えば様々な手法があるだろうけど…
いかに余計な作業を減らして「やりたいことを実現」するための作業に専念するか、を考えている。
いろんな言語への興味はあるが、むしろそのせいで今まで時間食いまくってるので、そろそろ「手早く作る方法」を知りたい。
あんまり色々な手法を試してもいられない。
「これ！」ってやり方を決めたい。
プログラミング言語は、C C++ Java Python Perl VB C# HSP PHP JavaScriptなど、どれも基礎を触ったりしてばかりで何年も過ごしてきた。
FLASHは持ってない。(PalaFlaは触ったことあるけど、いまいちイメージしにくかった)
なんだかんだで一番慣れてるのがHTML+CSSで、次点でPHPかJavaScript。
ただ、PHPだのjavaScriptだのSQLだの、複数言語を同時に扱ってると非常に面倒。
そこでサーバーサイドJavaScriptに目をつけたものの、『Jaxer』は2008年に書かれた記事がちょっとあるばかりだし…
Node.jsってどうなんだろう…？
うーん、あまり纏まってないが、とりあえず現状をダンプしておく。
なんか参考になるものがあればなー。
こういうこと色々聞ける相手も周りにいないし…
http://www.lastday.jp/2010/11/22/objective-c
早速Objective-Cとやらを勉強しようと思ってググってみたら、Objective-CはC言語の拡張なので先にC言語を学ぶ必要があるという驚愕の事実が発覚！
この文書はC言語については解説されていないため、C言語にある程度慣れていることが前提となり ます。しかし、それほど熟達している必要はありません。Objective-Cによるオブジェクト指向プロ グラミングはANSI Cの手続き型プログラミングとはかなり違っているので、熟達したCプログラマで なくても、さほど不利にはなりません。
http://developer.apple.com/jp/devcenter/ios/library/japanese.html
Cの知識があるに越したことはないけども、どこまで必要かという話になるとごにょごにょ。
少なくとも、Objective-Cを公開している連中が、"Cの手続き型プログラミングとはかなり違う"と言っているのだから、C言語的なコードの流れには（あんまり）ならない（はず）。
それより、フレームワークの扱いに慣れることに重点を置いたほうがいいんじゃないかな。
苦Cで言うところ、文字列やら、ファイルの取り扱いあたりになってくるとかなり微妙で、出来る限り言語機能やフレームワークに任せたい。
ポインタはそりゃ、Python使いが見たら発狂するんじゃないかってぐらいポインタ演算子が出てくるけど、オブジェクトインスタンスは全部ポインタなんだから、いっそ気にしなくていいんじゃない？ それとも関数ポインタとか使いたい？ きっとデバッグが大変だよ。
YouTubeやVimeoで『Xcode tutorial』で検索すると大量のiPhoneプログラミングのチュートリアルが無料で視聴可能です！
公式の「iOS アプリケーションチュートリアル（日本語版）」を読んだ上で言っているのであれば、どこの誰が作ったかも分からない英語の動画が、アップル公式の日本語ドキュメントより優れている点を挙げた上で、その動画のURLを示して欲しい。
英語なんて分からないよ。
オススメってことは必読じゃないのかな？
3.初期投資
Intel Mac + iPhone or iPod Touch + 10,800円
ここから、開発者プログラムの参加費用$99（¥8000程度）を差っ引くと、一冊分しか残らないから、下の方で紹介されてる本が必読なんだろう。
初心者にわかりやすくObjective-Cの事が書かれています。必読です！
こっちが必読？
内容全く知らないで発言するけども、書評を見てみると、Snow Leopardに対応していない旨が書きこまれていて、多少不安。
流行りに乗ってMacbook Airを購入した人は、大抵Snow Leopardのはず。
記事には、"二ヶ月前"からとあるので、少なくとも記事を書いた人はMacbook Airではないのだろう。
自分のアプリの必要な部分だけを勉強すれば、それだけリリースも早くなりますしモチベーションも下がりません。全部網羅しようと思うと開発自体を頓挫しかねません。
遅延評価勉強法の考えで行くと、C言語を先に勉強する必要はなかったと思うけど、どっちなんだろう。
その辺も遅延で気付いたのかな。
英語力がなくてもアプリは作れますが、英語がわかると公式ドキュメントや先にあげたYouTubeのチュートリアル動画も理解できるので簡単な英語くらいはできる方が良いです。
日本語の公式ドキュメントがあるので、是非参照して頂きたいです。
http://developer.apple.com/jp/devcenter/ios/library/japanese.html
Apple Developer Documentation日本語版
http://developer.apple.com/jp/documentation/japanese.html
日本語ユーザが増えたら、Xcodeのクイックヘルプとかドキュメントとかも日本語化してくれないかなあ。
それとも、実はただの調査不足で既にあったりとか…
