Error in user YAML: (<unknown>): could not find expected ':' while scanning a simple key at line 13 column 1
---
## 発表者のプロファイル
- 中村研二(@k2nakamura) 株式会社シグニファイア代表
- 大学在籍中にFreeBSD, Linuxにハマり、NEXTStepでオブジェクト指向を習得
- 93-97年 野村総合研究所で、UNIXとTCP/IP WANベースの流通業向け基幹システムの開発
- 97-00年 NRIパシフィックでシリコンバレー技術調査とプロトタイプの構築
- 01-16年 ベイエリアのスタートアップ数社で、通信・金融・知的財産の開発・マネジメントに従事
- Java, Groovy, Scala
- 08年 株式会社ディーバの米国開発拠点の設立
- 15年 フィンテックLOYAL3で、2億米ドル規模の米国証券バックオフィスシステムにClojureを適用
- 16年 Clojure+Docker+AWSをベースにビスポーク開発に特化した株式会社シグニファイアを設立
- 17年 開発に参画のプロジェクトがLegalWeek Innovation Awards 2017 International Law Firm Innovationを受賞
- サーバーサイド: clojure, ring, compojure-api, elastic search, redis, postgres, docker, rancher, AWS
- クライアントサイド: cljs, reagent, re-frame
--- - 82年バークリー音楽院卒業
- 92年 State Univ. of New York Empire State Collage コンピューターサイエンス専攻 卒業
- 詳細は本編で...
- 今晩は息子の結婚式が州外であるので、旅行してとんぼ返りしなければならない。
- 妻は100人Clojureを使ったらビックリといっていた。10年前には想像できなかった。
- 今日はClojureを書くに至った動機について話したい。
- 普通はマーケティング上おいしくないからこんな話はしない
- 自分に正直であれば、自分がその動機を知らないことが多い
- 今日は、自分が最初から計画を持っていたつもりで話しますが、もちろんClojureコミュニティと対話する中で、自分がやりたいことを意識するのに長い時間がかかっている。
- しかし、Clojureはopinionatedである！
- Opinionatedの一つの見方は、Clojureを使うときには、特定のやり方を強要されているように感じることかもしれない。しかし、それは少数のしかし強力な慣用法をClojureが持っており、そのやり方をサポートするライブラリがたくさんあるからだ。
- デザインとは選択であり、Clojureには意図的にやり残してあることがある。それは後ほど
- もうひとつのopnionatedの見方は、どうしてその意見にたどり着いたのかということである
- それは自分の経験から来ている
- 2005年にClojureの開発を始めたときには、既にアプリケーションデベロッパーとして18年間働いてきた
- その当時、プロのプログラマーが使っていたC++をメインに使用していた。
- 放送局向けのスケジュール管理システム
- 視聴者の時間帯に合わせた多次元の時間軸を考慮したもの
- 徐々に最適化していった
- 放送自動システムはオーディオの自動再生について。当時はDSPボードを使う必要があった
- 音声指紋システムは、ラックの中でラジオを聞き続け、曲の指紋をとり、プレイリストを作成したり放送局のCM統計のために使われたりした
- 音声の違いを声紋から抽出する
- イールド(とれ高)管理とは、飛行機、ホテルの部屋など、時間とともに消滅していく在庫を管理するためのシステムである
- 在庫の最適化が目的であり、全ての在庫を売るといった単純なゴールではない
- このころにCommon Lispを使い始めたが、エンドユーザーに使ってもらえるものではなかったので、アルゴリズムをSQLストアドプロシージャで生成するロジックをCommon Lispで書いた
- またスケジューリングシステムに戻り、当初はCommon Lispで書いたが、結局はC++で書き直した。
- 書き直すのに4倍の時間がかかり、出来上がったC++コードは5倍の量があり、そして実行速度はCommon Lispより速くならなかった
- このときに、自分がやっていることが間違っていることを悟った
- 友人が投票の出口調査のシステムを作っており、C#を関数型スタイルで書いて手伝った。
- その後、2005年から商業的なコミットメントを一切排除し、２年間の休暇を取り自分のやりたいことに集中した。
- Clojure
- マシンリスニングと人工渦巻管
- 一つしか終わらせる時間がないことが判り、Clojureに集中した。
- もう一つのプロジェクトはもともとCommon Lisp, Mathmatica, C++で書いていたが、最近もう一度触りはじめ、今回はClojureで全てを書くことができている
- Datomic
- ほとんど全てのプロジェクトでデータベースを使ってきた
- ISAM, SQLは多数
- RDFは何度も使おうとしたが、統合したのは数回
- データベースは今までのプロジェクトにおいて必要な本質的な機能
- LWW Lightweight language Workshop ... MITでの軽量原語の勉強会
- たまたま出会ったコンピュータ言語リサーチャーが、データベースに「堕落した」同僚についてバカにして話しているのを聞いて、ピザを喉につまらせるほど驚いた
- DBを使ったことがない人がコンピュータ言語を作れるのなら、自分にできないわけがない... Clojureを書き始めたキッカケ
- プログラムにはいろいろな種類があるが、自分が扱ってきたプログラムの種類について話したい
- 'Situated'プログラムという言葉を思いついた。外界と関わりを保つタイプのプログラムのことである。特徴として
- AWS Lambdaのように入力を受け取って計算し、出力したら終わりのプログラムではなく、長い時間動き続けるプログラムのことである。外界とつながって24時間無休で動くことが多い
- 30年前のプログラムが今も24x7で動いていると思うとぞっとする
- 「情報」を扱う。先程のスケジュール管理システムの例であれば、過去の放送内容、リスナーの嗜好についての調査データを合わせて将来のスケジュールを作成する。
- イールド管理であれば、過去の売上、時間軸で分析した売上を元に価格情報を生成する。
- 選挙システムであれば、過去にどのような投票があったか
- 全てのシステムについて共通しているのは、情報を取り込み、それを元に情報を生成しているということである。
- データベースは固定したデータを保持するのではなく、時間が経つとともに新しいデータを追加していく
- 自分のプログラムが生成した結果自体も追記していく。その情報は自分のプログラムで使われる場合もあれば、他のプログラムに提供する場合もある
- 現実の不整合に対応していくことがこの種のプログラムでは非常に重要
- スケジュール管理であれば、同じ曲、同じアーティストの曲を視聴者が聞いている時間軸の間に繰り返し流さないことが目的で、せっかくアルゴリズムで最適化しているのに...
- でもラジオ局が "Two for Tuesdays" キャンペーンで、火曜日だけは同じアーティストの曲を２回流そうとか言い出す
- 自分が心血注いだアルゴリズムが台無し
- この種のプログラムはほぼ全て他のシステムと関係を持っている
- また、人とのインターフェースもほぼ必須。
- スケジュール管理システムであれば、DJ向けに「スキップ」ボタンを提供したり
- 投票システムであればデータを多次元分析できるように表示したり、テレビに出ているデータを読み込んだりする
- 人と人が対話するのを手助けするのが大きな役割
- 自分はいまだかつて現場で使われているシステムが捨てられるのをみたことがない
- プログラムを書いた初日の条件がそのままであることはない。”Three for Thusdays"とか言い出されるかも (頭韻に注目!)
- 最近よく考えているのは、自分がスクラッチからプログラムを書くことはなく、他人が書いたライブラリを取り込まなければならず、またそれも変化していくということ
- 自分の経歴の中で一つだけ例外がある。それはClojure。言語は、外界の不整合を排除し、自分で作ったルールに従えばいい。
- 「使う人が意図していたり、期待している結果を生成すること」この言葉は重要
- Correctnessという言葉にうんざり。コンパイラ相手に型があっていると満足させればいいのか？
- 仕事で作ったプログラムで、そんなことを気にしているユーザーに会ったことがない。
- 一方、Hackingは使用する人の意図とは関係なく、やりたいことをなんでもやる、というイメージ
- 'Effective'を、Clojureのように企業向けのアプリケーションに使われる言語の目的として取り戻したい
- 自分にとってプログラミングとは、コンピュータを世界にとって'effective'にするための手段
- その結果、人が世界にとって'effective'になってほしい
- ミサイルの弾道計算など、純粋な計算が人の役に立つこともあるが、それは稀なケース
- 経験に基づいて推測力をつけること。穴や崖に向かって歩いていったり、吠えているライオンに向かって歩いていったり、マーケティングをしたり、手術の手順を考えたり、問題の分析をしたり
- 人は経験から学ぶからeffectiveである
- Effectiveであることはほとんどの場合、コンピューティングパワーではなく経験から来る推測力なのである
- Informationという言葉について自分が語ったことをあるのを知っている人も要るだろう
- 経験と情報と事実は同値であり、これらをプログラミングに持ち込むのが成功の必要最低条件である。
- プログラムは人をサポートしたり、置き換えることで、人がもっと意義のあることに集中できるようにするべきである
- 自分にとって、「プログラミングじゃないこと」は何か？
- プログラミングそのものじゃない。 定理を証明したり、型が自分が当初想定していた計画と一致しているかを気にしたりすることじゃない
- 面白い取り組みであるが、自分にとってのプログラミングではない
- バートランドラッセルは意地悪に見えるコメントをしているが、実際のところ、彼が言おうとしているのは、数学の価値を高めているということである。 数学はそれ自体への学問であり、型安全がペースメーカーの安全性につながるといってしまうと、それは数学の領域をはみ出しているわけだから。
- アルゴリズム・計算は重要だが、問題の一部に過ぎない
- 誤解しないでほしい。自分は論理が好きだ。だが多くの場合、論理の外側にうめものが必要である。
- プログラムにおいて論理は小さな一部で大多数は情報処理に割かれている。UIが入ればこの円はもっと大きくなっちゃうが
- グーグルの検索アルゴリズムだって、ページが表示されなければなんの意味も持たない
- 過去の経験では、情報処理の割合が必要以上に大きかった
- 何故か、それは言語の設計者が情報処理に重きをおいていなったからだ
- さらに他人の書いたライブラリも考慮しなければならない
- そしてデータベース
- プログラムとライブラリは同じ言語か、少なくともJVM上で動作するが、DBは明らかに違うメモリ空間と言語で動作している
- 何らかのワイヤープロトコルが必要で、DB独自の世界観がある
- 後述するが、従来のプログラムは「オレオレルール」にもとづいていることが多い。そして、プロトコルの差異を見つけると、自分が間違っていると考える代わりに、そのプロトコルを直そうとする。
- そのプロトコルは関係代数を元に作られているから、それを直そうというのは間違ったアイデアである
- プログラムは他のプログラムと会話する。別の言語でかかれているかもしれないし、それぞれ独自の世界観があり、プロトコルがある。
- プログラム同士をつなぐプロトコルとして使われるようになったのがJSON。いいアイデアじゃないね
- さらに、時間軸を考慮しなければならない。ルールが変わり、要件が変わり、ネットワークが変わり、ライブラリが変わり、プロトコルさえかわってしまうかも。
- これらを上手に扱えるのが、自分にとっての"effective programming" である
- Clojureだけが良い言語で、他の全てがダメというつもりはないが...
- 多くの言語は、汎用言語を目指して書かれている
- でも、コンパイラやデバイスドライバなどに最適化して言語を設計すれば、違ったアプローチになることは明白
- Clojureは情報駆動の外界に適合するプログラムのために設計されている
- 自分が過去にしてきたことはそれだし、友達もそう。向き不向きの問題なのだ
- プログラムにまつわる問題を視覚化したもの
- 過去18年自分がプログラムを書いてきてしっくりこなかったものを、プログラムの問題として取り上げた
- 一番上は世界自体が複雑なのだから、どうしようもない。
- 認識間違い。ここを上手く扱えなければ、成功するわけがない
- 下の2つは大したことがない
- 真ん中のブロックの緑色がClojureが解決しようとしている問題
- リソース管理はJavaのやりかたそのもの。
- Clojureがライブラリを記述するのに適した言語にしようとはしたが、ライブラリのエコシステムについては触れていない。昨年のキーノート"Spec-ulation"で述べたようにこれは、将来解決すべき問題と考えている。
- 18年C++とかでプログラムしてきて、もううんざり
- （会場で挙手してもらって）Clojureはビギナーと、疲れ果てて不機嫌になった年寄りプログラマのためのものかな？
- Common LispとC++を使ってわかったのは、LISPを使えば最初の2つは実現できる
- 過去の経験で、Common Lispを使おうとしたときはいつもプロダクションシステムに採用することができなかった、というか選択肢にすらならなかった。
- だから人々が受け入れてくれるランタイムをターゲットに開発しなければならないと悟った
- 言語が受け入れてもらうために満たすべき問題がある
- Clojureが受け入れられているとは正直まだ思っていない
- だが、パフォーマンスとディプロイについて答えを用意していなければ親しい友だちにも使ってもらえない。
- 既存資産の活用と互換性が大きな影響力を保つ
- LISPのカッコは問題ではない。誰でも一度はカッコにおののいた経験があるのは認めてもいいんだよ。
- 自分ならこの問題は容易に解決できると思っていた
- むしろ、S式はコアな価値の源泉
- 動的であること。C++で書いているとき、「コンパイルが通ったから多分動くよ」といっていた。それは今でも真実。Haskellでも真実。コンパイルが通ったからEffectiveなプログラムを書いたことにはならない。
- (PLOPについてはキーノート"Value of Values"で詳説されている。とりあえずレジスタ、メモリ、ディスクを書き換えるスタイルのプログラミングと理解してください）
- LISPはPLOPである。C++でマルチスレッドのアプリを書くのはほぼ不可能に近い
- 関数型言語とイミュータブルデータ構造がその答えであることは分かっていた
- パフォーマンスのでるイミュータブルデータ構造を見つけることがClojure開発の大部分を占めていた。
- パフォーマンスをリードで２倍、ライトで４倍に上げることが目標だった
- Chris Okasakiの論文を読んだが、完全な関数型アプローチでは満足できるパフォーマンスは得られなかった
- BagwellのHash Array Mapped Trie はイミュータブルではなかったが、自分が改良し、はじめて満足のいくパフォーマンスが得られた。
- 関数型プログラミングの慣用法を支える多くの純粋関数群
- 一番の障壁はカッコではなく、関数型の考え方。それをささえるためにたくさんのライブラリを書いた。
- 関数プログラミングのコミュニティの大部分は関数型言語=強い型付き静的言語、と思っているが、型は関数型言語に必須な要件ではなく、関数のメリットは80:20どころではなく、99%型を使わずに得ることができる。
- 静的言語でもっともイライラさせるポイント
- 情報の扱い方に手間がかかりすぎる
- 情報は事前には決まっていない。対象もなんでもあり。
- 時間が経つにつれ、事実は増え続けていく
- 名前を使う以外に情報を扱ううまいやり方はない
- 静的言語でしばしば困るのは、データが複数に分かれているときに、派生型を使うのか、別のデータ型を使うべきなのかはっきりせず、情報を組み合わせるうまいやり方がないことである。
- 情報を格納するコンテナを意味づけをするものとして格上げして使っているところに問題がある
- Personクラスに名前、Eメール、マイナンバーが入っているとして、その関係性はPeonクラスに含まれているという一点である。
- 多くの言語では名前がない。String, floatなど値の型のみ指定されており、名前がない。
- 名前を持つ言語でも、コンパイル時に取り除かれてしまう。First classではないので、名前を使って引数にしたり、ベクターを検索したり、名前を関数として使うことができない。
- 情報処理のために、合成代数を活用することができない。
- もともと他の目的のために設計された仕組みを用いて情報操作をしなければならない。
- 集合が意味を決定しているのは全くの間違い。たとえばWebのフォームで収集されるデータは、そのフォームによって意味付けが決まるのではない。フォームは単に情報を収集するためのデバイスに過ぎない。
- 結果として、巨大な「具象化」の塊をつくることになってしまう。
- Javaはメカニカルな問題を扱うのには適している。が、我々が扱うタイプのアプリケーションの記述に利用すると、情報のひとつひとつに対して型を適用していかなければならない。
- この中で、1500以上のクラスが定義されたJavaアプリケーションを見たことがない人がいる？
- 私の経験では、言語の種類に関わらず、小さな「オレオレルール」で作られた大量のクラスを作ることになる。
- 抽象化とは何か？抽象化を、名前をつけるものと教えている場合があるが、それは「具象化」である。関係代数、Datalog, RDFは抽象化である。Personクラス、Productクラスは抽象化ではなく具象化である。
- 一方Clojureが開発者に与えているのはMapだけである。クラスもなければ deftype もなし。
- Map操作を支える巨大なライブラリ、文法的サポートを提供しているので、連想配列を操作するのは直感的で、関数的で、パフォーマンスに優れている。そして汎用化されている。
- もし情報が複数システムに分散していたらどうする、Mapとして入手し、Mergeし、出力すればいいだけ
- Mapの一部しか必要でなければselect, select-keysでサブセットを取り出せばいいだけ
- 連想データに対して代数を適用することができる。
- 名前はFirst class. Keyword, Symbolは関数として連想配列の検索に使える。
- JavaやHaskellのパターンマッチングを学ばなくても、直接データを操作すればいい。
- Clojureでは集合に意味付けをするのではなく、属性に意味付けをする。
- Keyword, Symbolに意味づけすることが可能で、Clojure.specはまさにその作業を支援するためのもの。
- 個人的な経験では、型情報がシステムを後日メンテナンスし続けていく際の大きな障害となる。
- パターンマッチングはデータとコードと結びつけてしまっている。
- もっと些細な例として、引数リストなど、位置に依存しているもの。スケーラブルじゃない。17個の引数リストをとる関数を使いたいと思う人いる？（1人手を挙げ、「必ずこういう人が一人はいるんだよ」で笑）
- 現実的な上限は５つくらい？それを超えると扱いづらい。それを超えると型を分割しなければならない。
- 病院で、記入内容の説明が左、右に罫線だけのフォームを渡されることがあるけれど、いちいち行番号を引き比べながら記入するのはしんどいよね？
- 型は助けにならない。だって、x String, y float, みたいな情報しかないから。
- で次に出てくるのがパラメタゼーション。C++のテンプレートとか。でも限界があるのは彼らもすぐわかった。
- そこで出てきたのがSpring
- パターンマッチングはスケールしない。順序が重要なしくみでは、限度を超えるとついていけなくなって、やる気がなくなってしまう。
- Clojureは動的タイプ。情報を送る人、使う人だけがわかっていればよく、その間で情報を伝達する人はどんなデータタイプが送られてきているのか、考える必要がない。
- switch文やパターンマッチングを用いるより、defprotocol, defmultiを利用したランタイムポリモーフィズムのほうがメンテナンスが遥かに簡単
- Mapはオープン。静的言語みたいに、
Maybeを使ったりする必要はない。知らないデータがマップに含まれたら、触らずにそのまま - 情報は予め予測できないのだから、
Maybeなのは当たり前。 - マイナンバーの型はStringであって、
Maybe Stringなんてものは存在しない。データの型と存在をごっちゃにしている。 - データの入り口のプロトコルとして、そのデータが存在するかしないを判定することがあっても、
Maybeは型ではない。 - 宅配業者が僕にTVを配達するとして、トラックに他の人あてにどんな荷物が載っているか気にする？しないでしょ、それと一緒。
- C++, Haskell, Javaは複雑な言語
- Schemeほどではないが、Clojureは小さい
- ラムダ計算、関数と値だけ。継承も、パラメタも、拡張可能な型も存在しない。
- Cではクラッシュすれば自分のせいだとわかる。パフォーマンスも自分自身でコントロールできる。この点、ClojureはJavaと同格。制御できないことはあるが、そのかわりJava向けのYoukitプロファイラーなど、優れたツールを活用することができる。
- いよいよ自分が好きじゃないことの本質に入るよ。
- 今まで型について色々不満をのべてきたけど、それにParochialism（直訳：偏狭さ、意訳：「オレオレルール」）という名前を付けた
- 静的言語は継承とかの仕組みを通して、オレオレルールを強要してくる。
- 情報の表現の仕方は、その言語特有のローカルルールで表現することになる。
- 他の言語の考え方と融合しない。DBに送ったり、他のプログラムに送ったりするたびに衝突する。
- RDFはこの問題を正しく扱っている。例えば、同じメールを２回受けとったことあるでしょう？それは会社が買収されて、会社AはPersonテーブルにデータを持っていて、会社BはMailing_listテーブルに格納している。 合併してDBを統合しようとしても、その２つのテーブルが同じ情報を持っているなんてことは名前からはわからない。
- これは重要な問題。このテーブルのオレオレルールは、型について同じように当てはまる。
- 解決法として、RDFを統合データベースとして導入する。そしてその2つのテーブルの表す内容が同じであることを定義することで、最終的に同じメールが２度送られることを防げるようになる。
- 型システムを使えば使うほど、オレオレ度が増していく
- 汎用性が下がり、移植性が下がり、わかりやすさが減り、他のシステムから使いづらくなり、再利用性が下がり、柔軟性が下がり、他のシステムに通信した場合情報の追加が難しくなり、汎用的な操作を適用するのが難しくなる。
- Clojureには名前空間付きKeywordがある。
- LISPの一部と同様、KeywordとSymbolは独立したスカラ型である。
- コンパイルしても消えてなくならない。
- 逆引きドメイン・ネームは素晴らしいアイデア。まだ多くのClojureライブラリは採用していない。
- システム全体を考えた場合、他のシステムと通信しなければいけないのは必須であることはすぐわかる。
- リモートオブジェクトシステムを使ったことある人？ひどいでしょ？社外の人とリモートオブジェクトを使って通信なんかほぼ不可能
- 他のシステムが認識できるのは基本的なデータ型だけ
- もしClojureでリモートオブジェクトのようにロジックを共用したいとしたら？Ednファイルとして送ればいいだけ
- Common Lispを学んだときに最も感動した点
- 実際にプログラミングを書いたことがある人によって書かれたことが、Common LispとSmalltalkからははっきり感じられる
- 自分は遅くなって学んだので、特に感動した。
- 名前がプログラムの一部としてランタイムに残っており、tangible（実体として）感じられる。
- システムが大きくなれば、動的な特性は必要になる。Springがいい例
- Clojureを開発して気付かされたのは、JVMは非常に動的だということ。言語はC#と似ているかもしれないが、もともと埋め込み用として開発されており、外界に非常に上手く適応できる優れたプラットフォームである。
- もともとの設計がまだ生き残っていることに感謝している。
- JVMとCLRを比較すると、CLRは非常に静的言語向けに作られており、JVMは動的言語向けに作られていることがわかる。
- 関数型・イミュータブルデータ構造でほとんどの問題は解決済み
- このトピックについては以前のキーノートで説明済み
- しかし、このステート管理機能と他の機能の組み合わせで、友達に薦められる言語を作り上げることができたと考えている。
- 手軽に試せるだけがREPLの価値ではない
- REPLを自由なワイヤプロトコルと捉えるべき
- EdnをREPL経由でやりとりすることで様々な可能性が広がる
- 具象化の上に構築されている
- ClojureをCommon Lispのライブラリとしてではなく、一から書いたのは、ミュータビリティなど、土台となる機能に問題があるから。
- Listはかろうじて慣用的に関数的に使われている
- 他の構造は関数的ではない
- Listの実装がダメダメ
- packaging/interningが非常に複雑
- EdnはClojureの小さな一部ではなく、大きな役割を果たしている。
- Ednは共通言語として他システムの橋渡しをする可能性を持っている
- Simon Peyton Jones
- 型はある種のエラーがないことを保証するがSimon自身これは型を使うメリットの中で最も些細なものであると言っている。
- 機械によるスペック検証の機能は非常に限定的
- 型はデザイン言語であるという
- 最大のメリットはメインテナンス
- ほとんどの意見に反対
- テストはそれでも重要
- 型に意味はない。reverseという関数名を消したら、なんの有意義な意味も持たない
- UMLが好きな人いる？ この矢印はここに繋げないとか、制限が多すぎ。Omni Graffle使ったほうがはるかに簡単でしょう
- 500箇所のパターンマッチを型で検索して新しい型を追加できたところで、その情報はそもそもその新しい型が必要なコードにしか 有用ではなく、そもそもメンテナンスする必要がないはず。
- ここにいるのは年寄りプログラマが多いからあなたたちにはもはや関係ないかもしれないが...
- 若い頃には、頭に「フリースペース」があって、型システムを解くことはパズルのような興奮をもたらす。
- 検証は重要だが、アラカルトであるべき
- 予算、目的に応じて適用する範囲を調整できるべき
- SpecはDBとかWireプロトコルとかシステムレベルでより価値を発揮する
- 次バーションはプログラマビリティを向上させる予定
- どうやって運転するか、囲碁を打つか、説明できない
- 今や我々は説明できないものをプログラミングする時代に差し掛かっている
- 情報が駆動するモデル（ディープラーニング）が注目されている
- 情報をやり取りするための手段が必要
- TerminatorのSkynetコンピュータができれば要らないかもしれないが、今は情報処理が必要
- Clojureを意思決定の結果としてアクション部分に適用できるのでないかと考えている。
- 認識違いの部分にフォーカスする
- Clojureはこの目的に適した言語
- クルマの運転でも大変なのにその上でMonadやらなんやら考えている余裕ある？
- Clojureが他の言語と違うという事実を受け入れてほしい
- 型信者の脅しに屈しないでほしい
- 論理を使いこなせ、使われるんじゃない
- 設計はシステムレベルで行うこと。言語はプログラミングのごく一部に過ぎない
- ディープラーニングなどを活用してプログラムするプログラムの能力を活用してほしい
- 問題を解くべきであって、パズルを解くことに目的を置かないこと
- 今回の発表形式の改善点についてフィードバックをお願いします
- 次回はRich HickeyのValue of Valuesを取り上げたいと考えていますがいかがでしょう
- 今日の内容を社内でも共有したい方、出張講演しますのでご相談ください
- Clojureプロジェクトの導入、プルーフオブコンセプト、請け負います。ご相談ください
- @clj_nakanoのフォローと#clj_nakanoで拡散お願いします