「サブルーチン」を含む日記 RSS

はてなキーワード: サブルーチンとは

2016-09-06

手続き型で代入ができる言語では、参照透過性があり副作用がないサブルーチンって存在しないんだろうか。

int sum (int n) {
  int i = 0;
  int result = 0;
  while (i <= n) {
    result += i;
    i += 1;
  }
  return result;
}

例えばこんなサブルーチンなら、ローカル変数のiとresultに再代入はするけど、同じ引数で毎回同じ結果になるし、ローカル変数以外には影響を与えない。

条件はおそらくこのくらいでいいはず。

こういうのがコンパイラIDEで検知できれば便利そうなんだけど。

2016-07-18

IT業界認定試験もっと重要視すべき

IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。

PHPプロジェクトPHP認定試験に受かってる奴しか使わないとか、MySQL資格もってないとテーブル設計やらせないしSQLも書かせないみたいな。

認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。

Java入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観から自分は実力あるとナチュラルに信じこんでるし。

VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールJavaに持ち込んで「全メソッドcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界

ダメ技術者が、年をとってるってだけで評価されて上にたってダメ技術者を育成するって負のループに入り込んでるから一定客観的基準評価する仕組みをもちこんで負のループを断ち切るべき。

2015-11-07

http://anond.hatelabo.jp/20151107014318

サブルーチンの行数は一画面に収まるようにすべしというのは、PC20行とか25行しか表示できなかった時代から言われてるけど、当時それを言ってた人たちは本当に実践してたのかね。

2015-09-20

オブジェクト指向はなぜダメなのか?

人類には難しすぎたから。

日本PG/SEの60万人のうち、オブジェクト指向らしいコードを書けるのは1割以下だと思うわ。

もっと少ないかも。

オブジェクト指向言語オブジェクト指向フレームワークを使っていても、クラスにどんどんメソッドやメンバ変数を追加していって、クラスの中で手続き型言語風にコーディングしてるだけだし。

まだ手続き型で、ちゃんと構造プログラミングしてればいいけど、一個のクラスにやたらとメンバ変数を作って、各メソッドから適当アクセスしてるから手続き型言語グローバル変数を多用したようなコードが量産されてるし。

普通人間には手続き型で「サブルーチンを使いなさい」「グローバル変数は多様しないように」と教育するくらいが限界だと思われ。それでも対応できるのは何割かしらんけど。

2015-08-19

僕のいつまで経っても初心者プログラミング

タイトル通り、ちょっとでも詳しい人なら情けなくなるレベルでさえそこに達するのに何年も掛かった。

何せ、本業どころか趣味ですらないし、たぶん一般的プログラマとは全然違う。

ともかく、レベル的にはがっかりするような話であることは最初にどうしても断っておきたい。

 

事の始まりは前職の会社就職した時のことである

非常に特殊仕事で、ある環境計測データ現場で測定し、それを持ち帰って取りまとめて分析して報告書を提出するのが主たる業務の会社であった。

世の中にはほんと色んな仕事があるもので、そんな業種があるなんて務めるまで聞いた事もなかっただけど、パソコンという文明機器に触れたのも僕はその会社が初めてだった。とても古い話でお前いったい何歳だ?みたいな。

 

なので、その最初に触れたPC-9801シリーズの型番は言わないが、勤め始めた時にその会社にあったHDDは外付けでSCSI接続されたものがたった一台あっただけ、とは言っておこう。

環境計測データを取り扱うのが主たる仕事からパソコンデータ処理出来なければ仕事にならない。

その計測機器基本的に、当時は計るだけであり、記録データと言えば、記録紙にペンで波形記録してくれるレコーダーや、分析値を印字出力してくれる分析器、あるいはまた磁気記録によるデータレコーダくらいしかなく、今みたいにパソコンどころかメモリーカードや、スマホデータ記録といった直接AD変換記録してくれるものなんてなかった。

・・・いや、あるにはあったけど、そのAD変換機器パソコンをつないで自家製プログラムで処理したりしていた。

とにかく、アナログ値をどうにかしてデジタル値に変換するのは、手入力やらプログラムやらで処理するほかはなかったから、それなりにプログラム技術をどうしても身につける必要があった。

 

一番最初に書いた、ちょっとはまともに動くプログラムとして憶えているのは、サインとかコサインみたいな計算をやってパソコン上で波形を構成し、その値を使ってXYペンプロッターで作図する、というものであった。

ペンプロッターなんて今でも生きているのをたまに見る事があるけど、今は普通にプリンタだよね。

でも当時は、プリンタで作図したものを打ち出すとかありえない世界だった。ドットインパクトプリンタ?くらいしかなかった。

感動したよ、実際には今とは比較にならないほど極超低速だけども、滅茶苦茶にウィンウィン素早く動くペンに感動したもんだ。

僕が書いたとおりに動く、と言う感動。

言語はN88-Basic

ペンプロッタをRS-232Cパソコンと繋いで、描画命令を送るとその通りに動く。

但し、プログラムバグがあると紙とペンのインクを無駄にする。

僕はそこからプログラムを書くという魅力に取り憑かれるようになり、その会社では在職期間中、多分数で言えば一番プログラムを多く書いたのではないかと思う。と言ったって小さなさなプログラムばかりだが。

なお、それから何年か経ち、レーザープリンタが導入されたけども、作図のやり方自体は変わらず、プリンタに直接描画命令を送って、みたいなやりかたをしてたよ。だって当時、レーザープリンタを買うと漏れなくコマンドマニュアルが付いてきた時代だったしね。

 

しかし、言うまでもないけど、DOS上で、いちいちエディタを使ってBasicソースコードを書き、保存してrunさせるという一連の手続きはとても面倒で、N88-Basicは行番号を行ラベル、GOSUB~RETURNという感じでのサブルーチン処理が出来たくらいで、例えば変数初期化を忘れて気付かずに同じ変数名でサブルーチンを使ってしまうと、最悪ハングアップしてどうしようもなくなり、リセットする羽目になること屡だった。

から自家製ブレークポイントと言うか、STOP命令ソースのあちこちに書いて、うまく行けばSTOPを削除するとかコメントアウトするとかは必須な当時だった。

 

そんなこんなで勤めてから半年くらいで確か社長マイクロソフトのQuickBasicを買ってきた時にはほんとに感激した。

構造Basicであることもさることながら、統合開発環境ほとんど全てやってしまえるってのが如何にすごい効率化を生むかを知った。

汎用サブモジュールを作ってしまえば、あとはそのソースファイルを読み込んで、引数与えてサブルーチンを読めば同じ記述を何度もこぴぺする必要から開放される。

あるいはもう、バイナリライブラリファイルにまとめて、クイックベーシック起動時にスイッチで読み込むバッチファイルとしてしまえば考える必要もない。

さらに、exe形式の実行ファイルも作れてしまい、特定の処理のためにいくつもそれ用に実行ファイルを作っておけば、プロンプトから一発で様々な処理が出来る様になった。

 

QuickBasic時代が一番多くのプログラムを書いたと思う。もちろん、数だけの話で行数や文字数ではないけれど。

しかしそれは、僕にとってのプログラミング世界を狭小なものにしてしまった。

ちっとも勉強しなかったと言えばそれまでだけども、僕はいまだにBasic言語しか使えない。

Cやらその他の言語を書けなくはないのだけど、Basic言語で先ず考えて、みたいな頭に出来上がってしまったみたいである。

 

いや実のところ、早いことBasic以外の言語も覚えたかったのだけど、その会社社長がそれを許さなかった。

一度、Pascalを使ったプログラムを書いた事があったのだけども、社内で僕以外の他の誰も触ることができないと言う理由で禁止されてしまった。

社長は元々FORTRANから始めた人で、BASICと非常に良く似ていると言う理由で、会社を立ち上げた時からBASIC一本やりだった。

彼はそもそもプログラムは書いたとしてもプログラミング技術にはあまり興味がない人で、とにかく仕事のために問題なく動きさえすればよく、言語などどうでも良かったのである

からプログラムスピードアップのためにC言語の導入を僕が進言した時には「それを覚える時間無駄」と取り合ってもらえなかった。

Windows時代になってVisualBasicが導入されてもそれは変わらなかった。

