  |
はてなキーワード: サブルーチンとは
IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。
PHPのプロジェクトはPHPの認定試験に受かってる奴しか使わないとか、MySQLの資格もってないとテーブル設計もやらせないしSQLも書かせないみたいな。
認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。
Javaの入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観だから、自分は実力あるとナチュラルに信じこんでるし。
VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールをJavaに持ち込んで「全メソッドでcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界。
ダメな技術者が、年をとってるってだけで評価されて上にたってダメな技術者を育成するって負のループに入り込んでるから、一定の客観的な基準で評価する仕組みをもちこんで負のループを断ち切るべき。
日本のPG/SEの60万人のうち、オブジェクト指向らしいコードを書けるのは1割以下だと思うわ。
もっと少ないかも。
オブジェクト指向言語やオブジェクト指向のフレームワークを使っていても、クラスにどんどんメソッドやメンバ変数を追加していって、クラスの中で手続き型言語風にコーディングしてるだけだし。
まだ手続き型で、ちゃんと構造化プログラミングしてればいいけど、一個のクラスにやたらとメンバ変数を作って、各メソッドから適当にアクセスしてるから、手続き型言語でグローバル変数を多用したようなコードが量産されてるし。
普通の人間には手続き型で「サブルーチンを使いなさい」「グローバル変数は多様しないように」と教育するくらいが限界だと思われ。それでも対応できるのは何割かしらんけど。
ソースコードの複雑さを表す指数で、これが高いソースコードはバグが多いって言われてるの。
サイクロマチックの発案者に直接、科学的根拠あるのかって聞いたら「実際に役にたってるから(根拠は)いいだろ」みたいな返事らしいのな。
たしかにソースが複雑だったらバグは増えるだろうけど、それならツールを使わないと算出できないような複雑な指数をつかわなくても「ネストは○段まで」「サブルーチンは短く」「サブルーチンのローカル変数は○個まで」みたいな単純なやり方でもいいよな。
サイクロマチックでなくても、見た目が複雑なソースなら大きくなる指数を適当にでっち上げても「この指数とバグの発生件数は相関関係がある」って言えそうだよな。
http://weekly.ascii.jp/elem/000/000/306/306175/
「ニコニコ生放送」のコードに、循環的複雑度が600を超えるメソッドがたくさん入っていることが判明したことがあった。循環的複雑度が75を超えるとバグの混入確率は98％、「いかなる変更も誤修正を生む」状態になると言われていて、要はニコニコ生放送は動いてるのが不思議なくらいバグがめちゃくちゃ出やすい状態だった。
循環的複雑度って科学的なメトリックスだと思ってる人がいっぱいいるけど、あれ根拠ないからな。はっきり言ってオカルト。
サブルーチンのなかにif文は何個以下とかネストの深さは何個とか、もっと単純な基準で「循環的複雑度がxx以下」と同じ効果をだせるはず。
毛の壁以降、色んなところであーだこーだ再定義言われてるけど、結局名前が悪いんだよなぁ。
どちらかというとオブジェクト指向の方が「何もかもサブルーチン(ただし値を覚えていてくれるおまけつき)」で、関数型の方が「何もかもが値(関数も)」なんだけど、まず名前からだと逆っぽく聞こえる。
加えて、この二つの概念が対立すると思われてしまうけれど、んなこたーないのはjavascript見れば分かる。何もかも値かつサブルーチン、でOK。
両立しにくいのは、オブジェクトの概念と高階関数の概念ではなく、オブジェクト指向言語が採用してきた型システムと、関数型言語が採用してきた型システムだ。
つまりC++やらJavaやらが採用してきたサブタイプ多相をベースにしたクラスによる型付けと、ML系言語が採用してきた代数的データ型が噛み合わない。致命的に。
いやまぁScalaは頑張って統合したけど、コンパイル遅いわ書き方次第で型チェックが無限ループになるわで、色々と無茶しやがって感ある。
Androidアプリ作ろうとしてJavaプログラマ募集したらクズしかこなかった全部クズだったとか、ひどくありません?
まあそれは置いといて、UIみたいに最初から仕様を決められなくて何度も作り直すようなコードはJavaは不向きみたいな話もまったく同意できないわ。
string url = "http://www…";
のように、URLを文字列で持っていたけど、やっぱアドレス用のクラスでもったほうが安心だなって思って
URI url = new URI("http://www…");
と書き直しました。
当然、このurlを参照しているところは全部エラーになります。
Javaをはじめとする静的型の言語をけなしてる人たちは、これが面倒だと思うんでしょうか。
逆にエラーの出ている箇所を片っ端から直してエラーが無くなれば、修正漏れなしの証拠だからめちゃくちゃ安心できます。
JavascriptやらRubyでこういうことをしたら、人間が目を皿のようにして全部チェックしないといけないわけでしょ。
どう考えても変更の多いコードこそ動的型の言語は不向きだと思われますが。
こういう話をすると、エディタの検索でどうこうって反論がくると思いますけど、あれは言語を理解しないでテキストでマッチしてるだけでしょ。
たとえば func($url); と他のサブルーチンに渡して、
function func($address) {} みたいに受け取って、そこから先は文字列として扱ってるコードがあっても探しきれませんよね。
静的型の言語なら、void func(string address) {} を void func(URI address) {}と修正したら修正漏れの箇所があってもエラーが伝播して言って、すぐ分かります。
OracleとGoogleの裁判がらみで「Java終了よかったよかった」みたいな話の流れで、AndroidアプリはJavascriptで作ればいいって盛り上がってたけど、そうなったらIDEのサポートが大幅になくなる原始的な環境に逆戻りでしょ。
勘弁して欲しい。
ほんとうに動的型の言語はめんどくさい。
配属されてからいろんな機能を追加してきた。中規模くらいのプログラムで、研究ではメインで使っている。
でもだんだんつらくなってきた。とにかく見づらい。
1980年代に作られたこのプログラムは今までの人たちのコメントの蓄積が半端ない。
プログラム書き換えでとりあえずとっておいたコードのコメント、書き換えた日時と人が書いてあるコメントがプログラム中に混在している。
これらは実際に動く部分のコードよりも多く、可読性をかなり下げている。
前者については、ほとんどが不要だと思うのだがあまり考えずに消すと将来困るかもしれないのでちゃんと確認して消したい。
そして未だに残るGOTO文とFORMAT文と文番号。implicit noneではない暗黙の型宣言。
Fortran入門: 知識として必要な過去のFortran このページに書いてあるほぼすべてが詰まってる。
COMMON文もほぼすべてのサブルーチンにあったが、これはなんとかmoduleに書き換えた。
moduleに書き換えたとはいえ、本来は引数で渡したほうが適切なものも機械的にCOMMON文からmodule文に書き換えたためその辺も見直したい。
一番面倒なのが一行の文字数制限。何段かのインデントを入れるとすぐにアウト。
エディタ使ってると自動でインデント入れてくれるのでいちいち直すのも面倒だし、インデント好きなのでできればインデント入れたい。
エディタといえばシンタックスハイライトもfortran77モードだとうまく表示できないことが多い。
allocatableとかmodule文なんかは厳密に言えばfortran90以降の機能だけどコンパイラが対応してくれているおかげで使える。
でもエディタのシンタックスハイライトにはそういうコンパイラが気を利かせたような実装は含めないのでうまく表示されない。
fortran90モードを使うと今度は行頭カラムの空白が守られなかったりしてコンパイルエラー。
すっげー書き換えたい。全部きれいにしたい。他言語にするとあまりにも変わりすぎて教授が混乱するからせめてFortran90にしたい。
でもさ、よく考えるとこの書き換えって全く自分の実績にならないんだよね。
そもそも今までプログラム改良して出来る計算の幅をだいぶ広げたけど、それ自体は発表できないからほぼ表に出ない。
計算結果を出してそれを発表しないと表面的にはまったく意味が無い。
ましてやプログラムの保守作業であるこの書き換えは計算結果に影響をおよぼすものでもないから研究成果にはまったく現れない。
しかもプログラム書き換えた自分だけじゃなく、みんなも使うから書き換えた自分が特別得するわけでもない。
プログラムすべてのコードを書き換えるのは単純に機械的にやっても結構時間がかかるし、書き換えても一発では絶対にうまく動かないから修正にも時間がかかる。
研究者の中にはそういうプログラム書いてばかりの人間を馬鹿にする人もいる。プログラムを書いてる研究者は自分の分野ではかなりヒエラルキーは低い。
情報系でもないんだし、それが研究の本筋じゃないからというのはわかる。自分たちのやるべきことじゃない。（でも専門性の高い道具を作り、整備する技術・人も必要なんじゃないかなと思ったりもする。）
やってもあまり得しないし他のことやったほうが絶対に自分の将来を助けるけど、ほっとくのもなんだかなあと悶々としている。
多分きれい好きの人が自分の部屋を見たら同じ苦悩を抱えると思う。
高校時代からの友人で、東大に行った奴がいるのだが落ちぶれすぎていて痛い。
思えば入学すぐのゴールデンウィークあたりからもうおかしかった。
大学は自分で勉強する所とか言って講義にもろくに出てないとか、教授や先輩がいかにバカかを熱弁していた。
２年目の夏ぐらいから２ちゃんねるまとめを自動生成するシステムを作るとか言い出していろいろやっていた。
β版発表会とか言って、仲間内を集めてお披露目会をしていたが、ただのPHPを使った動的ウェブページで、
ソースを見たらオブジェクト指向はおろかサブルーチン呼び出しすらろくに理解していないようなウンコードだった。
これじゃスパゲッティになって開発続かないだろと思ったからそう指摘したら、
そんなもの俺には必要ない、お前らとは頭の出来が違うの一点張り。
文系に行った奴らはだまされてたみたいだが、プログラミングが分かる仲間はみんな(^^;)って顔になってた。
結局完成しなかったらしい。
この間久しぶりに会って、就活や勉強の話になったらもうひどいのなんの。
そいつもIT系なのに、流行りの技術はおろか、基本的な知識もない。
関数型言語を勉強していると言ったら時代はアセンブラだと言い返したり、
じゃあアセンブラでどんな開発したのと聞けば、なぜか古文の助動詞や複素平面の話になっていた。
古文は分からないけど、複素関数なら習ったからコーシー・リーマンの関係式の話でもしようとしたら、
遮って東大の過去問の、数学的には低級な話にもっていって、最終的には俺の知識の無さについての話になった。
それを聞いて、あぁ、こいつはダメになってしまったんだな、と思った。
所詮、高校までの勉強が俺よりマシな程度にできるだけだったというのに。
信頼とか友人らしい感情はもはや無い。
ちゃんと進級できてるのかどうかも分からないが、仮に就活しているとして、まともに就活できるんだろうか。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
一部で話題になってるこれだけど、投稿件数100越えてる割には、他のネット論争と比べて比較的コメントが読みやすい。これについては、投稿してくる人も d:id:perlcodesample も余計なノイズや一言を入れずに投稿してくれているからだと思う。見習いたい。
にもかかわらず、ここを読まないでトラバ突っ込みを入れてくる奴は馬鹿ばっかりだから話は全然収束しないし。トラバ投げる奴は、ただ自分が気持ち良いエントリを書きました、って話しかしてない。
d:id:perlcodesample は「perlだとスカラーも各種リファレンスも全部 my $var って書くだけで受けることができる！ 楽！」って話しかしてない。（そこから派生する色んな"利点"については「お前がそう思うんならそうなんだろう、お前ん中ではな」レベルの主観だらけなので"インデントをスペースにするかタブにするか論争"のように対話しても万人に納得のいく結論は出ない）
そう言う話に「そんなことをしてると(あらかじめコンパイル時にチェックが入らないから)後から大変なことになるぞ！」ってツッコミが入り、それに対して「後から大変ってどういうことですか？ どうせ全部テストするんですから(コンパイルを行った時点である)最初から大変なのも、(プログラムをテスト実行した)後から大変なのも、大変度合いの総和は大して変わらないでしょう？」というあたりで止まっている。
この d:id:perlcodesample の主張は、(本人にとっては)暗黙の以下の前提がある。
この前提のどれかに無理があることを直感的に示さない限り、この対話は終わらない。
・プログラムの変更点について話をしていても「でもさっき『サブルーチンはＡで』と○○さんにいわれた」と主張しつづける
・はじめに教えたことが変更になると混乱し、ためいきを大量に吐く
・はじめに教えたことを絶対だと思い込んでしまう
・プログラムの仕事は実は出来ない（バグはチーム内で直している）
・自分の開発案件以外のチームが慌てはじめると、なぜか自分も慌てなければならないと思い込む
・前の会議で「次回の会議は無し」とメモを取っているはずなのに、次回の会議が無いことを「僕、聞いていないんですが」という
・話し始めると意外と長く、同じ話を繰り返すことがある
・プライドが高く承認欲求があるようにもみえるが、自己卑下する発言もある
・普段、異常におどおどしている
・声が極端に小さく、声が大きい人を恐れる
こういった人と楽しく働く方法を教えてもらえませんか。
