新・日々録 by TRASH BOX@Eel このページをアンテナに追加 RSSフィード

2018-10-06

ジュニアは採用できてもノービスは採用できない。ベテランになれないジュニアは淘汰される。

ジュニアを採用しない連中はシニアに値しない - portal shit!」を受けて。

そもそも「ジュニア」がどの程度の人を指し示すか、という話はあるが、アメリカの話っぽいので、おそらく最低でもCSコンピュータサイエンス)の学士は持っているだろうし、修士や博士を持っている人もそれなりにいるだろう。

で、「履歴書の順序づけ - The Joel on Software Translation Project」からエスパーすると、アメリカのテック企業はCS学位そのものの有無に拘っているのではなくて、「学位を持っている=CS知識を持っている」という判断で履歴書をふるい分けた上で、次の採用ステップ(電話面接など)に進めているのだと思う。日本企業でも、例えば電子機器メーカーの技術者採用でその手の学部卒を採用しているものだが、それと似たようなものだろうか? ただアメリカのテック企業や日本の中小ベンチャー企業の場合、ソフトウェア開発の経験者(それこそ創業者)が履歴書のふるい分けに関わっているなら、CS学位が無くても特筆すべき事項(例えば有名なOSSのメンテナである等)が書かれていたら履歴書のふるい分けで落とされることは無い――という印象がある(実際のところは不明だが)。

ついでに、「どうしてプログラマに・・・プログラムが書けないのか?原文)」を読んでアメリカのテック企業でのソフトウェア開発者採用事情を推測するに、流石にプログラムを書けない人はアウトだと思われる。

つまり「ジュニア=CS知識を持っていて、簡単なコードぐらいは書ける人」である。

「ジュニアを採用しない連中はシニアに値しない」というのは、裏返せばソフトウェア開発者を採用する際の足切り基準がジュニアであると言っているに等しい。

そして、空気を読んで書かれていない行間を推測するなら、ジュニアに満たないノービス*1は考慮に値しない、ということである。CS学位を持っていないとか、学位を持っていてもFizzBuzzのような簡単なコードすら書けない連中は、そもそもスタートラインに着くことを拒否される可能性が高い(ただし先に挙げた「例えば有名なOSSのメンテナである等」の天才枠は別で、CS学位が無くても拒否されないだろう)。

あとアメリカの企業の場合、日本の企業よりも「職務不適格による解雇」は行われやすいだろう。

だから、スタートラインに着くことができたジュニアも、ベテランやシニアにステップアップできなければ、少なくとも職業プログラマとしては淘汰されるだろう(もちろん、キャリア開発を経て別分野に転身するなら話は別だが)。

一方で、元記事にもあるように、企業側はジュニアを受け入れてキャリア開発を支援する体制を整える方が健全だろう。誰だって最初は(職業プログラマとしては)素人なのだ。

ところで、ジャパニーズ・トラディショナル新卒一括採用では、企業によっては「計算機科学とは無縁で、プログラムを書いたこともない人」みたいなノービスがソフトウェア開発者として採用されることがある。採用時に所属学部などでフィルタしている場合も、採用の過程でプログラムを書かせるところは稀だろう。

つまり日本企業では、ソフトウェア開発者としてジュニアに満たないノービスが採用される可能性が(少なくともアメリカのテック企業よりも)高い傾向にある。

あと、「職務不適格による解雇」に値する水準が高く設定されている(でないと解雇の妥当性をめぐる訴訟リスクを抱える)点もアメリカとは異なる。

そういった日本独自の事情を勘案した上で、幾分か割り引いて件の記事を読むべきだろう。

個人的には、ジュニアを採用した場合でも彼/彼女がベテランに育つか否か博打な面があるのに、ジュニアよりも教育コストがかかる――そして心が折れて数年で退職してしまい、それまでかけたコストが水泡に帰する可能性がある――ノービスを採用するのはリスクが大きいと思う。

せめて情報系の学部卒や専門卒に絞り込むとか、もしくは「職業訓練で半年座学と実習を受けながら基本情報技術者を取りました」ぐらいに気合いの入った退路の無い人でないと……教育するにしても、ジュニアとノービスではスタート位置が大きく異なるからなあ。

*1:フィギュアスケートの競技会の年齢別クラスはシニア、ジュニア、ノービスらしいので、ジュニアよりの下のクラスを意味する言葉としてノービスを使っている。

2018-09-22

umask(1)は引き算しない、多分。

umask(1)の仕様を調べようとしたのである。

で、ググって見つかった「デフォルトのファイルアクセス権 (umask) (Solaris のシステム管理 (基本編)) 」を見てちょっと驚いた。

設定する umask の値は、与えたいアクセス権の値を 666 (ファイルの場合) または 777 (ディレクトリの場合) から引きます。引いた残りが umask に使用する値です。たとえば、ファイルのデフォルトモードを 644 (rw-r--r--) に変更したいとします。このとき 666 と 644 の差 022 が umask コマンドの引数として使用する値です。

デフォルトのファイルアクセス権 (umask) (Solaris のシステム管理 (基本編))

「引きます」とか「引いた残りが」とか、引き算をしているかのような記述である。

職業病だと思うのだが、私は `mask' という単語より、ビット演算によるマスクを行っているものと予想していた。しかしこの文書のニュアンスでは、ビットマスクではなく引き算を行っているように読み取れる。

日本語に翻訳する際に微妙な訳になったのかと思ったが、Oracleの別の文書である「umask(1) (man pages section 1: User Commands) 」の記述はこんな感じだった。

The value of each specified digit is subtracted from the corresponding ``digit'' specified by the system for the creation of a file (see creat(2)). For example, umask 022 removes write permission for group and other (files normally created with mode 777 become mode 755; files created with mode 666 become mode 644).

umask(1) (man pages section 1: User Commands)

`subtracted' という単語より、私の拙い英語読解力では「引き算している」という感じに読み取れる。

しかし「Umask - ArchWiki」には別の記述がされていた。

新しく作成されたファイルに設定されるパーミッションビットの値は論理非含意 (付加) を使って計算され、論理記号で表現することができます:

R: (D & (~M))

つまり、最終的なパーミッション R はデフォルトパーミッション D の論理積とファイル作成時のモードマスク M の論理否定が合わさった結果になります。

Umask - ArchWiki

ArchLinuxのドキュメントでは、引き算ではなくビットマスクしているものと読み取れる。

どちらが正しいのだろうか? 

POSIXのumask(1)の説明には以下のように「logical complement」とあるので、ビットマスクしているっぽいように思うのだが……。

For a symbolic_mode value, the new value of the file mode creation mask shall be the logical complement of the file permission bits portion of the file mode specified by the symbolic_mode string.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/umask.html

試しに、挙動を検証する方法を考えてみた。

まず、引き算とビットマスクとで計算結果が異なるケースは存在するだろうか? マスクが0022の場合、引き算とビットマスクとで計算結果は同じだ。しかしマスクが0033の場合、ファイルの場合の既定値(0666)との組み合わせにおいて、計算結果が異なるはずだ。

以下のプログラムC言語)で確認したところ:

#include <stdio.h>
#include <stdlib.h>

static void pmask(const int bmsk, const int umsk)
{
    (void) printf("%04o -  %04o == %04o\n", bmsk, umsk, bmsk -  umsk);
    (void) printf("%04o & ~%04o == %04o\n", bmsk, umsk, bmsk & ~umsk);
}

int main(void)
{
    pmask(0777, 0022);
    pmask(0666, 0022);

    pmask(0777, 0033);
    pmask(0666, 0033);

    return EXIT_SUCCESS;
}

実行結果はこんな感じだった。

$ ./a.out
0777 -  0022 == 0755
0777 & ~0022 == 0755
0666 -  0022 == 0644
0666 & ~0022 == 0644
0777 -  0033 == 0744
0777 & ~0033 == 0744
0666 -  0033 == 0633
0666 & ~0033 == 0644
$ _

0666と0033の組み合わせのみ、引き算では0633が、ビットマスクでは0644が得られる。しかし他のパターンでは引き算とビットマスクとで得られる値は同じだ。

手元のUbuntu 16.04で試してみたところ、「umask 0033」の時に生成されたファイルのパーミッションは「rw-r--r--」、すなわち0644だった、同じLinuxであるArchLinuxと同様に、umask(1)では引き算ではなくビットマスクで計算されているようだ。

ということで、少なくともUbuntuとArchLinuxでは、umask(1)の結果は引き算ではなくビットマスクだ。

問題は、事の発端のドキュメントのOSであるSolarisを含む「Linux以外のUnix系OS」でのumask(1)の挙動を調べていないことと、元文書の「subtract」という単語が引き算以外のニュアンスを持っているか否かが分からないこと、以上の2点だ。実際、どうなのだろう?

2018-08-28

Raspberry Pi用にQtをクロスコンパイルする――ただしQtはX11上で動かしたい

Raspberry Pi用にQtをクロスコンパイルする方法を探していたのだが、どの情報も非X11のコンソール環境にてEGLFS経由で直接OpenGL ESで画面描画する構成のQtバイナリを作るものばかりだった。

しかし私は、諸事情よりX11デスクトップ上でアプリを実行できる構成のQtバイナリが欲しいのである。

まあ、Linux上で「Qt for Linux/X11」を自前ビルドするのと同じ方法をRaspbian上で実行すれば、確かにブツは手に入る。だけどPC上でビルドする方が速いので、できればクロスコンパイルしたい。

Raspberry Pi向けのQtクロスコンパイル(EGLFSを使う版)

この文書を書いている時点で、最も有用文書Qt WikiRaspberryPi2EGLFSだ。このページの方法でEGLFSを使う構成でQtをクロスコンパイルできる。

以下、上記ドキュメントの補足:

X11用にクロスコンパイルするには?

色々調べた結果、先に挙げたドキュメントの「./configure」のオプションを以下のように調整することで、RaspbianのX11上でアプリを実行する構成でクロスコンパイルできることが分かった。

  1. オプション-opengl es2」を「-opengl desktop」に変更する。
  2. オプション-no-eglfs -qpa xcb」を追加する。
  3. Qt 5.11系をクロスコンパイルする場合はオプション-no-gbm」を追加する。

他の作業については、特に変更点はない模様。

2018-07-29

クライアントWindows上で仮想化ソフトウェアでゲストOSを飼うためのハードウェア構成

ここ4年ほどCore i5-3340Mを搭載したノートPC上でVirtualBoxを使ってきたので、その辺の知見を元に、VirtualBoxなどのx86仮想化ソフトウェアを使ってゲストOSを飼う際に必要な「ホスト環境のハードウェア構成」についてまとめておく。

WindowsをホストOSとして、ホストOS上でWebブラウザや開発環境を動かしつつ、ゲストOSとしてWindowsUbuntuGUICLIの双方)辺りを動かす――という非Web系のソフトウェア屋さんでありそうな環境を想定している。

――Web屋さんとかインフラ屋さん向けの仮想化の話なんて、割と直ぐに見つかるでしょ(無責任)。

仮想化支援機能をサポートするCPU選択する。

Intel VTAMD-Vなどの仮想化支援機能をサポートするCPU選択して、BIOS/UEFI設定で有効化した上で、仮想化ソフトウェア側で支援機能を使用する設定にしないと、ゲストOSの性能は劣化する。

IBMメインフレームとは異なり、x86アーキテクチャは元々仮想化なんて考慮されていなかった訳で……x86上で動作するOSも仮想化を考慮しない作りになっている。だから、単純にソフトウェアだけで仮想化を実現しようとするとオーバーヘッドが大きい。

Intel VTAMD-Vは、このオーバーヘッドを軽減するための後付けの機能だ。

Intel VTについては、VT-xとVT-d双方に確実に対応しているデスクトップ・ノートPC向けCPUは「Broadwell/Skylake以降のインテルCoreプロセッサー・ファミリーに属するCore i7/5/3・PentiumCeleron」だ。それ以前の世代だと、ローエンドではVT-d非対応であったり、ハイエンドCore i7/5でもVT-d対応/非対応のモデルが混在していたりする。

Intel AtomベースのPentiumCeleron*1では、Apollo Lake以降でVT-xとVT-d双方に対応しているようだ。

AMD-Vについては、不勉強なので知らない。

シングルスレッド性能がそこそこ高めのCPU選択する。

ここでのシングルスレッド性能は(ハイパースレッディングのことを無視するなら)「1コア辺りの性能」を意味する。

シングルコアでの演算性能向上の限界により、PC向けCPUの分野でも2006年ごろからマルチコアによる性能向上に舵が切られた訳だが――それでも依然としてシングルスレッド性能も向上している*2

正直なところ、仮想化ソフトウェアは重い。何しろ「独立したハードウェア上で直接実行する」という前提で作られているx86向けのOSを無理やりソフトウェア上で動かしている訳で、Intel VTAMD-Vなどの仮想化支援機能で軽減されるといえども、処理としては重い部類に入る。

ソフトウェアには「シングルスレッド性能が上がると高速化する」ものと「コア数を増やすと高速化する」ものの2系統があるが、経験的に仮想化ソフトウェアでは「1にシングルスレッド性能、2にコア数(ただしデュアルコア以上)」の順に効果があるように思う。

だから、まずはシングルスレッド性能が高めのCPU選択すべきだろう。

経験的に、またベンチマーク性能的に、シングルスレッド性能は「IntelAMD*3」という傾向にある。私ならIntelCPU選択するだろう。仮にAMDCPUから選択するのなら、現時点では最低でもRyzen 5の上位モデル以上を選ぶだろう。

IntelCPUでも、Intel Atomベースのものは例外的にシングルスレッド性能が低いので*4、少なくとも現時点では選択してはならない。

現在使用しているCore i5-3340Mが「ギリギリ実用に耐えうるかな……?」ぐらいの感じなのだが、ベンチマーク的にはKaby Lake世代のデスクトップ向けPentium Gシリーズにて追い抜かれつつある感じだ。他のソフトウェアと同様に、OSバージョンアップと共に肥大化していく傾向にあるので、余裕を見てKaby Lake以降のデスクトップ向けCore i7/5/3ないしKaby Lake Refreshのモバイル向けCore i7/5に絞り込むのが現時点でのベターだろう。

できれば4コア以上のCPU選択する。

ある程度シングルスレッド性能が高い場合、次に効果があるはコア数だ。現在使用しているCore i5-3340Mは「2コア、4スレッド」の構成なのだが、できれば「4コア、4スレッド」、欲を言えば「4コア、8スレッド」以上が望ましいと考えている。

最近のPC向けCPUはほぼ全てマルチコアなので、OSマルチコア環境で性能を発揮するように実装されている。VirtualBoxなどではゲストOSに割り当てるCPUスレッド数を指定できるが、2スレッド以上割り当てることでゲストOSの性能が向上する。

その上で、例えば「4コア、4スレッド」の環境では、ゲストOSに2スレッド(2コア)割り当てたとしても、残り2スレッド(2コア)をホストOSで使用できるので、「ホストOSで作業しながらゲストOSを動かす」という使い方にも耐えられる。

「4コア、8スレッド」の環境なら、「ゲストOSに4スレッド(2コア)、ホストOSに4スレッド(2コア)」とすれば双方ともまずまずの性能となるだろうし、「3つのゲストOSに2スレッド(1コア)ずつ割り当てて、ホストOSに残り2スレッド(1コア)」とすればゲストOSの同時使用にも耐えられる。

IntelCPUで確実に「4コア、4スレッド」以上なのはデスクトップ向けCore i7/5かKaby Lake Refreshのモバイル向けCore i7/5だ。モバイル向けでは長い間、Core i7/5でも「2コア、4スレッド」の構成が大半だったのだが*5、Kaby Lake Refreshでコア数が増えて「4コア、8スレッド」となった。でもゲストOSを飼うなら、できればデスクトップ向けCore i7/5を使いたい。

できればメモリは16GB以上積む。

ここまでCPUに注目してきたが、ゲストOSを飼うならメモリも欲しい。ゲストOSの同時実行数や、ゲストOSと並行してホストOSで行う作業に依存するが、個人的には16GB以上を推奨する。

ホスト環境に積むべきメモリサイズは「ホストOSで使用するメモリ量+(ゲストOSで使用するメモリ量×ゲストOSの同時実行数)」で決まる、と考えればよい。

例えばWindows 10 Home搭載の格安ノートPCの大半では、メモリサイズは4GBだ。この手のPCは「ネットサーフィン等の軽い作業」向けだ。だから、ゲストOSWindows 10で且つ軽い作業しか行わないなら、ゲストOSに割り当てる最小メモリサイズは4GBぐらいだと考えればよいだろう。

ゲストOSと並行してホストOSWindows 10)で行う作業も上記の「軽い作業」ぐらいならば、ホストOS用に確保しておくべき最低限のメモリサイズも4GBとなる。

この時点で、ホストOS・ゲストOS合わせて8GBのメモリを確保すべきだということになる。もちろん「8GB積んでいないと動作しない」という訳ではないのだが、色々と動かし始めた際に動作が遅い等の影響が出る可能性がある。

ソフトウェア開発でありがちな「ホストOS統合開発環境を動かしつつ、テスト環境としてゲストOSを動かす」というケースでは、ホストOS側で快適に作業するには4GBでは足りないし、テストするソフトウェアが重いのならゲストOSにより多くのメモリを割り当てる必要がある。

メモリサイズはOSの種類によって異なる。例えばUbuntuのSystem Requirementsを見ると、最近のUbuntu Desktop Editionのデフォルト環境ではシステムメモリだけで4GBが要求されている反面、Ubuntu ServerをCLIで運用するならシステムメモリは256MBで済む。この数字は追加のアプリケーションデーモンサーバ)を動かさない場合のものなので、実際には上記の値よりも多いメモリを割り当てるべきだろう。

こういったあれこれを考えると、ホストOSWindowsの場合、「メモリは16GB以上」という要求に当てはまることが多くなる。

大容量かつ高速なディスクを積む。性能重視ならSSDを使う。

CPU・メモリに次ぐ最後の要素は「ディスク」である。まず、ゲストOSを飼うならそこそこ容量の大きなディスクは必須だ。

例えばゲストOSWindowsの場合、経験的に、Windows 7以降の64bit OSクリーンインストールしてWindows Updateを当てただけの状態で、可変サイズの仮想ディスクは概ね10〜20GBの大きさとなる。OS以外にアプリケーションインストールすれば、仮想ディスクはより大きくなるし、スナップショット機能を使えばさらにディスクを消費する。

ゲストOSの数が増えれば、その分だけ仮想ディスクの数が増えるので、もっとディスクを消費することになる。

その上で、さらに経験に基づく話になるが、Windows PCではディスクの空き容量が少なくなりすぎると動作が遅くなることが多い。パーティションの切り方、OSのバージョン、常駐しているウイルス対策ソフトの種類その他に左右される話なので、未だに具体的な空き容量の目安は分からないのだが……しかし、空き容量が少なすぎると動作が遅くなることが多い、という傾向が見られる。

だから、ゲストOSの仮想ディスクを抱えつつもある程度の空き容量を確保できるだけのディスクサイズが欲しい。そうなると、用途次第ではあるが、そこそこ容量の大きなディスクが必要となる。

もう1つ重要なのが、ディスクIOの速度。バス速度も含めたIOの話だ。

ゲストOSがディスクを読み書きすると、仮想ディスクの読み書きが発生する。つまり、仮想ディスクを置いている「ホストOSのディスク」へのIOが発生する。ゲストOSが大量にディスクを読み書きすると、ホストOS側で他の作業に影響が出てしまうことがある。

この問題を解決するには、高速なディスクを使用するなどして、ディスクIOを高速化するしかない。

さらに言えば、HDDではなくSSDを採用して、仮想ディスクもSSDに置くようにすれば、より快適になるはずなのだが……1TB以上のSSDはまだまだ高いのである。残念。

まとめ

  • 仮想化支援機能をサポートするCPU選択する。
  • シングルスレッド性能がそこそこ高めのCPU選択する。
  • できれば4コア以上のCPU選択する。
  • できればメモリは16GB以上積む。
    • ホストOSで使用するメモリ量+(ゲストOSで使用するメモリ量×ゲストOSの同時実行数)」
  • 大容量かつ高速なディスクを積む。性能重視ならSSDを使う。
    • 仮想ディスクを置いを置いた状態での、ホストOSのディスク空き容量に注意すること。
    • 性能を求めるなら仮想ディスクを含めてSSDに置くこと。

*1:Pentinu JやCeleron Nなどの、JやNで始まるもの。

*2:もちろん上昇率は以前よりも低めだが、それでもじりじりと上昇している。

*3:ただし同価格帯での比較。

*4ベンチマーク的には、最近の格安ノートPCやWindows Storage Server搭載NASに搭載されることの多いCeleron J1900やCeleron N3160は、Pentium M(2000年代前半のノートPCに搭載されていたCPU)よりもシングルスレッド性能が低い。割と新しいPentium J4205にて、ようやくシングルスレッド性能がCore 2 Duo世代のモバイル向けモデルに追いついてきた感じだ。

*5Core i7のPerformanceモデルなら「4コア、8スレッド」だったが、該当するCPUを載せたノートPCが軒並み高かったり、ゲーミングPCでの採用が多かったり、17インチ大画面で持ち運びに不便だったりと、なかなか良い機種に巡り合えなかった。

2018-06-30

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

2018-06-30現在のステータス。id:eel3:20170708:1499445416 から1年経て、こうなっている。

なおCSSHTMLXMLは除外する。人工言語ではあるけれども「プログラミング言語」という括りからは外れると思う。

よく使っている

