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

2014/06/14現在のステータス。
id:eel3:20130615:1371228166 から1年経て、こうなっている。

なおCSS、HTML、XMLは除外*1

よく使っている

AWK (Gawk)
単純なテキストレコードの処理にはAWKで十分。最近では、自作ツールをAWKGawk単体で実装することは皆無になったものの、シェルスクリプトMakefileの中にコードを埋め込んで他のコマンドと組み合わせて使う機会は依然として多い。シェル上でワンライナーする時にも重宝している。これはこれで十分AWKらしい使い方だよね?
C++
時々お仕事で使う。最近はバイナリデータを扱うツールを自作する時にbetter Cとして使うこともある。なぜかバイナリデータの解析をC言語C++でしか書けない体質なのだが、STLを含むC++の標準ライブラリはC言語の標準ライブラリと比べれば涙が出るほど充実しているわけで、それならC++を選ぶしかない。低水準の処理を行いつつ便利な機能で実装時間を短縮できる点は便利。だけど機能多すぎ/複雑すぎな所は何とかならないものか。強力な反面人を選ぶ言語だ。
C言語
お仕事での主力言語。シンプルかつ低水準の世界が垣間見れる所が大好き。とはいえ最近の他の言語と比較すると、シンプルすぎて安全機構が欠けていたり標準の便利機能が少なかったりするので、入門用の言語としては薦められないと思う。にもかかわらずプログラミング未経験者向けのC言語の本は毎年出版されている――謎だ。
DOSバッチファイル
プログラミング言語に含まれるかどうか不明だが、含めてしまう。ちょっとした自動化や、複数ツールを組み合わせて使う時のラッパーとしてよく使う。コマンドプロンプトはシバン(shebang)に対応していないので、スクリプト言語で書いたツールを起動するラッパーとしても多用している。
make (Makefile)
プログラミング言語に含まれるかどうか不明だが、DSL扱いで……いやGNU Makeは幾分とプログラミング言語的か。GNU Make 4.0はさらにプログラミング言語的だな、特にGNU Guileなところが。先人の遺産をコピペしてガシガシ書き換えるだけだった私も、FizzBuzzを切欠に本格的にGNU Makeを触り始めた。伝統的なmakeやNetBSD Make(pmake)とは随分異なるのね。もう素のmakeでは書けないかもしれない :) まあでも私はGuileのコードが書けないので、その分だけはまだまだ素のmakeやpmakeに近いはず。
Objective-C, Objective-C++
時代の流れに逆らえず、iOS向けの試作とかが発生するようになった――あれ、でも主に弄っているのはMac用アプリのコードだな。最近流行の言語と比べると良くも悪くも80年代的だが、アプリケーションプログラミング用としてはC言語よりマシだし、C++ほど複雑怪奇*2ではない。まあ、アプリケーション開発向けの充実感はApple謹製のフレームワーク・各種ライブラリのパワーに因る部分も大きいわけで、その肝心のフレームワーク回りをMaciOS以外の開発で使用できないのが悲しいところ*3。あとフレームワーク込みでObjective-Cを勉強するにはMacが必要なので、貧乏人にはちょっとつらい。言語的には、Objective-Cのハイブリッドな所は好きだが、Objective-C++はハイブリッドすぎて微妙。せめてbetter CなC++にとどめたObjective-C++にしてほしい。
Ruby
AWKに代わって自作ツール実装での使用頻度が増えている。テキスト処理でも重宝するが、バイナリデータへの変換が絡んでくるとAWKよりもRubyを使った方が効果的だ*4。最近はirbを電卓代わりに使うスタイルが習慣化してきて、ますます手放せない。to_s(16)やto_s(2)で基数変換して表示できる所が大好き。
sed
プログラミング言語に含まれるかどうか不明だが、DSL扱いで*5。テキスト処理用。シェルスクリプトMakefileにて他のコマンドと組み合わせて使う。というか正規表現でのテキスト置換以外の機能を使った記憶が……あったな、dとiとpと=とブレースによるグループ化ぐらいは。私のレベルではsedFizzBuzzは書けない。
シェルスクリプト (/bin/sh)
プログラミング言語に含まれるかどうか不明だが……いや、私的にはシェルスクリプトは立派なプログラミング言語だ。基本的な用途はバッチファイルと同じくちょっとした自動化や複数コマンドを組み合わせて使う時のラッパーだが、実現できる内容は遥かに多い。言語本体(?)がバッチファイルよりも高機能だし、Unixユーザランドはコマンドが充実している。その意味ではMSYSよりもCygwinで環境構築した方がマシだと思う。CygwinやMSYSでは、主要な処理をシェルスクリプトで記述しておき、bashからはシェルスクリプトを利用し、コマンドプロンプトではラッパーのバッチファイル経由でシェルスクリプトを叩く使い方をしている。ただWindows上では処理速度が妙に遅くなる点が不満だ。

