(WIP) Problem Solving and Clojure 1.9 with Rich Hickey

Joy Clark: Hello, everyone, and welcome to a new conversation about software engineering. こんにちはみなさん。ソフトウェア工学についての今回の会話にようこそ。This is Joy Clark, and today on the CaSE Podcast I'm going to be talking to Rich Hickey about Clojure, and all of the reasons why Clojure is the way it is. 私はJoy Clarkです。今日のCaSE Podcastでは、Clojureと、その開発の方針について、Rich Hickeyと話します。Thank you, Rich, for joining me today. Rich、参加してくれてありがとう。

Rich Hickey: Thanks for having me. お誘いいただいてありがとう。

Joy Clark: We've had two episodes on Clojure so far - one with Alex Miller about Clojure, and one with David Nolen about ClojureScript (we'll link those in the show notes). この番組で以前にClojureについで2度扱いました。Alex MillerとはClojureについて、そしてDavid NolenとはClojureScriptについてでした。（それらへのリンクを記事につけます。） In this episode, for all the listeners who aren't that familier with Clojure, they can go and look at those. Clojureについて馴染みがないというリスナの方は、それらのエピソードを参考にしていただくことができますので、そうしてほしい。 But in this episode I want to concentrate on the Why question. 今回のエピソードでは、「なぜ」ということに集中して伺ってみたく思います。You are the creator of Clojure, so why did you write Clojure? あなたはClojureの作者ですが、なぜClojureを書いたのですか？

Rich Hickey: I wrote Clojure because if I had to continue programming in Java, I wouldn't still be a programmer; Java, or C++, or C#, or the languages I was using in consulting at the time. なぜ私がClojureを書いたかというと、もしJavaでプログラミングしつづけなければならなかったら、プログラマをやめていただろうからです。Javaに限らず、C++やC#などJava以外にも、私が当時コンサルティングに使っていた言語についてそうです。

RIch Hickey: I had become an independent consultant and I was still working primarily in C++, but I got to do some work in Common Lisp and realized how I'd been wasting my time for over a decade, and sort of got the bug to figure out a way to use a language like that professionally... And through many paths that eventually led to taking a sabbatical and writing Clojure. 当時コンサルタントとして独立してから専らC++を使っていました。しかしある仕事でCommon Lispを使うことになり、これまで10年以上の間にいかに時間を無駄にしていたか気づいたのです。そして、Common Lispのような言語を実務に使う方法を模索する気持ちになりました。そして様々なことがあり、長期有給休暇を取ってClojureを書く結果になりました。

Joy Clark: What problems was it designed to solve? Clojureはどんな種類の問題を解くために設計されましたか？ Why is it designed the way it is? どんな理由で、Clojureは今のような形に設計されたのでしょうか？

Rich Hickey: It's fundamentally designed to reduce the complexity in programming. Clojureは第一に、プログラミングの複雑さを抑制する意図で設計されました。I think programming is far too complex, and there are a bunch of things that make it so. 私はプログラミングはあまりにも複雑なことだと思うし、それをそのように複雑にしている多くの事柄が存在します。The domains are complex, and there's no way to get around some of that, but we have a lot of self-inflicted complexity. 問題ごとの業務知識は複雑です。そういったものの複雑さには避けようのないものもある。しかし、私達が自ら作り上げてしまった複雑さというのもたくさんあります。In particular in languages that aren't functional, the number one source of complexity is the use of state, so I knew I wanted to write a language that de-emphasized programming with "places", as I like to say (memory locations) and emphasized programming with values, like other functional languages. 特に、関数的でない言語らでは、状態を用いることが、複雑性の第一の源です。だから、私が好んで言う「場所」（メモリー空間）を強調するのではなく、他の関数型言語同様に、値についてプログラミングすることを強調するような言語を自分が書きたいということは、分かっていました。

Rich Hickey: Then there are other aspects of complexity that come into programming with any of these more commonly-used statically-typed languages, which have to do with the complexity in the language space. 複雑さにはまた別の側面があって、それは、一般的に使われている静的型付け言語らにおけるものです。それらにおいては、言語の空間の中で複雑さを扱わねばならない。I think there's a lot of just very idiosyncratic stuff in programming languages that is unnecessary, and not only it is unnecessary and causing complexity in terms of taking up your mental space to understand it and apply it, but it also has other costs in terms of yielding programs that are larger, full of more concretions, less general, and more brittle. 思うにプログラミング言語らには、必要ではない病的な要素があると思う。それは不要であるのみならず、それがもたらす複雑性は、理解するにも応用するにも認識の空間を無駄使いする。それに、プログラムを結果として大きくしてしまうし、具体性で満たしてしまい、一般性を失って、プログラムを脆くもする。

Joy Clark: We've had some episodes about Clojure running on the JVM and on JavaScript; what other platforms does it run on? この番組の過去のエピソードでは、JVMで動作するClojureとJavaScript上で動作するClojureとを扱いました。他のどんなプラットフォーム上でClojureは動作しますか？

Rich Hickey: There is a CLR port... CLR用のものがあります。I believe that's the only near-complete version of Clojure. ほぼ完全なClojureとしてはそれが唯一のものだと私は理解してます。

Joy Clark: Do you think there are any other platforms that it would be cool to run for it to run on the future? 将来、Clojureがその上で動作したら良いなと思うプラットフォームは何かありますか？

Rich Hickey: I don't think so. 別に無いなあ。Obviously, linkage to C is interesting, but I don't think there is as well-defined a library space there as there is for Java and .NET. もちろん、Cとの接続は興味をそそる。でも、Javaや.NETにあるもの以上にうまく洗練されたライブラリ空間というのは他にないと私は思っている。That was the main reason to target those. それがそれらをターゲットにした主な理由でもある。

Joy Clark: I heard there was some kind of Erlang port... Is there a possibility that that would be supported in the future? ErlangをプラットフォームとするClojureもあると聞いたのですが、それが将来、公式にサポートされる可能性はありますか？

Rich Hickey: Not by me. されるとしても私によってではないね。I'm happy to see people try things, but I'm completely uninterested in that.皆が色々なことを試みるのは嬉しいけれど、私自身はそれに少しも興味はありません。I don't know of any phenomenal Erlang libraries I'm dying to use. どうしても使ってみたいErlangのライブラリがあるとも私は思っていません。

Joy Clark: Do you regret putting it on the JVM? JVM上にClojureを置いたことを後悔していますか？ That's the main Clojure -- because people who use it are probably Java programmers, or are coming for that direction. JVM上のClojureがClojureの中心的存在ですよね。なぜなら、それを使う人々の多くはJavaプログラマですし、あるいはその方向から来る人でしょうから。

