株式会社クイープのレビュー一覧
-
Posted by ブクログ
ドメイン駆動設計やクリーンアーキテクチャの入門としてはめちゃくちゃおすすめしたい。
Pythonのような動的型付け言語で、秩序をどう守っていくのか。値オブジェクトからのボトムアップで解説してくれます。
Pythonの言語についての説明は一切ないので、Pythonコードが読めることが前提になっています。
以下は、レビューじゃなくて感想。
私はもうクリーンアーキテクチャーやドメイン駆動設計の本を読んでも心がときめかなくなっているのかもしれない。。というのも、というか当たり前なんだけどみんな似たようなことを言っているからね、言語が違うだけで。
なので途中で読むのやめました。 -
-
-
-
-
-
-
-
-
Posted by ブクログ
# 1周め 読み終えた
通常、本を読んだだけでプログラミングの能力が上がったりするものではない。そのことは理解しているつもりだけど、この本に関しては当てはまらないかもしれない。そう思わされるほど読み進めるごとに何かが変わっていくような、もっと大げさに言うと、新たな世界が見えてくるような、そんな内容だった。もっと昔に、Haskellとかに取り掛かる前に読むことが出来ていたら、違った道を選択していたかもしれない。遅すぎるということもなく、これからどういう風に関数型プログラミングと向き合っていくかを一度ちゃんと考えたほうが良さそうだ。本気で関数型言語をメインにしようという気持ちはまったくなかった。かといって無視して放置しておくわけにもいかない。そんな微妙な気持ちでいたところ、もっと積極的に取り組んでも良いと後押ししてくれてるような感じがする。
この本ではScalaを使っている。ただし、Scalaについての本ではなく、Scalaの経験を前提としないし、別の関数型言語にも共通する、関数型プログラミングの本質的なところを学ぶとしている。自分の場合は、念の為別の本でScalaの初歩的なことを学んでから取り組んだ。その効果十分にあったと思われ、かなりスムーズに読み進めることが出来たと思っている。なので、本当に初歩的なところだけでもいいので先に学んでおいて、Scalaのコードに足を引っ張られないようにしておいたほうが効果的なように思う。Part 3 (11章と12章)は真剣に関数型言語を使おうとしている人のためのもので、それらを除くと、命令形の言語で関数型プログラミングをスパイス的に使う上でも役に立つテクニックや概念が満載だった。よっぽど関数型プログラミングの素質があるのでもない限り、本格的に取り組む前に読んでおくと学習が捗るだろうことが期待できる。
## 12章を読んだ ➤ 関数型プログラムをテストする
最終章。なんか妙に難しいと思っていたら途中に11章と12章は上級者向けだと書かれていた。ついていくだけならそこまでとは思わないが、実践しようとするなら話は別で、相当な熟練度が必要な上級者向けの内容に間違いない。ただ単にテスティングフレームワークを使ってみるだけのものではない。これまで学んできた関数型プログラミングの手法を総動員して、正しいプログラムはどうあるべきかを追求する。テスト対象には11章のWikidataからデータを取得するプログラムを用いている。純粋関数をテストするケースや、副作用のある関数をテストするケース、外部のサービスにアクセスしないといけないケース、それらを可能な限り関数型の手法で扱っている。最後にはTDDに従って、新たな機能を追加するところまでやっている。最後の最後には、かなり難易度が高めの実習問題が用意されている。今までの実習問題にはすべて解答が用意されていたのだけどここだけはは用意されていない。11章と12章をきっちり理解していたのなら問題なく解答できるものだったのだろう。今回はそこまでは到達できなかったとして未着手のままにしておいた。
## 11章を読んだ ➤ 関数型プログラムを設計する
かなり難しい。これまでの総まとめのような内容。現実的なアプリケーションを作成しながら、どれだけ関数型プログラミングが身に付いたかをチェックすることができる。作成するのはWikidataからデータを取得して観光名所のガイドを返すプログラム。要件は今までよりずっと複雑になっている。「まず動かし、正しく動かし、その上で高速に動かす」というアドバイスに従って、順に進められる。Wikidataというのは初めて聞いた。SPARQLというSQLに似ていないこともないようなクエリ言語に対し、結果をやや謎めいたエンコードされたようなフォーマットで返してくる。このサービスを利用するためにApache Jenoというフレームワークを利用する。これは命令型のライブラリであるが、関数型のScalaでも上手く統合できることを示す例となっている。
今まではかなり順調に進んできた感触を得ていたけど、最後近くに来てようやく壁にぶつかった感じになった。特に難しいわけではないが、ちゃんと理解できているのか、引っ掛かりを覚える。この章をスムーズにこなせないということは、おそらく全体として何かが欠けているような気がしてならない。その上、どこが欠けているのかもはっきりと自覚できなくてなんとも言えない気分になった。
## 10章を読んだ ➤ 並行プログラム
関数型プログラミングで並行処理について学ぶのは初めてだ。並行プログラミングで最も問題となる共有状態へのアクセスについて、関数型プログラミングはどのような答えを出しているのだろう。関数型プログラミングはイミュータブルな値しか扱わない。そのような制約の中で、共有状態への更新はどう考えればいいのだろうか。この本では、アトミック参照という手法をとっている。いくつかの手順を踏むことで、安全に値を更新することができる。もうこの段階まで来ると、IOやStreamは遠慮なく、当たり前のように使われている。順番に読み進めていなければ、この章を理解するのは不可能だっただろう。ちゃんとついていけるのが不思議なくらいで、読み始める前は想像も出来なかった。
ScalaにはAkkaというライブラリがある。これはアクターモデルであり、状態の可変性を基礎とするため、純粋関数の利点が損なわれてしまうと書かれている。Scala歴1週間にも満たない自分でも聞いたことがあるくらい有名なので、使うかどうかは別にして、いずれそちらもちゃんと触っておきたい。
## 9章を読んだ ➤ 値としてのストリーム
ストリームによるプログラミングには全く馴染みがなかった。前章のIOをさらに押し進めた発展的な内容となっている。また、これまでの関数型プログラミングのツールを総動員している。これまでのことをきっちり理解してなければ厳しいものになるだろう。逆に考えると、この章でつまずかなかったのなら、これまでのことをちゃんと理解できてきたのだと自信につながる。今に限ったことではないが、この本はまず例題として作成するプログラムの要件を提示して、それを関数型プログラミングの視点から分析する。そして、関心事を章の見出しに合ったものに絞り込んでいく。そのステップがあまりにも洗練されすぎていて、驚かされることが多々ある。確かに、書かれていることはなっとくできる。しかし、現実でこんなにきれいに問題を解決することができるのだろうかと思わされるところがなくもない。この章について言えば、あまりにもストリームがジャストフィットしている。関数型プログラミングの習熟度がどの程度になれば、これほど完璧な解が出せるのか、見当がつかない。なっとくするだけで終わるのではなく、できれば現実の問題に適用できるだけのものが欲しい。もちろん、なっとくもできなければその先に進むことも出来ない。まずはなっとくすることであり、そのための役割は十分すぎるほど果たしている。まずはなっとくすること、後は練習あるのみといったところか。
## 8章を読んだ ➤ 値としてのIO
副作用のある処理、信頼できない純粋でない関数をどうするか。
かなり手こずった。内容がどうこうという以前に、Scalaの環境を整えるのに手こずった。これまでと違い、信頼できないAPIをシミュレートするのに、Javaのコードが提供されていて、それをScalaから利用できるようにしなければならなかった。本書のサンプルコードはsbtのプロジェクトとして提供されている。そのままではREPLが使いにくいので、工夫する必要があった。最終的には上手くいって、しっかりと実習することができる環境が整った。
Scalaの標準ライブラリではIOモナドが提供されていない。この本ではCats Effectという外部ライブラリを利用している。このことが何を意味するのか、もしかしたら、通常のScalaのプログラミングではさほど副作用がある関数に対して神経質にならなくて良い場合があるのかと疑いを持った。しかし、この本は徹底して関数型プログラミングの流儀に従う。関数型プログラミングは純粋関数でイミュータブルな値を変換するプログラミングだ。副作用のある信頼できない関数をIOという値に閉じ込めてしまう。例えIOの中の処理が副作用を起こすものであっても、このIO自体は副作用を持たない。したがって、このIOを返す関数も、値を変換する関数も純粋なままである。最終的にはどこかでIOが実行されなければならない。Cats EffectのIOではunsafeRunSyncという関数を呼び出すことで、IOが実行される。この呼び出しだけが、これまでのIOに閉じ込めてきた副作用のある処理を実際に行うところとなる。つまり、副作用の発生するポイントをある一点にまとめてしまうこととなる。IOで記述した処理は、この呼び出しまで遅延する。本当にこれで関数を純粋に保つ原則を守ったことになるのだろうか。狐につままれたような気分だ。しかし、本当にそうなのだろう。経験を積めばきっとその価値がわかるようになると期待したい。
## 7章を読んだ ➤ 型としての要件
この章は関数型プログラミングにおける設計の章だといえる。要件とは何か。プログラムに要求される機能とでも言えばいいのだろうか。これこれができるように、一方こちらはこうでなければいけないといったもの。この章では、音楽アーティスト、メタリカとかツェッペリンの簡単なデータをモデル化して、検索するプログラムを開発していく。最初は、Stringを中心にプリミティブな型だけを使用して、とりあえず動くものを作る。それでは何が問題なのかを掘り下げながら、少しずつ保守の面でも使用する上でも扱いやすくなるように改良していく。最終的には、Stringなどのプリミティブな型はほぼ姿を消して、堅牢なプログラムに改造していく。その中で最も大きな役割を果たすのが代数的データ型、略してADTと呼ばれるもので、この章のもう一つの中心的な話題だった。
平たく言ってしまうと、関数の引数の型がStringとかだと何を表しているのかわからないし、何でも放り込めてしまう。もっと関心の対象と直結した新たな型を独自で定義して、守備範囲を狭めていくのが良い。関連性のあるデータは一つまとめた新たな型を定義する。そのためのツールがnewtypeやADTとなっている。この章ではエラー処理を全く行っていない。それは手を抜いているからではなく、エラーが発生し得ない設計になっているからだった。良い設計ができるようになりたければ、何かを設計してみる必要がある。それも大量に。練習あるのみ、というアドバイスが書かれている。これからプログラムを書くときは、常に意識をしていこうと思う。
## 6章を読んだ ➤ エラー処理
Optionを徹底的に学ぶ。前章までの、特にflatMapで習得した考え方をベースに、一歩々々丁寧に考え方を広げていく。最終的にはOptionをEitherに置き換えて、エラーの内容を伝搬させることができる理想的といっていいようなエラー処理が出来上がる。OptionからEitherへの切り替えの例示は見事としか言いようがない。
OptionはRustに大々的に導入されていているので、少しは馴染みがあるつもりでいた。そんなことは全然なくて、本当の価値を全く知らずにいたことをはっきりと認識することが出来た。RustのOptionはまず間違いなく、関数型言語を由来とするものだろう。関数型言語で本物のOptionを知ることは、Rustでの重要なエラー処理の設計にもきっと良い影響を与えることになる。また、多くの主流の言語でもライブラリでOptionのようなものをサポートするようになってきている。もしかしたら、エラー処理は例外からOptionに完全にシフトすることができるのかもしれない。今後のプログラミングの考え方に大きな影響を与える極めて価値の高い内容だった。
## 5章を読んだ ➤ 逐次プログラム
flatMapのための章。この関数はmapと入れ子になったListなど平坦にするflattenを同時に行う関数だ。flatMapは関数型プログラミングにおいてもっとも重要な関数であると位置づけている。そんなことは思いもしなかった。そもそも、この章のタイトルである逐次プログラムとなんの関係があるのかも分からずにいた。読み進めていくと、確かにflatMapが逐次的な処理を行うために重要な役割を果たすであろうことがわかってきた。
Listを例に取ると、まず、flatMapを連鎖させる必要性があるところから始まる。次に、2つ目以降のflatMapで、それより前のコンテキストで出現した中間値にアクセスする必要性があるケースが多発する。そのとき、flatMapを入れ子にすることで対処できる。しかし、入れ子にしていくと、命令型のコードの入れ子になったループのような見苦しいコードになってしまう。そこで、for内包表記という糖衣構文が用意されている。この構文を使うと、遥かに読みやすいコードになる。コンパイラは非常に賢く、for内包表記をコンパイル時にflatMapの入れ子に置き換えるそうだ。何も知らずにfor内包表記を使うことは可能ではあるが、この事実を知らずにいることは危険が伴う。もう一つ重要なのは、命令型言語のforループとは全く違うということだ。for内包表記は間違いなく式であり、値に評価される。そもそもflatMapと同じものであるのだから、当然だとも取れる。
最後に、Optionをfor内包表記で処理する手法が示されている。Listほどはっきりとした感触が掴めない。次の章がエラー処理なので、そのための準備でもあるのだろう。後でちゃんと理解できるようになることを期待したい。
## 4章を読んだ ➤ 値としての関数
かなり長い章だった。Javaは徐々に影を薄め、Scalaが存在感を増してきた。関数を引数として取る関数、関数を返す関数、関数を返す関数を返す関数、まとめると高階関数を学ぶ。sortBy、map、filter、foldLeftを通して、高階関数がどれだけうまく問題を解決できるかを体験することができる。関数を返す関数を返す関数は、そのままでは扱いやすいとは言えない。そこで、他の関数型プログラミング言語と同じように、Scalaにも強力なカリー化の能力が備わっている。関数のパラメーターを分離することによってそれが可能となる。Haskellがデフォルトでカリー化を行うのに比べると、専用の記法を使わないといけないのはやや冗長な感じはする。しかし、十分に洗練されていて、自分のような関数型プログラミングの入門者にとってはScalaの方が脳みそに優しい。もしもっと早くこの本と合わせてScalaに手を付けていたのなら、関数型プログラミングの学習もはかどっていたのにと惜しむところがある。
## 3章を読んだ ➤ イミュータブルな値
関数プログラミングとは何かを「イミュータブルな値を操作する純粋関数を使うプログラミングである。」と定めている。もし本当にこれだけで片付くならどんなに楽だっただろう。現実はそんなに甘くなく、このプログラミングのルールを貫くには多くの困難を乗り越えて、厳しいトレーニングを積まないといけないことは想像に難くない。でも、今のところはそんなに難しい話は登場しない。前章と同じように、命令型のコードにありがちな落とし穴を例に上げて、イミュータブルな値しか扱わない関数型プログラミングならそれを完全に回避できることを強調する。それだけ、イミュータブルであることは重要だということだ。最後に、イミュータブルなリストに慣れるための実習がある。Scalaは少し学習済みなので楽勝だった。しかし、この程度の問題が解ける程度では、現実のプログラミングに立ち向かうのはまず無理なことはよくわかっている。もっともっと先にいかないといけない。まだまだ序盤なので、この本を読み終える頃には少しでもそこに近づけていることを期待したい。
## 2章を読んだ ➤ 純粋関数
なぜ純粋関数が良いのかを手取り足取り教えてくれる。命令型のコードに潜む問題を提示するためにまだJavaのコードが多く登場する。一方、徐々にScalaへ移行しつつある。
## 1章を読んだ ➤ 関数型プログラミングを学ぶ
別の本でScalaの初歩を一通り学んだので、読み始めることにした。第1章は、準備段階と行ったところ。この本を読むのに必要な予備知識や、どのように取り組んでいくべきかが書かれていた。Scalaに興味を持ったきっかけが、この本のメインの言語であったことにある。実際に読んでみると、Scalaの予備知識は全く必要ないとしている。しかし、今ちょうどScalaの初歩を学び終えた状態で読んでみると、明らかにすんなりとコードや書いてあることの理解が進んでいるように思える。手を付ける順序は間違っていなかったと思える。 -
-
Posted by ブクログ
入門とタイトルの頭に付く本には、きっかけに丁度いい本と独り立ちするのに必要なだけの情報が詰まった本とがあるが、この本は前者なので安心して読める。
第8章でWebAssembly上で衝突検出の計算をしてHTMLのcanvas上にアニメーションを描画するためのWATプログラムが紹介されるが、この章までコードを写経して実行していくとだいぶ納得感が得られる。スタックマシンを意識したコードや線型メモリの扱い方などは慣れていなかったのでおもしろかった。章の順序も内容の順を追っていてよい。
9章移行にはパフォーマンスの計測、V8エンジンJavaScriptコードから出力するIRバイトコード、WebAssemblyコードのWATコードへの逆アセンブル、AssemblyScriptの紹介などが書かれていて、何も知らない状態からWebAssemblyの一端に触れるにはよい本だった。 -
-
-
-
-
Posted by ブクログ
ドワルケシュ・パテルという著者なAIポッドキャスターが司会と編集をして、下記のような技術者・学者・経営者たちがAIやAGIの技術進化について会話をするという本だ。
因みに彼は2024年TIME誌で「AIで影響力のある100人」に選ばれた実力者である。
書店の店頭で見た時、リモートとはいえ本当にこんなメンバーの意見が読めるのかとびっくりした。
司会の進行や質問も上手く、知りたいことを的確に聞き出す会話になっている。流石に各人の応えも正確で迫力がある。発言も慎重でその分リアル感が伝わってくる。
東大教授の松尾豊の「AI革命の本質を見る必読の書」の帯書きも読む気になった理由の一つだ。
読む程に朧げながら今足元で起こっているAIによる社会進化のうねりが伝わってくる。
さらに最も気になる、「何が、何時、どこまで変わるのか」について最先端で競争している人たちから直接聞けるのが何ともいえない。
今年6月に出たばかりの本だ。
参加者は
ダリオ・アモイ(Anthoropic共同創業者CEO)
デミス・ハサビス(Google Deepmind共同創業者
CEO)
イリア・サツケバー(元オープンAIチーフサイエンテ
ティスト)
エリーザキ・ユドコウスキー(AI安全研究機関MIRI共
同創業者)
マーク・ザッカバーク(Meta会長兼CEO)
ジョルト・ダグラス(Anthoropic強化学習インストラ
クチャード)
ジャリッド・カプラン(Anthoropicの共同創業者)
シェーン・レッグ(Google Deepmind共同創業者
AGIサイエンティスト)
・・・・
現在米ビックテックをはじめ、台湾・韓国・日欧、さらに中国企業が馬乗りになってAIやデータセンター関連の巨額投資を競っている。そのことが連日日経で報道されている。2026年の投資額は1兆3千億$(約200兆円)になるという。
LLM(Large Language Model 大規模言語モデル)が肝だ。テキストデータで訓練し単語(トークン)を確率分布で予測するニューラルネットワークで15兆回の試行錯誤で作り上げたもの。音声・画像・アミノ酸配列などあらゆるものに対応できる、フィジカルAIもAGIにも。
意味を問わない単なるデータ処理で会話を実現する。データの量、スケールが大きければそれだけ正確になる。アルゴリズムでなくスケールなのだ。
・開発者が「私たちは神を想像している」という
・LLMのさらなる進歩に必要なのが、チップ、電力
データだけだ。それらは十分に存在するのか
・計算量を増やせば予測ミスが減る
・知能の正体とは単にチューリングマシンにわたる探
索である
・知能とは私たちが学習し脳のなかに符号化している
膨大な数の特例の集積に過ぎない
・GPT-4をGPT-4たらしめているのはそのアーキテ
クチャの細部というよりも、産業的な発想とそれに
伴い投入される歴史的に前例のない規模の計算リソ
ースとデータである
・これらのモデルをスケーリングすればするほど、
少なくとも極限では、アーキテクチャやアルゴリズ
ムは重要ではなくなる
・画像生成進歩の大半はアーキテクチャによるもので
なく、すべてスケーリングによるものだ
・スケールこそがすべてである
・AIモデルをスケーリングさせるとは、突き詰めれ
ばその入力を拡大すること。まずは資金、次に大量
のチップ、膨大な電力、そして気が遠くなるような
データである
・AGIへの投資は「経済全体」を投じる価値がある。
現在世界経済は100兆ドルの規模で、年間50〜70
兆ドルの賃金が払われている、AGIが実現すれば
それがすべて自動化し、その先まで拡大する
・AGI超知能クラスタの必要性、人々は「GPT用の凄
い設備だ」くらいにしか思っていない
・知能爆発、AIがAIを改良し知能が指数関数的に向
上すること、機会学習研究の10年分の進歩を1年で
達成できる---AIはいかなるテクノロジーとも異質
・・・・・
AGI社会の到来について、時期・リスク・効用などあらゆる面からの会話には引き込まれる。読めば読むほど言っていることがイメージできて、心が凍る。
人類が発生以来経験してきたことが一変する。
技術的根拠にもとずいた彼らの議論は面白い。 -
-
-
