何度も書いてるが、仮にプログラミングを一度もやった事がなくって、Pythonでプログラミングを始めてみたい、と言った人は素直にPython備え付けのIDLEを使うべきだ。
Pythonはオールインワン環境として開発されている。すなわち、プログラミング学習をはじめる際に「余計な設定は要らない」ようになっている。
「余計な設定が必要な」プログラミング言語は初心者向けじゃない。下手すればプログラミングそのものより設定の方が難しいんだ。
設定がややこしいと「プログラミング学習をはじめる前に」心が折れて「やーめた!」となりかねない。
Pythonのオリジナルの設計者、グイド・ヴァン・ロッサムは「取り敢えず初心者でもIDLEさえ起動すればすぐプログラミングを始められる」ように考慮した。
これは正しい、んだよ。圧倒的に正しい。「人に使ってもらう事を」充分に考えると正しい選択であり、ある意味「だからこそ」数多くのユーザーを獲得してきたんだ。
言語処理系にある程度の簡単なIDE程度も付いてない、なんてプログラミング言語及び処理系は人気が出ようが無いんだ。
当たり前だ。
こういう事を書くと、「俺は愛用してる××ってエディタがあるから備え付けの△△は要らん」って言うヤツが必ず出てきて、辟易するんだわ。そりゃ自分の愛用の何かがあるのなら、それと言語処理系を接続して使えばいい。
ただ、こういうトンチンカンな事を言うヤツってどういうわけか、「言語処理系備え付けのナニカ」と「自分が愛用してるナニカ」が互いに排他的だ、って前提で物事を言ってるんだよな。
んなわけねぇだろ（笑）。「貴方が愛用してるエディタやIDEがある」から、どうして「ある言語処理系には備え付けのナニカが要らない」って結論になるんだろうか（笑）。関係ねぇんだよな、それとこれとは。
こういう事を脊髄反射的に言うヤツが多くて、「だからこそ」プログラマは論理的でも何でもねぇ、っつってんだわ（苦笑）。必ずと言っていいほど「俺は」と言う話を言ってくる。
個人的な経験なんざどーでもいいんだ。「俺は」は要らないんだわ。
実際問題、プログラミングが出来る人、にとっても「言語処理系の付属IDE」は役立つと思う。と言うのも「その言語処理系を試してみる時どうすんのか」って問題があるから、だ。
例えばとある言語「ほげ」が昨今人気がある、と言う話を聞いたとする。「試してみよう」とするだろ?でも自分愛用のIDEなりテキストエディタなりで「設定から始めて・・・」とかクソメンド臭くないか?「試すだけ」なのに。言語処理系に付属IDE(モドキ)が付いてたら、自分の使ってるIDEの設定を弄らなくても「どんな感触なのか」簡単に触って確かめる事が出来るんだ。「あ、これ良さそう」となった時、自分愛用のIDEで「本格使用する為に」設定すればいい。
一方、「試験的に使ってみる」だけで自分のIDEの設定、何か設定ファイルを書くなりプラグインをインストールして・・・だったらどうだろう。「こりゃダメだ!」ってなった時にそれまでの設定やらプラグインインストールした「手間」とか「時間」は全部無駄になってしまうんだ。
人間ってのは「面倒を嫌う」んだよ。だから保守的にならざるを得ない。「簡単に試せる」ならともかくとして、「一々設定弄ったり膨大なプラグイン導入が必要」だとすれば、そんな言語処理系を「試しに使ってみよう」とか思えるだろうか。多分試す前に「面倒くさくなって」やらない、と言う選択になる。
これでもピンと来ない人に言うと、仮に「どんなに素晴らしい言語処理系でも」、ソースファイルで提供されてて自分でビルドしなきゃならんかったらどうする?そしてそのソースをビルドする為に、ネット中駆けずり回って、必要な*.dllやらライブラリを持ってきて、ビルドして試して「合わんなこりゃ・・・」ってなった場合。
同じ事、なんだよ。
言語備え付けのIDE(モドキ)ってのは「お披露目の場」なんだ。「気楽に試してもらえなければ」導入を躊躇するのが人間ってモンなんだよ。
グイド・ヴァン・ロッサムは「そこが分かっていた」人だと思う。んで、残念ながら、例に挙げて済まないが、Rubyの作者のまつもとゆきひろ氏は「分かってなかった」。もちろんPythonがRubyより「良かった」トコは他にもあったかもしんない。いや、個人的にはRubyの方が「より良い言語」だと思ってるんだけど、「初動で試せる」気楽さだけは圧倒的にPythonの方が勝ってるし、それがこの２つの言語のユーザー数の差を広げていった原因の一つ、いや、大きな原因だと思ってるんだ。
繰り返すが、言語処理系にIDE「らしきもの」を付属させる事ってのはマーケティング的に考えると超重要だと思ってるんだ。
ちなみに、だからLispはダメなんだ、って結論になる(笑)。Lispの人気の無さの秘密ってのは、実のトコ、IDEで誰もがEmacsを指定する辺りで、選択肢がEmacsしかないから、なんだ。Emacsファンが聞くと驚くだろうけど、実際問題「Lispに興味があっても」Emacsが嫌でLispに踏み込めない人は思ったより多いんだわ。
そう、実はLispの人気の無さの半分以上の原因はGNU Emacsのせいなんだ(※1)。UNIX系OSでは必須IDEと言ってもいいEmacsなんだけど、Windowsユーザー及びプログラマにとってはそれほど魅力はない「ヘンテコリン」なエディタだ。これを強要する事がLispのダメなトコなんだわ。
だから僕は今まで、「Lispにちょっと興味がある」って人に対してRacketしか薦めた事がない。RacketはLispには珍しくIDEであるDrRacket込みのオールインワン環境、だからだ。Emacsが要らない。他にIDEが要らない。気に入らなかったら単にアンインストールするだけ、で済む。日本人にとっては「英語の公式サイトしかない」ってのは痛いけど、それでも付属IDEがある、ってのはデカいんだよ。もっと言っちゃえばRacketユーザーは「EmacsよりDrRacketの方がいい」って思ってる(笑)。もちろんEmacsからも使えるけど、「UNIX系ユーザーよりWindowsのユーザーの方が多い」と言う現実を見ると、LispのプライマリチョイスはRacket以外はあり得ない、んだ。
ANSI Common Lispの場合はちと悩む。現実的な観点からすると、機能制限はあるけどAllegro CL 11.0 Free Express Editionしか選択肢がないんじゃないか(※2)。Emailアドレスやら名前や住所やら登録せんとアカンが。しかし、上で書いた通り、付属IDEがある、って前提だとANSI Common Lispだとこれになっちゃうんだ。
Allegro Common Lisp。IDE付きの処理系で、上に「実行ボタン」があったりして、言わば「良くある」オールインワンでのIDEの形式になっている。
と言うわけで、言語処理系での付属IDEの重要性、ってのは分かってもらえただろうか。少なくとも、「プログラミング初心者」にとっては付属IDEがあるかどうか、ってのは大きい。繰り返すが、付属IDEがある、って事は「設定要らず」だと言う事だ。
仮に付属IDEが「機能が足りなくて不便だ」と言う意見が「正しい」にしても、それでも「要設定」よりゃマシなんだよ。それが初心者の立場、なんだ。
結局、何度も書くが、「プログラミング初心者向け」を謳ってるPython本で、「IDEを導入」させよう、なんつー本はクソなんでぶん投げていい。
そしてGoogle Colabなんかを使わせよう、なんつー本もクソなんで、んな本は買わんでエエ。それらは「まずはプログラミングに慣れてから」導入すべきモノで、初心者にそれを使わせよう、なんつー奴らはアタマがおかしいんで、アタマのおかしい奴らの言う事を聞く必要はない。
黙ってPythonだけをダウンロードしてIDLEを使うべきだ。
余計な事はさせないしない。
初心者にはそれで充分、なんだ。
とまぁ、それが基本だ。
ところで、書店なんかで昨今出てるプログラミング未経験者向けのPython入門なんかを眺めてみると、だ。IDEを導入させようとし、また、そのIDEにMicrosoftのVisual Studio Codeを推挙する本が増えてるカンジがする。上で書いた通り、そのテの本を書いてる奴らはバカ共ばっかだ、って事だが、別にUNIX系OSユーザーに良くあるように、Microsoft製品を馬鹿にしてるわけではない。つまり、Visual Studio Codeを特に「悪いIDE」だとは思ってはいないんだ。
ただし、Visual Studio Codeをちと触ったカンジだと、単純に、Microsoftはインタプリタでのソフトウェア開発に関してのノウハウが、少なくとも現時点では極めて低い、としか言いようがない、と思う。
大体、Microsoftはコンパイラ型処理系を明らかに得意としているんで(※3)、言っちゃえばVisual Studio Codeはコンパイラ型処理系を対象にしてる、ってのが原則だ。
Visual Studio Code
基本的にVisual Studio Codeはウィンドウが上下2分割されていて、上半分がテキストエディット部分、下半分がターミナル(※4)となっている。C言語なんかのコンパイラ処理系だと上半分でソースコードを書いて、F5キー辺りを叩くとそのままソースコードがコンパイルされ、下半分で実行ファイル指定のコマンドを打てば作成したCLIのアプリが走るようになっている。
なかなか便利な環境なんだけど、インタプリタだとそれだけじゃダメなんだ。
インタプリタの旨味、ってのは対話的開発にある。言い換えるとインタラクティヴな開発がコンパイラより良い辺りで、Visual Studio Codeに欠けてるのはリスナー(※5)なんだ。
このリスナー無しで開発する、ってのはハッキリ言うけどインタプリタ処理系では仏作って魂入れず、に等しい。っつー事は入門者向けにVisual Studio Codeを導入しろ、なんて事を書いてる本の筆者はインタプリタ開発を知らないか、慣れてない、って事になる。っつー事は、もっと言っちゃうとやはりPythonを知らん、って事になるんじゃないか。
知らん事を書いて本を出すな、と言う事だよな(笑)。
リスナーが無いVisual Studio CodeでPythonコードを書く事を初心者に強要する、って事は自然と悪い習慣を身につけさせる、って事になる。そうだな、書いたコードはprint塗れ、って事になる。
何度か書いてるけど、プログラミング言語に備わったprint系関数の役目は何か、っつーとターミナルに表示する為だ。しかし、リスナーがあればわざわざターミナルに表示せよ、って命令をする必要がない。
これは文法じゃなく、書法の問題だが、ハッキリ言っておく。Pythonに於いてはprintはオチ、であり、if __name__ == '__main__' :以降でしか使ってはならない(※6)。繰り返すが、これは文法じゃなくって書法の問題、だ。プログラム本体ではprintを書くな、使うな、って言っている。
printが無くてもリスナーさえあればそこで動作確認は可能だし、また、リスナー上で何らかの関数定義を試みて上手く働いたブツをテキストエディタ側にコピペしても良い。
インタプリタによる開発がコンパイラによるそれよりラクだ、ってのはそういう事でそれをインタラクティヴ性、って呼んでるわけだ。
IDLEはそれを許すが残念ながらVisual Studio Codeはそれを原則許さないようなデフォ設定になってるんだな。言い換えると、Visual Studio CodeはIDLEが出来るような事が出来ず、「プログラミング初心者にVisual Studio CodeをインストールさせるようなPython入門書を書いてる連中」ってのはPythonでのインタラクティヴでラクな開発方針をわざわざ捨てるような道を示唆してる、って事になる。
そしてPythonスクリプトのターミナルでの実行、が必須となり、ソースコードはとても褒められたモノじゃない、print塗れと相成るわけだ。
IDLEエディタ部。Python 2.x時代はホントに非力なエディタだったが、最近では補完機能も付いて、かつてでは考えられない程便利になってきている。また、Python専用なだけあって、リターンキーを叩くだけでオートインデントが入る辺りも○。これも、「出来ない」IDEやテキストエディタの方が多いんだ。知ってる範囲で言うと、まだダメなのが「リインデント機能」が欠けてる辺りで、Pythonのコードを修正する際に、ある範囲を「インデントし直しする」と言うのがメンド臭い。残されるのはこの機能が付く事だろう。なお、F5キーを叩くと、ここで書いた/編集されたソースコードはリスナー部分にロードされて、プログラムが上手く動くか「試す」事が出来る。
IDLEのリスナー部、IDLE Shell。テキストエディタ側でプログラムを書いてF5を叩くと、書いたプログラムがここへとロード出来て、「打ち込んで」テストが出来る。これがあるが故、テキストエディタ側でprintする必要がない。また、UNIX系端末でお馴染みの履歴機能があって、一回打ち込んだコードは再度呼び出して修正が可能だ。Alt-p(Altキーを押しながらPを叩く)と、「以前入力したコード」を順繰りに最新から呼び出して行き(Previous)、戻す場合はAlt-n(Next)で今度は古い入力から順に新しい入力を探していく。例えば上の例だと、fold(lambda y, x: [y] + x, z, lst, reverse = True)を打って実行した後、Alt-pでもう一回それを呼び出し、,reverse = Trueを消して実行してる。なお、「履歴機能」と言うのはリスナー及びインタプリタでは非常に重要な機能で、これが欠けてるブツだと非常に使いづらい(HaskellとかOCamlとか)。そういう意味では、やはりPythonのIDLE Shellは必要十分な機能を持っている。
余談だけど、もちろんisamさんは初心者じゃないし、色んなプログラミング言語をVisual Studio Codeで書いてるから手慣れてるんだろう。
でも、正直言うと、isamさんがPythonのコードを提示する度に
「やりづらそう」
とか
「苦労してるよな」
とかどうしても思っちゃうわけだ(笑)。
何故なら、上で書いてきた通り、Visual Studio CodeだとPythonプログラミングのインタラクティヴ性が全く味わえないから、だ。だから本体のソースコードにprintを書きまくらないとならなくなる。
16行目以降は結果「変数aRational」を埋め込んで、それを文字列に変換し、printしなければならない。これもVisual Studio Codeにリスナーが無いから、だ。
下に表示されてるのは「計算結果」ではなく出力だし、コンパイラ型処理系ならいざ知らず、インタプリタ相手だとあまりにも役立たない情報表示に見える。 => isamさんの記事はこっちから
一方、IDLEなら、プログラムのソースコード部分ではVisual Studio Codeで書いたブツの16行目以降は要らなくなる。
IDLEだとprintなんかの指令はソースコードに埋め込まなくていい。結果、見た目は当然スッキリする。
Visual Studio Codeでの16行目以降は、本来なら、リスナーに入力すべきものだ。
エディタ側でF5を叩くとリスナーにRationalクラスが読み込まれ、リスナー側で色んなテストを行える・・・と言うか「行うべき」だ。ユニットテストならいざ知らず、テストコードを不用意にプログラムのソースコード本体に埋め込むべきじゃないんだが、C言語なんかじゃそういう書き方をして固定したテストコードをmain関数に埋め込まなきゃどーしよーもないんで、ハッキリ言えばVisual Studio Codeはそのテのコンパイラ型処理系前提で設計されてる、って事だろう。
また、上のリスナーの実行を見れば分かると思うが、そもそもリスナー/インタプリタ上ではprintが必要ない。入力に即したレスポンスがすぐ返ってくるわけで、これが繰り返すがPythonを使った開発でのインタラクティヴ性なんだ。
こういう特性があるんで、最初に書いた通り、プログラミング・ニュービーはPythonに於いてはIDLEさえあれば他に何も要らないわけだ。
繰り返すが、コードをprint塗れにする必要はないし、コードをprint塗れにする事は悪習に通じる。
もう一度言うが、Visual Studio Codeはコンパイラ型処理系に適するような基本設計になっていて、インタプリタでの開発には今のトコ向かない。Visual Studio Codeにはリスナーが欠けている。
散々腐したGNU Emacsだけど、インタプリタでの開発に於いてはVisual Studio Codeに比べると、やはり一日の長がある。
いや、僕自身もEmacsから離れたくって、過去、特にJavaの父、と言われるジム・ゴスリングが
「Emacsは時代遅れだ。NetBeansを使おうよ。」
と発言してた事もあり、NetBeansに期待してた事がある。
しかし、実際は、ほぼC/C++/Javaにしか対応してなかったし、他の言語に対してのプラグインなんざほぼ無い、って状況だったんで、先行するEclipseなんかに比べても使い様が無かった。そしてEclipseなんかもメジャー言語しかほぼ使えなかったんだ(プラグインがあってもメンテされてない、とか)。
それに比べると、最後発の筈のVisual Studio Codeの成長具合は凄まじい、の一言に尽きる。さすがMicrosoft、ってカンジだ。ユーザーベースが圧倒的に先行者達を凌駕してるんで、先行してるEclipseやNetBeansに比べてもマイナー言語にも対応してるしプラグインも多い。今後ますますの成長が期待できる。そこはそうなんだ。期待できる。
ただし今のトコリスナーがない。少なくともその一点に於いてGNU Emacsより劣るんだわ。
インタプリタを使った開発だと現時点ではGNU Emacsを超えるシステムは無いんじゃないか、とか思ってる。別にEmacsを褒めてるワケじゃなくって、単なる事実だ。Emacsにはinferior-何とか、と言うプラグインが提供される事が多く、それによりリスナーが準備され、書いたプログラムはターミナルじゃなくってリスナーへと送り込まれる。まんまIDLEと同じで、Pythonも例外じゃない。
EmacsでのPython開発環境。M-x run-pythonで下部のリスナーでPythonインタプリタが走り出し、上部のエディタで書いたPythonのソースコードはC-c C-c(Ctrlキーを押したままcを二回叩く)でリスナーにロードされる。
このinferior-何とかを利用したリスナー提供は、Pythonに限った話ではなく、GNU Emacsでは手広く行われている。コンパイラだけじゃなく、インタプリタも提供している言語実装にはお馴染みのプラグインなんだ。
GNU EmacsでのOCamlのリスナーの例。ここでも画面上半分で書いたコードをリスナーへとロードし、テストコードをリスナー上で実行する事ができる。なお、isamさんの話だと、Microsoft F#(OCaml方言)とVisual Studio Codeの間にもリスナーが存在せず、結果、使いづらい開発環境になってるらしい。
調べてみたら一応、Visual Studio Codeでも曲がりなりにもPythonリスナーを構築する事は辛うじて出来るらしい。ただし、方針は間違っている。
Visual Studio CodeでのPythonインタラクティヴ開発環境の例。「入力欄」にコードを入力してShift + Enterで実行可能だが、そもそもテストする部分を「マウスで選ぶ」とか、一々やる事がメンドイ。あるいはCtrl + a(Ctrlキーを押しながらaを叩く)で全ソースコードを選択しておいてからShift + Enterで実行、って手もあるが、Emacsでのインタラクティヴ開発環境から考えると手間だらけ、だ。
インタラクティヴ開発環境には、Windowsで言うトコのinteractive Python「だけ」あれば充分、なんだ。素直にソースをリスナーにロードする仕組みさえあればいいんだ。何もGoogle Colabで流行りだから、っつってわざわざJupyterなんざ経由せんでもエエ。
そして当然、プログラミング初心者用のPython入門書にはこんなインタラクティヴ環境の構築法なんざ説明していない。あまりにも構築は初心者向けとしては敷居が高く、結果、Pythonによる開発の利点を全てドブに捨てたような「不便さ」を初心者に強要してるわけだ。繰り返すが、バカじゃねぇの?だ。
常々、IDLEで充分だ、って言ってる意味が分かるだろうか。これを把握してないような輩はプログラミング初心者用にPython入門書を書くような資格がない。
2000年代だとEmacsは後発のEclipseなんかの後塵を拝してたと思う。Eclipseなんかはネットを介したプラグインの直接ダウンロード/インストールをサポートしていて、当時のEmacsのように「Emacs Lispによるプラグイン」提供サイトまで出かけていって、そこで提示されてるコードをコピペしてはEmacsに書き込む、なんつーメンドい事をせんようになってた。
しかし現在では、Emacsでもプラグインの直接ダウンロード/インストールが可能になった上に、Spacemacsの登場で、「バラバラで存在してた各種プラグイン」を「パッケージ」と言うカタチでインストール出来るようになった。現時点ではそのテの利便性が逆転して、Emacs(正確にはSpacemacs)を上回る環境を他のIDEでは提供していない。Visual Studio Codeを含め、そのテのIDEではプラグインの導入は個別に行わないとならない。一方、Spacemacsは限りなく「設定要らず」へと近づいている(※7)。
いずれにせよ、マイナー言語、及び、インタプリタでの開発環境は知る限り現在ではGNU Emacs(Spacemacs)が最強だ。もちろん将来的にはVisual Studio Codeの環境が「より良くなる」事はあり得るだろう。EclipseやNetBeansなんかより進化の度合いが速いんで「期待は出来る」。
ただし、それでも現時点では「まだまだ」なんだ。繰り返すが、汎用IDEとしてプログラミング初心者にVisual Studio Codeを使わせるより、現時点ではPython付属のIDLEの方が「総合的には」勝っている。何故なら手間要らず、だからだ。
素直にIDLEを使わせよう。汎用IDEの「細かい設定」は闇の深度が深すぎる、んだ。バカな個人のこだわりは捨てて、とにかくIDLEを使わせろ。
以上。
※1: こういう事を書くと、Emacsユーザーは「始めはともかく慣れる」とか言うが、説得力があるたぁ思えない。
人間は嫌でも慣れる、ってのは事実だが、それは「SMしても女は痛みに慣れるよ」と言うようなモンで、そんなモンをアテにしちゃあいけない(笑)。
むしろ、「独特のキーバインドを採用する」と言うのは「乗り換えを阻害する」と同義で、ソフトウェアの作り方として間違ってると思う。
Emacsのキーバインド(ショートカット)はヘンだ。しかし、基礎的ショートカットをCUAモード(いわゆるデファクトスタンダードなキーバインド)に変更する事は可能なんだけど、それにはカスタマイズが必要だ(一応、「編集」から選択する事は可能だ)。
しかし、これは設計思想としてはヘンで、「Emacsはカスタマイズが可能だ」と言うなら、Emacs慣れしてる層がEmacsのキーバインドへとカスタマイズするようにすべきで、何故にEmacsニュービーの方が要カスタマイズになってるのか。逆なんだよ。
結局、既存のEmacsユーザーの方が「俺はこれの方に慣れてるから」と言う声がデカい、って事になる。いっつも言ってるがおっさんは自己中心的なんだ。おっさんは若者をマウンティングするのが生きがい、ってのがEmacsには端的に現れてると思う。決して若者に道を譲ろうとはしない。
個人的には、プログラミングの世界には二大老害ツールがある、って思っていて、一つがC言語、もう一つはEmacsだ(笑)。おっさん優先な設計思想がダダ漏れになっている。「俺は昔からこうしてた」「これが伝統だ」と言う言い訳が必ず出てくる。
しかし、実際問題、Emacsのキーバインドそのものはそんなに「伝統に裏付けされた」モノじゃない。Emacsのキーバインドがヘンテコリンなのは、そもそも、Emacsが生まれたMITは、独自キーボードを開発してて、それが巨大なキーボードで現行機ではありえないキーがてんこ盛りだったから、だ。
MITのKnight Keyboard。これがMITオリジナルの「拡張キーボード」で、見慣れないキーが山程あるのが分かるだろう(笑)。そして「これで済まなかった」(笑)。この後、MIT内製のキーボードのキー数は「どんどん増えていく事と」なる。
元々、Emacsは、「MIT内製のキー数拡張キーボード」のキーと基礎コマンドが一対一で対応してて、特定のキーを叩くとそのキーにバインドされたコマンドを即実行、ってカンジだったんだな。
ところがこれじゃ、フツーのミニコンのキーボードでは使えない。リチャード・ストールマンがEmacsの作者のクセに、FSFでGNU計画をスタートさせる際に、何故に他者(後にJavaの開発者の一人となるジム・ゴスリング)が作ったGosling Emacsのソースコードを流用しようとしたのか、と言うのは、Gosling EmacsはUNIX向けに開発されたクローン品で、UNIXで標準的に使われてた「小さいキーボード」でも問題ないようにキーバインドが整理されてた、ってのが大きな理由なんだ(結局この目論見は流れるわけだが)。
だからEmacsの複雑怪奇なキーボードショートカットに別に崇高なナニカ(信念とか・笑)があったわけでも何でもねぇんだ(笑)。むしろ、Emacsの教訓とは、特定のハードウェアに過度に依存して最適化するようなソフトウェアを作るな、って辺りにある(笑)。
しかし、Emacsは未だにその教訓を活かさず、独特のキーバインドを前面に出して、乗り換え阻害を生じさせている。
繰り返すが、こんなんとてもじゃないけど褒められた伝統でもなんでもないだろう。単におっさん共が頑ななだけ、だ。
余談だが、ハッカーとして有名な高林哲さんがこんな事を言っていた。
1 つエピソードがあるんですけど、学会などに行くと、「古き良き」ものが好きな人が割といるんですね。 ある学会の帰りに、皆で食事に行って、Emacs について話していたんですけれども、 誰かが確か、「 Emacs に色をつけるなんて嫌だなぁ。」という話をしていたんですね。 僕は「色がつかない Emacs なんて信じられない。」と言ったんですね。 そしたら、何と、同じテーブルに座っていた人達が「 Emacs に色をつけるなんて邪道だーーー！」って (笑)。 僕はたった 1 人の少数派になってしまって、ピンチだったんですけど、 古き慣習を頑なに守ろうって人達が居る所には居るんですが、その頑なさは何なんだろうと思いますね。
なお、本文では幾分キツい事を書いたが、個人的にはVisual Studio CodeがGNU Emacsを上回るようなインタラクティヴな開発環境を提供する日が来れば、いつでも乗り換える所存だ。
ただ、現時点ではEmacs(と言うよりSpacemacs)が、制限がないとは言わないが、圧倒的に便利な環境なんだ。
※2: ANSI Common Lispは悩ましい。過去にEmacsとANSI Common Lispを設定要らずにワンパッケージ化したLispboxなるブツがあって、これがプライマリチョイスだったが、メインテナンスがされてなく、現行のWindowsだと上手く動かない。
また、商用ANSI Common Lisp処理系では、FranzのライバルであるLispWorksなんかもフリー試用版を提供してるが、一日での使用時間制限があり、Allegroより不便だろう。
フリーな処理系ではClozureがIDEを提供している「らしい」が、「らしい」と言うのは元々これは旧Macintoshから始まるMacintosh用Common Lisp(MCL)がルーツで、IDEの「ビルド」がそもそも現行のMacでしか出来ないみたいで、「どんなIDEなのか」見たことがないから、だ。
結果、プラットフォームが限られる、って言う意味でオススメにはならない。
※3: こう書くと「あれ、Visual Basicは?」って思う人もいるだろうが、ぶっちゃけ細かいトコは(使った事がないんで)良く分からんのだが、ExcelのVBA(Visual Basic for Applications)なんかを見ると、VBも恐らくコンパイラだろう。Basic = インタプリタ、ってワケじゃないんだ。
Basicがインタプリタの印象が強いのは、往年のパソコンのROMにOS代わりにBasicが積まれてて、そいつがインタプリタ処理系だったから、だが、同時代の、いや、それ以前からミニコンではBasicコンパイラが山程あった。
繰り返すが、「インタプリタ言語」とか「コンパイラ言語」と言うモノは存在しない。あるのは特定の処理系がどっちの実装になってるのか、と言う話で、Basic、と聞いたら即「インタプリタ」だと思い込むのは間違っている。
※4: 端末。WindowsではDOS窓等と呼称される。正式名称はターミナル・エミュレータ(あるいは端末エミュレータ)で、ソフト名はコマンドプロンプト。UNIX系OSではShellと呼称される。
※5: IDEで表示されるインタプリタ部分。端末そのものじゃない。後述。
※6: Pythonのif __name__ == '__main__':以降でC言語で言うmain関数、あるいはエントリポイントを形成する、と考えていい。端末で動く部分だ、と。
しかし実の事を言うと、Pythonの構造上、これが無くてもスクリプトとして働くが、そのファイルが他のファイルからライブラリのモジュールとしてimportされる際、if __name__ == '__main__':以降はスキップされる。
Pythonではスクリプトファイルがimportされる際、ファイルは一旦評価されるが、その際、if __name__ == '__main__':が無いとprintなんかも実行され、importする度に表示が実行されると煩くてかなわない。それを避ける為、printなんかを使った関数テストでさえif __name__ == '__main__':の後に書いた方がいいわけだ。
従って、ホントの事を言うと、if __name__ == '__main__':は端末上での動作の為、と言うよか、モジュールとして呼び出された際に「余計な部分を実行させない」為にあり、printなんかはその「余計な部分」に当たる。
プログラムの「再利用性」を考えた場合、if __name__ == '__main__':は必須であり、入出力なんかの「余計な部分」はif __name__ == '__main__':以降に纏めて置いておくべきだ。
※7: 言い過ぎ(笑)。Spacemacsでも.spacemacsと言う初期化ファイルでの設定編集はいまだ必要だ。ただし、往年のGNU Emacsに比べると手間はホントに無くなった、ってのが事実で、Emacs Lispによるプラグインの個別設定のメンド臭さは「パッケージ」がかなりの確率で解消してくれている。
