16 ポイント 投稿者 GN⁺ 2024-05-21 | 5件のコメント | WhatsAppで共有
  • 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件のコメント

 
zihado 2024-05-23

Windowsでは、やっぱり Everything かな(笑)

 
bus710 2024-05-23

Magit がこれほど高く評価されて、こんな名作ソフトウェアの列に名を連ねるほどなのはなぜなんでしょうか? Emacs を使っていないので分からないですね。
Nvim では Neogit が Magit から影響を受けたと言われていますが、それでも使ってみるべきかもしれません…

 
bbulbum 2024-05-23

lazygit もおすすめです(笑)

 
bus710 2024-05-23

ありがとうございます。
週末にsuperfileとlazygitをインストールして、ちょっと触ってみようと思います。

 
GN⁺ 2024-05-21
Hacker Newsの意見

Hacker Newsコメントまとめ要約

  • Compiler Explorer:

    • Compiler Explorerは、コンパイラと性能最適化に関する議論を大きく変えた。
    • フォーラムでの議論の質に良い影響を与えた。
    • 大胆な主張をリンク経由ですばやく検証できる。
    • llvm-mcauiCA のようなツールも有用だ。
  • Windows利用についての意見:

    • Windowsについてバランスの取れた見方を示している。
    • NT系のWindowsは優れたオペレーティングシステムだ。
    • ゲームのためにWindowsをインストールしてある。
  • Docker:

    • Dockerはコンサルティングのキャリアのあいだ、多くの時間を節約してくれた。
    • 古いプロジェクトをすばやく実行できるようにしてくれる。
    • 複数のデータベースサーバーをインストールする必要がなくなった。
    • Python環境を再現可能にし、並列実行できるようにしてくれる。
  • Spring Framework:

    • Spring Frameworkは依存性注入の概念を理解するうえで妨げになる。
    • 多くのJava開発者に、複雑なフレームワークが必要だと思わせる。
    • Spring自体は有用だが、ソフトウェアをより複雑にし、移植性を低くすることがある。
  • Nix:

    • NixとNixpkgsで多くの複雑な作業を行える。
    • Rustバイナリの静的ビルドなどを簡単に行える。
    • さまざまなビルドオプションとキャッシュ機能を提供する。
    • Nixは非常に有用だが、NixOSには慎重に向き合うべきだ。
  • Emacs:

    • Emacsはバグ修正作業を技術的な練習に変えてくれる。
    • 退屈な作業を面白くしてくれる。
  • 「Round」概念:

    • 「Round」概念は、最小限のコアボリュームで最大限のインターフェース領域を提供する。
    • EmacsとGitのコアは小さく単純だが、強力だ。
  • Magit:

    • Magitは、単純さ・有効性・発見可能性の教科書的な例だ。
    • Gitの機能をよりうまく表に出してくれる。
    • 独自の用語やワークフローを導入しない。
  • SVNとGitの比較:

    • SVNの利用経験は非常に否定的だった。
    • Gitははるかに直感的で理解しやすかった。
    • Gitを使うことで作業フローがより良くなった。
  • Linux、Emacs、Bazel、Magitの利用経験:

    • LinuxでEmacsとBazelを使って作業している。
    • ブログを調べ、Emacsで作業を保存し、Magitでコミットメッセージを書く。
    • Gitリポジトリにプッシュする。