Rich Hickey: That's not actually true. 実際はそうでもありません。We get as many people coming from Ruby and Python as we do from Java. Javaから来るのに劣らない数の人々がRubyやPythonからも入ってきています。We get plenty of people from Java... But no, I don't regret it at all. Javaからも多くの人々が来ますが、そういったことで私がそれを後悔しているということは全くありません。It's probably one of the most important things to it having succeeded, because when people start with a new language that doesn't have libraries, they wait a long time to get up to the power level they expect by having access to libraries... And Clojure had libraries the very first day - you could use any database in existence, because jdbc existed and Clojure could use it. それはむしろ、Clojureが成功した最大の要因の一つでしょう。なぜなら、ライブラリのない新しい言語を使う時には、ライブラリがある場合に得られる力の程度に至るまでには長い時間待たねばなりません。しかしClojureには、その初日からライブラリがありました。Clojureを使う人は既存のどんなデータベースも使えたのです。JDBCが存在して、Clojureから使えたからです。

Rich Hickey: It's quite critical to the design of Clojure that it be hosted, and that it be hosted on a platform like Java. Clojureの設計においてClojureがホストされることはとても重要であり、Javaのようなプラットフォームによってホストされていることは重要です。 So I don't think that its interaction or dependence on Java (or Javascript, for the ClojureScript case) is a negative; I think it's a big positive. ですから、ClojureがJavaと（ClojureScriptについてはJavaScriptと）相互関係を持っていることやそれに依存していることを、私は否定的に思っていない。むしろ大いに肯定的に思っています。It does add something to what you'll have to become familiar with in order to be most productive. 生産性を最大限に発揮するためには修得しなければいけない知識を追加してしまう面はありますよ。On the flipside, you can be most productive, that's the point... As a pragmatic point, having access to libraries means you have power. しかし裏を返せば、最大限に生産的になる。そのことのほうが大切です。実用的な観点からすれば、ライブラリにアクセスできるということは、利用者に力をもたらします。

Joy Clark: Clojure 1.9 was just released... What's new in Clojure 1.9? Clojure 1.9が先日リリースされましたが、Clojure 1.9の新要素は何ですか？

Rich Hickey: At the language level it's mostly bug fixes and things like that, but one of the things that we've been working on is something called Spec. 言語レベルでは、更新はほとんどバグフィックスなり、そのようなものです。しかし私達が精力的に取り組んできたものの一つとして、Specと呼ばれる機能があります。Clojure.spec is a library for expressing what our program is supposed to do, and do they do it? Clojure.specは、私達が書くプログラムが何を期待され、実際に何をするかを表現するためのライブラリです。Like many things that come into Clojure more recently, is a library. Clojureに最近追加された多くのものと同様に、これはライブラリです。Clojure is a Lisp; as a language, by design, it's supposed to stay small. ClojureはLispの一つであり、言語として、設計として、仕様の小ささを保つことが望まれています。We shouldn't be modifying the language to accomplish new things... But we had architectural things to do so that Clojure itself could use Spec in its implementation a little bit, and that led to a bunch of work that is maybe hard to see, but quite important, around how Clojure consumes dependencies and things like that. 私達は、新しい物事を成し遂げるために言語をあれこれ修正するべきではありません。しかし建築のための道具については発展が求められ、例えばClojure自身もその実装のために多少、Specを用いることができる。それは明らかには見えない部分でのとても多くの作業を必要としますが、例えばClojureがどのように依存関係を処理するかなどに関連する、とても大切なことです。That's probably the biggest thing in 1.9, in the language. おそらくそれが、言語については、1.9での最も大きなことでしょう。

Rich Hickey: The other thing that came out with 1.9 is a set of tools. 1.9で追加されたまた別のものは、ツールのセットです。This is the first version of Clojure that actually has a brew installer, so you can brew install Clojure. 1.9はClojureがbrewインストーラーをちゃんと持った最初のバージョンですから、brew install clojureとしてインストールできるようになった。The other thing is has is a runner, which can analyze dependencies and create a classpath -- actually procure those dependencies, create a classpath and run your program. プログラムを動作させる機能も備わったので、依存関係を解析しクラスパスを作ることができます。実際に、依存するそれらを調達し、クラスパスを作成し、あなたのプログラムを起動することができる。

Rich Hickey: This is something that people had gotten from third-party tools, but we never really had a solution for newcomers who wanted to grab Clojure and use libraries on the first day. これらはすでに、Clojureを使う人達がサードパーティのツールをつかって行っていたことです。しかし、新しくClojureを始めようという人がClojureを一括してインストールして、すぐにライブラリを使いたいという時、従来私達は、そのための方法を提供してこなかった。

Jocy Clark: So the intention of the installer script is to make it easy to install on your machine, correct? つまりインストーラスクリプトの意図は、ユーザが自分のマシンへインストールする操作を簡略化しようという、そういうことですよね？

Rich Hickey: There's two aspects - there's the installer, which is just a matter of obtaining Clojure. ここには2つの側面があります。一つはインストーラであり、これは単に、Clojureを得る方法についてのことです。The more important thing is what you get when you run that installer. より重要なことは、そのインストーラを起動した時に何が得られるか、という点です。What you get are a set of command line tools that do this dependency-aware invocation of Clojure. 得られるのは、コマンドラインツールのセットであって、それにより、依存関係を自動解決する形でClojureを呼び出せます。So if you want to run anything on the JVM, you have to eventually call Java and provide it with a classpath. もしJVM上の何かを起動したくなったら、何にせよ結局はJavaを呼び出し、Javaにクラスパスを与える必要があります。And Clojure works by just supplying only Clojure on the classpath, but when you want to use libraries, they have to be put on the classpath, and you have to get them. そして、ClojureはClojureだけをクラスパスで提供すれば動作しますが、ユーザがライブラリを使いたいと思った時には、それらライブラリがクラスパスに含まれなければなりませんし、それによってライブラリを取得せねばなりません。And the whole getting libraries is a test that people usually rely on something like Maven to do for them. そしてライブラリの取得全体がテストになります。ライブラリの取得は人々が普段、Mavenなどに頼っていることです。

Rich Hickey: Then classpath building is something that, again, people had to go to other tools outside of Clojure, like Leiningen or Boot to do that. そして、クラスパスの構築はやはり、人々がClojure自体ではないツール、例えばLeiningen やBootに頼らねばならない部分でした。So the idea of getting started was "Get Clojure and get something like Leiningen and Boot and learn all of that." だから当初のアイデアは、「まずClojureと、それとLeiningenなりBootを手にして、それからそれら全てを学ぼう」ということでした。Now you don't have to, because the Clojure command line tools themselves can find libraries, download them, and incorporate them in the classpath. 今やそうする必要はありません。今では、Clojureのコマンドラインツール自体が、ライブラリを見つけ、それをダウンロードし、クラスパスにそれらを組み込む機能を持つようになりました。

Joy Clark: So Leiningen and Boot are like the Maven equivalent in Clojure, basically... So does the new installer replace that, or is it intended to replace it? そして、LeiningenとBootは、ClojureにとってのMavenに相当するようなものですが、基本的には。では、その新しいインストーラは、それらを置き換えるものでしょうか？　置き換えることを意図したものですか？

Rich Hickey: No, not exactly. そういうわけでもありません。I think one of the problems is what it is; those things (and Maven) do a lot. 思うに、問題の一つはそれが何であるかという点です。それらは（Mavenを含め）多くのことをします。Most of them allow you to express your dependencies, and they can procure dependencies, and they can form the classpath, and they can be a runner and run Clojure with that classpath, but they also can build generally, and/or deploy, and make uberjars and all of that... And that aspect of Maven, and similarly in these other tools, turns them into kind of large, monolithic things... And another big part of what we're trying to do with this dependency stuff is to separate out and decompose that problem and say "This part that we've delivered is strictly about dependencies and classpath generation, and it doesn't do any building, or anything like that." それらのツールのほとんどは依存関係の表現を可能にしますし、また、依存関係の調達も担います。そしてクラスパスを構成することもするほか、動作させるプログラムとして、そのクラスパスと共にClojureを起動することもする。のみならずそれらツールは、ビルド作業一般を担いますし、デプロイ機能も持ち、uberjarを作る機能も持ち、それら全てを行う。Mavenのそのような性質、またMavenに似たそれらツールのその性質は、それら自身を、巨大なモノリシックなものにしてしまう。一方で私達がそういった依存関係の物事について試みているのは、問題を切り分けて分割し、「今回提供したこの部分は単に依存関係とクラスパス生成を扱い、ビルドなどその他のことは行わない」と言ってみせることです。 So you still might want a tool like that to build your final deployable thing. ですから、例えば最後にデプロイ可能なものをビルドするため、そういったツールは今後も必要になることがあるでしょう。

Joy Clark: Are there any ideas in the future about providing something similar for ClojureScript, so you can never have to go into npm hell ever again? 同様のものを将来、ClojureScript向けにも提供しようという考えはありますか？ npm地獄に再び陥ることのないようにするために。

Rich Hickey: I think that the problem of dependencies is a big problem; it's one of the unsolved problems right now for programming, and I've been thinking a lot about it. 依存関係についても問題は大きな問題であると私は認識しています。これはプログラミング一般にとって未解決の問題の一つであり、私自身、このことについて以前から考えつづけてきました。This is on the path towards that. その方向に向かってはいます。One of the other things that you can do with this new dependency stuff is directly consume code from Git repos by using Git SHA's as your dependency, as opposed to an artifact in a place. この新しい依存関係の問題について私達が行える方法の一つは、ある場所にあるアーティファクトによってではなく、GitのSHAで依存関係を表して、Gitリポジトリから直接コードを取って用いることです。It's an addition to that; it can consume Maven still. これは従来の方法に対する追加的な機能になるでしょう。Mavenも使えるものとなります。But the other thing that we did was sort of decompose or decomplect transitive dependency analysis, which most of these tools rely on Maven to do... But Maven only understands Maven and only navigates through Maven dependencies. しかし、私達が行ってきたまた別のことは、推移的な依存関係の解析をを分解してほどく種類のことであり、それらのツールのほとんどはこれをMavenに依存して行っています。しかし、MavenはMavenしか理解しませんし、Mavenの依存関係しかナビゲートしません。

Rich Hickey: We now have lifted the transitive dependency analyzer out so that it can traverse through Maven dependencies, but also through Git and through more than one way of representing your dependencies. - whether it's a POM or a project config file, or the new format that these tools use, which is called deps.edn. 私達は今では、推移的な依存関係の解析機を取り出して、Mavenの依存関係を辿れるのみならず、Gitについても辿れるようにして、複数の方法で依存関係を表せるようにしました。その表現方法は、POMであってもいいし、プロジェクトのコンフィグファイルであってもいいし、今回のツールが使う、deps.ednによる表現であってもいい。So this is super important, and it takes us towards where I'd like to us go, which is a stronger connection between what we're consuming, and the source truth of that. ですからこれは非常に重要ですよ。これは私達を、私が望んできた方向へ進ませるものです。つまり、私達が利用しているプログラムと、それに本当に対応するソースコードとの、より強固な繋がりがもたらされます。

Rich Hickey: I think a big problem is you grab a library and you really have no idea what you've gotten. 私が大きな問題だと思っているのは、あるライブラリを取得した際に、取得したものが何であるか分かりようがないということです。Maybe it has a label, it says it's 1.2, but you don't know which functions inside it have changed, or why... You don't actually know what you're running, and maybe the jar file or artifact tells you something about the source that was used to produce it, but the process that was used to produce it is often opaque, and any of that could be wrong because there's a lot of human steps involved in producing artifacts. そこにはラベルがあって、1.2と書いてあるかもしれない。しかしその中のどの関数が変更されたか、なぜ変更されたか知りようがない。ユーザは、自分がどんなプログラムを起動しているのか実際には知らない。そのjarファイルやアーティファクトは、それを生んだソースについて説明してくれるかもしれません。しかしそれを生む過程はしばしば不透明であり、アーティファクトを出力するには人間による過程を多く踏むから、どう間違っていないとも限らない。And because so many people use Git, I'd like to get closer to leveraging some of the features there, in particular using SHA's and content-based addressing to talk about things. そしてあまりに多くの人がGitを使ってますから、そこにある機能を私としては活用したい。中でも、SHAを使い、物事について、その内容に基づいて語ることを活用したい。

Rich Hickey: I had worked on a library called Codeq, which we'll have a new version of soon, that sort of extends the Git model down to the function level, so you would have SHA's for individual functions and you could have dependencies on functions, instead of on artifacts. 私はCodeqという名のライブラリについて作業することもしました。その新しいバージョンがまもなく完成しますが、そのライブラリはGitのモデルを拡張して関数の段階まで下げたものです。それを使えば個々の関数についてSHAが得られるから、アーティファクトによらずに関数の依存関係を解決できます。So a lot of work is happeningn around that, and some of that manifests itself in this dependency tool. だからそれについては多くの作業が必要でしたし、この依存関係についてのツールにあるマニフェスト自身についても作業が必要でした。

Joy Clark: I'm thinking about dependencies and what happens when I upgrade my dependencies, like in my Java project, and I get a whole bunch of compiler errors... But in Clojure they would be runtime errors, right? 私が考えてきたのは、依存関係についてで、依存関係をアップグレードした時に何が起こるかという点です。Javaプロジェクトにおいては、大量のコンパイルエラーが置きます。でもClojureの場合には実行時エラーになりますよね？ How do you deal with that? それに対してどうしますか？ Because Clojure is a dynamic language, it's not compiled; when you upgrade a library and it's incompatible, how does Clojure know what happens then? Clojureは動的言語ですから、コンパイルされない。ライブラリをアップグレードした時に整合性がなかったら、その時に何が起こるか、Clojureはどうやって知りますか？

Rich Hickey: Well, there's a lot of presumptions in that question. うむ、その質問には多くの仮定が含まれている。

Joy Clark: There are... There are a lot of presumptions. 多くの仮定が、含まれていますね。

Rich Hickey: The first thing I would say is what you're talking about are symptoms, right? 第一に指摘しようと思うのは、それは症状についての話題だということです。そうでしょう？ The problem is not that the problems are found later or earlier, or that they manifest themselves as compilation errors or runtime errors, but the fact that your libarary provider broke your program. 問題なのは、問題が遅く見つかったか早く見つかったかということではなく、問題がコンパイルエラーとして現れたか実行時エラーとして現れたかでもなくて、そのライブラリの提供者があなたのプログラムを壊したということにある。 That's something I don't think should happen nearly as often as it does, and is actually quite avoidable, but unfortunately we still do place-oriented programming in the library space... So you could say that library Foo is a place, and every time I look at that place, I find a different library... And sure enough, the values are changing out from under me, and the things I depended upon are no longer true. それは稀にも起きるべきことではないし、大いに回避可能なことだ。しかし不幸にも私達はまだ、ライブラリの空間において場所指向のプログラミングをしている。だから例えば、ライブラリFooは場所であって、自分がそこを見るたびに、そこには異なるライブラリがある。そうして案の定、私のコントロールを抜けて値は変更され、私が前提としていた物事が今や事実ではなくなる。

Rich Hickey: When a library breaks, it can break in many ways. ライブラリの壊れ方には色々な壊れ方がある。Some of those may or may not be manifest in types, others would just be manifest in behavior, or missing information, or additional requirements - things that you can't express in types, because most of what your program needs to do can't be expressed in the type systems we have today. そのいくつかは型の問題として起こるかもしれない。でも他のものは動作として、あるいは情報の欠落として、あるいは要求の追加として起こるかもしれないから、それらは型では表せない。なぜならあるプログラムが実現すべき動作のほとんどは今日使われている型システムで表せるものではないからだ。So yes, it still takes a string and still returns a map of information, but it stopped returning you some of that information, or it started returning other stuff, or it had additional requirements about the string... No, the types don't capture that. だから実際あるプログラムは、文字列を取って情報のマップを返しつづけるかもしれない。でもいくつかの情報を返すことをしなくなるかもしれないし、他のものを返すようになるかもしれないし、取る文字列について要求が追加されているかもしれない。それらの問題は型によっては捉えられない。

Joy Clark: Does Spec help with that problem, of knowing what actually goes into your function and what comes out? Specはその問題の手助けとなるでしょうか？ 自分のプログラムに実際に何が入力され何が出力されているのか知るために。

Rich Hickey: There are a couple of different problems here. ここにはいくつかの異なる問題がある。If we stick at the library level, one of the problems is breaking things, and I think one of the problems we have is that we think about change generically, as if change was a thing... But there are really two very distinct kinds of change - there are breaking changes, where your expectations have been violated, and there are accretions, where there's just some more stuff where there wasn't stuff before. And in general, accretion is not breaking. ライブラリのレベルに注目して見ると、問題の一つは物事が壊れてしまうことだ。私が思うに問題の一つは、変更というものをまるで物のように、区別せずに考えてしまうことにあると思う。しかし実際には、2つの非常に異なる種類の変更がある。破壊する変更があって、そこでは、ユーザが期待していた前提が侵害されてしまう。もう一方は、付け足しだ。以前はなかったものがそこに加わることだ。そして概して、付け足しは破壊的ではない。

Rich Hickey: If I had a library I was using and it had functions A, B, C, and version 1.2 of the library added functions X, Y, Z, my code that used A, B, C is unaffected by that. もし私があるライブラリを使っていて、その中の関数A、B、Cを使っており、そのライブラリがバージョン1.2になって関数X、Y、Zが追加されたとしても、A、B、Cを使っている私のコードはそれによって影響されない。So if you take that idea of what accretion means, you can now apply that to things like argument lists or return values, and you can start talking about what a function either requires, or provides. 付け足しのそういった意味を知れば、引数リストや戻り値についてその考え方を適用できるようになるし、ある関数が何を求め何をもたらすかについて会話することができるようになる。

Rich Hickey: Let's say I had a function - one of those A, B, C - that already exists and you're already calling, and I wanted to enhance it. 例えば、私がそのA、B、Cの中の一つの関数を持っていて、あなたがそれをすでに呼んでいて、私はそれを拡張したいのだとしよう。Well, if I require more from you than I used to, I've broken you. その時、もし私が従来よりも多くをあなたに望んだならば、あなたを壊すことになる。If I require less from you than I used to, I haven't. 従来より少なくあなたに望んだならば、壊すことはない。On the return value side, if I provide more to you than I used to provide, I haven't broken you. 返り値の側について考えるなら、従来より多くあなたにもたらすなら壊さない。But if I provide less, then I have (if I provide less than I used to promise).もし従来より少なく、（つまり私がかつて約束していたよりも少なく）もたらすならば、壊してしまう。