VisualBasic6.0にもなると、純粋オブジェクト指向ではないが、それなりにオブジェクト指向っぽいことは出来る様になっていたし、オブジェクトを扱う方が、サブルーチンコールだけに頼るやり方よりもずっと能率的だって事くらいは分かっていたので、僕はオブジェクト指向っぽくプログラムを書きたくて仕方がなかったのだけども、社長ユーザー定義変数を使うことすら許さない。

VisualBasicから最低限、フォームやらコマンドボタンを使う必要があるから、それらのプロパティメソッドなどを使わざるを得なくなっていたし、社長も使っていたのに、いざクラスを書こうとすると滅茶苦茶怒られた。

「一つ一つのプログラム会社資産であり君のものではない。別の人間保守できなければ、君がいなくなったらただのゴミだ」

というのが彼の口癖だった。

 

なので、構造プログラミングレベルで工夫するしかなく、それから数年後に辞めるまで、僕は構造プログラミング技術を磨き続けただけで進化は停止してしまったのである

Windows環境になり、VB5以降にもなると、プログラムはどんどん肥大化して行った。

DOS時代のようにメモリを気にする必要があまりなくなって行き、1つのプログラムで様々な事が出来る様になると、困った問題が1つ重くのしかかるようになって来た。

社長フローチャートを書かないと絶対に許さない。

どんな小さなプログラムでも業務上で使うものである限り、自分しか使わないユティリティーレベルのもの以外については、絶対フローチャートを提出し確認を貰う必要があった。

細かな変数やら関数やらのドキュメント仕様書は、ソースコード内に所定の様式コメントを書けばそれでオッケーだったが、小さなサブルーチンでさえもそれが存在する限り、細かくフローにしないとダメなのだった。

入社当時こそ、それが非常に勉強になったし、他人の書いたプログラム理解するのに役立ったのだけれども、慣れてくると煩わしくて仕方なかった。

だいいち、うちの会社プログラムを外部に売っているわけではない。

データ処理や分析など、業務に必要から作っているに過ぎない。

流石に、稀にある、ソフト設計自体重要意味を成す業務では、詳しい仕様書をまとめて、その仕様書を通して取引先とやり取りしたりしていたけども、そんなのは滅多にない話だったし、汎用プログラムでさえも、一回完成させたら、その中身を見ることなんか滅多になかった。

実際、不具合があったらフローチャートなんか見ずに、誰もが直接コードを叩いて直したりしていただけだし。

 

DOS時代の時は、そんなに大きなプログラムは書けなかったので、フローチャートもそんなに面倒ではなかったが(そもそも僕はめんどくさくなると業務自体を早く終わらせたいのでソースを完成させたあとにフローチャートを起こしていた)、VB時代になるとフローチャートがあまりにも複雑怪奇になって行き、そんなフローチャートを例え完璧に作っても、誰も読んで理解しようとは思わないくらいにさえなっていった。

僕以外の社員も実際困ってて、そのせいでみんな夜遅くまで残業するようになっていった。

社長はどうかというと、社長業が忙しくなり、自分プログラムする事は滅多になくなったし、あっても少しサブルーチン的なところを書いたりとか、大雑把なフロー書いて、実装社員に任せっきりだった。

但し、社員の作ったプログラムフローには絶対に目を通す人で、ソースコード自体はあまり見ないが、フローがしっかりしてないと何度でもダメ出しをし、社員社長のオッケーが出るまで何度も書き直さないといけない。

 

で、ある業務で、いつものようにプログラムを先に完成させてフローに起こし直していた時のことだった。

どーせソースコードなんか見ないだろう、と辻褄の合うようにだけフローを書き、実際のソースとはかなり違うフローチャートを提出し社長にオッケーを貰った。

ところが、その業務で追加の仕事が発生し、時間的に僕では無理で、社長が僕のプログラムを触るしかない状況になった。

フローとあまりに違うソースコード社長激怒し、しかしそれまでめんどくさいフロー起こしに鬱憤を貯めていた僕もその鬱憤を晴らすかのごとく、かなり暑くなって反論し返してしまい、もう少しで暴力沙汰になる手前まで口論して、それから数日後、僕は辞表を提出したのであった。

 