あまり使っていない

bash
最近はデフォルトシェルがbashな環境も多いので、自分用のツールぐらいは素の/bin/shではなくbashで書いても大丈夫な気がしてきた。shよりbashの方が遥かに便利だからなあ――PerlRuby等には負けるけど。bashスクリプトを書くときの唯一の欠点は、メジャーバージョンごとの差異や各ディストリでのビルドオプションの違いにより、同じbashという名前でも実は千差万別な所だと思う。PerlRubyのバージョンは気にするけど、これがシェルになると意外とバージョンに無頓着になってしまう。何でだろう?
JScript on WSH
他人が使うテキスト処理ツールの実装に使って以来、時々触ってきた。Windows用の配布可能な小ツールを実装する時の定番言語だった。でもそろそろ潮時だろう。HTAと組み合わせてクライアントサイドJavaScriptなノリで簡易なGUIツールを実装できる点も、PowerShell + WPF + XAMLで代替できそうだ。他のメリットは「JavaScriptECMAScript)でフィルタを書ける」だったが、WSHのなかなか目的にたどり着けないオブジェクト階層にイライラするよりも、Node.jsやPhantomJSを使ったほうが精神衛生的にマシだ。
Perl
時々、やむをえない事情で触ることがある。だが基本的によく分からない。何というか、あの記号の羅列っぽさに中々慣れないというか、自分は余りに自由度が高すぎる言語は苦手だと気づいたというか。
Python
やむをえない事情で触ることに。Open usp Tukubaiが入っている環境でスクリプトを書くとなると、確実に使える処理系がPython 2.xなので。しかし日本語を扱うから、せめてPython 3.xにしてほしかった……。なお、どのスクリプトシェルスクリプトに埋め込んでいるのだけど、こういう使い方だとインデント必須な言語仕様がかえって仇となってしまう。うーん。
Scheme
GaucheWindowsネイティブ環境用バイナリは実験版だが、私が触る分には何の支障もない*6ことに気づいて久しい今日この頃。『Scheme手習い』と『Scheme修行』を購入したので、とりあえずCommon LispではなくGaucheScheme)の勉強をする方向に転換しようか検討*7しているうちに何年たったのやら。Gaucheはフィルタ・ライクな小ツールの実装用としても良い感じだ。しかし最も多い利用方法はREPLを電卓代わりにすること。現状はirbかgoshの2択だ。
SQL
生まれて初めて触れたプログラミング言語その3ぐらいに位置する。MySQLを入れてコンソール用のモニタからSQL手入力で弄って遊んだことがある。組込みの人なのでSQLとは無縁だと思っていたら、なぜかTransact-SQLをちょっとだけ触ることになった。
Visual Basic .NET
いまさらVisual Basic .NETである。しかも2003。古いシステムの改修と移行だから、仕方ない。
Windows PowerShell
v4.0が出て久しいが、自分も周囲もWindows 7ユーザなのでv2.0で頑張っている。スクリプト言語としてのPowerShellは――またMicrosoftもエライ代物を出してきたものだなあ。シェルスクリプトなのにオブジェクト指向.NET Frameworkを触れてダイナミックスコープでスクリプトブロック(という名の無名関数)って、無茶しやがって……完全にプログラマ向けじゃないか。あえていえば、コマンドプロンプト上に構築した既存のツールや作業環境との親和性が微妙にイマイチなのが玉に瑕かも(特に文字コードとか)。それにしても、PowerShell 3.0は無理としても、せめて2.0に対応した言語解説本(日本語のもの)が出てくれないだろうか。『Windows PowerShell イン アクション』は良書だが1.0の頃の本なので。

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

