今までどのくらいプログラミング言語を触ってきたか(3秒で挫折したものものも含む) Ver.13

2021-06-20現在のステータス。
https://eel3.hatenablog.com/entry/2020/06/30/201935 から1年経て、こうなっている。

なおCSS、HTML、XMLはひとまず除外する。人工言語ではあるけれども「プログラミング言語」という括りに含められるか否かは議論が分かれる気がする。*1

よく使っている

AWK (Gawk)

単純なテキストレコードの処理はAWKで十分間に合う。今の時代、自作ツールをnawkやGNU awk単体で実装するのは苦行すぎて*2皆無なものの、シェルスクリプトやMakefileにAWKのコードを埋め込むなどして他のコマンドと組み合わせて使う機会は依然として多い。シェル上でワンライナーでテキスト処理する時にも重宝している。これはこれで十分AWKらしい使い方ではないだろうか？

C++

ちょくちょくお仕事で使うが、未だに本職のC++使いではない。C++11やC++14は非常に便利で、better Cでも使う価値がある。C言語使いからすると、C++03時代よりも充実度が進んだ標準ライブラリ、ラムダ式、autoによる型推論――などなど、便利で羨ましい限りだ*3。あと、Swift時代のクロスプラットフォームC++ライブラリ作者は、どうあがいてもARCから逃れられないので、C++11以降のスマートポインタは必須だ*4。正規表現とスレッドも標準ライブラリに加わったので、あとはソケット（低水準ネットワークAPI）をサポートしてくれないだろうか。C++17のstd::optionalも、KotlinやSwiftの経験者としては好ましい。低水準の処理を行いつつも便利な機能で実装時間を短縮できる点は便利で、少なくともシステムプログラム言語としての利点だと思う。だけど機能多すぎ／複雑すぎなところはなんとかならないものか。強力な反面、使い手を選ぶ言語だ。

C言語

お仕事での主力言語だった――ここ最近は仕事以外でしか使ってないけど。シンプルかつ低水準の世界が垣間見れるところが割と好き。とはいえ最近の他の言語と比較すると、シンプルすぎて安全機構が欠けていたり標準の便利機能が少なかったりするので、入門用の言語としては薦められない。にもかかわらず、プログラミング未経験者向けのC言語の本は今でも出版されている――謎だ。クロスプラットフォームなモジュール屋としては、今までC89を採用してきたものの、いい加減そろそろC99とかC11とか次世代の言語とか使いたい。でも古いVisual Studioもサポートしたいから、C99すら2023年まで使えない*5。悲しいなぁ。

DOSバッチファイル

プログラミング言語に含まれるかどうか不明だが、含めてしまう。ちょっとした自動化や、複数ツールを組み合わせて使うときのラッパーとしてよく使う。コマンドプロンプトはシバン（shebang）に対応していないので、スクリプト言語で書いたツールを起動するラッパーとしても多用している。意外と色々なコマンドが用意されているので、単純にそれらを叩く分には十分だが――言語機能がショボいので、バッチファイルでifやforのような制御構文系コマンドが必要になってきたら、何か決定的に間違えていないか、考え直すようにしている。

Kotlin

本格的にAndroidアプリ開発に関わるようになったのがGoogle I/O 2017直後の過渡期なので、JavaよりもKotlinでの経験値の方が多い。モダンな「強い静的型付け」の、割とええ感じの言語やね。ただ、使い始めが「Swift 3をつまみ食いして半年以上経ってからKotlinをつまみ食いした」みたいな経緯だったこともあり、未だに両者の概念・機能が頭の中でごった煮になっている。それと、NDK絡みの作業が多いので、C++11/14・Java 7/8・Kotlinを行ったり来たり。泣けるぜ。Swiftもそうだが、最近のメジャーな「強い静的型付け」の言語は「開発環境込み」で高い生産性とコードの安全性を両立させる方向に進んでいる気がする。

make (Makefile)

プログラミング言語に含まれるかどうか不明だが、DSL扱いで……いやGNU Makeはそこそこプログラミング言語的か。GNU Make 4.0はさらにプログラミング言語的だな、特にGNU Guileなところが。GNU MakeとNMAKEが主力で、稀にNetBSD Make（pmake）を使うが、いずれも独自拡張アリアリだ。もう素のmakeではMakefileを書けない :)

Objective-C, Objective-C++

時代はSwiftだと言われて久しいけど、どっこいObjective-CとObjective-C++は生きている。というかSwiftのコードにC++で書かれたライブラリを直接組み込むことができない以上、両者を繋げるグルー言語として生き残ることになるよね。一定以上のリアルタイム性が求められるアプリをSwiftだけで書くのは厳しくて、どうしても部分的にC言語やC++を使うことになり、グルー言語としてObjective-Cが召喚されることになる。最近流行の言語と比べると良くも悪くも80年代的だが、アプリケーションプログラミング用としてはC言語よりマシだし、C++ほど複雑怪奇*6ではない。そしてC言語やC++で書かれた既存のライブラリをそのまま使える。Objective-Cのハイブリッドな所は好きだが、Objective-C++はハイブリッドすぎて――C++のクラスとObjective-Cのクラスを、C++のラムダ式とObjective-Cのブロック構文を同時に使うのは大変だ。便利ではあるんだけどね。

Python

Python 2.xで実装した小ツール群をPython 3.xに移植した。Pythonではlazyなスタイルでのコーディングが許されず、整然とコードを記述する必要がある。その辺は、Perl 5やRubyとは随分と雰囲気が異なる。気になるのは、インデントが必須な言語仕様であるために、シェルスクリプトに埋め込んで使うのが苦痛な点だ。Pythonだけでコードを書く分には気にならないのだけど。

sed

プログラミング言語に含まれるかどうか不明だが、DSL扱いで*7。テキスト処理用。シェルスクリプトやMakefileにて他のコマンドと組み合わせて使う。というか正規表現でのテキスト置換以外の機能を使った記憶が……あったな、dとiとpと=とブレースによるグループ化ぐらいだが。私の技術レベルではsedでFizzBuzzを書けないので、sedで難しい処理を記述しないようにしている。

Swift

「コンパイラによる強力な型推論と型安全性のチェック」がお仕事用のメジャーな言語にまで降りてきたという点で、Swiftは静的型付け言語界のJavaScript*8だと思っている。でもユーザ数的には、Kotlinが「静的型付け言語界のJavaScript」ポジションなのかもしれない。割と好感が持てる言語だが、知識が中途半端にKotlinとごった煮になっているので、ついうっかりif式を書こうとしてコンパイルエラーになったり、「varとval」と「varとlet」の振る舞いの差異につまづいたりしてしまう*9。

シェルスクリプト (/bin/sh)

プログラミング言語に含まれるかどうか不明だが……いや、私的にはシェルスクリプトは立派なプログラミング言語だ。基本的な用途は、バッチファイルと同じくちょっとした自動化や複数コマンドを組み合わせて使うときのラッパーだが、実現できる内容は遥かに多い。言語本体(？)がバッチファイルよりも高機能だし、Unixユーザランドはコマンドが充実している。その意味では、WindowsではMSYSよりもCygwinで――いやむしろWSL（Windows Subsystem for Linux）で環境構築すべきだろう。Cygwinでは、主要な処理をシェルスクリプトで記述しておき、bashからはシェルスクリプトを利用し、コマンドプロンプトではラッパーのバッチファイル経由でシェルスクリプトを叩く使い方をしている。ただWindows上では処理速度が妙に遅くなる点が不満だ。まあしかし、Unixのシェルは言語設計もシステム開発技法も未成熟だった大昔に「プアな環境でも問題なく動作する、プログラマブルな対話型コマンドインタプリタ」として開発された代物なので、言語設計の研究が進んでから作られたプログラミング言語と比較してはならない。

あまり使っていない

Perl 5

時々、やむをえない事情で触ることがある。だが基本的によく分からない。何というか、あの記号の羅列っぽさに中々慣れないというか、自分は余りに自由度が高すぎる言語は苦手だと気づいたというか。（言語仕様に慣れているなら）半ば使い捨てなテキストフィルタとかをさっと書くには、悪くない言語だと思うのだが。

Ruby

自作ツール実装にて、AWKの代替言語の最有力候補だった（でも最近はPythonが多いんだな、これが）。テキスト処理でも割と重宝するが、バイナリデータへの変換が絡んでくるとAWKよりもRubyを使った方が効果的だ*10。そろそろirbを電卓代わりに使うスタイルも板に付いてきた気がする。to_s(16)やto_s(2)で基数変換して表示できるところが好き。

SQL

生まれて初めて触れたプログラミング言語その3ぐらいに位置する。組み込みの人なのでSQLとは無縁だと思っていたが、まさかTransact-SQLを少しだけ触ることになるとは。最近はAndroidアプリ絡みでSQLiteに触れることもあるが、AndroidXのRoom経由だったり、ContentResolverのqueryだったりと、フルセットのSQL文ではなく局所局所でDSL的に使う感じである。

Windows PowerShell

時代はPowerShell Coreらしいが、現行のWindows 10でデフォルトで利用できるv5.1に留まったままである。スクリプト言語としてのPowerShellは、オブジェクト指向で.NET Frameworkを叩けてダイナミックスコープでスクリプトブロック（という名の無名関数）と、無茶でピーキーで完全にプログラマ向けな代物だ。Microsoftもよくもこんなエライ代物を出したものだ。残念なことに、コマンドプロンプトの代替という観点では、外部ツールとの親和性が微妙にイマイチだ（特に文字コードとか）。でもPowerShell内で閉じている分には問題ないので、私の手元では「Windows専用のGUI付き小ツールを作るためのスクリプト言語」か「Excel COMとか叩く用のスクリプト言語」か「Windows Serverの管理スクリプトを書くためのスクリプト言語」扱いしている。ところで、いい加減『Windows PowerShell イン アクション』並みの言語解説書の最新バージョン対応版を出版してくれないだろうか。

最近使ってないが、縁は切れてない

bash

最近はデフォルトシェルがbashな環境も多いので、自分用のツールぐらいは素の/bin/shではなくbashで書いても大丈夫な気がしてきた。shよりbashの方が遥かに便利だからなあ――PerlやRuby等には負けるけど。bashでスクリプトを書くときの唯一の欠点は、メジャーバージョンごとの差異や各ディストリでのビルドオプションの違いにより、同じbashという名前でも実は千差万別なところだと思う。PerlやRubyのバージョンは気にするけど、これがシェルになると意外とバージョンに無頓着になってしまう。なんでだろう？

C#

かつて、勉強を兼ねてC# 2.0を少し触ろうとするも未完に終わり、数年後にあらためてVisual Studio 2013をインストールして少しだけ触った*11けどほんの少しだけで終わった過去をもつ私。変数の型推論・ラムダ式・LINQ・デフォルト引数は便利だなあと思っていたら、いつの間にかC# 8.0になってKotlinやSwiftに見られる流行を取り入れてますな。おっちゃん、付いてくのが大変だよ。.NET Frameworkの機能数は反則ものだが、所々に微妙に抽象化が行き過ぎたAPIが見られるのは気のせいだろうか？　それにしても、クラスが必須ではないC言語やC++に慣れてしまった弊害か、アプリケーション・メインエントリすらclass内に定義しなくてはならないC#には、なかなか慣れない。

Free Pascal

お試しで触っているのだが、微妙にDelphi/Free Pascal初心者（ただし他言語の経験者）向けの良い資料が少なくて難儀している。玉石混交なのだ。いっそのこと『OBJECT PASCAL HANDBOOK―マルチデバイス開発ツールDelphiのためのプログラミング言語完全ガイド』を買ってしまおうかしら……と思っていたら絶版っぽい。

Go

寡作ながらもいくつか小ツールを書いてみたが、標準ライブラリが充実しているコンパイラ型言語っていいっすね。C言語に比べればC++の標準ライブラリも充実しているが、どちらかといえばプリミティブな機能が中心だ。PythonやRubyばりの標準ライブラリを抱えているGoには及ばない。その辺は、やはりCプログラマ（特にCでフィルタやデーモンの類を書く層）には受けそうな言語だと思う。並列処理周り（goroutines）とかARM対応とかが気になる。ソフトリアルタイム限定だが「組み込みLinux + Goで書いたデーモン」とかどうだろう？　ただメモリを食うらしいという噂がどうなったか気になる――64bit環境では解消されるという話だったようだが、32bit環境でも解消されるようになったのだろうか？　組み込みでは現時点では逆立ちしたって64bit CPUはありえないからなあ、スマホやタブレット以外では。

Java

生まれて初めて触れたプログラミング言語その2。実のところ、職業プログラマとして本格的に使用することは一生ないと思っていた。Androidアプリ開発も、Kotlin採用後に本腰入れて関わるようになったので、Kotlinメインだ。だが、なぜかぬるい感じに時々Javaのコードを触っている。先にコレクションの操作方法が充実した他の言語を学んでからJavaを本格的に触るようになったので、Java 8以降のStream APIが使えないと身体が拒否反応を示す。少なくとも、構文の見た目こそ保守的なオブジェクト指向プログラミング・スタイルで書かれたC++に似ているけど、中身はC++とは似ても似つかない代物だということは体感している。

Lua

Wiresharkのパケット解析スクリプトを書いたことも、C言語で書かれたUnixデーモンの設定ファイル用に処理系を組み込んだこともあった*12。あれから数年経ったが、今はどんな感じなんだろう？

QML

宣伝文句のとおり、QMLはGUIの記述に非常に向いている。それも、単に標準のUI部品（エレメント）を使うだけでなく、少し改造して使うとか、オリジナルのUI部品を作って使うとか、それらを別のアプリケーションに使いまわすとか、そういう時に威力を発揮する。あと、プロパティバインディングやレイアウトのアンカー指定など、画面サイズの変更に追随するUIを作りやすい機能も揃っている。JavaScriptでちょっとした処理も記述できる――とはいえ、やりすぎるとパフォーマンスの罠が……。少なくとも、JavaScriptでゴリゴリコードを書くのはQML的ではない。QMLは宣言的に、シンプルに書くものだ。力技でロジックでゴリ押しすると、色々と罠に嵌る言語だ。

Scheme

GaucheのWindowsネイティブ環境用バイナリは実験版だが、私が触る分には何の支障もない*13ことに気づいて久しい今日この頃。『Scheme手習い』と『Scheme修行』を購入したので、とりあえずCommon LispではなくGauche（Scheme）の勉強をする方向に転換しようか検討*14しているうちに何年たったのやら。Gaucheはフィルタ・ライクな小ツールの実装用としても良い感じだ。しかし最も多い利用方法はREPLを電卓代わりにすることだ*15。うーん、作業環境がmacOSかLinuxに移ったなら、大手を振ってGaucheでフィルタを書くのだが。

Tcl/Tk

Tclは書き方を忘れた頃にテキスト処理ツールを書いている気がする。Tclは結構独特な言語だ。構文がシェルスクリプトばりに全てコマンドだったり、値が全て文字列だったり、実はリスト構造だったり、意外とTCPソケット通信が得意だったり……。それでも慣れれば結構使いやすい。意外とプロトタイピングに向いている気がする。8.6以降ではオブジェクト指向プログラミングもOKだが、それよりも例外処理用のtry末尾呼び出しの最適化用のtailcallの方が興味深い。しかし、これからメジャーになる可能性は低そうだ。Tkは……小規模なGUIツールをさくっと構築できるところは便利だが、Webアプリ全盛の時代にどれだけ訴求力があるのやら。

Visual Basic .NET

Visual Basic .NET 2003で書かれたコードを時々メンテ中。流石に開発環境はVisual Studio 2013移行したけど。

XSLT

よく考えてみたら生まれて初めて触れたプログラミング言語その4ぐらいに位置する言語だった。縁が切れたと思いきや、仕事でXHTMLから特定要素を抜き出す作業に使うことがあったり……。XMLからテキストレコードに変換してしまえば、後はUnix流テキストフィルタの世界が待っている。餅は餅屋というもので、定型的なXMLの変換はXSLTで記述するべきか。唯一気に入らないのは、xsl:sortでアルファベットの大文字と小文字を区別してソートすることができないこと。ぐぬぬぬ。

これから（また）使うかもしれない

Alloy

形式手法の中では比較的カジュアルに使えそうなので期待中。入門書も処理系も入手した。私の場合、先に何か論理型の言語をかじった方がよいのかも。

bison (yacc)

プログラミング言語に含まれるかどうか不明だが、DSL扱いで。やっぱり構文解析系統のコードを自作するのは割に合わない――だなんてうそぶきつつ、LALR法とか全く知らないままに、既存のyaccのコードを切り貼りして遊んでみた。簡易電卓レベルだが便利さを体感しつつ、さっそくtypo 1文字で痛い目（shift/reduce）に遭った。とりあえず、flexと組み合わせた上でのエラー処理（エラーメッセージの改善）が課題だ。

Common Lisp

2009年に勉強しようと思い立ったものの、未だに進んでいない。階乗とかハノイの塔とかiotaぐらいは書いたが、目標は「ちょっとしたツールを自作する」だ。まだ道は遠い。最近は時々CLISPを簡易電卓代わりにしている。

Coq

ソフトウェアの基礎が気になるので、処理系だけ入手。

F#

OCamlは「Windows上で日本語を扱う」という視点では処理系がちょっと微妙なので、いっそのことF#に乗り換えようかと……。『実践F#』が積読状態になっている。

flex (lex)

プログラミング言語に含まれるかどうか不明だが、DSL扱いで。字句解析用のツールという印象が強かったのだが、よく考えてみたら、flexは「sed(1)のよくある使い方」と同様に「正規表現でパターンマッチング --> 何らかのアクション」という内容を記述するためのツールだった。ただ単に、「何らかのアクション」をC言語で書けることと、flex自体ではパターンマッチングをせずに「パターンマッチングするC言語のコード」を生成することが少々風変わりなだけ。grep(1)やsed(1)その他で小ツールを実装して運用しつつ、性能が求められたらflexで専用ツール化する――とか考えたけど、普通にgrep(1)やsed(1)を使う方が高速だった。

Forth

pForthをMinGWでビルドしたので処理系は手元にある。スタック指向の言語はいつか勉強したい。

Io

プロトタイプベースである点を除けば、何となくSmalltalk的であるような――公式ドキュメントらしきIo Programming Guideでも影響を受けた言語として真っ先にSmalltalkが挙げられているから、あながち思い違いでもないだろう。今更ながら『７つの言語 ７つの世界』のIoの章を読み終えたので、ちょっとしたコード片を書いているが……Windows版のバイナリが古いためか、リファレンス通りなのに動作しないコードに直面している。

JavaScript（クライアントサイド）

クライアントサイドJavaScriptのコードを書いたこともあったけど、スキル的にはもう何もかも賞味期限切れだよなあ。ECMAScript 2015以降を使うなら、それ以前とはコードのスタイルから変えないと不味そう。

JavaScript（サーバサイド？）

Node.jsやPhantomJSが出てきた頃は、クライアントサイド以外でもJavaScriptが使われる文化が広まる可能性があるのか気になったものだが……結局どうなっているの？　何か処理系もNode.jsに収束してきた印象が。

LOGO

そういえばLOGOを触ったことがない。とりあえずUCBLogo（Berkeley Logo）だろうか？　Windows上でUCBLogoばりにGUI無しで動作する処理系はないだろうか？

Object REXX

思うところがあって処理系とIBM謹製のドキュメントを入手したものの、そこから先の進展は無いまま。ReginaでClassic REXXっぽい感じで触っているからなあ。

OCaml

Common Lispを勉強するはずが、いつの間にか触っていた言語。一応、階乗ぐらいは書いた。時間が取れたらもうちょっとしっかりと勉強したいが、面倒なのでF#に移行しようか検討中。

Oz

ふと思い立ってUbuntuにMozartを入れた。『Scheme手習い』の次はCTMCP片手にOzで勉強かなあ。道は遠いな……。

PostScript

これかForthか、どちらに手を出すべきか？　悩ましい。

Processing

入門書も処理系も入手して、あとは弄る時間をつくるだけ。

Prolog

『7つの言語、7つの世界』の地図の色分けプログラムには衝撃を受けた。何というか「正しい問い」を見つけられるか否かが肝なのか。この辺は、根底の部分でAlloyに通じる何かがあるように思う。ひとまず、Prologで論理プログラミングと宣言的なスタイルに慣れておけば、形式手法にて「論理で宣言的に」記述するときに戸惑いが減るのではないかと期待している。

Rust

仕事柄「C/C++の次のシステムプログラミング言語」はそれなりに興味の対象で、Go言語やD言語ほどではないが、Rustも……まあ、気にならなくはない。ちなみに、これら3言語と同列にObjective-CやSwiftが挙げられることもあるようだが、個人的見解としては、システムプログラミング言語としてのこの2言語には全く期待していない。あれは、Appleというしがらみからは逃れられないでしょうな。

VBA (Visual Basic for Applications)

今までVBAから逃げ回っていたのだが、ついに使うことになりそうな予感。たぶん、Access VBA 8割にExcel VBA 2割ぐらい。

今は全く使っていない

Active Basic

VBScripを触りだした影響で、時々思い出しては弄くっていた。ほんの少しだけ触って放置して、すっかり忘れてからまた触る――これを繰り返していた気がする。なので毎度初めて触るのと同じ状態だった。String型をバシバシ使用 :)

bc

その昔、Windows標準の電卓アプリの代わりに使おうとして色々あって挫折した。今はirbかclisp／goshで計算しているからなあ。

CASL II

生まれて初めて触れたプログラミング言語その1。何だかんだで、後でCプログラマになってからも低水準での思考ツールとして微妙に役に立っている。まあ考えるための言語であって実用言語ではない。仮に実用的な処理系*16があったとしても余りに命令がシンプル過ぎて悶絶するなあ、なんてFizzBuzzしてみて思った。

Clojure, Scala

JDKがなくてもJava APIを叩くスクリプトを書けるので非常に便利。Scalaの型推論とか、便利っすね。言語仕様はJavaよりも好みだ。とはいえ、IoT時代にJava VMベースでどこまでメインストリームに居残ることができるのか？　ちょっと興味深い。サーバサイドに活路を見出すのだろうか？

COBOL

FizzBuzzするためだけにOpenCOBOL 1.0をWindows上に用意して触ってみた。なんというか、COBOLの名前と生まれた時代が示すように基幹業務（というかお金や帳簿が絡んでくるところ）向けの言語だよなあ、といった感じ。COBOL 2002のフリーフォーマットを採用するだけでも使い勝手が変わる気がしたが、世の中にはまだ広まらないのだろうか。

CoffeeScript

仕事で使う予定はない。RubyやPythonその他の影響を受けているだけあり、その手のスクリプト言語っぽい感じでコードを書けるので、慣れれば素のJavaScriptで直接コーディングするよりは楽だ。しかし標準ライブラリ回りや処理系絡みの機能やサードパーティのライブラリなど、結局はJavaScriptを知らないとCoffeeScriptでコードを書けないと思う。それに生成されたJavaScriptのコードを見て「うわぁ、これあまり効率的でないなあ」と感じる時もあって、高速化が必要な部分では生成されるコードを気にしながら記述したりCoffeeScriptを諦めてJavaScriptで書くことになるので、やはりJavaScriptを知らないとマズイ。とはいえ便利なのは確かだ。CoffeeScriptのコードは即Node.jsで実行できるので、その辺りから「CoffeeScriptでテキストフィルタ」的な文化が生まれると面白いかも。気になるのはECMAScript 6の存在で、今までCoffeeScript独自の機能だった部分の多くがES6で取り込まれるので、今後ES6対応が進むにつれてCoffeeScriptの立場がどうなっていくのか、少々興味深い。

D言語 2.x

仕事柄「C/C++の次のシステムプログラミング言語」はそれなりに興味の対象で、Go言語ほどではないが、D言語も気になる存在だ。D言語はシンタックスがC・C++に近いだけでなく、コーディングしている時のアプローチ・判断についても、CやC++での流儀がそこそこ通用しやすい気がする。少なくとも、Go言語でコーディングするよりは、文化的背景の違いによるモヤモヤは感じにくい。あと、標準ライブラリを使ってテキストフィルタを書いたところ、エラー処理を1～2ヶ所のtry - catchにスッキリまとめることができて、ちょっと驚いた。throwされる例外のメッセージ文字列が、ちょうどよい塩梅の内容だったため、メッセージを変更する（いったんcatchして、再throwする）必要がなかった。ちょっと残念なのは、マルチバイト対応だが……。

Emacs Lisp

「.emacsにコピペ」限定で。Common LispやSchemeを触ったためか、何となく内容を追えるようになってきた気がしていたが、勘違いだった。

Fortran

Fortran 90やFortran 95あたりは結構近代的な言語だと思う。用途次第ではC言語よりもFortranの方が遥かにマシな選択だろう。配列がらみの処理はFortranの方が得意だし、言語機能としてのモジュール化の方法はC言語には存在しない。可変長な文字列の扱いに微妙な制限がある点はマイナスな気もするが、まあ基本的に数値計算プログラム用の言語だからなあ。

GDB (GNU Debugger)

……いやGDBはデバッガとして使っているが、GDBのスクリプトを書く機会は（FizzBuzz以外に）ない。勉強不足なだけかもしれない。

Groovy

JDKがなくてもJava APIを叩くスクリプトを書けるので非常に便利。動的型付け言語っぽくいくもよし、@CompileStaticや@TypeCheckedで型推論するもよし。言語仕様はJavaよりも好みだ。コンソールアプリを書く人としては、オプション引数解析用の機能を標準で持っている点で、GroovyはClojureやScalaよりもポイントが高い*17。個人的には、IoT時代に「Java VMベース」の言語としてどこに活路を見出すのが、興味深く見守りたいところ。やはりサーバサイドだろうか？

HSP (Hot Soup Processor)

FizzBuzzで楽しんでみたが、何というか他言語経験者には受けが悪そうな命令体系だと思う。もっとも初心者がプログラミングという行為に深入りせずにWindows用のGUIな何かを作る分には、あの命令体系でも十分な気がしないでもない。ところで元々は「HSPで職業プログラマ的な良いコードを書くと、どんな感じになるか？」というネタを思いついて処理系を用意したのだけど、そちらは全く進展がないまま。

JScript on WSH

他人が使うテキスト処理ツールの実装に使って以来、時々触ってきた。Windows用の配布可能な小ツールを実装する時の定番言語だった。でもそろそろ潮時だろう。HTAと組み合わせてクライアントサイドJavaScriptなノリで簡易なGUIツールを実装できる点も、PowerShell + WPF + XAMLで代替できそうだ。他のメリットは「JavaScript（ECMAScript）でフィルタを書ける」だったが、WSHのなかなか目的にたどり着けないオブジェクト階層にイライラするよりも、Node.jsやPhantomJSを使ったほうが精神衛生的にマシだ。

m4

その昔テキスト処理用に触ろうとして、Windows用のどの処理系も日本語の置換に何かしらの問題を抱えていたので泣く泣く諦めた。思うところがあって改めて少し触ってみたが――なるほど、確かに中毒性のある言語*18だ。

Smalltalk (Squeak, Pharo)

Smalltalkは有名な古典的プログラミング言語だというのに、触ったことがない。ということでSqueakとPharoの処理系のみ準備完了。うーん、「環境」付きなのが気になる――言語を弄くる基準が「コンソール上でテキストフィルタ」という変な人種な私だからなあ。

Smalltalk (GNU Smalltalk)

個人の思想信条による理由よりSqueakとPharoにわだかまりを感じてしまう変人なので、邪道だと思いつつもコンソールでテキスト処理もOKなGNU Smalltalkも用意してみた。これで言語としてのSmalltalkの勉強に集中できる……か？

REXX

Open Object REXXの処理系を入手したのに、何故かReginaを入れてClassic REXXっぽい方向に走っていた。何というか、COMコンポーネントや.NET Frameworkと無関係でいられるのなら、バッチファイルの代替としてはREXXあたりがほどよい塩梅だと感じる。しかし最近流行の言語とは随分と勝手が違うし、日本語の情報も少ない。メインフレーム以外の世界で流行る可能性は少ないだろう。

T4 Text Template

「へえ、こんなものがVisual Studioに入っていたのか。機能多すぎで色々と便利なツールを見逃しているんだな、やっぱり」と思いつつ触ってみた。テンプレート変換の用途ではピカ一だと思う。ただ処理系を手に入れる方法が「Visual Studioをインストールする」or「MonoDevelopをインストールする」なので、何となく「単体で手軽に使えるツール」ではないというイメージが……。まあC#やVBで処理を記述するので、それらの処理系が必要だという面での制約なのだろう。

VBScript on WSH

JScriptほどではないが「Windows上で他人も使えるツールを書くためのLL」扱いしていた言語。Windows Server管理の関係で触っていた。というかWebで入手可能なWSHのサンプルの大半がVBScriptで書かれていたり、ADSI関連のコレクションをJScriptで舐めれなかったりして、結局は必要に駆られて使用することに。明快に記述できる文法は評価に値するが、スクリプト言語としては少々冗長だ。配列は自動拡張しないし、組み込み関数はプリミティブ気味だし、冗長気味な文法との合わせ技でコードがさらに冗長になっていく……。文法や言語仕様の詳細なドキュメントが見つからないのだが、どこにあるのだろうか？*19

Vim script

少し触ってみた分には、exコマンドの拡張（＝コマンドの羅列）とは気づかない程度にはプログラミング言語らしいと思う。とはいえ妙なところで嵌ったり微妙に一貫性のない部分があったりするので、その辺りで好き嫌いが別れる気がする。

秀丸マクロ

7年ほど秀丸エディタを使っていたが、マクロを書く機会はなかった。一念発起してFizzBuzzしてみて感じたのは、最近の便利な言語に慣れた身としては色々とモヤモヤ感がある言語仕様だということ（歴史的経緯的に仕方ないのだが）。とはいえちょっとした拡張ツール的なものを手軽に作れそうではあった。

*1:「HTML5 + CSS」の組み合わせなら、チューリング完全の疑惑があったり、JavaScript使わずにCSSでWebチャットを作った猛者がいたりと、色々と怪しいのだけど。

*2:「独立性の高い単体のツールを実装する」という視点では、現代ではAWKよりも便利な言語が山ほどある。

*3:しかし標準ライブラリの充実度をJavaやC#（.NET Framework含む）と比較したり、型推論まわりをKotlinやSwiftと比較してはいけない。以前よりも随分と便利になったのだけど、だけど、隣の芝生を見てしまうと、うーん……。

*4:SwiftではC++の機能を直接呼び出すことができないので、Objective-Cでラッピングして利用することになる（インタフェースはObjective-Cで、内部実装はObjective-C++）。この時、Objective-Cクラスのインスタンス変数として「C++クラスのインスタンスを保持するスマートポインタ」を持つ構成にしておくと、Objective-Cクラスのインスタンスがdeallocされる時に、スマートポインタ経由でC++クラスのインスタンスもdeleteされる。

*5:本格的にC99がサポートされ始めたのはVisual Studio 2013以降だ。それよりも前のバージョンのEOLだが、Visual Studio 2012が2023年1月となっている。

*6:少なくともC++の言語仕様は私の手には余る。自分が把握している範囲の機能でコードを書くのは好きなのだけど。

*7:これでもsedはチューリング完全な言語だと証明されているらしい。

*8:私の認識では、JavaScriptは、第一級関数やクロージャがお仕事用のメジャーな言語に組み込まれて、少なくない人が使う契機となった言語だ。

*9:Kotlinのvalは「再代入不可の変数」だ（定数はconstで定義する）。Kotlinのプリミティブ型以外のデータ型はclass（つまり参照型）なので、valで定義した変数を破壊的操作する行為は割と普通だと思う。一方でSwiftのletは定数であるし、値型が中心の言語仕様である影響かstructやenum（つまり値型として振る舞うデータ型）が多用されるので、letで定義した変数を破壊的操作できるケースとできないケースが生じる。

*10:とはいえ、ついついC++を使ってしまうのだよなあ。

*11:言語仕様的にはC# 5.0の環境だが、ライブラビまわりはC# 4.0相当だったはず。

*12:Windowsのことを考えなければ、自前でライブラリをビルドしてアプリに組み込むのは結構簡単だった。

*13:支障がある部分を触るほど深入りするには、あと20年ぐらい掛かるのではないか？

*14:Schemeの勉強というよりも、再帰の勉強なのか？

*15:現状はirbかclispかgoshの3択だ。

*16:――といってもシミュレータだけど。

*17:ClojureやScalaに関しては、同様の機能を私が見逃している可能性も高いのだが。

*18:m4はマクロプロセッサなのでプログラミング言語ではないはずだけど……。

*19:MSDNの資料では物足りない。もうちょっと掘り下げた内容のものが欲しい。

Windows 10 Version 2004でのネットワーク名の扱いについてのメモ

Windows 10にてネットワーク名を変更する方法について、ネット上の情報は若干の混乱というか両論併記的な記述が多いようなので、少し整理してみる。

要は、Windows 10 ProやEnterpriseの場合：

• ローカルセキュリティポリシーでネットワーク名を設定する方法
  • Windows 管理ツール → ローカル セキュリティ ポリシー → ネットワーク リスト マネージャー ポリシー → すべてのネットワークを表示
• レジストリでプロファイル名を変更する方法
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

――という2つの方法があるのだが、それぞれどう影響しあうのか、という話だ。

（Windows 10 Homeではレジストリでプロファイル名を変更するしかないので割愛）

1. ローカルセキュリティポリシーでネットワーク名を設定した場合には、その名前が表示される。
2. ローカルセキュリティポリシーでネットワーク名を「未構成」に場合には、レジストリに設定されているプロファイル名が表示される。

ローカルセキュリティポリシーにて「すべてのネットワークを表示」とした際に一覧表示されるネットワーク名は、レジストリに設定されているプロファイル名だ。

興味深いことに、ローカルセキュリティポリシーで設定したネットワーク名は、レジストリのProfileNameとは別のどこかに保存されるようだ。

つまり、Windows 10 Pro / Enterpriseにおいては、GUIで表示される「ネットワーク名」には「ローカルセキュリティポリシーで設定した名前」と「レジストリ上のプロファイル名」の2種類があり、「ローカルセキュリティポリシーで設定した名前」の方が優先的に使用される。そして「ローカルセキュリティポリシーで設定した名前」が未構成の場合は「レジストリ上のプロファイル名」が使用される。

どうしてネットワーク名が内部的に2種類あるのかは不明だ。おそらく「歴史的経緯による継ぎ足し」によって、この二重化が発生したのだと思うのだが……プロファイル名には使用できない文字がある（なので「プロファイル名≒ネットワーク名」とすると、使用可能な文字種の制約が厳しい）とか、そんな理由かしらん。プロファイル名って「辞書型におけるキー値」っぽい役割で利用されていそうだから、色々と制約がありそうな気がする。

コードリーディング対象としての標準ライブラリのすゝめ

年頭において、初心を忘れないように書いておく。

新しいプログラミング言語の使い方を学ぶ時、個人的に、公式のチュートリアル／コーディングスタイル／リファレンスを参照するのと並行して、当該言語の標準ライブラリのソースコードを読むことが多い。

全くのプログラミング初心者には推奨できない手法だ。しかし、学習者が単なる「当該言語の初心者」でしかなく、関数やクラスなどのモジュール化機構による機能分割に慣れ親しんだプログラミング経験者ならば、話は違う。

大抵において、標準ライブラリの中身は、不要な部分が削られて小さくまとめられた単機能であり、手のひらサイズのコードで実現されている――だから読んで理解しやすい。昨今の言語ならば、REPLで振る舞いを確認することも容易だろう。

最近の主流言語の多くでは「言語仕様の設計者≒当該言語の最もメジャーな処理系の開発者≒『最もメジャーな処理系』に付属する標準ライブラリの設計・実装者」の図式が比較的成立しやすい。そのような環境においては、標準ライブラリの実装者は当該言語のグルだ。傾向として「言語設計者の思想」を強く受け着いたコードを書くはずである。

結果として、十分にレビューとテスト済みの、無駄が取り除かれた、その言語らしさが凝縮された短いコードを読むことができる。

学習の目的が「当該言語でのコーディング時にフラストレーションが溜まらない程度に、言語の流儀に慣れたい」であれば、標準ライブラリのコードを読んで真似することにより、足切りをクリアできる水準に比較的短時間で到達できる。

この方法を伝授された時の言語はC言語で、BSDユーザだった当時の先輩が構築したFreeBSDマシンにリモート・ログインして、BSD libcの文字列関数*1のコードを読むよう勧められた。まだGitなんて影も形もなかったころで、Webベースでのコードリーディングが堪らなく遅かった時代だ。System source tree込みでFreeBSDをインストールして、EmacsないしVim/nviでタグジャンプを駆使しつつBSD libcのコードを読む、というのは割とベターな方法ではあった。

最近ガッツリ学んだ言語はKotlinだが、GitHubに公式のリポジトリがあり、その中に標準ライブラリのコード一式も含まれている。ブラウザ・ベースでの閲覧で十分ならば、ちょっと検索するだけでコード自体にたどり着いてしまう――という事実には、隔世の感を禁じ得ない。ただ、興味深いことに、言語は変われども「読みやすいのは文字列とコレクション操作」という感想に変わりはない。

*1:一般にstring.hに定義されている関数群のこと。

シェルスクリプトを生成するシェルスクリプト

超小規模な社内サーバの管理に関わることが多いためか、管理用に「スクリプトを生成するスクリプト」を作成することがある。

「スクリプトを生成する」と書くと、なにかしら大層なことをやっているように聞こえるが、何のことはない、単に可変のパラメータをテンプレートに当てはめて出力しているだけである。

4月の新卒社員の入社や、オンプレミスのサーバの入れ替えにともなうデータ移行などでは、似たような作業を何度も繰り返す場面がある。例えばアカウントやグループの追加などだ。こういった場面では、事前にアカウント名などの一覧を作成しておき、それらをテンプレートに当てはめて、「アカウントを一括追加するスクリプト」を生成しておく。

生成したスクリプトは、事前に内容をチェックしておき、後で*1スクリプトを実行してシステムに適用する。

そして使用済みのスクリプトは、システムの運用記録の一部として保存しておく。

この手法を、まだPowerShellが無かったころにWindows Serverで採用した時は、「RubyのスクリプトでWSH（VBScript）のスクリプトを生成する」という、少々大げさな構成だった。システムをスクリプトで十全に管理するためにはWSHを使うしかなかったのだが*2、スクリプト生成自体はテキスト処理が得意な別の言語*3を使わないと辛かった。

（最近のWindows Serverはまともに触れていないのだが、PowerShellを使えば「PowerShellでPowerShellのスクリプトを生成する」という感じになりそうだと思っている）

今はLinuxサーバを運用しているが、Unix系のファイル・ベースの世界なので、「シェルスクリプトでシェルスクリプトを生成する」というシンプルな構成に落ち着いている。シェル環境はテキスト処理もそれなりにイケる口だし、システム管理自体もシェル・コマンドで済むので、こういう芸当が可能となる。

つい最近サーバを引っ越したのだが、ディレクトリ・サービスなんて存在しない環境なので、「引っ越し元のユーザとグループを、uidとgidが同じ値となるように、引っ越し先に登録する」という作業を行う必要があった。

全ユーザの情報は「getent passwd」で取得できるが、システム管理用のアカウントも含まれている。引っ越し元の環境では、一般ユーザのuidは1000以上なので、まずはuidでフィルタリングすればよい。ただし例外として、nobodyのuidは「1000以上」に該当するので、追加でフィルタリングする。

getent passwd |
awk -F : '$3 >= 1000 && $1 != "nobody"'

これで、例えば次のような出力が得られる。

foo:x:1000:1000::/home/foo:/bin/rbash
bar:x:1001:1001::/home/bar:/bin/rbash
baz:x:1002:1002::/home/baz:/bin/rbash

この出力を、例えばuseradd(8)のコマンドの羅列に変換してしまえば、後は引っ越し先で実行するだけで済む（パスワード・ログインが絡んでくると厄介だが、このサーバでは、一般ユーザはsshの公開鍵認証でのログインのみ許可している。また制限付きシェルを使用して、利用可能な機能を制限しており、su(1)やsudo(8)なんて夢のまた夢状態である。なので、この程度の変換で済む）。

getent passwd |
awk -F : '
$3 >= 1000 && $1 != "nobody" {
    print "useradd -b /home -g " $4 " -s " $7 " -u " $3 " " $1
}'

結果はこんな感じ。

useradd -b /home -g 1000 -s /bin/rbash -u 1000 foo
useradd -b /home -g 1001 -s /bin/rbash -u 1001 bar
useradd -b /home -g 1002 -s /bin/rbash -u 1002 baz

コマンドの生成はワンライナーでも可能だが、実際のサーバ運用では、引っ越し直前に急なアカウントの変更が発生することがある。なので、コマンドの生成処理自体をスクリプト化しておき、直前にアカウントの変更が発生した場合には再度スクリプトを実行するだけで済むようにしておく。

#!/bin/sh

getent passwd |
awk -F : '
BEGIN {
    print "#!/bin/sh"
}
$3 >= 1000 && $1 != "nobody" {
    print "useradd -b /home -g " $4 " -s " $7 " -u " $3 " " $1
}' >02-make-users.sh

実のところ、サーバ管理はほぼ独学でやっているので、このような手法が一般的なのかどうなのか分からない。でも、まあ、私のような素人が思いつくような方法なので、別段変わったやり方ではないと思う。

ただし、おそらく「大きな会社のシステム管理」や「大規模システムのインフラ管理」という「利用者の同質性が低い」環境では、このような手法は危険だろう。スクリプトを生成するとなると、本来はユーザ名などの可変パラメータのバリデーション（というかエスケープ処理）を真面目に考える必要があって、そこで七転八倒して苦しむぐらいなら最初から「スクリプトを生成する」ではなく「スクリプト内で処理までしてしまう」に舵を切ってしまった方が安全だ。

良くも悪くも、同質性の高い少人数が利用しているサーバだからこそ可能な手法だろう。

まあ、モダンなサーバ管理では、より安全で簡単な手法が採用されているに違いない。

*1:新卒社員の正式入社日や、サーバの入れ替え作業実施日など。

*2:システムの細かいところに手を加えようとした時、バッチファイルでは不十分だった。

*3:当時だとPerl・Python・Ruby。

2020年Objective-Cの旅

まだObjective-Cで消耗してるけど、なんか質問ある？

いや、別にSwiftが嫌いな訳じゃない。「Xcode + Swift」とか「Android Studio + Kotlin」みたいな「開発環境込みでの『モダンな静的型付け言語』」の便利さは体験済みな訳で、私だって今からiOS/macOSアプリを書くならSwiftを第一候補とするだろう。

なのだけど、例えば既存のPC向けクロスプラットフォーム・アプリをスマホに移植する場合、私の周囲にはアプリのコア部分がC++で書かれたものが多い。

そのようなアプリは、GUIは各プラットフォームのフレームワークで実現していて、コア部分はC++で書かれていて、さらにコア部分の中の機種依存層は各プラットフォームのライブラリをC/C++ベースの言語で叩いていて――という構造を持っている。

Windows向けの実装だと、以下のような感じになっていたりする。

• GUI：MFCやQtなど
• コア部分：
  • 共通部分：C++
  • 機種依存層：C/C++でWindows API

こんなアプリをiOSに移植しようとすると、Swiftからコア部分を利用しやすいようにObjective-Cでラッピングして*1、コア部分の中の機種依存層の中身はObjective-C++で書くかC/C++を使いつつCoreFoundationなどのC言語ベースのAPIを叩く――というアプローチをとることになる。

• GUI：Swift（SwiftUIやUIKitなどを使用）
• コア部分のラッパー：インタフェースはObjective-C、中身はObjective-C++
• コア部分：
  • 共通部分：C++
  • 機種依存層：インタフェースはC/C++、中身はObjective-C/Objective-C++もしくはC/C++ with 「CoreFoundationなどC言語ベースのAPI」

で、Swiftで書けるGUI側は若人に任せて、おっさんの私は泥臭い下回りを担当する……あれ？　結局Swiftのコードを書く機会が少ないぞ、と。

まあそんな訳で、2020年になってもObjective-Cのコードを書く機会があるのだけど、今となっては「モダンなObjective-C」を学ぶ情報源に乏しい。さてはて、どうしたものか？

Apple公式のObjective-Cのドキュメントの所在

Apple Developerのサイトを見た感じ、Objective-Cのドキュメントは軒並みDocumentation Archiveに置いてあるようだ。

ここに置いてあるということは `no longer updated' ということだ。まあ、そうだよね。

ところで、一部のドキュメントは日本語版が作成されていたはずなのだけど、それらへのリンクは無いのだろうか？　Documentation Archiveのものは全部英語っぽいのだが……。

日本語の書籍は電子書籍が頼り

Apple公式の資料の扱いがあんな感じなので、日本語で書かれた書籍は絶滅寸前――と思いきや、意外とKindleなどの電子書籍なら購入できるようだ。

今時Objective-Cを触る人は、かつてのiOSアプリ開発のような「オールObjective-C」ではなくて、私みたいに「Swiftとの連携」とか「C/C++との連携」とか、少々マニアックな用途で使うことが多いと思う。

そういう「若干、言語のコアな部分に踏み込む」ような用途を考えると、『Effective Objective-C 2.0』や『詳解 Objective-C 2.0 第3版』あたりを推奨したいところである。

Effective Objective-C 2.0

詳解 Objective-C 2.0 第3版

Swiftとの連携に関しては『Swift実践入門』や『詳解Swift』の古い版が良いと思う。古い版では、Swiftとの連携について章を設けて書かれている。

私は『Swift実践入門』の最初の版と『詳解Swift 第3版』を持っていて、この2冊ではSwiftとの連携について書かれていることを確認している。

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

詳解Swift 第3版

ネット上で章立てを確認した感じでは『Swift実践入門 改訂新版』や『詳解Swift 第4版』でも記述があるように見えるが、実際のところは不明である。

[改訂新版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

詳解 Swift 第4版

一方で現在出版されている『Swift実践入門 増補改訂第3版』や『詳解Swift 第5版』では、その辺の記述が省かれている。なので、せっかく新しい版を買ったのに、旧版を知人に譲ったりネットで売ったりすることができない。本棚が圧迫されていく……。

実際のところ、2020年にObjective-Cってどうなのよ？

SwiftやKotlinは、型チェックまわりを理解すれば安全なコードが書けるし*2、統合開発環境と組み合わせればコーディング時の生産性が高くなるし、言語や標準ライブラリ自体もモダンな機能が取り入れられていて使いやすい。便利な言語なことは間違いない。

最適化についても、Kotlinは分からないが、Swiftは色々と頑張ってくれているようだ。

なのだけど、一定以上のリアルタイム性が求められるケースでは、暗黙のうちにヒープ領域へのメモリアロケートや排他のためのロックが発生することがある、という振る舞いが仇となる。便利さは何かしらの犠牲の下に成り立っているものだ。

そういう時には「C言語におけるインライン・アセンブラ」のように、局所的にC/C++を併用せざるを得ないことがある。

このような場面にて、アプリケーションの大半はSwiftで書きつつ、一部モジュールのみインラインにC/C++のコードを書けるObjective-CやObjective-C++で実装したり、C/C++でモジュールを書いた上でObjective-Cでラッピングする――というアプローチは悪くない選択であるし、実際のところそれなりに機能する。

少なくとも今しばらくは、タンスのいちばん下の引き出しにObjective-CやObjective-C++がしまわれている日々が続くだろう。捨て去ってしまうのは、まだちょっと早いようだ。

*1:インタフェースはObjective-Cで、中身はObjective-C++で書く。

*2:ふわっと理解する程度なら短時間で済むし、その程度の理解でも効果が得られる。

EdgeRouter Xに組み込む自作ツールを作るなら、どの言語を使うか？

故あってEdgeRouter Xを触っている。

中身のEdgeOSがVyattaベースで、Vyattaの大本はDebianで、さらにコンソールがvbashで割と普通のシェル環境っぽく使えるので*1、自作のコンソールアプリを組み込めそうだと思ったのだ。

というかsshログインのホームディレクトリにbinという名前のディレクトリを作って、中にスクリプト等を置いておくと、次回のログイン以降に環境変数PATHに追加されるよね……。

タスクスケジューラ機能を使って自作スクリプトを定期実行することもできるようだ。

問題は、どの言語なら比較的容易にコンソールアプリを実装できるか、ということだ。

EdgeRouter X上のEdgeOSは32bit MIPS little-endianで動作している。CやC++で実装するとクロスコンパイルが面倒だ。一方でスクリプト言語の類は、限られた空きディスク領域に処理系を導入すると後々面倒なことになりそうだ。

一番手軽なのはシェルスクリプトだろう。POSIXでも定義されているような、一般的なテキスト／ファイル処理用のコマンドは一通り載っているようなので、凝ったことをしなければ大丈夫だろう。

スクリプト言語については、EdgeOS V1.x系にはデフォルトでPerl 5とPython2が入っている。CPANやPyPIが組み込まれていないので標準ライブラリ縛りとなりそうだが、Perl 5やPython2でスクリプトを書くこともできそうだ。ただし、スクリプトが実行開始されるまでにほんの少し時間がかかる。普段使いのPCと比較すれば、EdgeRouter XはCPUパワーもディスクI/O速度も劣るだろうから、仕方がない。

ダークホースだったのはGo言語。普通にPC上で開発して「GOOS=linux GOARCH=mipsle」を付与してgo buildして、生成された実行ファイルをEdgeRouter Xに転送すればよい。簡単だ。ただし実行ファイルのバイナリサイズが大きくなるので、若干注意が必要かもしれない。まあそこまで気にすることは無い気もするが……。

起動速度を勘案すると、簡単な処理ならシェルスクリプトで、凝ったことをしたいならGo言語で開発するとよさそうだ。Perl 5やPython2も悪くないだろうが、果たして標準ライブラリ縛りに耐えられるだろうか？　あと、Pythonは3系を使いたくなりそう。

*1:ただしUnixコマンドやファイルの入力補完は効かない。管理用コマンドの入力補完が組み込まれているためだろう。

Dockerのコンテナ停止時にバックグラウンド・プロセスとして動作しているデーモンを適切に終了させたい

続き。

前回、下記のような書き方だとコンテナを停止する際に問題を引き起こす可能性がある、と書いた。

FROM amazonlinux:latest

# 色々と準備（省略）

# コンテナ起動時に秘伝のデーモン magic-daemon を起動する。
# その後、コンテナを終了させないようにする。
CMD /etc/init.d/magic-daemon start; tail -f /dev/null

docker stopなどでコンテナを停止させる時、コンテナ内のPID=1のプロセスにSIGTERMが送信されるのだが、PID=1はCMDの内容を実行している/bin/sh -cだ。

つまり、バックグラウンド・プロセスとして動作しているデーモンそのものにはSIGTERMが届かない。デーモンは依然として動作したままとなり、一定時間後（既定では10秒後）にSIGKILLが送信されて、強制的に終了させられる。

待ち時間はdocker stopのオプション-tで変更できるものの、ついうっかりオプションを忘れて10秒待つのはイライラの元であるし、何より「本来意図されているだろう終了処理が行われない」というのも気持ち悪い。「気持ち悪い」だけで済めば良いのだが、例えば複数同時起動を回避するためにロック・ファイルを作成するシステムでは、強制終了によりロック・ファイルが残されたままとなり、次回以降のコンテナ起動時にデーモン起動に失敗する――といった具合に、何かしらの問題が引き起こされるものである。

この問題に対応するには、以下の内容を実行するラッパーのシェルスクリプトか何かを用意しておき、CMDにてexec形式で当該スクリプトを呼び出せば良い。

1. デーモン起動のコマンドを実行する。
2. SIGTERMを受信するまで無限待ちする。
3. SIGTERMをトラップして、デーモン終了のコマンドを実行する。

例えば次のような内容のスクリプトdaemon-runner.shを用意しておく。

#!/bin/sh
# -*- coding: utf-8-unix -*-
# vim:fileencoding=utf-8:ff=unix
#
# daemon-runner.sh
# 秘伝のデーモンの起動／終了を制御するスクリプト。

trap '/etc/init.d/magic-daemon stop; exit 0' TERM

/etc/init.d/magic-daemon start

# SIGTERM が届くまで待ち続ける。
# trap(1p) で指定したコマンドが即座に実行されるようにするため、
# バックグラウンドで sleep(1) させてフォアグラウンドで wait(1p) する。
while : ; do sleep 86400 & wait $!; done

このスクリプトをコンテナにコピーして、CMDで実行するようにしておく。

FROM amazonlinux:latest

# 色々と準備（省略）

# ラッパースクリプトをコンテナにコピーして、実行権限を付与する。
# いずれ COPY のオプションで --chmod=0755 みたく書けるようになるはず。
COPY ./daemon-runner.sh /usr/local/sbin/
RUN chmod 755 /usr/local/sbin/daemon-runner.sh

# コンテナ起動時に秘伝のデーモンを起動する。
CMD ["/usr/local/sbin/daemon-runner.sh"]

こうしておけば、コンテナ起動時にデーモンを起動した後は無限待ちとなるのでプロセスが生存し続ける。またexec形式で記述したことでPID=1のプロセスとして動作するので、コンテナ停止時にSIGTERMが届くから、trap(1p)でシグナルをフックしてデーモン終了のコマンドを実行することが可能となる。

蛇足

なお、秘伝のデーモンがシグナル受信だけで適切に終了する（つまり本稿で言うなら「/etc/init.dのスクリプトで停止」しなくても問題ない）場合、もしかしたら冒頭に挙げたCMD /etc/init.d/magic-daemon start; tail -f /dev/nullのような書き方をした上で、docker runの時にオプション--initを付与するだけで事足りるかもしれないが、あまり試していないので真偽は不明である。

バックグラウンド・プロセスが/bin/sh -cの子プロセスの場合には効果があるようだが、deamon(8)などを使ってバックグラウンド化したプロセスの場合にどうなるのだろうか？

Dockerのコンテナ起動時にバックグラウンド・プロセスとして動作するデーモンを起動させたい

Dockerのコンテナを起動する際に何らかのデーモンを起動させたい、という要求は結構多い（というか実務的にはむしろそれが主目的ではないか）と思うのだが、「何らかのデーモン」がバックグラウンド・プロセスとして動作する代物だと、若干ハードルが上がるようだ。

デーモンがフォアグラウンドで動作するならば、教科書通りDockerfileのCMDにデーモン起動のコマンドを記述すればよい。例えば次のような内容だ。

FROM amazonlinux:latest

# 色々と準備（省略）

# コンテナ起動時に自作デーモン my-daemon を起動する。
CMD /usr/local/sbin/my-daemon -l /usr/local/etc/my-daemon.conf

DockerfileのENTRYPOINTやCMDは、フォアグラウンドで動作するアプリケーションを前提としている節がある。ENTRYPOINTないしCMDに記述されたコマンドは、コンテナ起動時にPID=1のプロセスとして実行される。フォアグラウンドで動作するアプリケーションならば、自身のプロセス（PID=1のプロセス）は実行状態のままとなり、コンテナを停止するまで生存し続ける。

※より正確に書くと、docker run実行時にオプション--initを付与しなかったコンテナにおいては、ENTRYPOINTやCMDにexec形式で記述されたコマンドが、PID=1のプロセスとして実行される。シェル形式で記述した場合、そのコマンドは/bin/sh -cの引数として実行されるが、この時PID=1のプロセスは/bin/sh -cであり、その子プロセスとして「ユーザが記述したコマンド」が実行される。

ところで、非コンテナ環境で運用してきた秘伝のデーモンを組み込もうとした時、例えば/etc/init.dの起動スクリプト経由でバックグラウンド・プロセスとして起動させる、みたいな構成*1であることが結構多い。

起動スクリプト内でdeamon(8)を使っているならまだしも、中にはソースコード内でdaemon(3)を使って自前でバックグラウンド化している（しかもフォアグラウンドで実行させる術がない）アプリケーションもあったりする。

残念ながら、CMDの内容が「バックグラウンド動作するデーモンを起動する」だけであると、コンテナ自体が起動した直後に停止してしまう。例えば次のような内容だと、ユーザの意図した動作にならない。

FROM amazonlinux:latest

# 色々と準備（省略）

# コンテナ起動時に秘伝のデーモン magic-daemon を起動する。
# ==> デーモンは起動するが、コンテナ自体が直ぐに停止してしまう。
CMD /etc/init.d/magic-daemon start

CMDの内容に従ってデーモン起動のコマンドを実行した直後に、その処理を行ったPID=1のプロセスが終了してしまう。そのため、コンテナ自体が直ぐに停止してしまうのだ。

ではどうすればよいかといえば、CMDに「直ぐには終了しない処理」を記述すればよい。デーモン起動のコマンドを実行した後に、例えば以下のようなコマンドを実行するのだ*2。

• /bin/sh
  • 対話型コマンドなので、直ぐには終了しない。
  • ただし/bin/bashへのシンボリックリンクだったりすると、ほぼ使われないプロセスなのにVSZやRSSが大きくなりがちで、微妙な気分になる。
• sleep infinity
  • 厳密には有限だが、事実上問題にならないほど長い時間sleep(1)する。
  • なお、この書き方はLinux限定で、他のUnix系OSでは使えない……はず。でもDockerだからLinux以外の環境を考慮する意味はない。
• tail -f /dev/null
  • これも無限待ち状態になるが、他者に意図が伝わりにくい書き方だと思う。
• while : ; do sleep 1; done
  • 実はこれが一番手堅い方法かもしれない。

CMDに複数のコマンドを記述するには、ラッパーとなるシェルスクリプトを用意しても良いが（というか個人的にはそれを推奨するが）、シェル形式を用いて次のように記述するのもひとつの手だろう。例えば次のような塩梅だ。

FROM amazonlinux:latest

# 色々と準備（省略）

# コンテナ起動時に秘伝のデーモン magic-daemon を起動する。
# その後、コンテナを終了させないようにする。
CMD /etc/init.d/magic-daemon start; tail -f /dev/null

ところで上記の書き方は、コンテナを停止する際に問題を引き起こす可能性がある。回避するためには、ラッパーとなるシェルスクリプトを用意する必要がある。

（次回に続く）

*1:要は、システム起動時に SysVinit / Upstart / Systemd などを使用して起動する、という前提で実装されたデーモンだということ。

*2:ここでは、比較的どのDockerイメージにも入っていそうなコマンドを選択している。

21世紀に新たにMakefileを書く意味はあるのか？

物心ついた頃は昭和で、十代まるまる20世紀だった地方民にとって、21世紀は「超音速原子力旅客機が飛び、潜水可能な豪華客船が航行し、海底の透明チューブの中を列車が走り、マイカーは自動運転でホバーで空だって飛べるさ」な時代になるはずだったのだが、現実には超音速旅客機による商業飛行は無くなってしまい、客船は未だに潜水せず、列車は海底よりもさらに下の地底のトンネルを走り、私の車は自動運転じゃないしタイヤが4つ付いてるし地面を走ることしかできない。*1

そして、21世紀も10分の1どころか四捨五入すると5分の1が経過したにもかかわらず、未だに私はMakefileを書いている――それも、WindowsやmacOSアプリ向けに、新規作成である。

これが、組み込み機器のプロジェクトや、Linux向けアプリだったら、まだ驚きは少ないだろう。

組み込みの場合、最近は統合開発環境が増えたものの、過去のプロジェクトを見渡せば、使用するマイコン向けのコンパイラとセットでmakeが付いてくることは少なくなかった。この場合、システムのビルド用に書かれたMakefileを修正することはままあるものだ。

Linux向けのアプリやライブラリの場合、例えば「組み込みLinux」や「うちのサーバ1台で動かすデーモン」の類の場合、移植性とかあまり気にする必要がないのでautotoolsを持ち出さずにGNU Makeで済ましてしまうことも多い。

しかし、WindowsやmacOSアプリである。Makefileを書く意味はあるのだろうか？

実のところ、新たに書いたMakefileは、純粋なソースコードのコンパイル用ではない。アプリ本体と関連するプラグイン類のビルド、実行ファイルへの署名、インストーラの作成と署名、作成されたインストーラや関連ファイルをまとめた圧縮ファイルの作成――つまり、Webアプリでいう「デプロイ作業を自動化するスクリプト」の同等品だ。

そのため、Visual Studioのプロジェクトはdevenvで、Xcodeのプロジェクトはxcodebuildで、コマンドライン・ツール経由だが各プロジェクト・ファイルを用いてビルドしている。Makefile内でdevenvやxcodebuildを呼び出している訳だ。

本来ならば、Windowsアプリの場合、Visual Studio Installerプロジェクトを含めた関連するプロジェクトを1つのソリューション・ファイルにまとめて、ビルドの順序を整理し、ビルドの前後に実行するコマンドを設定することで、わざわざNMAKEで苦労せずとも全工程を自動化できるはずだ。こうして作成したソリューション・ファイルをdevenvで実行すれば、Visual StudioのGUIを起動する必要もない。

そのはずなのだが――例えば同じリリース・ビルドでも一時的に署名なしでビルドしたいとか、そういう時にどうすればよいのか、ちょっと分からないのである。「一時的に設定を書き換えろ！」とか「一時的にバッチファイルを差し替えて！」という、少々スパルタな回答は避けたい。このあたり、天下のMicrosoftなので何かしら方法を用意してそうなものだが、未だにMSDN（というかMicrosoft謹製のドキュメント）とは相性の悪いままの私は、手がかりすら見つけられていない。なので、わざわざMakefileを書いて、NMAKE実行時に特定のマクロ変数に値をセットすることで署名あり／なしを切り替えられるようにしている。

macOSアプリも、事情は同じだ。というかmacOSアプリのインストーラ作成については、コマンド直叩きで作成する方法しか情報が引っかからないのだが*2……ディスクイメージ（*.dmg）の作成や、ファイルの圧縮（bzip2）まで自動化している。

付け加えると、関連するコンポーネント全てにVisual StudioやXcodeのプロジェクト・ファイルが存在するとは限らない場合に、ある種のグルー言語としてNMAKEやGNU Makeを用いることもある。例えばGUIツールキットとしてQtを用いる場合、devenv/xcodebuild以外に「qmake、make/jom、windeployqt/macdeployqt」をMakefileから叩いたりする。

こういったmakeの使い方は、makeの特徴の一つである「更新されたファイルのみ処理する」という機能がうまく働かないことがあるという欠点がある*3。しかし一方で、「コマンドが失敗したら中断する」や「特定のターゲットのみを指定できる」という特徴は健在だ。デプロイの工程を自動化する時、途中でエラーが発生したら中断してほしいし、また後付けで「『○○のビルドだけ実行する』という機能を追加してくれないか？」という要望が出たときに、手軽に対応できるようにしたい。そんな時、makeは依然として役に立つ。

正直なところmakeは（それも、それぞれ独自に機能拡張されたNMAKE、NetBSD make、GNU Makeは）有用だとはいえバッドノウハウ度の高めなツールだ。しかし、なかなか代替の良いツール、それもデフォルトで開発環境に用意されている可能性が高く、かつ比較的規模の小さなプロジェクトにて手軽に使えるツールが見つからない。そのため、私は未だにmakeを重宝している*4。

ちなみに、こんなことを書いている私だが、実はmakeは21世紀になってから覚えた。だって、プログラミング自体21世紀になってから始めたんだもん、仕方ないじゃない。

*1:あと今研究されてる自動運転技術は、なんというか、ナンカコレジャナイ感がある。なんでだろう。インタフェースがメカメカしくないからか？

*2:Mac App Storeを使えってことだろうか？

*3:なぜなら、devenvやxcodebuildを実行しないことには、アプリの再ビルドが必要か否か分からないから。ビルド対象のソースファイルなどの依存関係を知りうるのはdevenvやxcodebuildであり、makeは知ることができない。なので、makeはファイル更新日時から「devenvやxcodebuildを実行すべきか否か」を判断することができない。

*4:しかしさすがにNMAKEやNetBSD makeは避けたい。せめてGNU Makeを使わせてほしい。

『プログラミング言語C』とは何であったか？

言語ではなく本の話である。ついでに言えば第2版の方。

最近、新人向けのC言語の本として『プログラミング言語C 第2版』を推そうとする声にストップをかけたのだが、その辺を含めて、この本についての2020年時点の個人的所感を書き残しておこうと思う。

プログラミング言語C 第2版 ANSI規格準拠

本書を無理やり一文で表現すると、かつては「コンピュータ科学の基礎を学んだプログラミング経験のあるUnix-like環境ユーザ向けの『C89/C90によるプログラミング』の入門書」だった。

時代背景を考えると、想定読者は「コンピュータにどっぷり肩まで浸った、FortranやPascalなどで本格的なソフトウェアを書いた経験のある人」あたりだったのではないかと思う。

ややこしいことに、本書はCプログラミングの入門書であると同時に、Cプログラミングの奥義書でもある。今となっては入門書としての側面は古びているのだが、奥義書としては十二分に通用する。

だから本書を最も評価するのは、Cプログラミングの酸いも甘いもかみ分けたベテラン勢であり――彼らは本書のダメな部分を排除した上で、残りの部分を是としている。守破離で言うならば、本書にたいして破や離のスタンスで接するようにならないと適切に扱うことができない、という難しさがあるように思う。

K&R 2nd. はコンピュータ科学の基礎を学んだプログラミング経験者向け

本書はプログラミング未経験者向けではない。他の言語でそこそこ本格的にコードを書いた経験のある人向けである。また、単なるプログラミング経験だけでなく、コンピュータ科学の基礎部分である離散数学・アルゴリズムとデータ構造・コンピュータシステムあたりの知識も暗に要求される。

少なくとも第1章「やさしい入門」について、第0章「はじめに」P.4に次のように書かれている。

ここでは，読者はプログラミングの基本的な要素に関する実際的な知識をもっているものと想定している。コンピュータ，コンパイル過程，n = n + 1といった式の意味などについては説明しない。

第2章から第6章は言語機能の各論であるが、それらに関してP.5に以下のように書かれている。

第2章から第6章では，Cのいろいろな側面を第1章よりもさらに詳しく，もっときちんと論じている。ただそうはいっても断片的なプログラムというよりは，完全なプログラムの実例に重きを置いている。

実際に第2章から第6章の内容は、C言語の言語仕様について事細かに解説している、とは言い難い。コードを書くのに必要な程度には細かく書かれているものの、同時にそこそこ本格的なサンプルコードも出現する。読者は本文の内容と同時にサンプルコードも読み、言語仕様の理解と並行して「実際にコードを書く際に、その言語機能をどう扱うか」という点を学ぶことになる。

「そこそこ本格的なサンプルコード」と書いたように、hello, worldの次のサンプルが「華氏・摂氏の温度対応表を出力する」であるし、第2章「データ型・演算子・式」では関数の解説もまだなのにatoi / rand / srand / strcat / strlenのサンプル実装例が出てきたりする。

一般的な入門書のサンプルコードが「紹介した言語機能の動作を紹介する」という点に注力した内容であるのにたいして、本書のサンプルコードは「現実のプログラミングにおいて、『紹介した言語機能』はどのように使われるか」という点を示したものだ。

このような構成は、他言語でのプログラミング経験がそれなりにある人がC言語を学ぶ際には、丁度よい塩梅だ。C言語に限らず、一般的な「○○言語入門」的な本は想定読者にプログラミング初心者を含むことが多く、プログラミング経験者からすると冗長で読み進めにくい内容となっている。本書にはその冗長な部分が排されている。だから「簡潔で明瞭な内容」と言われる。

留意すべき点として、サンプルコードの「完全なプログラムの実例に重きを置い」た内容には、コンピュータ科学ネタが多く含まれる。例えばシェルソートとクイックソート、二分探索、逆ポーランド電卓、二次元座標、二分木などだ。これらのネタについて、本書では事細かな解説はなされていない。なので読者には予備知識が求められる。

だから本書は、どちらかと言えば他人のコードを読み慣れている玄人向けであるし、コンピュータ科学の基礎として学ぶような内容に慣れ親しんでいる必要もある。裏返すと、本書はプログラミング未経験者に読ませるには早すぎる。

K&R 2nd. は少しだけUnix-like環境ユーザ向け

本書の別の特徴として、多少なりともUnix-like環境の経験があると読み進めやすい部分がある。

そもそも最後の章である第8章が「UNIXシステム・インタフェース」なのだが……それを除いたとしても、以下のような指摘ができる。

• P.7やP86のコンパイル実行例でcc(1)を使用している。
• 第7章「入出力」にてパイプとリダイレクトに触れている。
• cat(1)、echo(1)、wc(1)を題材としたサンプルコードが出現する。

これらの要素についても、やはり本書内では事細かな説明は無い。事前にUnix-likeなユーザランド（シェルによるCLI環境）に慣れ親しみ、予備知識を蓄えておくと安全だろう。

K&R 2nd. は「C言語」ではなく「Cプログラミング」の入門書

先にも書いたが、本書の内容はC言語の言語仕様について事細かに解説したものではない。プログラミングに必要な程度には細かく解説されているものの、主眼は「その言語機能を、現実のプログラミングにおいてどう用いるか」という点に置かれている。

つまり「C言語」の入門書というよりは、「Cプログラミング」の入門書という側面が大きいと考えた方がよい。

プログラミング経験者を想定読者とした上で、読者が短期間でC言語を使えるようになること、それもうまく扱えるようになること（UNIX環境で培われた「効率的かつ慣用的」なコーディングができるようになること）を目指した本だといえる。

この辺は、第1章「やさしい入門」の冒頭P.6に書かれている以下の一文が物語っている。

読者には，できるだけ早く役に立つプログラムが書けるようになってもらいたい。それには，変数と定数，算術，制御の流れ，関数，基本的な入出力といった基本事項に注意を集中する必要がある。

比較的最近の本で例えるなら『プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)』のノリに近い。こちらもプログラミング未経験者向けではないし、サンプルコードも実用寄りの題材を元ネタとした内容だ（少なくとも「機能説明のためのサンプルコード」ではない）。著者の片一方が同一人物だから、似たようなノリなのだろうか？

K&R 2nd. を読むうえで注意すべき点

本書を読むうえで注意すべきなのは、「早合点せずに章や節の最後まで読み進める」ということを心掛けないと誤読してしまう、という点だ。正確を期すためにアレコレ書いているためか、本文の最後に書かれた補足で「ちゃぶ台返しかよ！」という感想を抱くことが時々ある。

例えば1.10「外部変数と通用範囲」では、外部変数についてP.39に次のような記述がある。

これらの変数は，それを使用する関数の中でも宣言しなければならない。これは，はっきりexternと宣言するか，あるいは前後関係から暗黙のうちに宣言すればよい。

その上で、例えば外部変数char line[MAXLINE]について、各関数の中でextern char line[];と宣言したサンプルコードを掲載している。

/* copy:  特別版 */
void copy(void)
{
    int i;
    extern char line[], longest[];

    i = 0;
    while ((longest[i] = line[i]) != '\0')
        ++i;
}

ここまでの内容だと、あたかもTclでビルトインコマンドglobalを使うのと同じように、外部変数使う際には関数内で宣言しなくてはならないかのように見える。

しかし、ここまでやっておいて、P.40で次のようにちゃぶ台返ししている。

ある状況の下ではextern宣言は省略可能である。すなわち，外部変数の定義が，特定の関数で使われる以前にそのソース・ファイルの中でなされていれば，関数内でのextern宣言は不要となる。つまりmain, getline, copyにおけるextern宣言は余分である。実際，普通のやり方は，ソース・ファイルの最初ですべての外部変数を定義してしまい、extern宣言は全て省くという形である。

まあ、確かに書かれた内容の通りなのだが、正直なところ「なんで『例外則→通常例』の順番で説明してるんだ！　紛らわしいぞ。というか『extern宣言は余分である』というのなら、なんでextern宣言付きのコードを載せたのよ」というのが個人的な感想である。

そしてextern宣言が省かれたサンプルコードが掲載されておらず、上記の文章のみだという点に、「これ、誤読して混乱する人が出そう」と一抹の不安を覚えてしまうのである。

経年劣化した部分

本書は原書が1988年（日本語版が1989年）に出てから30年以上経過しており、メンテナンスされなくなって久しいため、経年劣化を含めて何点か問題が表面化している。

1点目は、所々に訳が良くない部分があることだ。明らかに誤訳……という部分は無いものの、分かりにくい表現の部分があって、理解の妨げにはならないけど理解に時間がかかってしまう。第2版の日本語版は1994年ごろに訳書訂正版が出ていて、現在流通している版はその流れを汲むものだと思われるのだが、それでも翻訳の問題が指摘されている。

個々の翻訳の問題については先人たちが指摘済みなので、ここでは挙げない。それよりも重要なのは、それら指摘済みの問題点が改善されないままであることだ。

一応、翻訳版を擁護しておくと、前項に書いたように元が「早合点せずに章や節の最後まで読み進めないと誤読しかねない」という部分のある代物なので、翻訳時に色々と惑わされた可能性は否定できないのではないかと思う。

2点目は、サンプルコードのスタイルが現代の「行儀のよいC言語のコーディングスタイル」と異なることだ。

例えばmain関数について、戻り値の型を明示しない*1、引数を利用しない場合にvoidを書かない*2、return文を書かないことがある*3、などの問題がある。これらのスタイルは、現代のCプログラミングでは推奨されないだけでなく、コンパイルを行う環境*4によっては警告が出てしまい、初心者を惑わせることになる。

また、防御的プログラミングの観点で忌避されることのあるぶら下がり文（制御構文の内容が単文の場合に、大括弧を付けないスタイル）が採用されている。これなどは、C言語のシンタックスとしては合法だが、Cプログラミングの先達として「初心者にはあまり真似してほしくない」と思うスタイルである（守破離の破や離の段階で触れるべきものであり、少なくとも守の段階では触れるべきではない）。

大概の新人は、教科書のサンプルコードのスタイルを真似るはずだ。そこでいきなり微妙な感じのスタイルを真似されると非常に困るのだ。同じような理由で『Cプログラミング専門課程』も新人に薦められなくて困っている。ある程度分かっているレベルの人なら問題ないのだが、新人に読ませるには躊躇する。ええ本なんやけど、なあ。

3点目は、あくまでもC89/C90の本である、ということだ。さすがに21世紀も5分の1が過ぎようとしている昨今では、特段の事情がない限り新規開発ではC99対応のコンパイラが使える訳で、やはり入門書も最低でもC99の仕様（の中でもC11以降でオプショナルにならなかったもの）には追随してほしい。

ただ、職業プログラマとしてC言語を扱う場合、時に「C89/C90/C95」と「C99」と「C11/C18」の3グループぐらいは区別をつける必要がある。そう考えると、本の構成として例えば「いきなりC99」とするか「『C89/C90』のちC99（もしくはその逆順）」とするのか、判断が難しいと言えるだろう。

なお私は最近その「特段の事情」で面倒な思いをしている。誰だよ、 Microsoft C/C++ Compilerをサポートしようと言い出した奴は*5。

蛇足として、本書の第8章「UNIXシステム・インタフェース」は、例えるなら現代のLinuxユーザが『UNIXプログラミング環境』を読み進めるのと同じ程度には、内容を鵜呑みせずに読解すべき章だろう。

……ここの記述って、多分POSIX1よりも前のものだよね？　POSIX1のリリースは1988年だから、おそらく原書の執筆時点ではPOSIX準拠の環境は存在しなくて、ベル研内のUNIX上でサンプルコードの実装と動作確認を行ったのだと思うけど、どうなのだろう？

色褪せぬ部分：C99もC11も所詮はC言語

色々と経年劣化した部分は見られるものの、それでも本書を評価するベテランは依然としてそれなりにいると思う。

それは本書が「Cプログラミング」の本であり、C99やC11に進化しようともC言語がC言語のままであるため、依然として内容の本質部分の多くが通用するからだろう。

例えばC++でのプログラミングは、STL登場の前と後とで結構変わったし、C++03とC++11の間でも大きな変化が生じたように思う。

一方で、C99やC11での言語仕様や標準ライブラリの変化は比較的「痒い所に手が届く」ものだ。確かに今まで不便だと思っていた部分は改善されたが、しかしCプログラミングの本質部分が大きく変わるような変化ではない。

だから本書は、細かい諸々こそ古びているものの、本質部分は現代でも十分に通用する。

問題は、読者に「古びている細かい諸々」をフィルタリングして読み進める能力が求められることだ。例えるなら『ソフトウェア作法』や『UNIXプログラミング環境』を今から読むようなもので、どちらも良書だけど中身を鵜呑みできない（RatforもFortranも使っていないし、UNIXではなくLinuxユーザである――という読者が大多数のはずだ）。必要に応じて「今、自分が置かれた環境ではどうなるか」という視点で読み替えを行うことになる。だから、新人に薦めたいけど薦められず、問題なく読める読者が中堅やベテランに限られてしまう傾向が生じる。

フィルタリング能力が求められる時点で、本書の読者にはC言語やCプログラミングの知識・経験が必要となるのだ。

まとめ

本書は「コンピュータ科学の基礎を学んだプログラミング経験のあるUnix-like環境ユーザ向けの『C89/C90によるプログラミング』の入門書」である。つまり元より、読者にそれ相応の知識や経験が求められる代物である。

同時に本書は「C言語」ではなく「Cプログラミング」の本である。C99やC11ではCプログラミングの本質が変わるような変化はなかったため、本書の本質部分は現在でも十分に通用する。その一方で、コードの細かい部分では変化が生じている。そのため読者には、過去のコンピュータ系名著を読むような「内容を鵜呑みせず、時代変化に応じて読み替えをおこなう」という技術が要求される。

だから今となっては、本書はCプログラミングの中堅やベテランには薦められるものの、Cプログラミングの未経験者には推薦できない。ましてプログラミング未経験者にはもってのほかである。

*1:暗黙の戻り値の型であるint型を期待している、C95以前の記法。C99ではNGである。

*2:関数の定義において、引数なしの時に f() と書く記法は、ANSI Cよりも前の伝統的な形式であり、C99にて廃止予定機能となった。だから使うべきではない。なお関数の宣言においては、 f() は「ANSI Cのプロトタイプ宣言」ではなく「伝統的な形式の宣言」とみなされ、「引数なし」ではなく「任意個数の引数をとりうる」と解釈される――つまりプロトタイプ宣言による引数の個数／型のチェックが行われないのである。

*3:C95以前でもC99以降でも合法的な記法ではあるが、main関数のみに許された特別扱いでもある。他の関数定義との整合性を考えると、慣れるまでは「戻り値がvoid型以外の関数では、必ずreturn文で『戻り値の型に合致する値』を返す」というスタイルで統一した方がよいだろう。

*4:コンパイラの種類・バージョン・付与するオプションなど。

*5:言い出した奴は自分なので、自業自得である。C99スタイルのインライン関数と可変長配列が未サポートなんだよね。