その会社を辞めてから、次の仕事は全く関連のない無関係な全く違う職種になり、パソコンこそ触るものプログラムなんか書くことはなくなってしまった。

DOS時代パソコン通信フリーソフトを二つほど作った事がある程度で、必要に迫られない限り、プログラミングをする人間ではない。

ただ、当時どうしても許されなかったオブジェクト指向だけはいつの日かチャレンジしてみたいなぁとは思っていた。

それで、あるとき思い立って、何度か仕事で生かせないかなぁと思い、エクセルVBAを使って、昔取った杵柄じゃないけども、こそこそプログラムを書くようになり、もしかしてオブジェクト指向的に書けばちっとは勉強になるかなぁとやってみたのではある。

しかし、大雑把な初歩的・概念的なことは知っていたけども、実際、オブジェクト指向プログラムしようとしても、構造プログラミングをあまりにもやりすぎたせいか、どーしてもオブジェクト指向的にならない。

歳を食ったせいもある。頭が新しいことを憶えたがらない。

クラス設計書であり、インスタンス実体である、とか言われても理屈こそ分かっても頭が理解を許さない。

フローチャートロジックばかりが頭に浮かんでしまい、インターフェース的な理解をしようとしない。

 

最近になってようやく、少しはまともなオブジェクト指向が身に付き始めたんだけどね。

ほんと、こんな歳になって、いったい何年掛かったのやらw

 

長々と、単に自分記憶を掘り出しただけの文章披露してみただけで、ごめんなさいです。では失礼。

2015-05-18

循環的複雑度ってさ

サイクロマチック複雑度とかいうやつ。

ソースコードの複雑さを表す指数で、これが高いソースコードバグが多いって言われてるの。

なにげにネットを見てたら、批判的な文章をみたわ。

サイクロマチックの発案者に直接、科学的根拠あるのかって聞いたら「実際に役にたってるから(根拠は)いいだろ」みたいな返事らしいのな。

しかソースが複雑だったらバグは増えるだろうけど、それならツールを使わないと算出できないような複雑な指数をつかわなくても「ネストは○段まで」「サブルーチンは短く」「サブルーチンローカル変数は○個まで」みたいな単純なやり方でもいいよな。

サイクロマチックでなくても、見た目が複雑なソースなら大きくなる指数適当でっち上げても「この指数バグの発生件数は相関関係がある」って言えそうだよな。

サイクロマチックを目にするとき普通に役に立つ指数だって紹介されてるから、ただのオカルトだって知ってショックだわ。

2015-02-23

「循環的複雑度」って

http://weekly.ascii.jp/elem/000/000/306/306175/

ニコニコ生放送」のコードに、循環的複雑度が600を超えるメソッドがたくさん入っていることが判明したことがあった。循環的複雑度が75を超えるとバグの混入確率は98%、「いかなる変更も誤修正を生む」状態になると言われていて、要はニコニコ生放送は動いてるのが不思議なくらいバグがめちゃくちゃ出やすい状態だった。

循環的複雑度って科学的なメトリックスだと思ってる人がいっぱいいるけど、あれ根拠ないからな。はっきり言ってオカルト

分岐とかループが多い処理はバグやすいってだけ。

サブルーチンのなかにif文は何個以下とかネストの深さは何個とか、もっと単純な基準で「循環的複雑度がxx以下」と同じ効果をだせるはず。

2015-02-11

関数型とオブジェクト指向って……

毛の壁以降、色んなところであーだこーだ再定義言われてるけど、結局名前が悪いんだよなぁ。

どちらかというとオブジェクト指向の方が「何もかもサブルーチン(ただし値を覚えていてくれるおまけつき)」で、関数型の方が「何もかもが値(関数も)」なんだけど、まず名前からだと逆っぽく聞こえる。

加えて、この二つの概念が対立すると思われてしまうけれど、んなこたーないのはjavascript見れば分かる。何もかも値かつサブルーチン、でOK。

両立しにくいのは、オブジェクト概念高階関数概念ではなく、オブジェクト指向言語採用してきた型システムと、関数型言語採用してきた型システムだ。

まりC++やらJavaやらが採用してきたサブタイプ多相をベースにしたクラスによる型付けと、ML言語採用してきた代数データ型が噛み合わない。致命的に。

