バベルの図書館は完成しない

Extended outer memory module
for my poor native memory.

Posts:
2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った
2020/09/13 ISUCON10 の予選を 7 位で通過した
2019/12/01 Puma の内部構造やアーキテクチャを追う
2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む
2019/04/29 InnoDB の B+Tree Index について
2019/04/29 InnoDB における index page のデータ構造
2019/04/28 InnoDB はどうやってファイルにデータを保持するのか
2019/01/06 Designing Data-Intensive Applications を読んでいる
2019/01/03 年末年始に読んだ本について、など
2019/01/01 Ruby から ffi を使って Rust を呼ぶ
2018/11/10 ブラウザにおける状態の持ち方
2018/07/01 Rust で web アプリ、 或いは Rust における並列処理
2018/05/14 なぜテストを書くのか
2018/05/13 Rust で wasm 使って lifegame 書いた時のメモ
2018/03/12 qemu で raspbian のエミュレート(環境構築メモ)
2018/03/12 qemu で xv6 のエミュレート(環境構築メモ)
2018/03/03 Ruby の eval をちゃんと知る
2018/02/11 Web のコンセプト
2018/02/03 Rspec のまとめ
2018/02/03 Ruby を関数型っぽく扱う

TypeScript

JavaScript の経験がほとんどなくて、せっかく今からやるなら TypeScript でしょと思って、これまたドキュメントを眺めていたけど、やっぱり型アノテーションは好きだな。一部には冗長とか美しくないとかいう向きもあるみたいだが、僕はいいと思う。

Rust やってみて思ったけど、型アノテーション(と、静的に解決される型システム)がある方が色々と処理を書きつらねていきやすい気がしている。量や時間で行ったら Ruby の方がよく書いているけど、 Ruby でプロダクションコード書くとなると結局テストで関数の引数と戻り値の値の幅を保証してあげることになる。それだったらテストに分断されることなく、アプリケーション側のソースコードの中に、値の取りうる幅(型だったり nullable かどうかだったり)の情報が含まれている方が読みやすいと思っている。

そもそも値の取りうる幅を全て型システムで決定できるというのは、パズルちっくなコードになりがちではあるが、素晴らしい点だよね。型システムの基本概念になれてしまえば他人の書いたコードも 70% くらいの理解度でもなんとなく読めて安全に扱える。 (Ruby は他人の書いたコードを読むのが非常にコストがかかるし、 90% くらい理解しないと怖いなって思ってしまう。。。)

逆に Ruby がいいのは、クラスベースのオブジェクト志向をベースに体系が構成されているから、論理的な世界での話なのに物理的な世界に対してプログラムを行なっているかのような思考の簡単さ・楽しさを持てる点が一つあると思っている。その上で基本的にいろんな方向に制約なく(しかも処理の流れの中で動的に)メッセージパッシングができるから、あんまり悩まなくても、やってほしい子にやってほしいことをやってもらえる部分もいいところかなって思う。(さらにいえば、そんな自由度の中でいかにお行儀よくわかりやすいコードを書いていくか、という部分も割と好き。)

2018/11/11 20:45
tags: minipost
This site is maintained by furuhama yusuke.
from 2018.02 -