問題を解決するつもりでキッチリ型を付けた先にある高い壁 - ぼくのぬまち 出張版
null安全おじさんになりかわりそれがしがお見せつかまつる 機械が理解できる複雑な契約の型表現がもたらすものは つまるところこのようなもの ずぶぶ(切った腹から証明オブジェクトを引き摺り出す)— Noriyuki OHKAWA (@notogawa) 2016年11月18日 過ぎたるは猶及ばざるがごとし． 最近null安全？だかの話のからみで，(静的な)型で契約云々を表現してシアワセになれるんだぜーと言うのをチラホラ見聞きする．たとえば，pythonで統計なり機械学習なりやっててnumpy弄るような人が，ndarray(多次元配列)のshape(多次元配列の形)が合わずエラーで落ちたりとかそういうアレについて云々という．なるほど型があれば実行前に止めることができ，実行時，エラー*1になってファーみたいなことは避けられるだろう． しかし，これが天国へ続く道かどうかはまた別の話．(依存)型で舗
孤独のHaskell - ぼくのぬまち 出張版
孤独のHaskellに行ってきた．ので，感想とそのフォローアップになりそうなことを書く． とてもいい会だったように思う． 遅刻して現場に付いたらRLEしてみようという例題("AABBCCC"を"A2B2C3"にする関数を書こう)をやっていて， id:khibino0 さんがおもむろに import Data.List ( group ) import Control.Arrow rle = concatMap (uncurry (:) . (head &&& show . length)) . group のような解をブッパしてたりするなど．で，各自自前実装してる人たちのコードとか見ると「細かい操作でボトムアップにやりたいことを実現しようとしてるなー」と感じることが多かった．Haskellの場合(なのかは知らないが)もっと大域的な変換からトップダウンに考えていったほうがシンプルでソレっぽい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
