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

最新から新しい日記やタレこみを確認できますよ。

13892191 comment

dotkuwaのコメント: Re:ちょっと違う (スコア 1) 5

by dotkuwa (#3603199) ネタ元: ソフトウェアに関する「違う科学」

>普遍的の範囲が狭いだけです。
>普遍的ではないものをなるべく普遍的なものにしようというのが、
>探せばインタビューなどで述べられているはずです。
自分が知る限り、最良の普遍的な言説でも、ウルトラ5つの誓い程度の
ことしか言っていないと思います。
それもこれも、第一原理の「不在」が原因だと思います。
 
自分は第一原理の「不存在」とまで言っていいと思いますが、少なくとも
「不在」は事実です。

13891282 journal
日記

dotkuwaの日記: ソフトウェアに関する「違う科学」 5

日記 by dotkuwa

博士の権威性を以って、企業活動で「合っている」とされている
科学を、
・古い、誤っている
と主張されると、通常、号を持っていない人間は太刀打ち出来ません。
 
ソフトウェア分野はまだ新しく、その様に主張される論点が
幾つも有ります。もっと古い分野なら、すでに検証され、教科書に
載っていて、ゆめゆめ、
・古い、誤っている
と主張されない様な、
・「違う科学」も、「合っている科学」も、企業の外部で専門的に
 学んでおらず、入社後、その科学に浸って、当たり前としてきた
 人間(職人だといわれれば、その通りです。)
では、思いもしない様な、
基本的な論点を、
・古い、誤っている
と権威性を以って主張され、現場の人間の意志を挫き、結果的に
誤りをスティグマとしてこすり付け、
(多くの場合)始末せずに逃げてしまう、
事が有ります。沢山あります。

13874056 comment

dotkuwaのコメント: あるパラダイムシフトとその顛末 (スコア 1) 7

by dotkuwa (#3590308) ネタ元: 奇妙な悪口を聞きました

コボラーとしての経験では、
・設計書は提出文書として、開発の目鼻が付いた後に書き始める
というのが普通でした。
もちろん、ポンチ絵的な要求仕様と、顧客との話し合いはされていました。
目鼻がついてから、テスト開始までに、文書化していると、
・あーーっ。不味い!!
という事を(文書上で)見つけて、慌てて言いに行った事も有ります。
 
しかし、
その様なパラダイムから、
・設計書は先に書くパラダイム
にシフトました。
大規模開発をするには、それで無いとダメだ、という要件からです。
 
しかし、設計書を先に書くパラダイムは、コボラーの(後に)書いていた
設計書を流用しただけではなかったでしょうか?
そのネタが尽き、
本当に本当に本当に初めから「先に書く」をすると、間違いだらけだったり、
つら過ぎて、間違いを苦に自死が多発したりして、こちらも廃れて、だれも
設計書を書かなくなった、経緯が有るのでは無いでしょうか?
 
本当に辛い時は、布団をかぶって寝るのが最善ですが、独り者だったから
出来た話です。新婚のSEが自殺したなんていうのも、それが出来なかった
せいかも知れません。
 
設計書は提出文書として後から書くのが正解で、それではダメな大規模開発
はよっぽどの巨額投資が無ければするなが正解かも知れません。
その巨額投資をしてどうやって作り上げるかというと、作っては壊し、
作っては壊しになると思います。

13869805 comment

dotkuwaのコメント: 設計書の嘘 (スコア 1) 7

by dotkuwa (#3587111) ネタ元: 奇妙な悪口を聞きました

>設計は技術です。設計者がいないからといって、勉強せずに設計できると思うなんて
>そりゃ設計者をバカにしすぎってものです。
 
自分は、勉強して設計が出来る点に対して疑問を持っています。
・情報で「設計者」として必要なのは、「類似した」分野
 での成果で無く、「今回必要としている」分野での
 精密でしつこい成果
・「類似した」分野の成果が役に立つことは、全くと言って
 いい程、無い。
と申しました通り、
★知識が有って、それを平易に述べられる能力が有れば
 出来る(設計者固有の知識ドメインは無い)
という主張です。
 
なぜなら、
・設計の文書を体系的に着実に構成する手順が無い。
・設計の文書を体系的に着実に検証する手順が無い。
・嘘を書くのは面白い。本当の事を書くのは心に錐をさす
 位苦しい。
・まだ、体系的に検証したり(欲を言えば構成したり)
 出来ればましだが、無い。(これは誰もが認める
 (好ましく無いが))真実。
という性質が有る為、
★設計書は嘘が混じる。特に即テストが書ける位の
 細かさの設計書では、正しい部分が1割を切る。
 その様な細かさの設計書は(そんな打率なら)無い方が
 良い。
★ドメインの専門家が、ポンチ絵やポンチ文で散文的に
 書いたものの方がありがたい。
からです。
 
まとめると、
「指導的な設計者」という存在を規定することは、疑似科学では
無いか?
 となります。設計書には嘘が混じります。必ずです。
それを振りかざす設計者もかなりの嘘を言います。それは仕方ない
のかも知れませんが、仕方ないと規定する代わりに、そういう人間は
「指導的」立場からは外すべきです。
そして、その様な存在を輩出しようとしている教育も疑似科学では
無いか?という事です。

13868493 comment

dotkuwaのコメント: Re:疑似科学を検証すべきは情報分野では (スコア 1) 7

by dotkuwa (#3586157) ネタ元: 奇妙な悪口を聞きました

個々の手段、要素が疑似科学かどうかは、ここでは
差し控えますが、
 
一つ、まぁ自信を持って言える事が有ります。
情報分野は、理系か文系かという事とも絡みますが、
・理系の大学の先生は、有る課題で成果を上げて、
 学位を取る。その後、類似した分野に進む。
と思いますが、
・情報で「設計者」として必要なのは、理系の大学の
 先生では無く、むしろ、小学校の先生(教える為に
 掛け算に順番を付けるのも厭わない)や、年取った
 経理のおっさん(そろそろ実用書でも書いてみるか)
 なのでは?
という事です。
 
そのこころは、
・情報で「設計者」として必要なのは、「類似した」分野
 での成果で無く、「今回必要としている」分野での
 精密でしつこい成果
・「類似した」分野の成果が役に立つことは、全くと言って
 いい程、無い。
という点です。
大学として「設計者」を何とか養成しようとして、専門学校
に劣ったパフォーマンスしか得られず、実際の大学機能は
SIerが保持し、個々の商用プロジェクトこそが1つ1つ学会で
有るという現実は、この点から来ているのでは無いか?
と言えると思います。
 
なので、何が疑似科学かは、
・問題と合っているか合っていないか
で決めるべきで、
・理系の物理とか化学とかのやり方と合っているかどうか
で決めるべきでは無いと最小限言えるでしょう。

13868451 comment

dotkuwaのコメント: 疑似科学を検証すべきは情報分野では (スコア 1) 7

by dotkuwa (#3586134) ネタ元: 奇妙な悪口を聞きました

なんで、この様な事になるのか?
それは、情報分野では公式に教師とされている人間が、
疑似科学を教えているからでは無いか?
 
(たとえば、本当に例えばですが)GMドライブという
疑似科学が有ったとして、テレビの前のちびっこに、
それを使って平和強制が可能か提示する事ならOKでしょう。
しかし、電力会社に入ったちびっこが、実務をしている
人の手を払いのけて、GMドライブこそ必要だと力説したら
かなりの説得が入ると思います。
 
とにかく、
疑似科学を検証すべきは情報分野では無いかと思います。
もし、公式に教師とされている人間が、それを教えていたら
絶望的だし、新しい若い人が言う新しい事が、絶望を
もたらすだけになります。
 
>プロトコル決めるのは上の人なので。
>必要な機能を洗い出してそこの部分は他の人に作ってもらう。
>綺麗に組み合わせるのはそれと並行して時間をかけて考える。
>それでこそ設計者というものです。
も、いう事は出来でも、実際には出来ない疑似科学の可能性が
有ります。

13868447 comment

dotkuwaのコメント: Re:つまり (スコア 1) 7

by dotkuwa (#3586132) ネタ元: 奇妙な悪口を聞きました

自分の疑問点は、
>プロトコル決めるのは上の人なので。
>必要な機能を洗い出してそこの部分は他の人に作ってもらう。
>綺麗に組み合わせるのはそれと並行して時間をかけて考える。
>それでこそ設計者というものです。
>例えば建築のモジュラー設計とかユニット工法とか。
を思いつくのはどうするのか?
です。

「建築のモジュラー設計とかユニット工法とか」が構成出来ない
から困っているのです。

実際にやってみないと思いつかない、のでは無いかと想像
しています。思いつく手段が無いと、絵空事にしかなりません。
設計者にとって、固まっていない時期の余計なテスト作成は、
邪魔にしか過ぎないでしょう。

ウルトラスーパーな「設計者」を持ち出せば済むのは、外野の
人間だけです。
現実には、ウルトラスーパーな「設計者」が不在で、実際に
やりながらプログラマーが決めていると思います。

13868121 journal
日記

dotkuwaの日記: 奇妙な悪口を聞きました 7

日記 by dotkuwa

奇妙な悪口を聞きました。それは、
・プログラミングしか出来ない蒙昧な職人のおまえに、
 科学的なデータの作り方を教えてやる。
というものでした。
 
単なる1関数だけを扱うなら兎も角、複数の関数などが
共同して、結果を正しく得るには、
・それら関数などの間にプロトコルを設けて、全体で
 正しい様にしなければならない。
・それのテストは、1関数をテストする様な、きれいな
 形にならない。
ですが、
その「プロトコル」というのと、「科学的なデータ構造」
というのは、かなり同じです。グラフの双つい関係の様で
瓜二つです。ViewModelなどというデータ構造的存在が、
プロトコルの切り口領域に出来るのも、だからだと
思います。
#そしてそれらは、概してたちが悪いです。

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) ネタ元: プログラミング的思考を学ぶべき理由

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

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...