CASL II
生まれて初めて触れたプログラミング言語その1。何だかんだで、後でCプログラマになってからも低水準での思考ツールとして微妙に役に立っている。まあ考える為の言語であって実用言語ではないけど。仮に実用的な処理系*8があったとしても余りに命令がシンプル過ぎて悶絶するなあ、なんてFizzBuzzしてみて思った。
CoffeeScript
仕事で使う予定はない。RubyPythonその他の影響を受けているだけあり、その手のスクリプト言語っぽい感じでコードを書けるので、慣れれば素のJavaScriptで直接コーディングするよりは楽だ。しかし標準ライブラリ回りや処理系絡みの機能やサードパーティのライブラリなど、結局はJavaScriptを知らないとCoffeeScriptでコードを書けないと思う。それに生成されたJavaScriptのコードを見て「うわぁ、これあまり効率的でないなあ」と感じる時もあって、高速化が必要な部分では生成されるコードを気にしながら記述したりCoffeeScriptを諦めてJavaScriptで書くことになるので、やはりJavaScriptを知らないとマズイ。とはいえ便利なのは確かだ。CoffeeScriptのコードは即Node.jsで実行できるので、その辺りから「CoffeeScriptでテキストフィルタ」的な文化が生まれると面白いかも。
Common Lisp
2009年に勉強しようと思い立ったものの、未だに進んでいない。階乗とかハノイの塔とかiotaぐらいは書いたが、目標は「ちょっとしたツールを自作する」だ。まだ道は遠い。最近は時々CLISPを簡易電卓代わりにしている。
Emacs Lisp
.emacsにコピペ」限定で。Common LispSchemeを触った為か、何となく内容を追えるようになってきた気がしていたが、勘違いだった。
Go
よさそうな入門書に出会ったこともあり、ちょっとしたテキストフィルタを書いてみた。そこそこCプログラマ(特にCでフィルタやデーモンの類を書く層)には受けそうな言語だと思う。並列処理周り(goroutines)とかARM対応とかが気になる。「組み込みLinux + Goで書いたデーモン」とかどうだろう? ただメモリを食うらしいという噂が気になる――64bit環境では解消されるらしいが、組み込みでは現時点では逆立ちしたって64bit CPUはありえないからなあ、iPhone以外では。
Java
生まれて初めて触れたプログラミング言語その2。でも、もう忘れてしまった――と思っていたのだが、思い立って昔どこかから拾ってきたツールのコードに手を入れることに。うーん、JDKを入れるのが面倒だ……。
Clojure, Groovy, Scala
JDKがなくてもJava APIを叩くスクリプトを書けるので非常に便利。Groovyで動的型付け言語っぽくいくもよし、ScalaやGroovy (with @CompileStatic or @TypeChecked) で型推論するもよし。言語自体の仕様としては、Javaよりも好みだ。
JavaScript(クライアントサイド)
組み込み系のCプログラマも世間の流行には逆らえず、クライアントサイドJavaScriptのコード書いてみた。機器のWeb管理コンソールとか、Webアプリとの連携とか。言語仕様的に単体テストしやすい所が羨ましい。無名関数もクロージャも大好きだ。
JavaScript(サーバサイド?)
Node.jsやPhantomJSが出てきたこともあり、クライアントサイドJavaScriptとサーバサイドJavaScriptの2大潮流とは別に、JavaScriptでフィルタ等の小ツールを作る文化が広まらないか少しだけ期待中。いやあ、TCP絡みのダミーサーバもどきをサクッと作るのにNode.jsが地味に便利だなあ、と。
Lua
なかなか使う機会が無いと思っていたら、Wiresharkのパケット解析スクリプトを書く機会があった。これはもう「職業柄」の範疇だと思う。ところでCのプログラムに組み込む辺りを本格的に勉強して、仕事が楽になるなら応用してみたいのだが、何か適当なお題はないだろうか?
Prolog
少し前に触っていた言語。『7つの言語、7つの世界』の地図の色分けプログラムには衝撃を受けた。何というか「正しい問い」を見つけられるか否かが肝なのか。この辺は、根底の部分でAlloyに通じる何かがあるように思う。ひとまず、Prologで論理プログラミングと宣言的なスタイルに慣れておけば、形式手法にて「論理で宣言的に」記述する時に戸惑いが減るのではないかと期待。
Tcl/Tk
Tclは書き方を忘れた頃にテキスト処理ツールを書いている気がする。Tclは結構独特な言語だ。構文がシェルスクリプトばりに全てコマンドだったり、値が全て文字列だったり、実はリスト構造だったり、意外とTCPソケット通信が得意だったり……。それでも慣れれば結構使いやすい。意外とプロトタイピングに向いている気がする。8.6以降ではオブジェクト指向プログラミングもOKらしい。しかしこれからメジャーになる可能性は低そうだ。Tkは触ったことがなかったが、少し前に小ツールの実装に使ってみた。小規模なGUIツールをさくっと構築できるところは便利だが、Webアプリ全盛の時代にどれだけ訴求力があるのやら。
VBScript on WSH
JScriptほどではないが「Windows上で他人も使えるツールを書くためのLL」扱いしていた言語。Windows Server管理の関係で触っていた。というかWebで入手可能なWSHのサンプルの大半がVBScriptで書かれていたり、ADSI関連のコレクションをJScriptで舐めれなかったりして、結局は必要に駆られて使用することに。明快に記述できる文法は評価に値するが、スクリプト言語としては少々冗長だ。配列は自動拡張しないし、組み込み関数はプリミティブ気味だし、冗長気味な文法との合わせ技でコードがさらに冗長になっていく……。文法や言語仕様の詳細なドキュメントが見つからないのだが、どこにあるのだろうか?*9
Vim script
少し触ってみた分には、exコマンドの拡張(=コマンドの羅列)とは気づかない程度にはプログラミング言語らしいと思う。とはいえ妙なところで嵌ったり微妙に一貫性のない部分があったりするので、その辺りで好き嫌いが別れる気がする。
XSLT
プログラミング言語に含まれるかどうか不明だが、DSL扱いで。昔、力任せに書いたレガシーコード(XMLからXHTMLに変換)を長らく使用していたが、ついに破棄することに。餅は餅屋というか、定型的なXMLの変換はXSLTで記述するのが一番楽だと思う。唯一気に入らないのは、xsl:sortでアルファベットの大文字と小文字を区別してソートすることができないこと。ぐぬぬぬ。

これから(また)使うかもしれない

Alloy
形式手法の中では比較的カジュアルに使えそうなので期待中。入門書も処理系も入手した。私の場合、先に何か論理型の言語をかじった方がよいのかも。
C#
勉強を兼ねてC# 2.0を少し触ってみた……のだが、気づいたらVisual Studio 2010をインストールしていた。色々と変わっているのでC# 4.0で勉強し直すべきだろう。匿名メソッド等を使うスタイルでコードを書くのは問題ないだろうが、Javaのようなオブジェクト指向プログラミングなスタイルでコードが書けない。私の頭の中には「オブジェクト=何らかの内部状態を抱え込んでいる」というイメージがあって、サンプルソース程度の短いコードにて自前のクラスを定義してインスタンスを生成する意義を見出しにくい*10。クラスが必須ではないC言語C++に慣れてしまった弊害かもしれない。
Coq
ソフトウェアの基礎が気になるので、処理系だけ入手。
D言語、Rust
仕事柄「C/C++の次のシステムプログラミング言語」はそれなりに興味の対象で、Go言語ほどではないがD言語も気になる存在だ。Rustは……ひとまず保留で。ちなみに、これら3言語と同列にObjective-Cが挙げられることもあるようだが、個人的見解としては、システムプログラミング言語としてのObjective-Cには全く期待していない。あれは、Appleというしがらみからは逃れられないでしょうよ。
F#
OCamlは「Windows上で日本語を扱う」という視点では処理系がちょっと微妙なので、いっそのことF#に乗り換えようかと……。『実践F#』が積読状態になっている。
flex
プログラミング言語に含まれるかどうか不明だが、DSL扱いで。字句解析の勉強の一環で触ったが、肝心の字句解析の勉強が頓挫してそのまま。一応、今後も触る予定ではある。予定は未定。
Forth
pForthをMinGWでビルドしたので処理系は手元にある。スタック指向の言語はいつか勉強したい。
Io
プロトタイプベースである点を除けば、何となくSmalltalk的であるような――公式ドキュメントらしきIo Programming Guideでも影響を受けた言語として真っ先にSmalltalkが挙げられているから、あながち思い違いでもないだろう。
LOGO
そういえばLOGOを触ったことがない。とりあえずUCBLogo(Berkeley Logo)だろうか? Windows上でUCBLogoばりにGUI無しで動作する処理系はないだろうか?
Object REXX
思うところがあって処理系とIBM謹製のドキュメントを入手したものの、そこから先の進展は無いまま。ReginaでClassic REXXっぽい感じで触っているからなあ。
Objective Caml
Common Lispを勉強するはずが、いつの間にか触っていた言語。一応、階乗ぐらいは書いた。時間が取れたらもうちょっとしっかりと勉強したいが、面倒なのでF#に移行しようか検討中。
Oz
ふと思い立ってUbuntuにMozartを入れた。『Scheme手習い』の次はCTMCP片手にOzで勉強かなあ。道は遠いな……。
PostScript
これかForthか、どちらに手を出すべきか? 悩ましい。
Processing
入門書も処理系も入手して、あとは弄る時間をつくるだけ。
Smalltalk (Squeak, Pharo)
Smalltalkは有名な古典的プログラミング言語だというのに、触ったことがない。ということでSqueakとPharoの処理系のみ準備完了。うーん、「環境」付きなのが気になる――言語を弄くる基準が「コンソール上でテキストフィルタ」という変な人種な私だからなあ。
Smalltalk (GNU Smalltalk)
個人の思想信条による理由よりSqueakとPharoにわだかまりを感じてしまう変人なので、コンソールでテキスト処理もOKなGNU Smalltalkも用意してみた。これで言語としてのSmalltalkの勉強に集中できる……か?
Swift
Appleの新言語については未だ未知の代物なのだが、その割には見覚えのあるシンタックスのような……。Objective-Cを駆逐して、D言語・Go言語・Rustと並ぶ4大次世代システムプログラミング言語となるか、はたまたMac/iOSアプリ専用(システムプログラミングなんて関係ないね!)となるか……まあ、後者だろうなあ。Objective-Cと併存可能ということは、処理系はLLVMのフロントエンドとして実装しているのだろうか?

今は全く使っていない

Active Basic
VBScripを触りだした影響で、時々思い出しては弄くっていた。ほんの少しだけ触って放置して、すっかり忘れてからまた触る――これを繰り返していた気がする。なので毎度初めて触るのと同じ状態だった。String型をバシバシ使用 :)
bc
その昔、Windows標準の電卓アプリの代わりに使おうとして色々あって挫折した。今はirbclisp/goshで計算しているからなあ。
COBOL
FizzBuzzする為だけにOpenCOBOL 1.0をWindows上に用意して触ってみた。何というかCOBOLの名前と生まれた時代が示すように基幹業務(というかお金や帳簿が絡んでくるところ)向けの言語だよなあ、といった感じ。COBOL 2002のフリーフォーマットを採用するだけでも使い勝手が変わる気がしたが、世の中にはまだ広まらないのだろうか。
Fortran
Fortran 90やFortran 95あたりは結構近代的な言語だと思う。用途次第ではC言語よりもFortranの方が遥かにマシな選択だろう。配列がらみの処理はFortranの方が得意だし、言語機能としてのモジュール化の方法はC言語には存在しない。可変長な文字列の扱いに微妙な制限がある点はマイナスな気もするが、まあ基本的に数値計算プログラム用の言語だからなあ。
GDB (GNU Debugger)
……いやGDBはデバッガとして使っているが、GDBスクリプトを書く機会はない。勉強不足なだけかもしれない。
HSP (Hot Soup Processor)
FizzBuzzで楽しんでみたが、何というか他言語経験者には受けが悪そうな命令体系だと思う。もっとも初心者がプログラミングという行為に深入りせずにWindows用のGUIな何かを作る分には、あの命令体系でも十分な気がしないでもない。ところで元々は「HSPで職業プログラマ的な良いコードを書くと、どんな感じになるか?」というネタを思いついて処理系を用意したのだけど、そちらは全く進展がないまま。
m4
その昔テキスト処理用に触ろうとして、Windows用のどの処理系も日本語の置換に何かしらの問題を抱えていたので泣く泣く諦めた。思うところがあって改めて少し触ってみたが――なるほど、確かに中毒性のある言語*11だ。
REXX
Open Object REXXの処理系を入手したのに、何故かReginaを入れてClassic REXXっぽい方向に走っていた。何というか、COMコンポーネント.NET Frameworkと無関係でいられるのなら、バッチファイルの代替としてはREXXあたりが程よい塩梅だと感じる。しかし最近流行の言語とは随分と勝手が違うし、日本語の情報も少ない。メインフレーム以外の世界で流行る可能性は少ないだろう。
T4 Text Template
「へえ、こんなものがVisual Studioに入っていたのか。機能多すぎで色々と便利なツールを見逃しているんだな、やっぱり」と思いつつ触ってみた。テンプレート変換の用途ではピカ一だと思う。ただ処理系を手に入れる方法が「Visual Studioをインストールする」or「MonoDevelopをインストールする」なので、何となく「単体で手軽に使えるツール」ではないというイメージが……。まあC#VBで処理を記述するので、それらの処理系が必要だという面での制約なのだろう。
秀丸マクロ
7年ほど秀丸エディタを使っていたが、マクロを書く機会はなかった。一念発起してFizzBuzzしてみて感じたのは、最近の便利な言語に慣れた身としては色々とモヤモヤ感がある言語仕様だということ。とはいえちょっとした拡張ツール的なものを手軽に作れそうではあった。

*1:というか人工言語ではあるけど「プログラミング言語」という括りからは外れると思う。

*2:少なくともC++は私の手には余る。

*3:GNUStepの互換性は高いけど高くないというか、マンパワーその他の要因で実装が追いついていないというか。

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

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

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

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

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

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

*10:staticを付けてクラス変数/定数/メソッドにすればよいかもしれないが、それでは無茶苦茶ダメコードだよなあ。

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