AWK (Gawk)
単純なテキストレコードの処理にはAWKで十分。自作ツールAWKGawk単体で実装することは皆無なものの、シェルスクリプトMakefileの中にコードを埋め込んで他のコマンドと組み合わせて使う機会は依然として多い。シェル上でワンライナーでデータ処理するときにも重宝している。これはこれで十分AWKらしい使い方だよね?
C++
ちょくちょくお仕事で使うが、本職のC++使いではない。C++11やC++14は非常に便利で、better Cでも使う価値があると思う今日このごろ。C++の標準ライブラリは、C++03の時代からC言語の標準ライブラリよりはるかに充実していたが、C++11でさらに充実しちゃってどうするのよ?*1 ラムダ式とかautoによる型推論とか使えるようになって大変ですな*2。あとSwift時代のクロスプラットフォームC++ライブラリ作者は、どうあがいてもARCから逃れられないので、C++11以降のスマートポインタは必須だ。正規表現スレッドも標準ライブラリに加わったので、あとはソケット(低水準ネットワークAPI)をサポートしてくれないだろうか。低水準の処理を行いつつも便利な機能で実装時間を短縮できるのは便利。だけど機能多すぎ/複雑すぎなところはなんとかならないものか。強力な反面、使い手を選ぶ言語だ。
C言語
お仕事での主力言語。シンプルかつ低水準の世界が垣間見れるところが割と好き。とはいえ最近の他の言語と比較すると、シンプルすぎて安全機構が欠けていたり標準の便利機能が少なかったりするので、入門用の言語としては薦められない。にもかかわらず、プログラミング未経験者向けのC言語の本は毎年出版されている――謎だ。クロスプラットフォームモジュール屋としては、現実解としてC89を採用しているものの、そろそろC99とかC11とか次世代の言語とか主流になってほしいところ。えっ、C++なら今からでも大丈夫だって? 冗談がきついなあ、10年以上前の秘伝のコンパイラを使ってる現場じゃあC++03だって無理無理。組み込みだとフットプリント諸々の都合でSTLすら辛いこともあるからなあ、Linuxとか普通のOSを載せる場合でも(リアルタイムOSや、そもそもOS無しの場合は……お察しください)。
DOSバッチファイル
プログラミング言語に含まれるかどうか不明だが、含めてしまう。ちょっとした自動化や、複数ツールを組み合わせて使うときのラッパーとしてよく使う。コマンドプロンプトはシバン(shebang)に対応していないので、スクリプト言語で書いたツールを起動するラッパーとしても多用している。
make (Makefile)
プログラミング言語に含まれるかどうか不明だが、DSL扱いで……いやGNU Makeはそこそこプログラミング言語的か。GNU Make 4.0はさらにプログラミング言語的だな、特にGNU Guileなところが。先人の遺産をコピペしてガシガシ書き換えるだけだった私も、FizzBuzzを切欠に本格的にGNU Makeを触り始めた。伝統的なmakeやNetBSD Make(pmake)やNMAKEとは随分異なるのね。もう素のmakeは書けないかもしれない :) まあでも私はGuileのコードが書けないので、その分だけはまだまだ素のmakeやpmakeに近いはず――といいつつも、最近書いたNMAKEも独自拡張アリアリで使ってたな。pmakeも独自拡張アリアリになるから、もはや素のmakeではMakefileを書けない身体なのか。
sed
プログラミング言語に含まれるかどうか不明だが、DSL扱いで*3。テキスト処理用。シェルスクリプトMakefileにて他のコマンドと組み合わせて使う。というか正規表現でのテキスト置換以外の機能を使った記憶が……あったな、dとiとpと=とブレースによるグループ化ぐらいだが。私のレベルではsedでFizzBuzzを書けないので、sedで難しい処理を記述しないようにしている。
Windows PowerShell
v5.1が出て久しいというのに、周囲にWindows 7ユーザが多いのでv2.0で頑張らざるをえない日々が続いていたが――もう面倒なのでv5.1に切り替えた(Windows 10ユーザなので)。スクリプト言語としてのPowerShellは――またMicrosoftもエライ代物を出してきたものだ。シェルスクリプトなのにオブジェクト指向.NET Frameworkを触れてダイナミックスコープでスクリプトブロック(という名の無名関数)って、無茶しやがって……完全にプログラマ向けですな。残念なことに、コマンドプロンプト代替という観点では、外部ツールとの親和性が微妙にイマイチだ(特に文字コードとか)。でもPowerShell内で閉じている分には問題ないので、私の手元では「Windows専用のGUI付き小ツールを作るためのスクリプト言語」か「Excel COMとか叩く用のスクリプト言語」か「Windows Serverの管理スクリプトを書くためのスクリプト言語」扱いしている。ところで、いい加減『Windows PowerShell イン アクション』クラスの最新バージョン対応の言語解説書が出版されてくれないだろうか。
シェルスクリプト (/bin/sh)
プログラミング言語に含まれるかどうか不明だが……いや、私的にはシェルスクリプトは立派なプログラミング言語だ。基本的な用途はバッチファイルと同じくちょっとした自動化や複数コマンドを組み合わせて使うときのラッパーだが、実現できる内容は遥かに多い。言語本体(?)がバッチファイルよりも高機能だし、Unixユーザランドはコマンドが充実している。その意味ではMSYSよりもCygwinで環境構築した方がマシだと思う。CygwinやMSYSでは、主要な処理をシェルスクリプトで記述しておき、bashからはシェルスクリプトを利用し、コマンドプロンプトではラッパーのバッチファイル経由でシェルスクリプトを叩く使い方をしている。ただWindows上では処理速度が妙に遅くなる点が不満だ。

あまり使っていない

flex (lex)
プログラミング言語に含まれるかどうか不明だが、DSL扱いで。字句解析用のツールという印象が強かったのだが、よく考えてみたら、flexってsed(1)のよくある使い方と同様に「正規表現でパターンマッチング --> 何らかのアクション」ということをやるためのツールだった。ただ単に、「何らかのアクション」をC言語で書けることと、flex自体ではパターンマッチングをせずに「パターンマッチングするC言語のコード」を生成することが少々風変わりなだけ。grep(1)やsed(1)その他で小ツールを実装して運用しつつ、性能が求められたらflexで専用ツール化するとか――夢が広がるな、いまさらながら。
Free Pascal
いや、お試しで触っているのだけど、微妙にDelphi/Free Pascal初心者(でも他言語経験者)向けの良い資料が少なくて難儀している。玉石混交なんだよね。いっそのこと『OBJECT PASCAL HANDBOOK―マルチデバイス開発ツールDelphiのためのプログラミング言語完全ガイド』を買ってしまおうかしら。
Io
プロトタイプベースである点を除けば、何となくSmalltalk的であるような――公式ドキュメントらしきIo Programming Guideでも影響を受けた言語として真っ先にSmalltalkが挙げられているから、あながち思い違いでもないだろう。今更ながら『7つの言語 7つの世界』のIoの章を読み終えたので、ちょっとしたコード片を書いているが……Windows版のバイナリが古いためか、リファレンス通りなのに動作しないコードに直面している。
Java
生まれて初めて触れたプログラミング言語その2。でも、もう忘れてしまった――と思っていたのだが、思い立って昔どこかから拾ってきたツールのコードに手を入れたり、急にAndroid用のサンプルアプリを触ることになったり。うーん、JDKインストールしたり更新したりするのが面倒だ……。とりあえず、構文の見た目は保守的なC++に似ているが中身はC++とは似ても似つかない代物だということは分かっている。Javaらしいコードまであと何マイル?
Kotlin
年単位でAndroid界隈をヲチしてなかった身としては急に出てきた感があるKotlinだが、実はそうでもないんだよなあ(後から経緯を見てみると)。ちょっとした実験用に簡単なAndroidアプリJavaで書いたので、試しにKotlinで書き直してみた。――うん、割とええ感じの言語やね。ただSwiftをつまみ食いして半年以上経ってからKotlinをつまみ食いしたので、両者の概念・機能が頭の中でごった煮になってしまった。
Objective-C, Objective-C++
時代はSwiftだと言われているけど、どっこいObjective-CObjective-C++は生きている。というかSwiftのコードにC++で書かれたライブラリを直接組み込むことができない以上、両者を繋げるグルー言語として生き残ることになるよね。最近流行の言語と比べると良くも悪くも80年代的だが、アプリケーションプログラミング用としてはC言語よりマシだし、C++ほど複雑怪奇*4ではない。そしてC言語C++で書かれた既存のライブラリをそのまま使える。Objective-Cハイブリッドな所は好きだが、Objective-C++はハイブリッドすぎて微妙。C++のクラスとObjective-Cのクラスを、C++ラムダ式Objective-Cのブロック構文を同時に使うのは大変だ。便利ではあるんだけどね。
Python
「標準ライブラリWAVファイル操作用モジュールがある」という理由で、小ツール作成用にちょくちょく使うようになった。ただし諸事情により、確実に使える処理系Python 2.xなので、どれもPython 2.xを念頭にコードを書いている。Python 3.xは遠いなあ。Perl 5やRubyと比べると、Pythonではlazyなスタイルが許されず、整然とコードを記述する必要がある。その辺は、Perl 5やRubyとは随分と雰囲気が異なる。Pythonで気になるのは、インデントが必須な言語仕様であるために、シェルスクリプトに埋め込んで使うのが苦痛な点だ。Pythonだけでコードを書く分には気にならないのだけど。
QML
宣伝文句のとおり、QMLはGUIの記述に非常に向いている。それも、単に標準のUI部品(エレメント)を使うだけでなく、少し改造して使うとか、オリジナルのUI部品を作って使うとか、それらを別のアプリケーションに使いまわすとか、そういう時に威力を発揮する。あと、プロパティバインディングやレイアウトのアンカー指定など、画面サイズの変更に追随するUIを作りやすい機能も揃っている。JavaScriptでちょっとした処理も記述できる。とはいえ、やりすぎるとパフォーマンスの罠が……。少なくとも、JavaScriptでゴリゴリコードを書くのはQML的ではない。QMLは宣言的に、シンプルに書くものだ(というか、力技でロジックでゴリ押しすると、色々と罠に嵌る)。
Ruby
自作ツール実装にて、AWK代替言語の最有力候補だった(でも最近はPythonが多いんだな、これが)。テキスト処理でも割と重宝するが、バイナリデータへの変換が絡んでくるとAWKよりもRubyを使った方が効果的だ*5。そろそろirbを電卓代わりに使うスタイルも板に付いてきた気がする。to_s(16)やto_s(2)で基数変換して表示できるところが好き。
Swift
コンパイラによる強力な型推論と型安全性のチェック」がお仕事用のメジャーな言語にまで降りてきたという点で、Swiftは静的型付け言語界のJavaScript*6だと思っている。でもユーザ数的にKotlinが「静的型付け言語界のJavaScript」ポジションを獲得しそうだなあ。割と好感が持てる言語だが、今しばらくは互換性のない言語仕様の変更が発生しそうな雰囲気なので、プロダクトオーナーとしてiOSmacOS向けアプリ開発を専業としている人以外は、Swift選択する際には少し慎重になった方が良いかもしれない。
Visual Basic .NET
いまさらVisual Basic .NETである。しかも2003。古いシステムの改修と移行だから、仕方ない……まあ流石にVisual Studio 2013環境に移行したんだけどね。

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

bash
最近はデフォルトシェルbashな環境も多いので、自分用のツールぐらいは素の/bin/shではなくbashで書いても大丈夫な気がしてきた。shよりbashの方が遥かに便利だからなあ――PerlRuby等には負けるけど。bashスクリプトを書くときの唯一の欠点は、メジャーバージョンごとの差異や各ディストリでのビルドオプションの違いにより、同じbashという名前でも実は千差万別なところだと思う。PerlRubyのバージョンは気にするけど、これがシェルになると意外とバージョンに無頓着になってしまう。なんでだろう?
bison (yacc)
プログラミング言語に含まれるかどうか不明だが、DSL扱いで。やっぱり構文解析系統のコードを自作するのは割に合わない――だなんてうそぶきつつ、LALR法とか全く知らないままに、既存のyaccのコードを切り貼りして遊んでいるところ。まだ簡易電卓レベルだが便利さを体感しつつ、さっそくtypo 1文字で痛い目(shift/reduce)に遭った。とりあえず、flexと組み合わせた上でのエラー処理(エラーメッセージの改善)が課題だ。
C#
かつて、勉強を兼ねてC# 2.0を少し触ろうとするも未完に終わった過去をもつ私。あらためてVisual Studio 2013をインストールして、また少しだけ触ることに。言語仕様的にはC# 5.0の環境だが、使用する機能はC# 4.0相当だろうか。変数型推論ラムダ式LINQデフォルト引数は便利っすね。それと.NET Frameworkの機能数は反則ものだが、所々に微妙に抽象化が行き過ぎたAPIが見られるのは気のせいだろうか? それにしても、クラスが必須ではないC言語C++に慣れてしまった弊害か、アプリケーション・メインエントリすらclass内に定義しなくてはならないC#には、なかなか慣れない。Javaよりはマシなのだが。
CASL II
生まれて初めて触れたプログラミング言語その1。何だかんだで、後でCプログラマになってからも低水準での思考ツールとして微妙に役に立っている。まあ考えるための言語であって実用言語ではないけど。仮に実用的な処理系*7があったとしても余りに命令がシンプル過ぎて悶絶するなあ、なんてFizzBuzzしてみて思った。
Go
寡作ながらもいくつか小ツールを書いてみたが、標準ライブラリが充実しているコンパイラ型言語っていいっすね。C言語に比べればC++の標準ライブラリも充実しているが、どちらかといえばプリミティブな機能が中心だ。PythonRubyばりの標準ライブラリを抱えているGoには及ばない。その辺は、やはりCプログラマ(特にCでフィルタデーモンの類を書く層)には受けそうな言語だと思う。並列処理周り(goroutines)とかARM対応とかが気になる。ソフトリアルタイム限定だが「組み込みLinux + Goで書いたデーモン」とかどうだろう? ただメモリを食うらしいという噂がどうなったか気になる――64bit環境では解消されるという話だったようだが、32bit環境でも解消されるようになったのだろうか? 組み込みでは現時点では逆立ちしたって64bit CPUはありえないからなあ、スマホタブレット以外では。
JavaScriptクライアントサイド)
組み込み系のCプログラマ世間の流行には逆らえず、クライアントサイドJavaScriptのコード書いてみた。機器のWeb管理コンソールとか、Webアプリとの連携とか。言語仕様的に単体テストしやすい(モックへの差し替えが簡単な)ところが羨ましい。無名関数クロージャも好きだ。
JavaScriptサーバサイド?)
Node.jsやPhantomJSが出てきたこともあり、クライアントサイドJavaScriptサーバサイドJavaScriptの2大潮流とは別に、JavaScriptフィルタ等の小ツールを作る文化が広まらないか少しだけ期待中。いやあ、TCP絡みのダミーサーバもどきをサクッと作るのにNode.jsが地味に便利だなあ、と。
Lua
Wiresharkパケット解析スクリプトを書いてから数年。今度はC言語で書かれたUnixデーモンの設定ファイル用に組み込むことに。これはこれで「職業柄」の範疇、なのだろうか? Windowsのことを考えなければ、自前でライブラリビルドしてアプリに組み込むのは結構簡単だった。
Perl 5
時々、やむをえない事情で触ることがある。だが基本的によく分からない。何というか、あの記号の羅列っぽさに中々慣れないというか、自分は余りに自由度が高すぎる言語は苦手だと気づいたというか。(言語仕様に慣れているなら)半ば使い捨てなテキストフィルタとかをさっと書くには、悪くない言語だと思うのだが。
Scheme
GaucheWindowsネイティブ環境用バイナリは実験版だが、私が触る分には何の支障もない*8ことに気づいて久しい今日この頃。『Scheme手習い』と『Scheme修行』を購入したので、とりあえずCommon LispではなくGaucheScheme)の勉強をする方向に転換しようか検討*9しているうちに何年たったのやら。Gaucheフィルタ・ライクな小ツールの実装用としても良い感じだ。しかし最も多い利用方法はREPLを電卓代わりにすることだ*10。うーん、作業環境がMac OS XLinuxに移ったなら、大手を振ってGaucheフィルタを書くのだが。
SQL
生まれて初めて触れたプログラミング言語その3ぐらいに位置する。MySQLを入れてコンソール用のモニタからSQL手入力で弄って遊んだことがある。組み込みの人なのでSQLとは無縁だと思っていたが、まさかTransact-SQLをちょっとだけ触ることになるとは。
Tcl/Tk
Tclは書き方を忘れた頃にテキスト処理ツールを書いている気がする。Tclは結構独特な言語だ。構文がシェルスクリプトばりに全てコマンドだったり、値が全て文字列だったり、実はリスト構造だったり、意外とTCPソケット通信が得意だったり……。それでも慣れれば結構使いやすい。意外とプロトタイピングに向いている気がする。8.6以降ではオブジェクト指向プログラミングもOKだが、それよりも例外処理用のtry末尾呼び出しの最適化用のtailcallの方が興味深い。しかし、これからメジャーになる可能性は低そうだ。Tkは……小規模なGUIツールをさくっと構築できるところは便利だが、Webアプリ全盛の時代にどれだけ訴求力があるのやら。
Vim script
少し触ってみた分には、exコマンドの拡張(=コマンドの羅列)とは気づかない程度にはプログラミング言語らしいと思う。とはいえ妙なところで嵌ったり微妙に一貫性のない部分があったりするので、その辺りで好き嫌いが別れる気がする。
XSLT
縁が切れたと思いきや、仕事でXHTMLから特定要素を抜き出す作業に使うことに。XMLからテキストレコードに変換してしまえば、後はUnix流テキストフィルタの世界が待っている。餅は餅屋というもので、定型的なXMLの変換はXSLTで記述すると楽だ。唯一気に入らないのは、xsl:sortでアルファベットの大文字と小文字を区別してソートすることができないこと。ぐぬぬぬ。

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

Alloy
形式手法の中では比較的カジュアルに使えそうなので期待中。入門書処理系も入手した。私の場合、先に何か論理型の言語をかじった方がよいのかも。
Common Lisp
2009年に勉強しようと思い立ったものの、未だに進んでいない。階乗とかハノイの塔とかiotaぐらいは書いたが、目標は「ちょっとしたツールを自作する」だ。まだ道は遠い。最近は時々CLISPを簡易電卓代わりにしている。
Coq
ソフトウェアの基礎が気になるので、処理系だけ入手。
Emacs Lisp
.emacsコピペ」限定で。Common LispSchemeを触ったためか、何となく内容を追えるようになってきた気がしていたが、勘違いだった。
F#
OCamlは「Windows上で日本語を扱う」という視点では処理系がちょっと微妙なので、いっそのことF#に乗り換えようかと……。『実践F#』が積読状態になっている。
Forth
pForthをMinGWビルドしたので処理系は手元にある。スタック指向の言語はいつか勉強したい。
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-CSwiftが挙げられることもあるようだが、個人的見解としては、システムプログラミング言語としてのこの2言語には全く期待していない。あれは、Appleというしがらみからは逃れられないでしょうな。
Smalltalk (Squeak, Pharo)
Smalltalkは有名な古典的プログラミング言語だというのに、触ったことがない。ということでSqueakとPharoの処理系のみ準備完了。うーん、「環境」付きなのが気になる――言語を弄くる基準が「コンソール上でテキストフィルタ」という変な人種な私だからなあ。
Smalltalk (GNU Smalltalk)
個人の思想信条による理由よりSqueakとPharoにわだかまりを感じてしまう変人なので、邪道だと思いつつもコンソールでテキスト処理もOKなGNU Smalltalkも用意してみた。これで言語としてのSmalltalkの勉強に集中できる……か?
VBA (Visual Basic for Applications)
今までVBAから逃げ回っていたのだが、ついに使うことになりそうな予感。たぶん、Access VBA 8割にExcel VBA 2割ぐらい。

今は全く使っていない

Active Basic
VBScripを触りだした影響で、時々思い出しては弄くっていた。ほんの少しだけ触って放置して、すっかり忘れてからまた触る――これを繰り返していた気がする。なので毎度初めて触るのと同じ状態だった。String型をバシバシ使用 :)
bc
その昔、Windows標準の電卓アプリの代わりに使おうとして色々あって挫折した。今はirbclisp/goshで計算しているからなあ。
Clojure, Scala
JDKがなくてもJava APIを叩くスクリプトを書けるので非常に便利。Scala型推論とか、便利っすね。言語仕様はJavaよりも好みだ。とはいえ、IoT時代にJava VMベースでどこまでメインストリームに居残ることができるのか? ちょっと興味深い。サーバサイドに活路を見出すのだろうか?
COBOL
FizzBuzzするためだけにOpenCOBOL 1.0をWindows上に用意して触ってみた。なんというか、COBOLの名前と生まれた時代が示すように基幹業務(というかお金や帳簿が絡んでくるところ)向けの言語だよなあ、といった感じ。COBOL 2002のフリーフォーマットを採用するだけでも使い勝手が変わる気がしたが、世の中にはまだ広まらないのだろうか。
CoffeeScript
仕事で使う予定はない。RubyPythonその他の影響を受けているだけあり、その手のスクリプト言語っぽい感じでコードを書けるので、慣れれば素の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する)必要がなかった。ちょっと残念なのは、マルチバイト対応だが……。
Fortran
Fortran 90やFortran 95あたりは結構近代的な言語だと思う。用途次第ではC言語よりもFortranの方が遥かにマシな選択だろう。配列がらみの処理はFortranの方が得意だし、言語機能としてのモジュール化の方法はC言語には存在しない。可変長な文字列の扱いに微妙な制限がある点はマイナスな気もするが、まあ基本的に数値計算プログラム用の言語だからなあ。
GDB (GNU Debugger)
……いやGDBデバッガとして使っているが、GDBスクリプトを書く機会は(FizzBuzz以外に)ない。勉強不足なだけかもしれない。
Groovy
JDKがなくてもJava APIを叩くスクリプトを書けるので非常に便利。動的型付け言語っぽくいくもよし、@CompileStaticや@TypeCheckedで型推論するもよし。言語仕様はJavaよりも好みだ。コンソールアプリを書く人としては、オプション引数解析用の機能を標準で持っている点で、GroovyClojureScalaよりもポイントが高い*11個人的には、IoT時代に「Java VMベース」の言語としてどこに活路を見出すのが、興味深く見守りたいところ。やはりサーバサイドだろうか?
HSP (Hot Soup Processor)
FizzBuzzで楽しんでみたが、何というか他言語経験者には受けが悪そうな命令体系だと思う。もっとも初心者がプログラミングという行為に深入りせずにWindows用のGUIな何かを作る分には、あの命令体系でも十分な気がしないでもない。ところで元々は「HSPで職業プログラマ的な良いコードを書くと、どんな感じになるか?」というネタを思いついて処理系を用意したのだけど、そちらは全く進展がないまま。
JScript on WSH
他人が使うテキスト処理ツールの実装に使って以来、時々触ってきた。Windows用の配布可能な小ツールを実装する時の定番言語だった。でもそろそろ潮時だろう。HTAと組み合わせてクライアントサイドJavaScriptなノリで簡易なGUIツールを実装できる点も、PowerShell + WPF + XAML代替できそうだ。他のメリットは「JavaScriptECMAScript)でフィルタを書ける」だったが、WSHのなかなか目的にたどり着けないオブジェクト階層にイライラするよりも、Node.jsやPhantomJSを使ったほうが精神衛生的にマシだ。
m4
その昔テキスト処理用に触ろうとして、Windows用のどの処理系も日本語の置換に何かしらの問題を抱えていたので泣く泣く諦めた。思うところがあって改めて少し触ってみたが――なるほど、確かに中毒性のある言語*12だ。
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で舐めれなかったりして、結局は必要に駆られて使用することに。明快に記述できる文法は評価に値するが、スクリプト言語としては少々冗長だ。配列は自動拡張しないし、組み込み関数はプリミティブ気味だし、冗長気味な文法との合わせ技でコードがさらに冗長になっていく……。文法や言語仕様の詳細なドキュメントが見つからないのだが、どこにあるのだろうか?*13
秀丸マクロ
7年ほど秀丸エディタを使っていたが、マクロを書く機会はなかった。一念発起してFizzBuzzしてみて感じたのは、最近の便利な言語に慣れた身としては色々とモヤモヤ感がある言語仕様だということ(歴史的経緯的に仕方ないのだが)。とはいえちょっとした拡張ツール的なものを手軽に作れそうではあった。

*1:とはいえ、C++標準ライブラリの充実度をJavaC#.NET Framework含む)のそれと比較してはいけない。

*2:でもKotlinSwiftを触ると、C++型推論(というか型チェック関連)は「もう少し頑張ってほしいなあ」という印象を持ってしまうから不思議だ。アレでも以前より随分と便利になったんだけどなあ。

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

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

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

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

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

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

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

*10:現状はirbclispかgoshの3択だ。

*11ClojureScalaに関しては、同様の機能を私が見逃している可能性も高いのだが。

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

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