いやまぁScalaは頑張って統合したけど、コンパイル遅いわ書き方次第で型チェックが無限ループになるわで、色々と無茶しやがって感ある。

これからは「サブタイプ多相言語」と「代数データ言語」って分けて呼ぶべきなんじゃないか?

2014-05-22

またrebuild.fmJavaの悪口で盛り上がってたよ

http://rebuild.fm/44/

 Androidアプリ作ろうとしてJavaプログラマ募集したらクズしかこなかった全部クズだったとか、ひどくありません?

 まあそれは置いといて、UIみたいに最初から仕様を決められなくて何度も作り直すようなコードJavaは不向きみたいな話もまったく同意できないわ。

JavaじゃなくてC#だけど、昨日コードを書いていて

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) {}と修正したら修正漏れの箇所があってもエラーが伝播して言って、すぐ分かります

 OracleGoogle裁判がらみで「Java終了よかったよかった」みたいな話の流れで、AndroidアプリJavascriptで作ればいいって盛り上がってたけど、そうなったらIDEサポートが大幅になくなる原始的環境に逆戻りでしょ。

勘弁して欲しい。

ほんとうに動的型の言語はめんどくさい。

2014-02-16

古いプログラムの書き直しをしたいけど

研究室で使っているFortran77のプログラム

配属されてからいろんな機能を追加してきた。中規模くらいのプログラムで、研究ではメインで使っている。

でもだんだんつらくなってきた。とにかく見づらい。

1980年代に作られたこのプログラムは今までの人たちのコメントの蓄積が半端ない

プログラム書き換えでとりあえずとっておいたコードコメント、書き換えた日時と人が書いてあるコメントプログラム中に混在している。

これらは実際に動く部分のコードよりも多く、可読性をかなり下げている。

前者については、ほとんどが不要だと思うのだがあまり考えずに消すと将来困るかもしれないのでちゃんと確認して消したい。

そして未だに残るGOTO文とFORMAT文と文番号。implicit noneではない暗黙の型宣言。

Fortran入門: 知識として必要な過去のFortran このページに書いてあるほぼすべてが詰まってる。

COMMON文もほぼすべてのサブルーチンにあったが、これはなんとかmoduleに書き換えた。

moduleに書き換えたとはいえ、本来は引数で渡したほうが適切なもの機械的にCOMMONからmodule文に書き換えたためその辺も見直したい。

一番面倒なのが一行の文字数制限。何段かのインデントを入れるとすぐにアウト。

エディタ使ってると自動でインデント入れてくれるのでいちいち直すのも面倒だし、インデント好きなのでできればインデント入れたい。

エディタといえばシンタックスハイライトfortran77モードだとうまく表示できないことが多い。

allocatableとかmodule文なんかは厳密に言えばfortran90以降の機能だけどコンパイラ対応してくれているおかげで使える。

でもエディタシンタックスハイライトにはそういうコンパイラが気を利かせたような実装は含めないのでうまく表示されない。

fortran90モードを使うと今度は行頭カラムの空白が守られなかったりしてコンパイルエラー

すっげー書き換えたい。全部きれいにしたい。他言語にするとあまりにも変わりすぎて教授が混乱するからせめてFortran90にしたい。

でもさ、よく考えるとこの書き換えって全く自分の実績にならないんだよね。

そもそも今までプログラム改良して出来る計算の幅をだいぶ広げたけど、それ自体は発表できないからほぼ表に出ない。

計算結果を出してそれを発表しないと表面的にはまったく意味が無い。

ましてやプログラム保守作業であるこの書き換えは計算結果に影響をおよぼすものでもないから研究成果にはまったく現れない。

しかプログラム書き換えた自分だけじゃなく、みんなも使うから書き換えた自分特別得するわけでもない。

プログラムすべてのコードを書き換えるのは単純に機械的にやっても結構時間がかかるし、書き換えても一発では絶対にうまく動かないから修正にも時間がかかる。

研究者の中にはそういうプログラム書いてばかりの人間馬鹿にする人もいる。プログラムを書いてる研究者自分の分野ではかなりヒエラルキーは低い。

