- ねこのこべや -
- ねこのこべや -
まぁ、猫の毒トークはココまでにしておいて、 このライターさんは、どうやら怒りにまかせて 本文を書いたらしく、この記事、なんのやくにもたたない ものと成りはてています。
そこで猫が、一つ一つの議題に対して、 ちょちょっと雑文を書くという、 猛烈な嫌みをしてみようかと思います。
くふふふふ。
※ 以下、非常に毒々しい文章が並びます。ご注意ください。
補足：猫は相手と同じ土俵で泥仕合するのが大好きな暗黒面を持っています。
補足2：このドキュメントのテーマは「売り言葉に買い言葉」です。 本文は猫と宮坂氏が掲示板で泥仕合を繰り広げているものとご想像ください。
補足3:したがって「技術的論議」より「宮坂氏をやり込めること」に 注力しているため、熱中のあまり技術的論拠が偏っている可能性があります。ご注意ください。
ここら辺まではまだ公平に近いかもしれませんが、 宮坂氏は必ずfreeしたい派で、しない方は機種依存実装がお好き、 と皮肉っているようにもとれる微妙な表現。
free論争は古典的な論争で、 goto文論文を下らないと斬って捨てる宮坂氏が なぜに取り上げているか理解に苦しみます。
要するに
という、ポリシー論なので、 双方とも一理あり。大切なのはつらぬくことではないでしょうか。 と、いうのが猫の見解です。
どうやら、宮坂氏はJavaが好きなので、Javaを批判されるのが嫌いな様子。
一応「ポインタ」の定義により答えは異なる。という 正論を導き出しているのですが、節々に「Javaの参照をポインタというやつは ダメダメです。」と言いたげな文章で、 読む人の神経を上手に逆なでする様は見事。
猫的にはこういう「正論調トゲトゲ文章」こそが、 メーリングリストや掲示板を荒れさせる最大の原因だと思うのですが、 彼の宮坂氏はそこらへんの理解が出来ていない様子。 人間、バカに小馬鹿にされると腹の立つもんです。
また、自分の好きな結論を得たいため、議論の掘り下げを意図的に(無意識に)避けている ようなところも見受けられます。 「定義が重要」としながら、「ポインタとはなにか」という考察に 足を踏み込まないあたり、「Javaが好き、批判しないで」という 某氏の好みに大きく左右されているのではないでしょうか?
話しが思いっきり毒方向に流されてしまいましたが、 結局この「ポインタ」論争も古典的で、 「"いわゆる"ポインタ」問題というやつです。
この論議の問題は、「Javaで言うポインタの定義とは?」なんていう低レベルな問題ではなく、 「本質的な意味でのポインタとは何か、 その本質的な意味でのポインタに、Javaの参照は当たるのか、 そして、CのポインタとJavaの参照の違いは何か」 ではないでしょうか?
ポインタのパイオニアのCでは、ポインタを以下のように位置づけています。
変数の中に実体の位置を指し示す値を保持し、 この変数を通して実体を操作する仕組み
です。(だから、pointerなのです)
この変数に演算機能をつけるか否かは、それぞれの言語のポリシでしかなく、 ポインタそのものの定義にとっては演算できるかどうかなんて、 どうでもよいものです。
ところがCでは強力かつ難解なポインタ演算のイメージが強いため、 "いわゆる"ポインタ というイメージ、
変数の中にアドレスが入っている。 変数の中のアドレスは自由に演算できる
が強いのが問題です。
結論からいうと、Cが本来定義する意味での「ポインタ」でいうなら Javaはポインタを持っていると言えるでしょうし、 "いわゆる"ポインタであるなら、Javaはポインタを持っていないでしょう。
こうなると「"いわゆる"ポインタ」の難解なイメージを持ち込みたくないSun側が 意図的にポインタを言う用語を正確な意味で取り扱うのをやめた、 という批判が成り立つとは思いますが、そうは簡単にいかないのがこの問題の 厄介なところでして。
C++という言語は、ポインタ演算を制限したポインタを実装しているのですが、 これを「参照」と呼んでいます。 これは純粋に「ポインタ」が既にあるシステムで 同じ名前にできなかったというだけなのですが、 Javaのポインタは、C++のポインタよりはC++の参照に似ているため、「参照」という名前を つかったのも肯けるのは確かです。
現状ではC++が呼び始めた(多分)「ポインタ演算の無いポインタ」=「参照」ですが、 Javaが「参照」という用語を採用したのが決定打になって、「ポインタ」と言うときは 十中八九「"いわゆる"ポインタ」で使われるようになりました。 (・・と猫は理解しています。)
ちょうど「ホームページ」という用語のような運命を辿った「ポインタ」ですが、 この歴史を持って、
のどちらの結論も導きだせる、・・というところまで触れて欲しかったです。 「定義が違うのに、定義もせずに議論する輩の頭はおかしい」という文章よりも よっぽど身になると思うのですが。
「ポインタである派」の意見として「NullPointerException」を持ち上げてるのは 幼稚と言う論法、理解不能です。 彼の某は 実装だ、観念だと言っていますが、
実装者が観念的にポインタでないと するならば、「ヌルポインタ例外」じゃなくって「実体のないオブジェクト参照例外」という 名前を付ければ良いんじゃない?
という意味だったと思われます。
つまりこの例外を取り上げた方は、 「すくなくともSunの実装者は参照とポインタは一緒と考えてるのでは?」という 論拠として挙げたと思われますから、これを「幼稚」と切り捨てるのは如何なものかしら。
この件については某氏の言っていることにそれほど異論がないのですが、 どうもネチコラしてる文章で、しかも「俺様は両方経験してるんだよ〜ん」な 物言いが鼻につきます。・・・この人ライタとして向いてないのじゃないかしら。
さて、この問題も一応三猫風に解説しますが、 某氏と大差のない結論しかでません。
前提として「RADは○○するのに良いものだ」の○○を定義しないと、 議論が広くなりすぎます。 まず、ここに「教育」を入れて見ます。
客観的に考察すると、RADのよさは「全体を知らなくても開発できる」ことにあります。
GUIベースのソフト開発はとてもコードベースで開発できる物理量でないため、 RADに頼るしかありませんし、初心者にGUIを実現するコードを勉強せよ、 と強要してもなかなか興味がわかないのが現実でしょう。
しかし、RADを使うと「ツールの使い方」に終始してしまう弊害もあるため、 スタートはRADで良くても いつかはRAD以外の開発手法を勉強したほうが良い という意見に異論は無いはずです。
一方RADを使わない開発においては、やはり大きいのは 「システムの全体や基本を理解しやすい」ことです。
しかし、初心者向けの練習のインターフェイスとしてGUIをつかうには、 コードベースはあまりにも手間とスキルがかかりすぎ。 どうしてもコマンドラインアプリの作成になりますが、 最近の新人さんは、DOSを知らない世代なので、プログラム教育の前に コマンドラインの教育をしなくてはならないのが現代プログラミング事情の頭の痛いところです。
原理から入るか、応用から入るかは、 教育論のガチンコ勝負であるため、ハッキリいって結論は出ません。 でも、どちらから入っても最終的に両方を理解する必要があるということだけは 変わらないです。
ちなみに○○に「開発」をいれた場合は、「RADは適材適所で使いましょう。」としか いえません。所詮ツールですので、「 使う」に固執するのも「使わない」に固執するのも論理的思考とはいえません。 要は開発コストの問題に帰結するからです。
これに関しては、某氏の主張は「メッセージとすべき」です。 しかも見解自身が「関数コールと呼ぶのは良くない」派の 典型的な意見であって、双方を検証した結果ではありません。
たまに、わかりやすくするために実装結果だけをポンと提示するだけで、 難しい概念を説明しているように錯覚させている例があります。
の下りは確信犯です。
まず、この命題のまずいところは 「教育の場で、メッセージ送信を関数コールと教えることは良いことか」 という命題であるはずのものを、 「関数コールとメッセージ送信は厳密に同じものか」 に置き換えているところにあります。
これは、十中八九 「NO!」と答えたい某氏が設問誘導を行ったとみて良いでしょう。 なぜなら、「メッセージコールは関数コールだ」と唱える人間は 誰もが「厳密に同じと言う意味ではないが、こちらのほうが分かりやすいから」という 理由で唱えているのが明らかだからです。
この議論の前提として、 OO指向の「メッセージ」という概念が非常に直感しにくい現実があります。
特に、OOでないプログラム言語のユーザの場合、スレッド間通信のような機構を 言語レベルで備えているように錯覚する方が多いです。 そういう人を対象に「メッセージ」とは「関数呼び出し」だ、と 説明することは間違いとは思えません。
つまり、概念と実装の2層を理解している「現役プログラマ」に対して、 実装をポンと表示することは理解を助けることになるからです。
OOを操るプログラマは、「メッセージ送信」という概念と、 それをしばしば「メンバメソッドのコール」として実装するということの 両方を理解する必要があります。
この議論はあくまで、OOの初期教育時に不正確だけど分かりやすい「実装の現実」を見せるか、 あくまで正確だけど理解しにくい「概念」で押し切るかの問題でしかありません。
「最初から正しいことを教えないとあとで間違えたままになる」も正論ですし、 「あくまで正しいにこだわると、理解できない脱落者を出してしまう」というのも正論です。
要は、ここまで議論のフェーズを進めておいて、 「ならば、双方のメリットを生かしデメリットを相殺するような 効率的な教育法は何か?」に議論の焦点をシフトさせるのが 正しい論理的思考というべきでしょう。
某氏の出した見解はOOを愛するがゆえに生じた「反対したい」という感情に誘導された 見当違いの見解であり掲示板等を「荒らす」発言以外のなにものでもありません。
こういう議論を扱いながらなぜかに 「インターフェイス」にまったく触れられていません。はっきりいって信じられないことです。
「インターフェイス」は「制限付き多重継承」とでもいうもので、 「多重継承」の問題点を解決しながら、利点を得ようとする一つの解です。
「多重継承」がOOP版の「goto文」という意見は的を射ていて、
と、メリット･デメリットがほとんど一致します。
なので結論をえる論法も一致していて、
となります。
面白いことに某氏の結論はgoto文と多重継承では一致しておらず、 某氏の思考形態が論理的一貫性に欠けるのでは?と思ってしまいます。 (これは言いすぎで、単に多重継承が「オブジェクト版goto文」となぜ言われるかを 検討してないだけなのかもしれません) なんだかこの方、初めに結論ありきで論理を用意してる節があるのよね〜。
問題外です。某氏は、「自分の会社はスキルが低いから、 どうせ頑張っても無駄です」といっています。 雑誌で愚痴をいってどうなるというのでしょうか。理解に苦しみます。
この問題は、
動いているコードを無断で書き直した
という設問自身が、「書き直すのは良くない」という結論を導くために用意されたと見るべきでしょう。
本質的には、開発工程において開発者は現状ソースを解析し、 再構築に必要があると認められた場合ソースの書き直しを行うと 将来にわたってコスト削減になるとの提案を上司にし、認められれば実行する。 それだけの話です。
ソフトウェアを保守するには、リファクタリングは必須です。 ただし、リファクタリングはその前と後にテストを行う必要があるため、 コストの面でできないケースが多いのが現実です。
リファクタリングにより十分なコスト削減が見込めるなら、それは行うべきでしょう。 それが認められない会社は「論理的経営が出来ない」というだけの話で、 本問題とは切り離して考えるべきです。
では、十分なコスト効果が得られないがリファクタリングすべきか、については プログラマの矜持と、会社組織の一員としての責任の板ばさみなので、 ケースバイケースです。
某氏の持って回ったいいようは、愚痴とちゃんとした開発が出来ない自分へ 「環境が悪いんだい」と言い訳しているだけです。出来ない事情は某氏のせいではないし、 某氏の「しない」という行動が無責任とはおもいませんが、 「したほうが良いが出来ないことが多い」だけのことに、どうしてこうも言い訳がましくなるのでしょう。
猫は某氏を「負けたくない人」と認定します。
猫的にはこのタイトルはずるいと思ってます。
正確には、
オブジェクト指向を取ると再利用性が高まるといわれているが、本当か?
とすべきです。本文中でも「オブジェクト指向と再利用を切り離して云々」と書いているとおり、 これもOOを偏愛する某氏の論理誘導です。
この「オブジェクト指向」を「構造化プログラミング」に置き換えると 20年くらい前に議論された内容となるのはご愛嬌。
結論は、「オブジェクト指向を使うと、再利用性の高いソースを書くことが可能になる。」と、 「オブジェクト指向を使うと、再利用性が高い」はイコールではない、 というだけの話です。
この議題はあくまで「オブジェクト指向が」が重要なのです。 なぜなら日経某などでは、「オブジェクト指向は再利用性がたかい」などと 技術をあおることが多いため、これは幻想である、という技術者がいた、 という背景に基づいた議題であると思われるからです。
しかし、某氏の見解文には「幼稚」だ「詐欺」だと言う発言が飛び交うのですが、 この方は冷静に議題を進めるような文章を書く能力が欠如しているのか、 よっぽど頭に血が上った状態で書いたのか。(^^;
これは凄い。もう言いたい放題です。
しかし「情報処理資格は必要か」と尋ねる人はそもそも必要なのか不要なのか判断がつかず、 プログラマとしての実力が未知数であるか低い段階でしょう。
それらのいずれかに有利にならないのでは、資格は単なる紙切れに過ぎません。 筆者の場合、仕事を得るときに有効に働いたのは実績と経験だけです。
猫も「資格は役に立たない」というの意見には同意なのですが、 この書き様は凄い、と関心してしまいました。
補足するなら「経験」と「実績」を得るには、まずプロのプログラマとして就職すること が必要になるのですが、 その就職に資格の取得は有利に働くかという話であり、 某氏の主張は堂々巡りにはまるスタート地点になるだけだと思うのですが。
猫の結論は役に立つ状況が思い浮かばない、というのが正直なところ だからこそ「役に立つ」という主張の方と議論を交わし、 見解を広めたいと考えるわけです。
某氏全般に言えるのですが、彼はどうも持論を変えるつもりもなく 議論に参加しているわけです。(某氏は他人の意見よりも自分の経験を 絶対視していて、その普遍的論理を布教するために議論に参加するタイプと見ました。)
しかし議論とは、持論に変化をもたらし より高い次元の論理を得るための 手続きだと猫は考えます。
これに関してはめずらしく面白く読むことが出来ました。 ただし、細かい揚げ足とりになりますが、以下の二点は突っ込ませていただきます。
35歳定年説は本当だったと結論付けるもデマと結論付けるも個人によってかわってきます。 そういう意味ではデマと結論づけてもよいでしょう。
タイトルが「35歳定年説はデマか」ならわかるものの なぜデマと結論づけるのか。 ・・ねぇなぜなの?
もう一点ですが「35歳定年説」の論拠から 「年をとると頭が固くなるので、新技術についていけなくなる」という ものを落とすのは、片手落ちです。
35歳を超える覚悟は、この硬くなる頭と古くなる知識の前で、 どのようにして若者以上の付加価値を年老いた自分に存在させるか の戦いであります。
決して不可能ではないですが、容易な道でもありません。
ちなみに某氏は生涯現役を貫く覚悟だけども、 収入が低いことに社会的不満を持っている様子。 ほんと解りやすすぎて ほほえましいです。(ほほえましいを通りすごして憎さ100倍?)
これは文章を書いているうちに某氏自身がなにがなんだか分からなくなってしまったのでは?
だって、最初にと言っているのに、
筆者はC言語とJavaの両方を取得することをお勧めします。
なんて、言っているわけですが、 答えになっていないのは明白です。 どうも「プログラマは複数言語を覚えるべきか」とか 「何か一つだけ覚えるならどれがいいか」と混同されてしまった様子。
こうなると議論もへったくれもないと思うのですが。
本題に戻るとタイトルと矛盾しているのですが、 どうも「最初の言語として、Cが良いのか」 という議題の様子。
全体的にこの設問は意味が二転三転するので、 崩壊してるとしか言いようがないです。
「最初はCが良いか」だと、次の設問「Cの上達にはアセンブリ言語の理解が必要か」 と被ってしまう感じなので、猫の見解はまとめて答えようと 思います。
とはいえ、某氏は本議題では自分の経歴を紹介して持論の肉付けをしているのですが、 結局「俺様経験に基づく見解は一つの究極である」と言いたいだけですので、 何を考えて記事にしているのやら。不快のきわみですし、その肉付けには何の意味もないことを 理解できていないことが情けない。
論理的にJava とCの併学が良いと説明するのを放棄して、 「自分はBASIC、PASCAL、アセンブリ言語、Fortranなども習得してきている。その経験上導き出したのだ」では、 一体誰が納得すると思っているのやら。
とても正気の沙汰とは思えないのですが、 掲示板での泥仕合でもした後に書いたとかでそもそも正気では書いていないのかもしれません。
ちなみに「最初の言語」論争では、 「最終的には複数言語を習得するのを前提として」、最初はなにがとっつきやすく、 他の言語に展開しやすいか、を論じるべきだと思うのですが・・・。
「アセンブリマニアはCの抽象概念が理解できないものがいる」 という風に主張していますが、これも意図的な論理誘導でしょう。
アセンブリ言語を習得することは、Cの実装を想像しやすいため、 理解の助けになるというのは事実です。
しかし、必須かといわれると「別に知らなくても覚える術はある」ということなのですが、 某氏は「必要ない」という結論を導くために、「ダメなアセンブラ屋さん」という、 極論を持ち出して説明しようとするあたり、なっていません。
どうも某氏は、自分の結論のためには「論拠として極論」 「前提条件を意図的に編算」することが得意技のようです。 わざと額面どおり受け取ったり、適切な誘導、時には拡大解釈することで 持論が結論になるように誘導されては、議論もへったくれもありません。
某氏の「この手の議論はけんかになる」発言は、某氏自身に問題があるのではと やっかみたくなります。
さて、この手の問題は教育をどういう順序で行うと覚えやすいかという議題です。
一つの考え方は「個体発生は系統発生を繰り返す」的パラダイム。 歴史的なプログラム言語、プログラム手法の進化を辿って学習する方法です。
二つ目の考え方は「現在あるものをあるがままに」的パラダイム。 抽象的であやふやなものはあえて そのまま「そういうものだ」と覚えさせることで、 最小の学習量で最大の効果を狙います。
最後は「原理原則」的考え方。 要するにボトムアップで学習すると、あやふやな理解はないという考え方。 技術はボトムアップ的進化を辿ることが多いため、しばしば一つ目と同じ道になります。
「Cにアセンブリ」や「初めはC」は一つ目または三つ目の教育方針を採用するということ。
「抽象概念」を上手くあやつれないのはプログラマとしては問題ですが、 しかし「抽象概念」と「あやふやな理解」は違うものの、教育初期では 「あやふやな理解」になりやすいのは現実で・・・と、 まさにあなたのアバタは私のエクボ状態。メリット・デメリットが背中合わせなため、 議論の種は付きません。
ゆえに個人的見解に帰結せざるを得ないのですが、 猫的にはプロになるなら原理原則型を支持します。 学習量が膨大になるデメリットはあるものの、プロならそれくらいこなしてよ、と思うからです。 逆にアマチュアプログラマでいいや、という方にこの方法を押し付ける気はありません。
なんだかいろいろありますが、切って捨てた論拠がわかりません。 ただ、本特集では某氏は決して議論を「上手く纏める」ことに成功しておらず、 むしろ自分の言いたいことを言っただけです。
なので、「OOPは本当に楽になるのか」という設問を「筆者の力量では上手くまとめられない」との 理由で見送ったのは、持論に誘導できなかったのでやめましたと 勘ぐってしまいます。
また「Javaにテンプレートは必要か」は既にテンプレートを実装する方向に動いているから論議が無意味 としています。そういう割り切りも個人としてはアリですが、 多数派の意見または時流で押し切るというのは、雑誌に載せる・載せないの規準とするには独善的です。
goto文論争は
これはカビが生えているというか今さら蒸し返すのもバカバカしくなる古典的論争です。 いまどきgotoがよいか悪いかを論じるのは時間のムダであるだけでなく、もっと論争すべき 大事なテーマがあるので労力のムダですらあります。
とおっしゃっていますが、きっと宮坂様の頭にカビがお生えになっているのかと思われます。 だって、他の古典的論争は引っ張り出すのに、これだけ「古典的」という理由でお蔵入りにしてますし、 その古典的帰着点とは違う持論を結論を引っ張ってくる辺り、お顔の皮が真菌に侵されているほど厚いとしか いいようがありません。
というか、どうしてこの方はこうもトゲトゲしい文章しか書けないのでしょうね。(^^;
ちなみにgoto文論争は、
構造化プログラミングを使うとスパゲティソースから開放される。 その手段としてgoto文を使わずに 3大構造でプログラムを表記する方法が提唱されているが、 ある一部の条件では返ってgoto文を使ったほうが構造化されたソースが記述できるのではないか。
というところまで掘り下げる必要があります。
で、これらの「goto文を使ったほうが良いパターン」は、 制限付きgoto文として言語に実装されて今に至っています。 「continue」や「return」、「try-catch」などの制限付きgoto文はダイクストラが提唱する 三大構造の何れにも該当しませんが、構造化プログラミングの一部として受け入れられています。
これらに触れず「現代では事実上goto文は死んだ」という某氏は 頭の中がお亡くなりになっているか、興奮のあまり仮死状態になられているのでしょう。
結論として、
といえるでしょう。
論議とは、「相手を認めること」「持論と、自分の思考を切り離すこと」 「自分がどのように語ると相手がどのように感じるかを常に考えること」 のいずれが欠けても成り立ちません。
しばしば、相手よりも自分が正しいという妄執にとらわれて論議の渦に参加する人が みられますが、これは結局「荒らし」でしかありません。
メーリングリストでも、掲示板でも有意義な論議というのはいくらでも発見できるに関わらず、 宮坂氏が、
というのも、議論と称する記録を調べてみるとほとんどはケンカです。
と述べていることにつけ、「ほとんど」を実現する要素を宮下氏が持っているものだと考えます。 つまり猫は、宮坂氏自身に問題があるものと推測できますし、 事実としてCマガジン2月号の「プログラミング○×△」の「見解」のような 意見が論議の場に飛び込めば十中八九ケンカへと発展するでしょう。
参考文献：頑張れ!!ゲイツ君
| SEO | [PR] おまとめローン 花 冷え性対策 坂本龍馬 | 動画掲示板 レンタルサーバー SEO | |
