Enlightenmentware - 自分を目覚めさせてくれるソフトウェアたち
(mmapped.blog)- UNIX, Git, Emacs, Boost.Graph, Bazel
- プログラマーとして毎日ソフトウェアツールと関わっているが、ほとんどのツールは単に作業をどうにかこなすために使われるだけである
- ときには、単なる有用性を超えて想像力を刺激し、新たな可能性を開き、システム設計のやり方に影響を与えるソフトウェアに出会う
- こうしたソフトウェアを「啓発ソフトウェア」(Enlightenmentware) と呼ぶ
- プログラマーにとって最もありふれた啓発の源は、使っているプログラミング言語である。趣味で学ぶ言語も含む
- MASM、C、Prolog、Idris のようなプログラミング言語に触れながら、多くの気づきを得た
- 言語学習が思考力の拡張に与える影響は古くから知られているため、この記事では言語に焦点を当てるのではなく、啓発を与えてくれるソフトウェアだけに集中することにする
UNIX
unix はユーザーフレンドリーだ——ただし友達を選ぶだけだ。
匿名, "Art of unix Programming" by Eric S. Raymond
- 2008年、大学で学びながら最初のプログラミングの仕事を探し始めた。
- 求人広告の大半で UNIX と socket の知識が求められていた。
- 大学のカリキュラムに unix やオペレーティングシステムの講義がなかったため、独学で学ぶことを決めた。
- Andrey Robachevsky らによる "The unix Operating System" を通じて unix の世界に入門した。
- Mandriva Linux をインストールしながら unix 環境を探検するようになった。
- それ以来、unix は人生のあらゆる段階で共にあった。
- ほとんどのソフトウェアは unix 環境で動作しており、今でも "Advanced Programming in the unix Environment" を参照している。
Git
git で自分の足を撃つのは簡単だが、以前の足に戻って現在の脚と縫合 (merge) するのも簡単だ。
Jack William Bell
- 2009年初頭、Rational ClearCase を使って初めてバージョン管理システムに触れた。
- ClearCase は非常に混乱していて、最低限の要件しかこなせなかった。
- その後 Subversion を使うようになり、"Version Control with Subversion" を通じて学んだ。
- Subversion は理解しやすく使いやすかったが、個人プロジェクトには不便だった。
- その後 Git を見つけた。
- Git は学習曲線が急で混乱も多かったが、ClearCase とは別種の混乱だった。
- Git はバージョン管理を使う際の摩擦を取り除き、価値のあるあらゆるものをバージョン管理できるようにした。
- Git の設計は、分散システム、有向非巡回グラフ、コンテンツアドレス指定ストレージの優雅な組み合わせとして魅力的だった。
- Git の内部を学ぶこと自体が面白く、他のバージョン管理システムにも関心を持つようになった。
- Git の主な欠点は、スナップショット志向のアプローチのせいでマージを理解しにくくしている点である。
Emacs
どんなテキストエディタでもファイルは保存できるが、魂を救えるのは Emacs だけだ。
Per Abrahamsen
- 最初のプログラムは Turbo Pascal 7.0 の親しみやすい青いウィンドウの中で編集した。
- 大学では Pascal を使ってプログラミングを学び、その後 C++ と Java を使った。
- 最初のプログラミングの仕事では NEdit を使っていたが、Vim と Emacs に興味を持つようになった。
- Vim は楽器を演奏するように難しいが、同時に楽しくもあった。
- Emacs はテキスト編集とウィンドウ管理の機能を提供する Lisp マシンである。
- Emacs の内部構造はクリーンでよく整理されており、ドキュメントも充実している。
- Emacs Lisp で拡張するのは、他のエディタよりもはるかに簡単である。
Boost.Graph
私は再利用可能なコードという流行に強い偏見を持っている。「再編集可能なコード」のほうが、ブラックボックスやツールキットよりずっと優れていると思う。
Donald Knuth, Andrew Binstock とのインタビュー
- 2013年の大晦日に Boost Graph Library を読んだ。
- ほとんどのアルゴリズムライブラリは特定のデータ表現に依存しており、既存のプロジェクトに統合しにくい。
- Boost.Graph ライブラリはジェネリックプログラミングを使ってこの問題を解決する。
- 実際にこのライブラリを使ったことはないが、その設計によって STL デザインとジェネリックプログラミングへの理解が深まった。
Bazel
make が期待どおりに動かないなら、makefile が間違っている可能性が高い。
Adam de Boor, "PMake—A Tutorial"
- 2009年、研究プロジェクトのために最初の
Makefileを書いた。 makeの複雑さのため、もっと良いツールを切望するようになった。- さまざまなビルドシステムを試したが、どれも満足できなかった。
- 2016年、Google に入社して
blazeを使うようになった。 - Bazel はビルドシステムにおける最後のパズルのピースだった。
- Bazel は高速で、正確で、使いやすく、言語に依存しない。
結論
- 優れた enlightenmentware に共通する点:
- 深い問題を解決し、日常的に直面する問題を扱っている。
- 小さな表面積に大きな奥行きを備えている。
- 内部を探検するよう誘い、励ましてくれる。
GN⁺の意見
- UNIX の重要性: UNIX は多くのプログラミング環境で基本的なオペレーティングシステムとして使われており、システムプログラミングの基礎を理解するうえで不可欠である。
- Git の学習曲線: Git は最初は難しいが、強力なバージョン管理ツールとして不可欠である。特に分散システムや協調作業の環境で有用である。
- Emacs の柔軟性: Emacs はテキストエディタ以上の機能を提供し、とりわけ Lisp プログラミングに関心のある人に勧められる。
- Boost.Graph のジェネリックプログラミング: Boost.Graph はジェネリックプログラミングの強力な実例であり、複雑なアルゴリズムを効率よく実装する方法を学べる。
- Bazel の効率性: Bazel は大規模プロジェクトでビルドシステムの効率を最大化できるツールであり、特に Google のような大企業で有用である。
5件のコメント
Windowsでは、やっぱり
Everythingかな(笑)Magit がこれほど高く評価されて、こんな名作ソフトウェアの列に名を連ねるほどなのはなぜなんでしょうか? Emacs を使っていないので分からないですね。
Nvim では Neogit が Magit から影響を受けたと言われていますが、それでも使ってみるべきかもしれません…
lazygitもおすすめです(笑)ありがとうございます。
週末にsuperfileとlazygitをインストールして、ちょっと触ってみようと思います。
Hacker Newsの意見
Hacker Newsコメントまとめ要約
Compiler Explorer:
llvm-mcaやuiCAのようなツールも有用だ。Windows利用についての意見:
Docker:
Spring Framework:
Nix:
Emacs:
「Round」概念:
Magit:
SVNとGitの比較:
Linux、Emacs、Bazel、Magitの利用経験: