「Mastermind of Programming」を読んで 3(APL)

3章はAPLを設計したアディン・D・フォークオフさんのインタビュー。

かなり初期の言語で、LISPと同じように、もともとは紙の上での記述を目的として作られた言語のようです。
つまりコンピュータに読み込まれて自動的に何かすることを目的としているわけではなく、
記述そのものを行うことを目的として作られた言語。

記号の数が大変多い言語として有名ですが、
紙に書く予定で作られたのなら納得ですね。

記号の種類が多いことにより、慣れないうちの可読性が低いと評判の言語のようですけど、
作った人はそういう認識は全くないようです。
数学の記述と以上に簡潔だと。
まあ確かに慣れたらそうですね。

FORTRANと同年代の言語ですから、
関数のように単語で機能を認識するより、
記号でするという方針だったのは当然といえば当然です。

関数のようにあらゆる分野にまで機能を拡張できるようにするという習慣がまだないので、
言語設計者が決めた言語内での規則によって多様な表現ができるという方向ですね。

そういう時代背景を考えると、
言語内に用意された多くのデータ型に対するあらゆる操作を、
統一した方法で簡潔に記述できるということを生み出したのは、
大変評価できると思います。

最近のLINQだって、結局はそういう構文なわけですしね。

古い言語の利点はその後多くの言語にまねされて今では当たり前になっていたりするので、
歴史を考えないと評価が難しかったりするものですが。
その辺を考えたうえで言えば、後世の多くの言語を使いやすくした原因となった、素晴らしい言語設計だったといえるのではないでしょうか。

配列に対する操作の記述なんて、主要言語で標準となってきたのは最近ですしね。
大変時代を先取りしていたと思います。

「Mastermind of Programming」を読んで 2(Python)

2章はPythonを設計したグイド・ヴァンロッサムさんのインタビュー。

新しく、かつすでに標準となっている言語だけあって、
あまり特筆すべきことが書いてなかったように思えました。

その二つの条件があると、その言語の備える機能は、、
すなわち最近のプログラム言語の常識と言えてしまうのですね。

どっちかというと、オープンソースの作業をチームでやるうえでの心得、
のような部分のほうが印象に残りましたね。

ひょっとしたらヴァンロッサムさんが控えめな性格なのかもしれません。

「Mastermind of Programming」を読んで 1(C++)

1章はC++を設計したビャーネ・ストラウストラップさんのインタビュー。

C++が現代に生き残っている理由がわかりました。

C++はC言語との互換がほぼ失われていないように、
かなり低レベルの記述ができます。

でまあ、できるということはやる人がいるのですよ。
それで、それはC++の本質的な問題なのだと思い込んでいましたが。

設計者に言わせると、メモリ管理やらポインタやらを使わなくていい方法はちゃんと用意したので、
使わないプログラミングができるし、当然やるべきだ、とのこと。
考えてみれば確かにその通りですな。

そう考えてみると、高級言語の中ではかなり低レベルな記述ができるCの機能を受け継ぎつつ、
テンプレートなんかを使って実は相当な高レベルの記述もできる言語ということになります。

実際、Boostなどで実現されている機能を見ればわかりますが、数値にいちいち単位をつけてコンパイル時にチェックをすることもできる。
これは実はC#ではほぼ不可能なんですよね。最近の言語でもできるものはわずかだと思います。

それだけ高レベルなことを、メモリを節約する機能も捨てずに実現できている。
これは結構すごいことです。

とはいえまあ、インタビューでは出てきませんが、やっぱりそれがデメリットにもなっているのは確かですが。
なんでも記述できるようになるということは、どうしても記述量が増えて可読性が落ちます。
いちいち、メモリ管理は自動で（つまりstd::shared_ptr<…>(newとか）、
ってソース上に書かないといけないということは、
それはそれである意味メモリ管理を意識しているということになるのですよ。常に。

ということで大変すごいのですが一部惜しい気はしますね。

しかしちゃんとしたC++のプログラムの書き方をいずれ練習する必要はあるなと思いました。

「Mastermind of Programming」を読んで 0(初めに)

古いものから最新のものまで、
プログラム言語を設計した18人のインタビューを集めたという、
鼻血が出そうなほど素敵な本。
こんな本が出版されていたとは。

一日のブログで書くと長くなりすぎますが、
短くまとめるのももったいないので、
一日一章ずつ感想を書いていこうと思います。

C#ショートコードプログラミング

C#のコードを、短く書くテクニックがいろいろ載っている本。
とはいっても変数名を短く、とかいうのが書いてあるわけではないですが。
ライブラリをうまく通とか構文をうまく使うとかがほとんどですね。

これがけっこう、読みやすいプログラムを書く方法を知るのに、
役に立ちます。

プログラムには、人間に見せるための情報と、
機械に教えるための情報が含まれています。

機械に教える情報は減らしたら動きが変わるわけで減らせないのですが、
人間には見えないところに隠すことはできます。
たとえば関数の中とか。
そしてたとえばそれがライブラリの中だったりすると、見た目かなり短くなるのですな。

この場合、削れていくのは人間に必要ない情報です。
人間に見せるための情報は、凝縮されて残ることになる。

それによって、きわめてシンプルで、
かつ必要な情報はすべて入った記述


人間に意味のある部分を削ればそうはならないはずですが、
実際にはなかなか難しいのです。
変数名や空白など、機械に全く意味がない部分なら削れますが。
そうでない部分はプログラムの構造の根幹とリンクしてしまっていて、
実際には普通は削れないのですね。
よほど変なメソッド構成にすれば削れるんでしょうが。

とかいう部分は作者はあまり考えていないようです。
こういう本を出した理由を一応書いてはありますが、
考えがまとまってない様子。
書いてある考えと実際の例があってなかったりする部分さえありますし。

しかしプログラマーは直感的に、
シンプルさをとらえます。
いわゆる美しいという感覚ですね。

ということで理屈は分からないまでも短く書く方法を試行錯誤していて。
その結果は大変美しく役に立つものです。

特にC#はライブラリだけでなく、構文でもそういうことがやりやすい新機能が多い。
短く書くと宣言的な気泡になります。
それはC#の作者も重視していることらしいです。
このことからも、この本には意味があるということがわかります。

「TCP/IPの絵本」を読んで

まずは褒めておきましょう。

技術書を読むのにけっこう慣れてきても、
自分がよく知らない分野の本に手を出すのはちょっと敷居が高く感じます。
プライベートで読むものですから、ストレスは避けたいものですし。

ですから、絵本と書いておけば簡単だということが非常にアピールできて、
それはよいことです。

絵本と書いてあるからあまり得意ではない分野でも手を出せたのかもしれませんし、
だからシリーズの別の本も買うかもしれません。
本屋で手に取らないと絶対勉強にはならないわけですからね。

そういう意味では確かに良い本なのですが。


内容的にちょっと戦略を間違えています。
というか絵本というものをなめているとしか思えん。

基本的な情報量としては、ちょっと図が多めの技術書というくらい。
その間を、かわいいキャラクターの絵で埋めているんですが。

キャラクターの動作と表情が、ほぼ全く何も伝えてません。
説明書きが単に全部吹き出しになっているだけ。

普通図が書いてある説明は、何となく読み流しても図に目が行くものですが。
そこに表情と手振りが書いてあったら、そちらに目が行ってしまいます。
そっちを見ても何も理解の助けにはならないのですから、
何となく読んでいると全く情報が目に入ってこない。

結局、キャラクターをなるべく見ずに、
文章と図に集中なくてはならないことになってます。
全く本末転倒。

お金を出して売っているんですから、
もうちょっと説明には何が必要なのか考えたほうがいい。
イラスト画家じゃなくて、漫画家を雇うべきなんじゃないでしょうか。
漫画家なら表情と手振りで何かを伝えるというノウハウがあると思います。
学習漫画とかちゃんと文だけよりわかりやすい説明になってますし。


まあ、最初に書いたように、手に取ってもらえるのは重要なことです。
一面字ばっかりというだけでアレルギーを起こす人もいるんでしょう。技術者にも。

私もまあ、結局は気軽に読めそうだったから読んでみたわけですし、
今までなんとなく説明は聞いていたけど頭の中でまとまってなかった部分が多少はまとまりました。
手に取らなければそういうこともなかったことを思うとまあ。
有意義な本とはいえるのでしょうが。

にしてももうちょっと何とかならんか、とか思った本でした。

「SEを極める 50の鉄則 マネジメント編」を読んで

入門編に続く、マネジメント編です。

SEとして出世して、
複数のSEを束ねる立場になった時に必要なことが書いてある本です。

当面こういう立場に立つことはないと思いますが、
将来役に立つかもしれず、
またマネジメントを実際にやっている人と意思疎通を図るには、
こういう視点は必要となるでしょうから、
読んでみました。

志を持って、SEの集団として社会の役に立つにはどうすればいいかが、
具体的な例を挙げつつ書いてあって、
大変役に立つと思います。

ただ。
著者がSEマネージャをやっていた時期はSEをやっていた時期より新しいことを考えると不思議ですが、
入門編より古さが目立っているように思えます。

多くの人を長いスパンで扱わなければならない分、
古さが致命的になることが多いのかもしれません。

いざとなったら徹夜すればよい、という考え方はだんだん通用しなくなっていっていると思いますし、
すべてのSEがいずれは技術重視のSEを卒業して、
多数のSEを従えるSEマネージャになることを前提に、
教育方針を決めるのもちょっと困る気がします。

ひょっとすると古いことは関係ないのかもしれません。
いろいろな開発を並行して進めるという方針は、
製造業界の混流生産やアジャイル的な考え方の流れを考えると、
むしろこれからの時代に必要になってくることなのかもしれませんが。

ただ、一つの開発に専念しないといけないってのは、
単なる個々の開発者の好みの話ではなく、
そうしないと生産性が大幅に落ちる、というデータをもとにしている話のはずです。
慣れれば大丈夫とかいう話ではない。
これだけいろいろ勉強して考えている人なら、知らないはずはないと思うのですが。
そのへんどう考えているのでしょうか。

新しいことを提唱するのはよいことですが、
それが今まで導入されてこなかった理由となるデメリットを解決したうえでなければ、
意味がないことだと思うのですがね。

全体的にこれまでの自分の経験が、
時代や状況によらずすべての状況で有効である、
ということを前提とした記述が多いような気がしますね。

ということで、入門編より鵜呑みにはできない面は増えているように思えます。
とはいえまあ、この本の主要読者はマネージャーのはずですから。
鵜呑みにする人は少ないので実質問題はないのかもしれません。

「SEを極める 50の鉄則 入門編」を読んで

SEとして大成する方法が、
技術面ではなく社内や顧客との人間関係についてを中心に書いてある本です。

とはいっても技術力のないSEが書いた本ではなく、
技術も重視してきた人が書いているようなので、
技術力重視のSEもある程度安心して読めます。
人間関係が非常に重要というのは、間違いないことですしね。

SEとして志をもって実績を上げるために、
基礎的に行わねばならないことが、
丁寧に解説してあります。

著者は実際にSEとして仕事しなくなって久しい人のようなので、
多少古めの記述も見られましたが。
まあ人間関係を中心として書いてある以上は、そんなに問題にはなりません。

なかなか役に立つ本でした。

「Ruby on Rails 逆引きクイックリファレンス」を読んで

しばらく前に買った本。
読むのを後回しにしているうちに、Ruby on Railsは3.0が出てしまいました。
なので、細かい部分を覚えても仕方がないので、
現在世界最高峰を行くというライブラリのすごさを楽しむつもりで読んでみました。

実際大したものです。

Webアプリの開発という分野において、
余分なコーディングを極力省いて、
必要なことのみを書けばよいようになっている。

たいていのことは１行書けば実現できるようになっています。
それも、長い１行じゃなくて、簡潔な1行。

簡潔な1行で書けないことは、簡潔な１行で書けるようにする構文が用意されている。
アプリケーション全体で一回しか出てこないような特殊な処理はあえて長く書くこともいいですが、
２回以上出てくるようなことは１行で書けるようにしておいて、
簡潔な１行で書くのがRuby on Railsの流儀のようです。

１行で書けないことは、本質的に１行以上の情報量が必要なことのみ、です。
関数ができてから目指されていたことだと思いますが、
２１世紀になって、掛け値や誇張なしに本当に達成できる世の中になったようです。

ちゃんとついていかねばなりませんね。

作業を再開

前回F#で作るとか書いていましたが、
使いやすいライブラリを作るには言語の文法を熟知しないといけないので、
やはりC#で。

新人時代に会社で作ってから、
似たようなものを作り始めたのは３回目です。

１度目 ７年前
オブジェクト指向を学びつつC#の文法の解析を行う。解析結果はオブジェクト指向化できたが、解析のロジック自体をオブジェクト指向化できなかったため保守性が悪い。

2度目 3年前
解析のロジックをオブジェクト指向化。それも事前設計ではなくテスト駆動開発で設計を進める。ロジック記述のライブラリができた時点で満足してしまってC#の解析は中断。

3度目 今
前回ライブラリは作ったものの、使い勝手が今一つだったので、きっちりと使い勝手を考えたDSL化することを考える。


こう見ると、プログラマー始めたころから同じことをやっているように見えて、着実に進歩はしていますな。
機能的には同じようなプログラムですが、拡張性を考えると、
複雑なロジックをかけるようになることではなく、
インターフェースを設計すること自体が重要なので、
そっちの方向に進歩しているのはよいことなのでしょう。

長年構想しているだけあって、なかなか良いインターフェースになったと思います。
最近になってPerl6のgrammarやboost::spiritなども見ていますが、
だいたい似たようなインターフェースになっているのを見ると、
この方向が正解みたいですな。
現在そっちのほうも参考に細部を詰めているところです。

作ってみたところ、言語を使いこなすよい練習になるので、
いずれF#やRubyでも作ってみたいものです。