パスワードを忘れた? アカウント作成

こちらは、dotkuwaさんのユーザページですよ。 Idle.srad.jpは、あなたの人生において完全な時間の浪費です。見るなよ、見るなよ。

13841313 comment

dotkuwaのコメント: Re:どのレベルかによる (スコア 1) 4

by dotkuwa (#3567015) ネタ元: 例えば

これは、
・文系と理系の違い
と、
・その違いにより、初学者に授けるべき知識の違い
が絡むと思います。
 
文系は、
・ノーベル賞をもらうような人が最高に頑張っても、あまり合わない。
理系は、
・最終的に神の数式になる。合う。合う。合う。
の違いが有り、
それにより、
・初学者に授ける知識が異なる
と思います。
 
文系はたちの悪い知識を初学者から教えます(漢字とか英単語とか)。
理系は最高に規律正しい、たちの良い知識を教えます。
(ただし掛け算の順番は文系です。)
 
初学者に、開発でのたちの悪い部分を教えるか、たちの良い部分を
教えるかは、プログラミングというのが
・文系なのか、理系なのか
の認識によると思います。
自分は、経済学との対比で考えても、圧倒的に文系だと思っています
から、
・初学者から、たちの悪い知識を与えるべき
と考えています。
#もちろん、そうで無い考えも有ると思います。

13841301 comment

dotkuwaのコメント: Re:関数はいいものです (スコア 1) 4

by dotkuwa (#3567004) ネタ元: 例えば

define lambdaやprog-nとか言って、xfyの関数で無く、
複数の文を持つ(一番最後以外の結果を捨てる)関数の様なもの
を始めたのは、LISPでは無かったでしょうか? あなたにぞうさんぞうさんの。

そういうたちの悪い書き方をしないと実用的なプログラムは書けなかったの
でしょうけれど、C++と合わせて「関数」という言葉を不順にした大罪言語
じゃないですかね?

13840027 journal
日記

dotkuwaの日記: 例えば 4

日記 by dotkuwa

例えば、微積をおしえるのに、
・i=1から順に足して行く
だけを教えるとしたら、かなりひんしゅくものだと思います。
プログラムをおしえるのに、
・関数
だけを教えるとしたら、同じだと思います。

13827832 comment

dotkuwaのコメント: Re:手続きはむしろどうでもいい (スコア 1) 4

by dotkuwa (#3557738) ネタ元: オブジェクト指向の決定的な制限

自分が、
●関数(コボルではPROGRAM)は、
 内部と外部に分けられ囲われた、プログラムの単位で、その内部とは、
 
 ・特に同時に動く事が宿命づけられている訳でもない、いくつかの
  ロジックが同時に動く
 
 性格のものだ
と、(ぼんやりと)思いついたのは、
★COBOL74のプログラムで、
★(例として)Aという製品とBという製品が有り、
★製品の量と料金はすべてテーブルを検索すれば出る
 (『本当の関数』(状態を持たない)に当たる部分はここのみ)
★「Aという主商品とBという副商品」を扱う(1単位の)処理と、
 「Bという主商品」を扱う(1単位の)処理が有り、前者と後者のBという
 商品の処理は同じはずで、ロジックは同じだが、書き方が微妙に違う
★規定改正の度、2つのBという商品の処理をきちんと修正しないと
 いけない
システムの面倒を見ている時でした。
 
思ったのは2つです。
①何でBを1つにしないんだ
というのと、
②AとBは何の関係もない(独立して計算できる)が、PROGRAMは
 それを結び付けている
というのでした。
 
#上記システム以降は、主商品、副商品などと分けず、全部単位商品と
#する様になりましたが、なにせCOBOL74で、PERFORM UNTIL 終わるまで
#すら無い、古いシステムだったので仕方有りません。
 
--------------
 
①の事を思うと、「関数を(PROGRAMを)複数の関数に分割する」というのは、
全くその通りです。喉から手が出るほどその通りです。
肯んじ得ないのは、
★分割したからと言って、「たちの良い、テストしやすい断面が現れるか?」
 また、(上記システム例の様に)その様なたちの良い断面は、すでに
 開拓されていて、テーブルで定式化されていて、自動テストもなされていて、
 いまから提案しても遅すぎるのでは無いか?(簒奪に過ぎないのでは無いか?)
★分割し、たちの良い断面を見つけても、その外側には(それを呼ぶ側には)
 さらに濃縮されたたちの悪い部分が残るのでは無いか?
 (「濃縮されたたちの悪い」とは、いままで自分の内部で有ったのが、
  良い部分だけ関数に被覆され、いつその内部が変化するかを恐れつつ、
  見えないものを呼ばないとならなくなる。
  これは、いうなら、単純系だったのが複雑系になる≡悪い部分が濃縮
  されることにほかなりません。)
★たちの良い部分を見つける事で成果と出来る人に対して、たちの悪い部分を
 押し付けられた人はどうなってしまうのか?
です。
 
②の事を思うと、人間がお金を出して、よかったと思われるシステムは、
単なる「関数機能の呼び口の一覧」では無く、
それらの呼び口を複合して、人間が一番大変だと思う大域的な探し物を
代わりにやってくれる事だと思います。
(主商品と副商品を結び付けて計算し、合算しetc.etc.をしてくれる)
その「よかった」を実現すればするほど、
★たちの悪い部分が現れる
事になります。
もちろん、単なる「関数機能の呼び口の一覧」のみを提供して、それから
先は人間の手動や、ロボットに任せるのがベストだという考えも有るでしょう。
けれど、
それも、
★たちの悪い部分を濃縮して、他人に押し付ける
行為だと思います。
 
自分の懸念は一貫してこれ(濃縮された悪さを押し付けられないか)です。

13826956 comment

dotkuwaのコメント: Re:手続きはむしろどうでもいい (スコア 1) 4

by dotkuwa (#3557107) ネタ元: オブジェクト指向の決定的な制限

>入力に対して想定される出力がきちんと返ってくるなら中身はどうでもいい。
 
がはかばかしくない(実例が全く表面化しない。これは「誰かが隠し持っている」
か「誰も持っていない(言っているだけ)」のどちらかになる)から、
別案を言っているだけです。
中身はどうでもいいというのは、言い過ぎだと思います。
 
ここで説明の為、"関数"という言い方を、
・「関数表現」

・『本当の関数』(状態を持たない)
に分けたいと思います。
前者は後者を含みます。

自分は、
入力と出力以外隠す「関数表現」というのは、プログラミング言語では、
・同時性を表す
以上の意味付けは無いと思います。
ましてや、
・入力と出力と関数名が、中身を代表している
という証明は無いと思います。
そして、「関数表現」が『本当の関数』(状態を持たない)で無い場合も
沢山あります。
 
単に、
・特に同時に動く事が宿命づけられている訳でもない、いくつかのロジックが
 同時に動く
・逐次的にしか実行出来ないいくつかのロジックを、あたかも同時に実行したか
 の如く振舞う事が可能で、その為に中間変数を使う
事を表現しているのが「関数表現」です。
これは、普通の表現でも、アロー形式の表現でも同じだと思います。
 
それ以上の、
・外部から観測できる範囲で観測するだけで、正しい事をテストし切る事が
 出来る。
という事は、「関数表現」では、まず有り得ません。
ならば、中身を見ないといけないと思います。
#『本当の関数』(状態を持たない)ならどうか判りません。

13826151 journal
日記

dotkuwaの日記: オブジェクト指向の決定的な制限 4

日記 by dotkuwa

オブジェクト指向は、メモリ(データ)を抽象化するためのものに過ぎず
入力・処理・出力(以下関数という)を抽象化しないのでは無いか?
なぜなら関数は状態を持たない為、メモリ(データ)のみを抽象化する
オブジェクト指向は、何の役にも立たない事になるから。
 
むしろ、関数は抽象化し尽くされた存在で、抽象化の余地は無く、
それに対して可能なことは、具体化しか無いと考えるべきかも知れない。
 
そして、具体化のポピュラーな手法として、処理を複数の行に分ける、
手続き指向が有力なのではないか?
 
--------------
 
オブジェクト指向は、データオブジェクトや、ビューモデルで最高の
役割を果たし、画面のウィジット(テキストボックスやチョイスなど)
で最高に美しい構造を示します。
前者はもちろん後者も「データの湧き出しや吸い込み」を表すからです。

13818750 comment

dotkuwaのコメント: テストドリブンとは移行星の流儀? (スコア 1) 8

by dotkuwa (#3551067) ネタ元: プログラミング的思考を学ぶべき理由

ソフトを開発していると、小前提は頻繁に
(結合テストをしている時ですら)変更が
有ります。
変更のマネージャーがテストのマネージャーと
連携を取らず、全部こちらのせいにもされたり
しますが、それが実態でした。
そして、オブジェクトのインターフェースは、
小前提単位に切り分けられ、すげ替え可能に
なる様になっている筈です。
 
中前提を変えるなんてなったら、トップレベルの
仕切り直しになるでしょうし、大前提を変えると
なったら、開発側が裁判で勝つでしょうけれど、
その様な事は、自分らとは関係が無いレベルです。
 
そういう背景の元、
・小前提を固定する「テスト」を初めに書く
事を推奨しているのはなぜでしょうか?
 
それは、
・それが移行星の風土に合っている
からでは無いでしょうか?
移行星では、
・モデルは所与で、移行元のシステムも実行可能
です。
そういう風土での最適な手法を、新規開発に持ち
込もうとした結果だとするなら、
理屈に合います。
 
しかし、その様な事は移行星の外では成り立たない
事が多く、特に、初学者が自分で自分のメンタルモデル
と向き合おうという時には、猛毒となるでしょう。
無い、顕在化されていないメンタルモデルから直接テスト
を書こうとするのですから、本当に有害です。

13818360 comment

dotkuwaのコメント: 移行星獣の今後 (スコア 1) 8

by dotkuwa (#3550822) ネタ元: プログラミング的思考を学ぶべき理由

自分は大学時に家でいじっていたマイコン(MZ-80C)の
SP-5030とSP-4010とHu-Basicの知識だけで、会社に入り、
オフコンのコボルプログラムをいじれ言われて、いじった
ら出来てしまったという経緯でコボラーになったので、
伝手とかが有った訳でも無く、ゆえに、
伝手の無い人に対して優越性を持てた事も無かったのですが、
 
何故かコボラーとして非難される側になったのです。
それは今でも続いています。
 
ただ、現状は変わってきています。
本当にコボルを別の言語に移行するのが流行っていた時期は、
★説明・説得が不要
でした。まるで携帯電話か何かの様に、「明白なる運命」として
広まっていきました。
しかし、現在、例えば「Forを排すべきだ」とか、迅速かつ適応的に
ソフトウェア開発するのにこのやり方にそろえろとか、
年中説明・説得がなされています。
それだけで、移行星獣の現状が理解できます。間違いなく
追い詰められています。
 
移行星では、テストにおいて特異な事実(良い事実)が有ります。
同じ入力をして同じ処理をして同じ結果が出れば、テストOKと
出来る点です。
しかも、モデルは既に与えられていて、考える必要が無いのです。
これらの事から、移行星獣は、(ハマれば)大儲けが出来ます。
 
特に移行星獣の内でも、最高にハマっていた時期に、功績から
大学などに進んだ個体はまずいと思います。
移行後のシステムを保守していれば、自分で成員間のメンタル
モデルの再調整を求められたりして、星獣が星人にスキルアップ
出来たかも知れませんが、
現場を離れた移行星獣は、獣のまま、次の移行のネタを探してる
のでしょう。
 
しかし、本当に移行が誰からも望まれる状態では、
★説明・説得が不要
なのです。だから望まれてもいない状態で、第二のどじょうとして
PHPをやり玉に上げようとしてしくじったのだと思います。
 
今後は、時代から取り残された移行星獣の言う事は聞かず、
現行のやり方でもかまわず、小さい事から積み重ねて行き、
成員全員が納得できるメンタルモデルを導き出すのが
肝要だと思います。

13815375 comment

dotkuwaのコメント: Re:コボラーを責めるべきでは無かったのでは無いか (スコア 1) 8

by dotkuwa (#3548585) ネタ元: プログラミング的思考を学ぶべき理由

一度整理してみたいと思います。
 
ここで、「コボラー」だと言って非難する人間の事を
(怪獣つながりで)「移行星獣」という事にします。
(なんでかは後述)
 
COBOLがだめになったいきさつは、
1.大きいPC(サーバー)で、情報処理が出来る事に
  なった。
  (これだけなら、COBOLもサーバーで動く様にしさえ
   すればよかっただけですが、そうはなりませんでした。)
2.RDBが流行るようになったが、COBOLにNull項目など無く、
  各基本項目の直前に1バイトのNullか判定する項目を置け
  だの、頭が痛くなる事ばかりだった。
3.COBOLで無いVB4とかDelphiだとかは、何十万か出しさえすれば
  無制限にRDBアクセス環境をインストール出来た。
  Null項目(As Variant含む)も有った。
4.しかも新しい言語はオブジェクト指向対応だった。
  メモリ直アクセスが原則のCOBOLと違い、
  オブジェクト指向言語は、インターフェースを介さないと
  メモリにアクセス出来なかった。
  これは大違いで、言語を移行するに足る進歩だった。
ですが、
成員全体のメンタルモデル(別名お気持ち)から見て、
何とか納得するモデルは、
既にCOBOLで有りました。
 
ですので、コボラーから破壊的に奪い取って、新システムを
成し遂げた人間は、移行しかしていません。
だから「移行星獣」です。そう考えると、それからの彼ら彼女らの
行動に納得が行きます。
 
--------------
 
成員全体のメンタルモデル(別名お気持ち)から見て、
何とか納得するモデルを作り上げる事は、非常に難しく、
ill condition で有ると言っても過言では無いと思います。
 
MT装置数台とカードリーダとLP装置(と大量の汎用用紙とカード)
だけで、マージソートをしたり、マージをしたり、マッチングを
したり、帳票に出したりする様な、
非常に小規模な頃から、試行錯誤を経た末のモデルです。
 
すぐに思いつく手法が有る訳でも何でも有りません。
(これも、プログラミング的思考の一つだと思います。)
 
--------------
 
なにが言いたいかというと、
★移行星獣たちは、モデルを思いついた事が無い。
★移行星獣たちは、モデルを思いつく事がコボラーの専売特許だと
 思い込んでいる。
★移行星獣たちは、モデルを思いつく事が困難なのは、コボラーのせい、
 あるいは、コボラーが簡単に思いつく方法を隠していると思い込んで
 いる。
★だから移行星獣たちは、コボラーを非難する。
のでは無いでしょうか?
 
もし、そうだとしたら、その非難は的外れです。だれがやっても
それを思いつくのは困難で、初めに正しい事を思いつくのは不可能で、
コボラーにそのill condition をなすりつけるのは不当です。
 
さらに、別のより新しい言語、フレームワークでまた移行をしようと
考えた移行星獣たちは、
★オブジェクト指向とPCサーバー
という新規性と同程度以上の新機軸を見つける事が出来ず、
COBOLより昔で有るに違いない、単なる欠落に過ぎない関数型プログラミング
だなんていう物を持ち出し、移行出来るだけの成果を上げられない
のです。
もうその轍を踏んではいけません。心よりそう思います。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...