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

dotkuwaの日記: 公教育のひそみに倣う

日記 by dotkuwa

2点、公教育のひそみに倣うと、プログラミングを
仕事とする上で役に立つ事があると思います。
それらは、
・それぞれに自治を行っている社会によって、規範が異なる
・公教育の場で実際に、違反者に懲戒が行われた
ものです。
 
1つには、掛け算の順番です。英語の場合、掛け算には
順番が有るのは事実との事ですが、順番の無い日本後の
教育でも、順番を設けるのが正とされ、実際に違反した
人間に対し懲戒が行われ、上部の監督する人間も、
それを非としなかった事実が有ります。
 
2つには、哲学分野の教育です。自分が高校生だった頃は
サルトルが、現代の最先端の哲学だと実際に教わり、
誤った回答をすると懲戒を実際に受け、やはり監督側も
それを非としませんでした。これも事実です。
サルトルなど、フランスの為のポジショントークをする
だけで(当人も意図的にやっていたそうです)、
そういう風に哲学を実用的に使うのが「最先端」と
された訳です。
ただ、どんなに「心理的安全性」に意を尽くしている
プログラミングに関する職場でも、他国のポジショントークを
持ち込まれたら、ダメ(懲戒の対象)でしょう。
 
なにが言いたいかというと、
・それぞれに自治を行っている社会によって、規範が異なる
・公教育の場で実際に、違反者に懲戒が行われた
・「逆もまた真なり」では無いか!!
という事です。
 
自分は前から申している通り、
・自治の範囲において、掛け算の順番に対する規範は
 変わって構わない
と思っています。
ただ、自治の範囲を超えて、それを主張された場合、
逆襲が可能だとも思っています。
 
さて、
・コンピュータにおいて、(比喩的表現ですが)選択公理を
 実現するのを第一の使命としている
コンピュータサイエンスですが、実社会において功罪が有ります。
・これ無しでは、お話にならない位、ひどいプログラムしか
 出来ない。欠く事が不可。
なのは事実ですが、
・本当に範囲が狭い。これだけ有ってもひどいプログラムしか
 出来ない。あまりに狭量。
なのも事実です。(特定のフレームワークを使いさえすれば、
事実上、コンピュータサイエンスと合致出来てしまう位、狭い
ものだと思います。)
 
自分は、これを改善するには
・コンピュータサイエンスを学んだ場合、副専攻として哲学も学ぶ事
で改善されるのでは無いかとは思う様になりました。
ただ、公教育の世界でなされている哲学をそのまま持ち込むと
懲戒を受けかねない、違う規範のものとなっているのも事実です。
 
純粋理性程度の範囲での「特定の社会用の、たとえるなら『順番を
固定した』哲学」を構築し、それがうまく行く、限定された社会のみでの
流布・教育がなされると、良いと思いますし、
公教育のひそみに倣うなら、それはしても良い事だと思います。

15275749 journal
日記

dotkuwaの日記: 関数型プログラミングの独自性

日記 by dotkuwa

1.副作用(それが有ると、実行するたびに結果が変わってしまう
 のでテストが困難になる)の無い部分を抜き出し、
 関数としましょう!
 ↑ 手続き型プログラミングでも当たり前の様にされていた事です。
  www
 ↑ ブロックという考えがなかった頃、gotoレスでプログラムを
  組むためには、必ず関数を書かなければならない
  (ループの中身は1行で無ければならない)ので、
  関数として抜き出す事を事実上、強制としていた言語も有った。
 ↑ このパターン(規範?)のみを「関数型プログラミング」と
  すれば良かったのかも知れませんが、実際の歴史では、なぜか
  それ以上の独自性を求める事になった。
 ↑ ただし、副作用の"有る部分のみ"を抜き出そうとしたのが、
  オブジェクトの始まりで
  (openやread,writeやclose事にメソッドが必要で、
   それを1つにまとめるクラスも必要だし、状態変数として
   のインスタンス変数も必要)、
  そちらの方向性に対しては、関数型は無力。
 