情報系でもないんだし、それが研究の本筋じゃないからというのはわかる。自分たちのやるべきことじゃない。(でも専門性の高い道具を作り、整備する技術・人も必要なんじゃないかなと思ったりもする。)

やってもあまり得しないし他のことやったほうが絶対に自分の将来を助けるけど、ほっとくのもなんだかなあと悶々としている。

多分きれい好きの人が自分の部屋を見たら同じ苦悩を抱えると思う。

2013-12-24

東大に行った友人が使えなさすぎでヤバい

高校時代からの友人で、東大に行った奴がいるのだが落ちぶれすぎていて痛い。

昔は勉強ができたのに、どうしてこうなったんだか。

思えば入学すぐのゴールデンウィークあたりからもうおかしかった。

大学自分勉強する所とか言って講義にもろくに出てないとか、教授や先輩がいかにバカかを熱弁していた。

2年目の夏ぐらいか2ちゃんねるまとめを自動生成するシステムを作るとか言い出していろいろやっていた。

β版発表会とか言って、仲間内を集めてお披露目会をしていたが、ただのPHPを使った動的ウェブページで、

ソースを見たらオブジェクト指向はおろかサブルーチン呼び出しすらろくに理解していないようなウンコードだった。

これじゃスパゲッティになって開発続かないだろと思ったからそう指摘したら、

そんなもの俺には必要ない、お前らとは頭の出来が違うの一点張り

文系に行った奴らはだまされてたみたいだが、プログラミングが分かる仲間はみんな(^^;)って顔になってた。

結局完成しなかったらしい。

この間久しぶりに会って、就活勉強の話になったらもうひどいのなんの。

そいつIT系なのに、流行りの技術はおろか、基本的な知識もない。

だけどプライドだけは高くて分からないと言えないらしく、

関数型言語勉強していると言ったら時代アセンブラだと言い返したり、

じゃあアセンブラでどんな開発したのと聞けば、なぜか古文の助動詞複素平面の話になっていた。

古文は分からないけど、複素関数なら習ったかコーシーリーマン関係式の話でもしようとしたら、

遮って東大過去問の、数学的には低級な話にもっていって、最終的には俺の知識の無さについての話になった。

それを聞いて、あぁ、こいつはダメになってしまったんだな、と思った。

所詮高校までの勉強が俺よりマシな程度にできるだけだったというのに。

信頼とか友人らしい感情はもはや無い。

ちゃんと進級できてるのかどうかも分からないが、仮に就活しているとして、まともに就活できるんだろうか。

多分学歴を盾にそこそこいいとこ入っていくんだろうけど、就職浪人でもしたら友人やめると思う。

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。

例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。

このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)

目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。

もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。

今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。


そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。


できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。

それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである

正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。

プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。

1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ

ただし以下のことは出来ない。

・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない

2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している

ただし以下に当てはまる。

自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない

3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる

全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。

前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。


初心者レベルの人に向けて

完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。

検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経

上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである

プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。

それなのに、なぜいつまで経っても書けないのか?

それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである

特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。

プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。

もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。

それには以下の点を意識してプログラミングすればよい。

・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること

このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。

1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す

まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである


これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。


関数メソッドをたくさん覚えなければいけない

無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事

エラーがいっぱい出てつらい

全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要

写経をしなければならない

教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。

なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。

写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。

また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである

とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。

さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。

1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである

初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。

しかし、それでよいのだ。

エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。

おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。

プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。

自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。

それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。

そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。

2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である

僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである

初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである

ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。

からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。

例を挙げると、

C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug

言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。


3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。

そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。

そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。

一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。

ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。

"Small is Beautiful"

これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。

まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。


4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。

おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。




現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。

でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。

そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。





2013-03-02

からプログラマ馬鹿ばっかだとか空気読めないとか言われるんだよ

一部で話題になってるこれだけど、投稿件数100越えてる割には、他のネット論争と比べて比較コメントが読みやすい。これについては、投稿してくる人も d:id:perlcodesample も余計なノイズ一言を入れずに投稿してくれているからだと思う。見習いたい。

にもかかわらず、ここを読まないでトラバ突っ込みを入れてくる奴は馬鹿ばっかりだから話は全然収束しないし。トラバ投げる奴は、ただ自分が気持ち良いエントリを書きました、って話しかしてない。

d:id:perlcodesample は「perlだとスカラーも各種リファレンスも全部 my $var って書くだけで受けることができる! 楽!」って話しかしてない。(そこから派生する色んな"利点"については「お前がそう思うんならそうなんだろう、お前ん中ではな」レベル主観だらけなので"インデントをスペースにするかタブにするか論争"のように対話しても万人に納得のいく結論は出ない)

そう言う話に「そんなことをしてると(あらかじめコンパイル時にチェックが入らないから)後から大変なことになるぞ!」ってツッコミが入り、それに対して「後から大変ってどういうことですか? どうせ全部テストするんですから(コンパイルを行った時点である)最初から大変なのも、(プログラムテスト実行した)後から大変なのも、大変度合いの総和は大して変わらないでしょう?」というあたりで止まっている。

この d:id:perlcodesample の主張は、(本人にとっては)暗黙の以下の前提がある。

  1. (perlで言う)すべてのモジュールにある全サブルーチンに対して、全パターン自動ユニットテストが用意されている(されるべき)
  2. モジュール間の結合試験についても、全パターン自動ユニットテストが用意されている(されるべき)
  3. コンパイル時のエラー検出&修正コスト」と「(コンパイルエラーにならないため発生する)ユニットテスト実行時に検出されるエラー&修正コスト」はほとんど等しい。
  4. プログラム品質保証する根拠のほとんどすべてはテストである

この前提のどれかに無理があることを直感的に示さない限り、この対話は終わらない。

2012-07-06

http://anond.hatelabo.jp/20120706000349

コメントありがとうございます

プログラム仕事は実は出来ない(バグはチーム内で直している)

いじめ

いいえ、チーム内のだれもいじめてないのですが。

納期を逆算して、影響が最小限になるよう、とりあえずのサブルーチン群は作ってもらい、「最終チェックするからね」といって修正しています

  

・たまに、突然カバン雑誌を机の上に叩きつけるように置く

毎回ならともかく、たまに 大きな音を立てる・・・小姑か?

普段音を立てない事、そういう置き方をする人がチーム内には居ないので目立つのです。

  

たんに、坊主悪ければ袈裟まで憎い に見える。

もしそうだとしたら、どうしたら楽しく仕事が出来るようになるのでしょうか?

  

どなたかアイディアをいただけませんか。

2012-07-05

プログラマーの特性?じゃないよね?

プログラムの変更点について話をしていても「でもさっき『サブルーチンはAで』と○○さんにいわれた」と主張しつづける

・使えるプログラム言語を増やそうとしてくれない

・はじめに教えたことが変更になると混乱し、ためいきを大量に吐く

・はじめに教えたことを絶対だと思い込んでしま

プログラム仕事は実は出来ない(バグはチーム内で直している)

自分の開発案件以外のチームが慌てはじめると、なぜか自分も慌てなければならないと思い込む

・前の会議で「次回の会議は無し」とメモを取っているはずなのに、次回の会議が無いことを「僕、聞いていないんですが」という

雑談仕事の話をしていると、横から突然自分の話をしだす

・会話がまともに通じるときと、思いっきりズレるときがある

・話し始めると意外と長く、同じ話を繰り返すことがある

プライドが高く承認欲求があるようにもみえるが、自己卑下する発言もある

・たまに、突然カバン雑誌を机の上に叩きつけるように置く

・普段、異常におどおどしている

・声が極端に小さく、声が大きい人を恐れる

  

こういった人と楽しく働く方法を教えてもらえませんか。

2011-10-18

VB.NET : My.Settings 登録は、対象にする Frameworkバージョンを切り替えた後ですべし

4.0 対象の状態(つまりプロジェクト作成した初期状態)のまま

My.Settings (設定)を登録したあとで 2.0 対象に切り替えると、

デバッグ時に、ハンドルもされず、アプリ異常終了もしない、

サブルーチンの途中でこっそり抜けたりする不可解な動きをする。

My.Settings の登録を全部消して、登録をやりなおしたら復活した。

App.Configのどこかを直接いじっても対処できそうだけどね。


VB.NET EXPRESS 万歳

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん