プログラミングの解説
どういう内容があるといいのかを考えるnishio.icon
構造的型付けについて
文字のエンコーディングについて、書記素や異体字セレクタ、結合絵文字の話
物事をスコアで表現するロジック
これの延長線上にいわゆるAIがあるわけで今後のプログラミングにおいてそれを無視することはできない
学習済みモデルを部品として使うことが行われるようになっていく
今までのプログラミングにおける「確実に正しいものを積み上げていくことで正しいプログラムを作る」というアプローチが機能しなくなる
「人」と同様の「間違いうる部品」
システム全体としては今までもユーザーという間違いが起こる場所があるのでエラー処理を入れていた？基素.icon
そうnishio.icon
単体テストなどの方法で「間違っていない部品」を作り、それを組み合わせることによって「間違っていないプログラム」を作ろうという思想が一時期あった
「間違いうる部品」は当初は軽視されるが、その部品の質が上がっていくことによって「使わないわけにはいかない」状況が生まれる
これは「単体テスト」的な思想を根底から揺さぶる
古い思想を開発プロセスと密結合にしてしまってる組織は適応が遅れるだろう
この種の「間違いうる部品」は何もAIに限ったことではない
例えば外部のAPIを叩くプログラムは、呼び出しが失敗しうる
失敗したことを検知して、その場合にどうするかを実装する必要がある、リトライするのか、フォールバックするのか
UIのコンポーネントを表現する手法としてのオブジェクト指向から脱却する動きについて
Reactの関数コンポーネントの話
イミュータブルパターンとの関連
古いオブジェクト指向において「状態の管理」はオブジェクトと抱き合わせになっていた
本質的には関数に状態を渡して更新することと変わらない
遅延評価のあるHaskellなどの話
この関数の管理が面倒なのでオブジェクトの名前空間に入れようと考えた
これはIDEが貧弱だったから
型の情報を元にサジェスト
そもそも階層的分類が上手くいくだろうが
単一継承の問題と、ミックスインの話を書いた
階層的な名前空間で整理しようとするのも似た感じ
Rustの所有権の概念
move
これはスコープの章に追加だと思う
参照カウンターの話、書いてたかな？
二重フリーの問題
文字列の章
単に加筆するというより、再構成が必要そう
初版2013年
陳腐化しにくい、長持ちする技術書を作るぞ、というモチベーションで作られた
それから10年経った
答え合わせの時期だ
学び方や知識の構造化の方法や、この本を作るという「知的生産」がどのように行われたのかに関しては2018？年の「エンジニアの知的生産術」に書いた
1〜5章に関して特になし
6章エラー処理
ユーザの手元で起こったエラーの情報を収集することが行われるようになった
ブラウザ上で起きたエラーを自動でクラウドサービスに送信するなど
特にスマートホンの普及によって
あと、インターネットへの常時接続を仮定できるようになった時代の変化
7章名前とスコープ
Rustの所有権の概念が話題に
8章 型
構造的型付け
概念自体は昔からあった
JavaScriptに対する代替スクリプトとして多様な言語が競い合った結果、TypeScriptが注目を集めるようになった
ここで「構造的型付け」を理解することの必要性が多くのプログラマにとって必要な課題になった
よく知られているJavaなどの形をイメージしていると混乱する
9章 文字列
Unicodeはしゃぎすぎ問題
絵文字
10章 並行処理
ブラウザがシングルスレッドであったことによってJavaScriptなどでは協調的マルチタスクが必然だった
Promiseの概念、async awaitなど、協調的マルチタスクをきれいに書くための道具が整備されていった
サーバサイドでのNode.jsなども同じような書き方が可能に
一方でブラウザの側にはwebworkerという形でスレッドを増やす仕組みが…
11章 オブジェクトとクラス
変数と関数をたばねる方法1〜4
新たな動き
更新される値である「状態」と、それを扱う「関数」を束ねる必要があるか？
むしろ束ねない方がメリットがある、という考え
これがReactの関数コンポーネントの概念に繋がっていく