Rich Hickey: So there's a real directionality to the contracts of functions and code, and there are changes you can make in both directions that are compatible with exisiting consumers, and changes you can make that are not. だから関数やコードの契約には確かな方向性がある。だから変更というものには、既存の消費者と整合性のあるものがある一方で、そのような整合性のない逆方向のものがある。And when you understand that you're either adding requirements breaks and removing requirements doesn't, and provideing more doesn't break, and providing less does break, then you could say all the non-breaking changes are evolution-compatible. そのことを理解したなら、行うことは、要求を追加して壊すか、要求を撤廃して壊さないか、より多くもたらして壊さないか、より少なくもたらして壊すか、となって、それら非破壊的な変更は進化に整合的だと言える。They allow programs to evolve, they allow them to evolve independently, which are supercritical properties for systems to run over a long period of time. それはプログラムの進化を許す。プログラムそれぞれの個別な進化を許す。このことは、長期に渡って稼働するシステムにとって非常に重要な属性だ。

Rich Hickey: I think that it's a big mistake to say "Well, static types allow me to break people and they can figure it out." 「静的な型は私が人々を壊すことを許し、彼らはそれを検出できる」と言うならそれは大きな誤りだと私は思う。That's exactly what you don't want to do. それはまさにあなたがしたくないことだ。So I would say that if you're going to break someone at all, just don't, and call the function D, or A2, and leave A around. だから私が言いたいのは、もしあなたが結局誰かを壊すことになるなら、それをすべきじゃないということだ。関数DなりA2なりを呼ぶようにして、Aはそのままほうっておけばいい。These are the same kinds of strategies that we use at the sevice level in order to have loosely-coupled systems that don't break consumers and allow consumer clients and servers to independently evolve, and it's just as important in the small. それらは私達がサービスレベルで使う種類の戦略と同じだ。私達はサービスレベルで、消費者を壊さず、消費するクライアントとサーバとが独立に進化できる緩やかに組み合わさったシステムを実現するためにその戦略を使うが、それは小規模な事柄についても同様に重要だ。

Rich Hickey: I think that it's, again, sort of a big problem that we think about change generically, and we think about typing tools as tools to enable breakage, and that makes for brittle programs... And it was certainly my experience before Clojure, working with static type systems that all the systems were incredibly brittle, and eventually the costs of change just got so high... Every system eventually got thrown away because the costs of change became too great. 思うに、すでに言ったように、変更というものを区別せずに捉えてしまうことが大きな問題だと思う。変更を区別せずに捉え、型ツールを破壊を可能にする道具として捉え、そのことが脆いプログラムを生んでいる。これは実際、Clojure以前に私が経験したことで、静的型付けシステムで作業していたが、全てのシステムは信じられないほどもろかった。結局、変更に要する費用はとても高くなって、しまいにはあまりにも巨額になってしまって、どのシステムも投げ捨てられる。

Joy Clark: So in these functions you would usually take a map and return a map? 仰るような関数においては、一般に、マップを取りマップを返すことになるのではありませんか？ Because I can imagine that even if I were to change a function and say "Oh, I need something else", if I change the arity of the function, that's also breakage. 関数を変更しようとする時に、「別のものが必要だ」と言って、関数のアリティを変更したら、それだけでも破壊的だと考えられます。I mean, I can put another function next to it, or make it a vararg function... But essentially, every time I need something new, I personally would go for creating functions with a couple of arguments, as opposed to putting everything in a map, but maybe that's not the best way to do it... なのでそれを避けて、その関数の隣に別の関数を置いたり、可変長引数関数に変更することはできます。しかし基本的には、新しいものが必要になった時には私自身はいつも、いくつかの引数を取る関数を作るのであって、何もかもマップに詰めることなどしません。それは最善ではないのかもしれませんが。

Rich Hickey: So it ends up being the case - and this directly connects to Spec and to your question from before... だから結局場合によるという結末になる。そしてこのことは、Specに直接繋がり、あなたの先ほどの質問にも繋がります。You know, is Spec in this space, trying to contend with these challenges of allowing you to talk about what your program does and determine that it works, and allow you to communicate to consumers about your contracts? Specがそのような課題と戦うためのものであり、プログラムが何を行うか、それが実際に動くかを記述可能にするものであるか、あなたがあなたの消費者とあなたの契約について対話することをSpecは可能にするか、ということですよね。It does, in fact, and the way it does is it allows you to talk about either function signatures or data structures using one of two logics. 実際Specはそれを行います。1つか2つのロジックによって、関数シグネチャやデータ構造について語ることを可能にします。One would be a set logic around maps and map keys, and the other would be regular expressions for things that are sequential, like function argument lists are an example of a sequential contract. 片方はマップやマップのキーについての集合論理かもしれません、もう片方は、関数の引数リストなどのシーケンシャルなものについてシーケンシャルな契約を表すものの一つである正規表現かもしれません。

Rich Hickey: And it ends up in both spaces, those ideas I talked about before, about requiring less or providing more - both apply. だからどちらの話題にせよ、私が先ほど言った考え方に、つまり、より少なく要求するか、より多く供給するという考え方に合致します。If you think about a set of keys, if you're accepting that as an argument, then to require more keys would be breaking, but to require fewer keys would not. 例えばキーらのセットについて考える場合に、それをある引数として受け入れるなら、より多くのキーを要求することは破壊的です。しかしより少ないキーを要求することは破壊的ではない。If you're returning maps, then to return more would be non-breaking, and to return less, at least about the things you promised you would return, would be breaking. マップらを返すという場合には、より多く返すなら非破壊的であり、一方で少なく、少なくとも以前に返すと約束したよりも少なく返す場合には、破壊的たりうる。So the same ideas apply, so you can talk about maps and you can -- well, we're still working on the language to make it precise to talk about providing and requiring certain keys. だから同じ考え方が使える。マップについてそれが言えるし……。うん。あるキーを供給するかとか要求するかということをこの言語の上に正確に表現する方法については、私達はまだ作業中です。

Rich Hickey: The other thing is in the regular expression space there's also a notion of regular expression compatibility, which is to say there is logic behind regular expressions that allows you to say that this regular expression can accept all things this other one could, but maybe some additional things. もう一つの論点は正規表現の議論です。正規表現の整合性の記法があります。正規表現の背後にある論理を用いれば、この別のものが受け入れるものは全てこの正規表現で受け入れるし、さらに追加のものも受け入れうる、ということが表せます。And you could leverage that logic to actually make non-breaking changes to function arity... それによって、関数のアリティに対する非破壊的な変更を実現する論理を活用できます。For instance, if you could take two arguments before and now you could take two or three, you haven't broken anyone as long as you haven't changed the meaning of what it means to pass two. 具体的には例えば、以前には2つの引数を取ったとして、今や2つないし3つ取るとする。2つ取る場合の意味さえ変えないならば、あなたは誰も破壊せずにすむ。You've just enabled people to be able to pass three. あなたは単に、皆が3つ目の引数を渡すことを可能にしただけだということになる。

Rich Hickey: I think it's essential for people to start understanding what it means to provide or require, and to look at their changes in that light. 私が思うに、供給ないし要求するということの意味を理解しはじめるためにこれは不可欠です。この観点で変更というものを見る必要がある。It's certainly one of the long-term objectives that for Spec we will take the expressions you make in Spec about providing and requiring, and turn that into a test for change, to say "If I wanna modify this spec and it's a spec about requiring, is it compatible or is it breaking? If it's breaking, we won't allow it." このことは疑いなくSpecの長期的目標の一つです。供給と要求に関するSpecのあなたの式を受け取り、変更へのテストに変換して次のように言う。「もし私がこのspecを変更しようと思った時、このspecが要求のためのものであるなら、この変更は整合的だろうか、それとも破壊的だろうか？　もし破壊的なら、その変更は許されない」 And same thing flipped around on the return side. そして、返り値についてもちょうど逆のことが言えます。

Joy Clark: What does Spec look like? Spedはどんな見た目ですか？

Rich Hickey: Spec is a predicative language about data. Specはデータについての述語的な言語です。So much in Clojure is data; we express all of our information as generic data, we write code as data structures, we use data structures as domain-specific languages for configuration, or HTML, and pretty much everything. Clojureにおけるとても多くのものがデータです。私達は、全ての情報を総称的なデータとして表現する。コードをデータ構造として書きますし、ドメイン固有言語をデータ構造によって表し、設定情報やHTMLなど、多岐にわたるものを表している。

Rich Hickey: The idea is to have an open system that is not limited to any particular logic or static verifiability, but to say, any predicates you want, you can write regular Clojure code, and you can basically say what you consider to be required to be true of a data structure. 根本的な発想は、特定の論理や静的検証へと制約されない開放系にしようということです。ただし例えば、どんな述語をあなたが欲するにせよ、普通のClojureのコードを書くことができる。それによってあなたは、あるデータ構造について、本当はどんな要求があると思っているのかを記述できる。And you do that either in the small, with assertions about the types of atomic things, like numbers, or booleans. そしてそれを、一方では、小さなものに適用できる。数や真偽値などの単位的なものの型のアサーションなどですね。Then in the large, you use one of these other two techniques, talking about either maps and the sets of keys associated with maps, or with regular expressions for sequences. 一方では大きなものについては、2つの技法の片方を使う。マップかセットかマップに関連づけられたキーらによる技法と、シーケンスに関する正規表現という技法。

Rich Hickey: Most of the sequences -- people tend not to use sequential things in like wire protocols or service contracts, because they're terrible; they're very brittle. 配線のプロトコルや、サービスの契約にシーケンシャルなものを使えば脆いから、皆、そういったものにシーケンシャルなものを使おうとはしません。But we do still use sequentiality in function signatures, so it's necessary for that. しかし私達は、関数のシグネチャについてはなおシーケンシャルに利用してますから、そのために必須です。

Rich Hickey: So you write those expressions, and it's just like a little domain-specific language... よって、あなたはそういった式を書く。それらはドメイン固有言語の一つであるかのようです。But it's independent of the Clojure code. しかしそれはClojureのコードからは独立している。You can write specs for things that you wrote, or things that other people wrote and they haven't spec-ed themselves... あなたは自分で書いたコードについて仕様を書くこともできるし、他の誰かが書いたが彼ら自身では仕様を書かなかったコードについて、仕様を書くこともできる。If you're trying to understand a library, you can write some spec expressions about it and see if they hold, and the first job of Spec given one of these specs is to do validation, which is what you would expect. もしあるライブラリを理解しようと思ったときに、それについて仕様の式をいくらか書いて、矛盾が出ないか見ることができる。そしてその仕様の式についてSpecが始めにやることの一つは、普通予想されるように、検証をすることです。"I have this predicate about this data structure - is it true of this particular value?" 「このデータ構造について私はこの述語を用意しました。ある値について、この述語は真ですか？」と。

Rich Hickey: But Spec does a lot more, because it also does generation - it can generate data satisfies the predicate. しかしSpecができることではそれだけではありません。Specは、ある述語を満たすデータを生成できます。So you can say "I have this function, and I said it returns this shape", and you can say "exercise this spec" and it will generate a bunch of those shapes. だから例えば、「こういう関数がある。この関数はこういう形を返すという仕様がある」と言い、「この仕様を実習して」と言うと、Specは大量にその形を生成する。And that's the underpinnings of the next feature, which is that Spec supports generative testing, QuickCheck style testing. そしてそれが次の特徴の土台になる。QuickCheckの方式の、生成的テストをSpecはサポートします。So if you spec some or all of your code - and it's not a type system, it's not necessary for it to be complete or for there to be types everywhere; it's not like types, it's really predicates... もしあなたのコードの一部あるいは全体をspecするとして……。これは型システムではありません。不可欠ではないし、完全である必要もない、全てを型付けする必要もない。これは型のようなものではなく、全く、述語そのものなのです。But for whatever predicates you've defined on functions, Spec can automatically generate data to test those functions, taking it through a random space, and validate the function's work, that they are returning what they say they will. 関数らにあなたがいかなる述語を定義したとしても、Specはそれら関数をテストするデータを自動生成できます。乱数の空間を通過させ、関数らが返すと称している値を関数が実際に返すか見ることで、関数が正しく動作するか検証します。

Rich Hickey: And remember, these are arbitrary predicates, so the predicates of what you return can include what you put in as port of the argument, so you actually can spec the behavior of a function, as opposed to just its return value has some particular shape. そして思い返してほしいのは、specは任意の述語であってよいということです。ゆえに、ある関数の返り値についての述語には、対応する引数への言及を含めることができる。よって実際には、関数の振る舞いをspecすることができるということになります。これは、その関数の返り値が特定の形を取っているかだけ検証するのとは異なるということです。You can for instance make sure that, you know, if you were passed a collection coming in, every member of that collection coming in is present in the collection going out... 例えば、あるコレクションを受け取った時に、そのコレクションの全ての要素が、その関数が返すコレクションにも含まれているということを、あなたは保証できます。And various other value things like that. 値一般に関して同様に様々なことを保証可能です。

Rich Hickey: The idea behind the testing is that these validations and these tests are not for production runtime. テストを行うことの背後にあるアイデアは、これらの検証やこれらのテストはプロダクションの実行時のためのものではないということです。All the tools are set up to allow you to do this work prior to release... 全てのツールは、リリースより前にこの作業ができるように作られています。That it's part of the development time, and testing phase of development. つまり、開発時や、開発時のテストのフェーズのためにね。And all the checks and everything are turned off at runtime. そして全てのチェックその他全てが実行時にはオフにされる。You can still use Spec if you want to, to be a gatekeeper on the end of a wire, for instance because you can use Spec to define specs for wire protocols and communications protocols, so that's something you might want to leave in in production. もしも使いたければ実行時でもSpecを使えます。例えば、通信プロトコルのspecをSpecで定義できるから、プロダクション後にもそれをオンにして、処理の末端の門番として利用することはできます。But otherwise, there's no overhead associated with using Spec. しかしそうしない場合には、Specを使うことによるオーバーヘッドは生じません。

Joy Clark: So at production runtime you assume that you've done so much generative testing that the functions must be the correct specifications, so we don't have to do the same checks during runtime, at production? つまり、プロダクションの実行時については、存在する関数らについて十分に多くの生成的テストをすでに行ったから関数らは正しく仕様に従っているはずだと考えるということですか？　そうであるから、プロダクションの実行時においては同じチェックをまたする必要はないと。

Rich Hickey: Well, you can make whatever decisions you make ordinarily, but it's no different from static systems. うむ。普段しているようにどんな決定をすることもあなたの自由ですよ。でもそのことは、静的なシステムの場合と変わりません。They have tests too, and they can either run those tests all the time, or just before they ship. 静的なシステムにもテストはあり、そのテストを常に実行することも、そうではなく出荷前にのみ行うことも可能です。But what you can express with Spec is way more than you can express with a type system.しかし、Specを使って表現できることは、型システムを使って表現できることよりも多い。

Joy Clark: Is it sufficient -- because I came form a background of doing a little bit of like formal validation and specifications for safety-critical systems... それで十分ですか？　というのも私は、安全クリティカルなシステムの形式的な検証や仕様設定の分野にいた者ですので。Would Spec be helpful in that context? Specはそのような文脈でも有用であれるでしょうか？ Because that's one area that I personally find... というのも私は個人的にその分野について思いました。Like, a type system or some kind of proof - I want to have a proof that my program actually does what it says it's going to do, because someone's life is on the line. つまり、型システムやある種の証明が必要な分野です。私は、あるプログラムが、それが行うと称していることを実際に行っているという証拠が欲しい。誰かの命がそこにかかっていますから。But would Spec be a valid -- しかしSpecはそういった場合にも有効でしょうか？

Rich Hickey: I consider that pretty much hyperbole... それは非常な誇張だと私は考えます。So let's take the function reverse. 例えばreverse関数について考えてみると。In Haskell, reverse has a type of "list of a to list of a". Haskellにおいてはreverse関数の型は、「aのリストからaのリストへの関数」です。If that type checks, do you know that that works? その型チェックが働いたからといって、あなたはそれが正しく動作していると知ることができますか？

Joy Clark: No. できませんね。

Rich Hickey: No. できません。And that's true of most of your statically-typed software. そしてそのことは、静的型付けされたあなたのソフトウェアのほとんどについても同じように言えます。Most of what's important about what they do is not captured by the type systems, because they are not semantic in the first place, they're mostly just mechanical, and the logics they have are pretty weak. それらソフトウェアが行う重要な動作のほとんどは、型システムによっては捕捉できない。なぜなら、それらはそもそも意味論的ではないから。型システムはほとんど単に機械的なものであり、型システムが持つ論理はとても弱い。

Rich Hickey: I think if I had a safety-critical system, I'd be looking outside of a type system - because they're so anemic - to a stronger formal verification system that is outside of the program. 思うにもし私が安全性クリティカルなシステムを扱っていたら、型システムの外側に方法を求めます。型システムは全く貧血症ですから。プログラムの外側について、より強力な形式検証システムを求めます。If you wanted to write an algorithm to make sure you were doing spinlocks correctly, or distributed transactions correctly - people do use proof systems for that, but they don't use the ones built into programming languages, they use much more powerful ones. もし例えば、スピンロックが正しく動いているか、あるいは分配トランザクションが正しく動いているか確実にするためにあなたがアルゴリズムを書こうと思うなら、世間では皆、そのために証明システムを使う。彼らは、プログラミング言語に組み込まれているものに頼ろうとせず、ずっと強力なツールらを使います。

Joy Clark: That is true. その通りですね。

Rich Hickey: I'm in favor of that; I'm mostly advocating that, like Spec, it be à la carte. 私はそうすることに賛成してます。提唱していると言っていいくらいです。アラカルトのように、Specもその一つとして、単品料理として選べばいい。

Joy Clark: Yes, okay. そうですね。よく分かりました。You also created Datomic. あなたはDatomicも作りましたね？

Rich Hickey: Yes. はい。

Joy Clark: Could you talk a little bit about just what that is and what its current state is? Datomicとはそもそも何か、そして今どんな状態か、少し教えていただけますか？

Rich Hickey: Sure. はい。Datomic is somewhat pointed at the same problems that Clojure is. Datomicが意図しているところはClojureと言わば同じです。Things are too complicated, and we're doing place-oriented programming... 物事はあまりに複雑で、私達は場所指向のプログラミングをしている。And the other big place you have left once you switch to a functional programming language is your database. そして、あなたが関数型プログラミング言語に移った時、残されている大きな場所は、あなたのデータベースです。So you can do whatever you want, you can use Clojure or Scala or Haskell, and then this database ruins everything for you, because it is a place, and most databases updated in place. あなたは自由にClojureなりScalaなりHaskellなりを選んで使うことができますが、そのデータベースが全てを台無しにしてしまう。データベースが場所ですから、そしてほとんどのデータベースは、場所で更新する。There's all the complexity associated with that, that there is with using places in memory. メモリ上の場所を使うことで、あらゆる複雑性を伴ってしまいます。

Rich Hickey: What Datomic endevavors to do is to say "Let's stop doing that. We have a lot more storage space than we ever did, and we have enough that we could take a functional approach to storing our data." Datomicが頑張っていることを次のように言えます。「今のやり方はやめようぜ。かつてよりもストレージは潤沢にある。これだけストレージがあるのだから、データを保存するにも関数的な方法を取ろうぜ」ってね。

Rich Hickey: I think people already realize this. 世の人々はもうこれに自覚的だと思う。People are certainly logging everything and keeping everything and going append-only. 今は皆きっと、何もかもログしているし、過去のものは何でも保存して、データを追加のみしている。The real value proposition of Datomic is to both, again, sort of only accrete information, not change it in place, but also provide the logical support for accessing that, and in particular for allowing you to use the database at a point in time as if it were a value in your program. Datomicの現実の値についての命題は次の2つです。1つは、情報はその場所で更新するのではなく、付け足すということ。また、そのデータへアクセスするための論理的なサポートも提供します。もう1つは、データベースを、自分のプログラムにおける値であるかのように、当時の時点のものとして扱えるということ。That is the big trick of Datomic. それらがDatomicの最大の工夫です。

Rich Hickey: When you do that, a lot of things that were complex become straightforward, just like when you move away from mutable variables to values - you're able to say "Of course I can perform three distinct operations with this value and not worry about the consistency of their results because the value might have changed." そうすると、複雑だった多くのものが単純明快になります。ちょうど、可変な変数から値へとあなたが移った時と同じようにです。「私はこの値に3つの異なる操作をして、しかしその結果の一貫性について心配せずにすむ。なぜなら値が変わっているかもしれないから」と言えます。That is a hard thing with update in place databases - you do three queries, and if stuff happened in between, then the basis for the queries was different, and the results can't be correlated. 場所で更新するデータベースの場合にはこれは大変です。3つのクエリを行う、しかしもしその間に何か起こったら、各クエリの前提は異なってしまう、そして処理結果も、互いに関係のないものになってしまう。

Rich Hickey: With Datomic, even if things have accreted in between your three operations, you could treat the database as a value and perform three operations, and now you get results that are consistent between them. Datomicを使った場合には、あなたの2つの操作の間で何かが付け足されたとしても、あなたはデータベースを値として扱って、3つの操作の結果として、相互に一貫性のあるものを得られます。That's the idea behind Datomic, and the state of it is we're right on the verge of shipping the cloud version of Datomic. そしてDatomicの開発状況と言えば、今まさにDatomicのクラウド版を出荷しようとする直前です。So it had been so far that you run on your own behalf, with a traditional install, and now we will have an offering in Amazon's AWS Marketplace for getting Datomic that way; you'll have the ability to get a Datomic instance up for around a dollar a day to get started and explore it, and then we have different production levels of instances and deployments. 従来は個々のユーザが各々、普通にインストールして実行するしかなかったのですが、Amazonのマーケットプレイスを通じてDatomicが利用できるようになりました。1日1ドルくらいでDatomicのインスタンスを用い、どんなものか検討できます。そうして、もっと異なるプロダクションレベルのインスタンスやデプロイも提供しています。

Rich Hickey: We're hopeful that we'll make it a lot more accessible, and certainly help people program for the cloud. 私達はDatomicを今よりさらに利用しやすくしていくつもりだし、Datomicはきっとクラウドについて皆がプログラミングする手助けになると思います。I think, again, we see in that space a lot of complexity, as people take software that was written for a stable network, with machines you could go and put stickers on with pet names, and kick, and unplug, and plug back in, and replace the hard dirves in, to this more ephemeral world of the cloud, and as you move data center software up to the cloud, you struggle with a lot of things. 現在ではその領域は複雑性に満ちている。安定したネットワークのために書かれたソフトウェアを手にした人は、ペットの名前を書いたステッカーをマシンに貼って、蹴飛ばし、プラグを外し、プラグをまた繋げ、ハードドライブを取り替え、今やクラウドのより儚い世界に来て、データセンターのソフトウェアをクラウドの移行して、人々は多くのことと格闘している。Datomic Cloud was written for that environment, so it's completely tuned for working with Amazon's logging, and metrics systems, and encryption systems, and things like that. Datomic Cloudは当初からクラウド環境のために書かれているから、Amazonのロギングとも完全に協調するようにしてあるし、メートル法や暗号化システムや、多くのものと協調する。We're hopeful that we'll make Clojure a really good language for doing cloud development, because you'll have this tool that's compatible with that. Clojureを私達は、クラウド開発を行うのにとてもいい言語にできるだろうと予測している。Clojureと整合性のあるDatomic Cloudが使えるようになるからです。

Joy Clark: Awesome. 素晴らしいですね。I'll have to check that out. どんなものか私も見てみなければならないな。In your opinion, is there a benefit to opinionated approach to program architecture? 意見を伺いたいのですが、プログラムのアーキテクチャについて独自の考えを持って取り組むことには利益があると思いますか？ I have some people who talked to me about Clojure and they're coming from the Rails world, or the Spring Boot in Java, and they're like "How do I write a web application in Clojure?" and I'm like, "Well, you can use all these different libraries, and they compose together, but you can pick and choose." 何人かの人々、Railsの世界からの人やJavaのSpring Bootからの人ですが、彼らがClojureについて話しかけてきて、「Clojureではどういう方法を取ればウェブアプリケーションが書けますか？」と聞かれて、私は、「そうですね。この多様なライブラリの中から好きなものを選んで組み合わせたらいいでしょう」といった感じに答えました。And I think one of the reasons it's difficult -- well, it's not that difficult, but it's a reason that makes it more difficult to get started, because there's so many options. 思いましたのは、それの難しさの原因の一つは。いえ、そう難しくはないのですが、始めてみる時の難しさの理由にはなっていると思うのです。あまりに多くの選択肢が今ありますから。So is there a benefit to having a standard stack, where you can say "This is what you should use?" だから、ある標準的なスタックがあったら良いのではないでしょうか。そしたら「これを使うべきですよ」と言えますよね。

Rich Hickey: Well, some parts of that question are social, which I can't really speak to... うーん。その質問の一部は、社会的な論点に関するものですね。そういう意味じゃ私にはさほど分からない。I think certainly when somebody figures out how to do web development, they should encode it in a framework. もしウェブ開発をどうやるか解き明かした人がいたら、その方法をフレームワークに埋め込んでしまえばいいんじゃないかな。But I'm not sure that that's a solved problem, and I think until it is a solved problem, opinions are very much opinions, and therefore you're at risk adopting a set of opinions that may not be an answer. ウェブ開発が解かれた問題だと私は思っていないし、それが解かれた問題になるまでは、意見は全く意見であり、ある意見のセットを用いるリスクはユーザにある。それが正しい答えじゃないかもしれないリクスがある。I certainly let the community find its own way in this area, I think we have some very talented people doing really good work, including David Nolen... ClojureのコミュニティがClojureなりの適したウェブ開発方法を見つけることが望ましいと私は思っている。私達の仲間にはとても優秀な人々がいて、とてもいい仕事をしてくれています。それはDavid Nolenを始め……。

原文: https://www.case-podcast.org/20-problem-solving-and-clojure-19-with-rich-hickey