2.副作用を無くしましょう!
 ↑ 確かに手続き型プログラミングではされていませんでした。
  しかし、出来る見込みが有りません。
 ↑ 数学的な選択公理の元では、どんな値も0時間で入手が可能で、
  実行するたびに結果が変わらない様に値を得ることも、
  ノーコストですが、CS的な選択公理ではそうは行かない。
 ↑ というか、そもそもCSの第一の存在意義は、コンピュータ上で
  選択公理を実現する事で、さらに言うなら、そのコストを推し量る
  事ではないか!!
 ↑ コンピュータ上でも頑張れば副作用を減らせるが、それで、
  1万円で出来ていた事が1兆円になってしまっては、CS的には
  敗北で有り、トレードオフの問題ではないか?
 
3.モダンとされる有用なプログラミングのアイディアのいくつかを
 関数型プログラミングならではの物としましょう!
 ↑ アイディアを独占することは出来ませんでした。手続き型の
  プログラミングでも、それらモダンなアイディアは取り入れられて
  います。
 ↑ 同じ機能が備わっているなら、関数型かどうかなどどうでも
  良く、逆に「より良いレッテルが貼られている」にも関わらず
  「何の違いも無い」→「詐欺だ」という、逆風にしかならない。
 
4.モダンを超えたアイディアを関数型プログラミングならではの
 物としましょう!
 ↑ プログラミング言語として高階関数を実現しましょう!
  (自然言語による曖昧な哲学的な表現で、かろうじて高階に
   関する表現が出来ていますが、動くプログラムでは何を
   やっても1階のままです。
   高階的表現が必要なら、そちらを指向するのが王道です。)
 ↑ プログラミング言語として副作用を封じ込め、見えなく
  しましょう!
  (かえってテストしにくくなります。)
 ↑ 特定の言語を「関数型」と認定し、モダンで有ると喧伝しま
  しょう!
  (プログラミング言語の発展の過程で「関数型」→「手続き型」
   の様に多様化していったのに、先祖返りをすれば済むという
   訳でもないでしょう。)
 ↑ 特定の言語で、nullを廃し、より良くしましょう。
  (プログラミング言語の発展の過程で「null無し」→「null有り」
   の様に多様化していったのに、先祖返りをすれば済むという
   訳でもないでしょう。)
 ↑ 陽関数を極度に持ち上げ、陰関数は無視しましょう!
  (かえってテストがしにくくなります。)
 ↑ 内部の状態は極力捨てましょう。そうすれば副作用は隠れます。
  (かえってテストがしにくくなりますし、運用方からすると
   大迷惑です。)
 
5.訳の分からない、一見「宗教的」とも言えるドグマを信じて
 いれば、「何をするか分からない」と周りに思わせる事が出来、
 報酬はもらった上で、プログラミングの実務はしなくて良くなる!
 ↑ 5年、10年程度はそうかも知れませんが、それを超えて成果が
  0なら、流石に行き場を失います。
 ↑ 別の専門性を磨いておく事をお勧めします。
 
6.特定の人間を攻撃しましょう。そうやってそれらの人間を排除
 すれば、「全ての良い事」は関数型プログラミングの物です!
 ↑ 完全に排除すべきでした。そうで無いなら未来は有りません。

15268724 journal
日記

dotkuwaの日記: CS版選択公理 3

日記 by dotkuwa

選択公理:X が互いに交わらないような空でない集合の集合であるとき、
X の各要素から一つずつ要素をとってきたような集合(選択集合)が存在する
(Wikipedia 日本語版 公理的集合論より)
という言い方が有り、人間が構成可能な数学的には0時間で実行可能だそうです。
 
しかし、CS的には違うと思います。
・集合の集合はたいていデータベースで実現される。
・必要な値を持ってくるのは0時間で出来ない。
・必要な値を持ってくることこそ、事務計算のプログラミングの要諦であり、
 計算はそれより楽だし、自動テストも容易で、何十年前から自動テストは
 実用化されている。
・必要な値を持ってくるのに副作用が必要な場合がある。
・「必要な値を持ってくる」をテストするのは困難で、データベースに追加された
 値しだいでは、追加のテストが必要になる(現在のテストのみではバグを検知
 出来ない場合が出る。)
  という悪い性質を持っています。

関数型プログラミングは、この点を等閑視しており、オブジェクト指向
プログラミングより真に出来る範囲が狭い
(その代わり、表現できる範囲では簡単でテストもしやすい)
し、
出来ない範囲に、ちょうど事務アプリが分類されてしまっている
(自分が仕事をしている社会では実用にならない)のだと思います。
 
関数型プログラミングがオブジェクト指向プログラミングと同等の能力を
持っていない事がそれの停滞
(試してみないと正しいかわからないのは事実だが、5年、10年経っても、
成果が0である場合、解呪すべきであり、ビジネス的にはファクトとして
『いんちき』と認定すべき)
の原因ではないでしょうか?

15254700 journal
日記

dotkuwaの日記: 「モダン」の分類 5

日記 by dotkuwa

『モダン以前で無いもの』を全てモダンと位置付けてしまうのは、
乱暴だと思いました。
 
ポストモダンという言い方がある様で、
・モダンは四角いビルの様で、普段使いで役に立つ
・ポストモダンは本の表紙が焼けたり、案内板でテプラが
 貼られたりする
もので、
モダン以前で無いものが、全てがモダンだとは言えない
のかも知れません。
 
要するに、
・鏡を自分の真前に置き、自分の課題が鏡の中心に置かれる
 様にし、圧倒的大多数の、他人の課題ば全て鏡の辺縁に
 なっても気にしない
のがポストモダンだと思います。
 
確かに学びはあるのかも知れませんが、普段使いでは
無いと思います。
なるべく多くの課題が鏡の中心に映る様にし、辺縁となって
しまった課題には、特段の配慮をするのが普通です。

15248707 journal
日記

dotkuwaの日記: 解呪2 13

日記 by dotkuwa

なにやらホラー映画の続編の様なタイトルになりましたが、
・EXCELでDBやPGの設計書を書くのはダメだ
というのも解呪すべきでは無いか?
という趣旨です。
EXCELで設計書を書いて悪いはずが有りません。
 
EXCEL文書の設計書には、
・個々の工夫の説明を
・全部書く
のが一般的です。プログラムで出来る事の真似をして、
実行ロジックを書くのは間違いです。
(やってみれば分かりますが、すぐに破綻します。)
 
プログラムは、
・延々と連鎖が続く、木でできたグラフ
を表現でき、
・「実際に動く」を表現
できます。
 
もちろんこの特典の代償として失点も有ります。
・分かりやすい小ささのプログラムの一部分に
 個々の工夫の説明をまとめる事が出来ない。
 (プログラムのそれなりの範囲に散らばって、
  それら全部で、一つの個々の工夫の説明となる。)
です。関数という括りはもちろん、オブジェクトと
いう括りでもまとめる事が出来ない場合が有ります。

もちろん、工夫とはとても言えないトリビアルな内容なら
まとめる事も可能でしょうけれど、
仮にも「工夫」と言えるレベルの内容だと、間違い
無く散らばります。

 
なので、その失点を補完する為にEXCEL文書が
必要なのです。
(もちろんEXCELで無くてはならない訳では
 有りませんが、ここでは「EXCEL文書かその
 類の文書」程度に捉えて下さい。)
 
ーーーーーーーーーーーーーーーーーーーーー
 
・EXCELでDBやPGの設計書を書くのはダメだ
と言っていた人間は、
・では何が良いのか
を明確にはしませんでしたが、想像するに、
・EXCEL文書とプログラムの利点を融合しようとした
のだと思います。
なぜなら、
・ダメだとしたEXCEL文書より良いものとして、
 ERツールとかを推していた
からです。
実行可能な文書というやつだと思います。
 
これは完全な誤りでした。
役割分担がきちんとしていた、EXCEL文書とプログラム
を、何の根拠もなくまぜこぜにしただけだからです。
 
・実行可能文書ならプログラムが有ります。
 そしてプログラムは、実行可能であるが為の失点も有ります。
・それを補完する(個々の工夫の説明を全部書く)為の
 EXCEL文書だったはずが、
・その役割の文書内に、実行可能の要素を入れて
 「改良した」とイキっても、
EXCEL文書で得られていた特典を減らし、失点を増やす
 だけ

となったからです。
 
その役割の文書に実行可能の要素を少しでも入れただけで、
・分かりやすい小ささの実行可能文書の一部分に
 個々の工夫の説明をまとめる事が出来ない。
という失点が、即座に現れたはずです。自分が見た限りでは、
100%そうでした。

 
この点は解呪されるべきです。
EXCELで設計書を書いて悪いはずが有りません。

15242012 journal
日記

dotkuwaの日記: 我が手法

日記 by dotkuwa

自分がそこそこできる様になり、全体から見るとどうでも
良い部分を任された時、「辺縁で、ほぼ見切れている部分」
の問題に出くわしました。
それは、
・仕様の本当に些細な変更も、増幅され、全部書き直しに
 なってしまう
点でした。
鏡なんかでも、「辺縁で、ほぼ見切れている部分」は、
少し鏡面を動かしただけで、鬼の様に変わってしまう
のと同じだと思います。
 
その時は、文句を言ったら、固まるまで待ってヨシと言われ
ました。どうでも良い部分だからこそ、そう言ってもらえた
のだと思います。
もし、全体から見て必要不可欠な部分が、辺縁となる様な
手法を選んだとしたら大変です。
 
どんな手法で有っても、辺縁は必ず出来ます。
問題は、ある手法を他のどの手法より上に有るとする
傲慢さだと思います。
「我が仏、隣の宝、婿舅、天下の軍、人の善悪」が公共の
場で憚られる話題とされますが、
「我が手法」もその程度だと思うべきです。
 
また、ある手法が他のどの手法より上に有るとする
という言い草は、
・辺縁で本当に困っている人間の評価を等閑視する
 (辺縁なので些細な変更も大変になるのに、それは
  辺縁であるとして、価値を下げる)
事にもつながります。
 
大変な事の評価を下げると、一時的には成果が出た様に
見えますが、
一回り時間が経つと、
・誰も大変な方をしなくなる
事になります。
学校とかで一回り時間が経つと、人間も入れ替わって
なし崩しになるならともかく、
成人のみの実社会では、絶対になし崩しでは終わらず、
最後には動かなくなる事でしょう。
 
不動産屋さんの副業となった今では、もっとサスティナブルな
やり方も有るのかも知れませんが、
筆一本で稼ぎを得ようと本気で思った場合は、
時に応じて角度を付けるというのは、本気の本音だった
のでは無いでしょうか?
#そもそも角度は付けるのでは無く、付いてしまうという
#方が正しいかも知れません。
 
そして辺縁で大変な事を減らす様、部分ごとに角度を調節する
柔軟さも必要だと思います。
#ある辺縁を何とかしようと、全体の角度を一気に変えると、
#別の辺縁が出来るだけだと、強く指摘します。

15229747 journal
日記

dotkuwaの日記: 職人と研究者 1

日記 by dotkuwa

料理人の漫画を(電書で)読んでいたら、
・職人とは無心に手が動く者のことを言う
みたいなセリフが有りました。
確かにプログラマーは、
・対象間のつながりにひたすら意を尽くす
存在で有り、最終的にクラス図とかにまとめると
しても、形になるまではひたすら手を動かし、
テストをし続ける者で、
職人と言われても妥当と思います。
 
それに対して研究者はコーディとナチュラルの
様に、洞察力をもってリードしていく存在なら
万事うまく行きます。
 
しかしソフトウェア開発の現実では、
・うまく行っている職人をまどわし、正しいことを
 言っていたはずなのに、*改心させ*嘘を言わせ、
 その後、自分がうまく行くを言う、マッチポンプの
 様なことしかしない
存在です。
関数型と言いながら、結局はいまだ最先端で有る
オブジェクト指向の背乗りをしたくて仕方ない
だけとしか見えません。
 
ーーーーーーーーーーーーーーーーーーーーーーーー
 
そもそも、ソフトウェア開発で職人と研究者の
比喩を持ち出すのが問題なのかも知れません。
一般に言う(正調の)職人とは、
・物性の様に、第一原理の有る
対象を扱うものでした。
ですと、遠回りをしてでも第一原理を修めた、
研究者に職人が敵わないのは明白です。
 
しかし、ソフトウェア開発では、
その社会の置かれている現状が違えば、
(優先されるべき)原理も変わってしまう
性質をもった科学に支配されている対象
(ソフトウェア)を扱います。
コーディとナチュラルの対比では、(第一原理の
無い)紛争をどうにもできなかったのと同様に、
職人と研究者のモデルでは、ソフトウェア開発に
寄与出来ない可能性が有ります。
 
極論するなら、
CSを分離しソフトウェアの科学を文系に持っていく
のも有りかも知れません。
対象の社会の味噌っカスあえて自らを置き、その対価
として真実を得る、みたいなノリです。

15223642 journal
日記

dotkuwaの日記: 学界と産業界

日記 by dotkuwa

学界では、
・公理系は永久にムービングゴールポストが好ましい。
 その方が代々の人間が関与でき、論文のネタになる。
 論文のネタを提供するのが、商材だからである。
・もし使いたかったら、公理依存な自動テストを作って
 使う側が対処しろ。
・ムービングゴールポストしない処理系を古いと非難
 出来る。
・自分が教える人間だけに特別に入門的な知識を授ける
 ことが出来る。そうでないならgithubを丹念に追え。
で、
産業界では、
・ムービングゴールポストに対処するのはお金がかかる。
 ムービングゴールポストを長期間しないでもらうにも
 お金がかかる。
 後者なら出せる。
・公理自由な自動テストなら(知る限り)30年前から有るが、
 公理依存な自動テストは、作ろうとした時点で思考が
 固まる。
・ムービングゴールポストを長期間しない処理系は、
 古いと非難を受ける。
・ムービングゴールポストな処理系は入門書(往年の、
 猿でもとか、256倍とか)が書けない、書いた段階で
 古くなる。
 その意味でもムービングゴールポストを長期間しない
 方が好ましい。
という対立が有ると思います。
 
その点から読み解くと、
DXとかで内製に近い形での作成を産業界でする場合、
・古い
という非難は無視する、あるいは
・古いという非難こそ、産業界にマッチしている
 判定基準になる
という割り切りが必要なのかも知れません。
 
社会の分断が有利な場合である一例かも知れません。

15217511 journal
日記

dotkuwaの日記: 嘔吐主義者に対する疑念 1

日記 by dotkuwa

もしかすると、
・コントローラーという物は「公理」の様な物で、
・上位の公理であるフレームワークの持ち味を殺すのは
 まずいが、
・それ以外は、正しい?間違っている?というテストの
 対象とはならず、
・そうでは無く、他のモデルやビューの正しい?間違って
 いる?のテストの合否に影響を及ぼすだけの存在
なのかも知れません。
 
だから、コントローラーは、
・出来たらいじるな
・最小限にしろ
なのかも知れません。
 
もしそうだとすると、疑念が起きます。
・年寄りは「生き残り」で有り、コピペをしくじる事
 などそうそう無いはず
 (もちろん扱った事の無いものは別。自分も20年選手に
  なってから初めて扱ったVC++で大しくじりをして
  現役引退になってしまったし。)
・では、(コントローラーの)コピペでしくじるのは誰か
という物です。
自分のしくじりを年寄りになすりつけていただけだと
したら、さらなる鉄槌が必要です。
また、
・(コントローラーの)コピペでしくじったら、確実に
 各所でテストがおかしくなる
はずです。
必要が有ってコントローラーをいじったとしたら、
嘔吐主義者はテストをしていないのでしょうか?
大きな疑念です。

15211531 journal
日記

dotkuwaの日記: 嘔吐主義者への最大限の侮辱を 15

日記 by dotkuwa

・コピペばかりの年寄りに吐き気がする
と主張する人間がいます。(以下、嘔吐主義者と言う)
 
しかし、
・全く同じプログラムならコピペすら不要で、コピペだけで
 異なるアプリケーションが作れるなら、最高にその社会に
 合致したやり方では無いか?
・高いライセンス費用を払いつつ、いつ売り止めになるか
 を心配しなければならないノーコードなどより、ずっと
 コピペの方が柔軟に対応できる。
のは確かで、それを誹謗するのはおかしいです。
 
さて、
・コボラーに対する人格攻撃も含めた、無制限の侮辱は、
 srad本スレも含め、容認されています。
・しかも、本当に活躍したコボルの立役者では無く、その
 弟子筋に対しての侮辱です。
 (自分も、「更改の為のソース調査の繰り返し、ときどき
  マスタメンテ」しかしていないのにコボラーとして侮辱
  され続けました。)
・これは公益に合致しているとみなされているのだと思います。
 
ここで、
アプリを作る良い方法を、エビデンス無しに攻撃する主義者
が居るとすると、それに対する最大限の侮辱も、
ソフトウェア業界の慣習(コボラーに対する人格攻撃も含めた、
無制限の侮辱の容認)から鑑みて、
公益に合致するとして良いのでは無いでしょうか?

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...