ポリモーフィズム(polymorphism; 多態, 多相)」というとオブジェクト指向プログラミングにおける継承(インターフェースの継承)による実現手法がよく知られている。 しかし、ポリモーフィズムを実現するための手法はオブジェクト指向的な型階層によるものに限らず様々なものがある。 ここでは、Expression Problemに対する解決策として挙げられる、継承によらないポリモーフィズムの代表的な実現手法として、 型クラス(type class) プロトコル(protocol) マルチメソッド(multimethod) による実装を複数言語で試してみた。 いずれの方法も明示的な継承関係を必要とせず、拡張に対して開いているため、既存の型(例えば言語組み込み型)に対しても容易に拡張可能なことが特徴的で、ある種のインターフェース定義に対する実装を追加することで、いつでも適用範囲を拡大できる。
Clojure’s transducers are an intellectual curiosity. Not only are they interesting from a usage perspective, people (perhaps mostly Haskellers?) also try to understand what their types are. Trying to derive some sort of type for transducers is not as easy as one would think, partly because of state, mutability and IO. Franklin Chen wrote a great blog post about this, unfortunately, I feel it doesn
Clojure勉強会clj-nakanoの課題として"situated-program-challenge"のClojureとHaskellによるREST APIサーバ/クライアントの実装にこれまで取り組んできました。 今回は、このREST APIに対する(テーブル変更を含む)仕様変更に対応してみた結果をご紹介します。 過去の実装とその紹介記事はこちら: Clojure/Duct版RESTサーバ(version 1): lagenorhynque/situated-program-challenge/rest-server at clj-version1 ClojureのDuctでWeb API開発してみた - Qiita Haskell/Yesod版RESTサーバ(version 1): lagenorhynque/situated-program-challenge/rest-serv
昨年末のAdvent Calendarで2回に分けて紹介したsituated-program-challengeのClojure/Duct版実装とHaskell/Yesod版実装ですが、そこではもともとの課題のうちRESTサーバしか実現できていなかったため、今回新たにRESTクライアント実装についてご紹介します。 Clojure/Duct版RESTサーバ: lagenorhynque/situated-program-challenge/rest-server at clj-version1 ClojureのDuctでWeb API開発してみた - Qiita Haskell/Yesod版RESTサーバ: lagenorhynque/situated-program-challenge/rest-server at hs-version1 ClojurianがHaskellでWeb API
It has been nearly two years since our former CTO Arnaud Bailly posted his widely read article on Capital Match’s architecture on November 16, 2015. Since then, we have written about our architecture several times, but they were all were intended for an audience of investors or business people, which necessarily means a high concentration of buzzwords, fancy graphics with impressive-looking diagra
Clojurian時々Haskellerでラブライブ!ファン(海未🏹&曜⛵推し)のlagénorhynque (a.k.a. カマイルカ)です。 Opt Technologies所属で、普段は広告運用に関わる社内向けプロダクトをPHP, TypeScript, Clojureで開発しています。 最近までにClojureをプロダクトに導入したり、Haskell/Elmプロダクトの開発者を募集したりと、社内でもClojureやHaskellといった言語への注目度がこれまで以上に高まっています(断言)。 そこで今回は、今年11月から新たに始まったClojure勉強会clj-nakanoでの課題を題材に、HaskellでのWeb API開発に入門してみることにしました。 ちなみにclj-nakanoといえば、Clojure開発者Rich HickeyのClojure/conj 2017でのキーノ
Skip to the content. by @eborden on November 01, 2017 Recently Lispcast wrote a post interpreting Rich Hickey’s controversial statements on static types. This post had some very interesting perspectives and some unfortunate misinformation. Within the post the author proposed a challenge to static typing communities. Is it possible with our current understanding to build a statically typed language
Software design, functional programming, and software engineering practices Summary: Rich Hickey explained the design choices behind Clojure and made many statements about static typing along the way. I share an interesting perspective and some stories from my time as a Haskell programmer. I conclude with a design challenge for the statically typed world. Rich Hickey's Keynote at Clojure/conj 2017
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
