見出し画像

Retro-gaming and so on

Rubyはオワコン?

Web検索をしてたら次のような記述を紹介している記事があった。

「Rubyは今後使われなくなる言語だと思いますか?5年、10年後はどうなっているでしょう?」

と言うしょーもない問に対する回答だ。




ちなみに良く読んでみるとこの回答者はRubyユーザーだ。最後にそう書いてある。
実は分かりづらいが、

> 2014年の時点でRubyは死すべき言語だったのです。


> なんだ、まだ生きていたのか、しぶとい奴め…

と言う記述はスラッシュドットの件の記事に対する皮肉だ

そもそも、元々の質問がくだらない、と言う理由は、言語が標準化されていると言う事に対して全く理解してない、って事だ。2012年にISO/IECで国際規格が制定されていて、JIS規格もある。そういう言語がオワコンとか死とかなるわけねーだろ、ってな話だ(※1)。
僕は存在は知らんが、既に「誰もがRubyの言語処理系を作っても構わない」状態になっている。「標準仕様がない」Pythonは基本1個の「公式実装」しかないが(※2)、Rubyは仕様に則って実装すれば「Ruby言語」を名乗れる。公式実装以外があっても良い言語なんだ。
これはJavaScriptに対しても同様で、正式名称「ECMAScript」には実際、ブラウザ毎で別々の実装が走っている(※3)。ECMAScriptにも色んな実装があるんだ。
ただ、上の回答はちとおかしな事を書いていて、

> 安心して下さい。JavaScriptはWebAssemblyによって駆逐されることが確約された言語であり、生き残ることができないと考えられます。

と言う文脈はこういう文脈と同じになる。

安心して下さい。C言語はAssembly言語によって駆逐されることが確約された言語であり、生き残ることができないと考えられます。

いくら俺がC言語嫌いでもこんな事は書かない(笑)。そりゃそうだろ、WASMだ何だ、っつったってその本質はアセンブリ言語なんだよ。一体今どき、誰が高級言語を捨ててアセンブリ直書きするか、っつーの。こんなの直書きしてぇのか、ってな話だ。
TypeScriptにせよ現時点Microsoft依存だし、そもそもTypeScriptはECMAScriptのスーパーセットだ。そもそも対立してるわけじゃないんだよ。
あるいはアレか?WASMだったらC言語からコンパイル出来る(可能性がある)からJavaScriptを使わなくても適当な言語処理系があればWASMが生成出来る、って話だろうか?
いやいや、そう上手くは行かない。Emscriptenなんかも試してみたが、確かに"Hello World!"程度ならC言語で書いたソースからWASMを生成可能だ。一方、そんなクソなプログラムなんて書いてもしゃーないわけで、もうちょっとマトモなプログラムを書こう、なんてしたら途端にコンパイルは上手く行かないんだ。GLibなんて組み合わせた日にゃあコンパイルエラーの嵐だ。
じゃあ、GLibなんかを避けてフルスクラッチでCで書くのか、なんて言えばそんなのはアセンブリ直書きに限りなく近い。結果、そんなメンドイ事するなら「WASMの元々の想定通り」素直にJavaScriptで何か書いて、ブラウザ上のコンパイラに任せた方がエエんだよ。
結果、「ブラウザ基準」で考えるなら、JavaScript(ECMAScript)からは離れられないんだ。

とまぁ、そんな事が言えるわけだが、上の回答を請けて次のような事が書かれていた。



んん〜〜〜〜。
いや、別に嫌いな言語がある事自体はいいんだ。構わない。俺もC言語が大っ嫌いだしな(笑)。
ただし、特定のプログラミング言語が嫌い、ってのは通常、シンタックスが嫌いだとか機能がどーの、って話になるんだよ。
しかし、プログラミングスクール詐欺師共の格好のネタってのが、具体的に何を指してるのか知らんが、そんなのが嫌いになる理由ってのはなんだかなぁ、ってな話だ。プログラミング言語自体は全然関係ねぇやん、と(笑)。
いや、例えばRubyはendだらけで嫌いだ、とか(笑)、JavaScriptはC言語くせぇ構文だから嫌いだ、とかなら分かる。でもプログラミングスクール詐欺師共の格好のネタってのは全くをもって説得力がない。
っつーかそんなん嫌う理由にしちゃアカンやろ。
例えばこの筆者はPythonも嫌いなのだろうか。昨今の流行りだとPythonが一番(具体的に何を指してるのか知らんが)Webアプリ作りに使われてる言語だ。翻って言うとPythonが一番プログラミングスクール詐欺師共の格好のネタだと言う事になる。
他にもPHPって言語がある。FacebookWikipedia(※4)を書いてる言語だ。まぁ、ここで書かれてるWebアプリが厳密に何を指すかは知らんが、これも単純にはプログラミングスクール詐欺師共の格好のネタだろう。
僕もPythonのプログラミング初学者向けの本がクソばっかだ、って言ってて、「初心者はPythonに手を出すな」とは何度も書いてきてるが、それとPython自体が好きとか嫌いとかは関係ないんだ(しょーもねぇ仕様がある、とは言ってるけど・笑)。
言い換えると「プログラミング初心者じゃなければ」手を出して良い。JavaScriptに関しても同じ、だ。
いずれにせよ、こういう「理由にならない理由」である言語を嫌う、と言う事を是とすると、「良い、自分に向いたプログラミング言語を見つける」って意味だと失敗するだろう、たぁ思うんだよな。
勿体ない。

確かにPythonに比べるとRubyの方が「Webアプリに向いてる」と言う「印象」はある。現時点だとPythonの用例の方がむしろ多いんじゃないか、ってなカンジだが、歴史的な経緯、特に2000年代なんかだとぶっちゃけ、Pythonで頑張ってWebアプリを作ってたのはGoogleだけ、って印象だった。ハッキリ言っちゃうと、PythonでもZopeだ何だ、とWebアプリケーションフレームワークがあったが、Ruby on Railsには太刀打ち出来なかったんだ。
そしてGoogleは今や「自分で立ち上げたWebサービス/アプリ」を一生懸命潰す企業と相成った。よってGoogleが作った「Pythonで書かれたWebアプリ」なんざ結構な確率で消え去っている。
しかしPythonに比して、Rubyが「Webアプリに向いてる」って印象を作り上げたのはある種偶発的なんだ。
次の二つが理由として大きい。
  1. Pythonに比べるとRubyの方が出自からして「UNIXベッタリ」であった事 -> Windowsで使うのを元々意図してなかった為、UNIXサーバー上で使うには相性が良かった
  2. 掲示板作成言語として著名だったPerlを置き換えるには都合の良い性能を持っていた
1. に関して言うと、Pythonなんかだと比較的Windowsでデスクトップアプリを作るのがラクなのに反して、Rubyは元々そっち方面は苦手だ(※5)。しかしWebアプリ分野だと結果そういう「UNIX臭いプログラミング言語」の方が使い勝手が良かったんだ・・・しかも2. が示してる通り、Rubyが登場した前後だと、「やっつけ仕事でWebアプリを作れる」競合がPerlくらいしかなかった・・・結果、RubyがWebアプリ記述用言語として第二陣を切れた、って事なんだ(※6)。
JavaScriptもWebアプリ作成を目指した言語じゃない・・・Webアプリって具体的に何を指してるんだかサッパリなのが良くないんだが、原則、いわゆるWebアプリはサーバー側で走っている。今じゃサーバーサイドJavaScript、なんてのもあるが、元々は「ブラウザ側で動く」目的で設計されたのがJavaScriptだ。クライアント側のスクリプトなんだよ。

> 猫も杓子もWebアプリ様々状態なのはおかしいと思っていた。
> そもそもWebアプリで何がしたいんだ?

この辺には同意する。プログラミング初心者向けを謳ってるのに、なんでもかんでもWebアプリ作成、ってのはおかしい。
過去、「プログラミング初心者向け」を謳ってるにも関わらず、Webアプリ作成法に付いて語ってる本、なんつーのがあったが意味不明だ。Webアプリ作成が難しい、って言ってるんじゃない。そもそもプログラムを動かす環境として要Webサーバーにならざるを得ない、ってのが非現実的だ、と言ってるんだ。今からプログラミングを学ぶ、っつーのに自宅Webサーバーを立てろ、ってのか。レンタルサーバーを借りるにせよ、要はプログラミング初心者向けだとして考えると環境構築がメンド臭すぎるんだ。
プログラミング学習は手元に書いたプログラムを手軽にそのまま実行出来る、ってのが一番だ。Webアプリ作成、ってのは論外なんだよ。
よって、この意見は妥当だ。そして現実世界だとWebアプリが流行ってるんで、流行りに乗ってWebアプリ作成法を入れればウケて、本の売上が伸びるだろう、とか教育効果を無視した色気があるのも事実だと思う。
ただし、ここには以前書いた通り、ある種の背景がある。一般にプログラマ、っつっても画一じゃない。大まかに三種類のプログラマがいるんだ。

  1. Windowsプログラマ
  2. UNIXプログラマ
  3. ゲームプログラマ
2番目のプログラマは要はWebプログラマだ。そして、Python、Ruby、JavaScriptのプログラマはこのテのプログラマで、要は彼らが何か書く時には「自分の得意範囲に寄せて」書く。そして彼らはWindowsのGUIのデスクトップアプリを作る、ってのが不得意分野だ、って背景がある。
加えると、1番目のWindowsプログラマは基本的にはPython、Ruby、JavaScriptの本なんて書かない。何故なら業務でそれに触る、なんて事はほぼ無いんで、要は不得意分野に付いての本なんざ書かないんだよ。
極端に言うと、Windowsで扱えるプログラミング言語はC++、C#、F#、Visual Basicの4つしかない。どれもOSの提供元、Microsoftが提供している言語だ。加えるとするなら良くってJava程度だろう。特殊言語だとエロゲ向けのNScripterとか吉里吉里Zとかがあるが。
Windowsで使えるプログラミング言語が4〜5つくらいしかない、って事は当然彼らがデスクトップ向けで販売する「商品」はこれらで書くしかない、って事だ。従って他の言語は知りようがないし、当然それに付いての本は書けない、って事になる。
彼らがPython、Ruby、JavaScriptで「商品を書く」なんて事はほぼあり得ない、んだ。何故ならこいつらは原則インタプリタなんで、そもそも「商品」としてソースコードなんざ売りたくないだろう。「どんな風に書かれてるか」丸見えになっちまう、ってこたぁライバル会社にも「何が行われてるのか」知らせる事になっちまうし、非常にマズい(※7)。結果、Microsoftが提供するコンパイラを利用した方が「機密保持」のためにも適してて、それがデスクトップアプリでの「商売」なんだよ。
分かっただろうか?プログラミングスクール詐欺師共の格好のネタなんじゃなくって、そもそもPython、Ruby、JavaScriptやPHPを教えられる、なんてヤツは基本Windowsプログラマではなく、UNIX(Web)プログラマである事。反面、「今からプログラミングをはじめたい!」とか言う「プログラミング初学者」の殆どはWindowsユーザーだろう。
結果、「プログラミングを教える」層と「プログラミングを教わりたい」層の間には環境ギャップがあるんだよ。前者はWebアプリが得意、後者はデスクトップアプリが作りたい、となれば意思疎通は難しい(笑)。片方が英語喋ってるのにもう一方が理解出来るのは日本語だけだ、ってくらいズレてるんだ(笑)。
それが、UNIX生まれのプログラミング言語をWindowsユーザーである「プログラミング初学者」に教える事の難しさで、今貴方の目の前で起きてる事なんだ。

さて、色眼鏡を外してみると、実はRubyもJavaScriptも極めて良い言語だ。
もちろん、好みの問題、ってのはどうしても出てくるが、実はこの二つの言語は基本設計が極めて良い。特にJavaScriptは名称のせいで「Javaより劣ってる」と言う印象を与えがちだが、結論から言うと実はJavaより言語の基本性能はいい
Rubyは常々、このブログではプログラミング初学者用プログラミング言語としてはオススメだと言っている。実の事を言えば、Rubyは非常に高機能で、初心者向けとしては設計されていないんだけど、何度も書いてるが、初学者対象としては言語の性能よりそれを使ったプログラミング教材に良いモノがあるかどうかが肝要で、Rubyはそういう環境が整ってるんだ。Webでも良い入門教材がある、とは毎回言ってるわけだが、結果、タダでプログラミングを学びたい、と言うニーズに応えられる状況になっている。

 
一方、プログラミング初学者向けとしてはJavaScriptはサイテーだ(笑)。これも基本機能の良し悪しは関係なく、単にJavaScriptはWebブラウザを端末として動かすように設計されていて、結果、HTMLやCSS、そしてWebブラウザのAPIと組み合わせる事が念頭に置かれてる為、「HTMLやCSSやWeb APIの知識を持たない」状態だと学習効率が極めて悪い、んだ。スタンドアロンの処理系もあるにはあるが、Windowsだとそれらをインストールするのに物凄く手間がかかる。
結局、「プログラミング初学者にとっては学習環境構築の敷居が高い」と言う一点のみ、で全く薦めていない。
ところが、この二つの言語には共通点がある。両者共ある意味Lispの亜種だ、と捉えられている。

Rubyは作成者、まつもとゆきひろ氏の愛称を用いて、別名MatzLispと呼ばれている。あるいはAcceptable Lispとも認識されている。
一般に、RubyとPythonは競合する言語、として認識されてきた。が、実の事を言えば根本の設計思想は全く違う。Pythonは元から「初心者が扱い易い言語」を意識してた。インデントによるオフサイドルールを採用したのも「初心者が間違いにくい」と言う研究から採用したわけだ。
一方、Rubyはそもそも自称言語オタクであるまつもとゆきひろ氏が自身を含めた言語オタク向けに作った言語だ。言い換えると初心者の存在なんざ眼中にない。キレッキレに尖った言語、っちゅーのがRubyの本質だ。
これは極端に言うと、Rubyのユーザー数の増加率やコミュニティの性質に反映される。Rubyのオワコン的なイメージ、と言うのは主に対Pythonに付いてのモノだろう。明らかにPythonのユーザー増加数に比するとRubyのそれは小さいカンジはするだろうが、それは元々そうなんだ。そしてPythonを見てみろ。C言語脳が増えすぎてPythonicとか言い出して「窮屈なコーディングスタイル」を標榜してしょーもない事になってる。
一方、Rubyユーザーはそもそも言語オタク系であり、コミュニティもそういうケがある。そして「言語オタクが集う」って事は実は排他的ではないんだ。僕が見る限り、彼らは常に「他のプログラミング言語」に興味を持ち、リスペクトを忘れない。結果、他言語ユーザーに対しても極めてフレンドリーだと思う。そして「言語オタク」が集う以上、ハッカーの存在率も極めて高いんじゃないか。
実際、欧米でのRubyの紹介者も「達人プログラマー」の人たちだ。キレッキレの人がキレッキレの言語として紹介し、注目を集めたんだ。

 
 
 
そしてそれなりに規模がデカイユーザー数を獲得出来なければ当然「国際標準規格化」なんか成し得ないだろう。
「Rubyってのはどんな言語なのか?」と言うのは、端的にスティーヴ・イエギが記述した通り、だと思う。

おおよそのところ、 RubyはPerlの文字列処理とUnix統合をそのまま取り入れた。つまりシンタックスまで含めて同じなのだ。だから他の何かを待つまでもなく、すでにPerlの最良の部分を手にしているのだ。そして これは出発点としては素晴しいものだ。特にPerlの他の部分を取り入れないならば。
しかしその後Matzは最高のリスト処理をLispから取り入れた。そして最高のOOSmalltalkその他の言語から。そして最高のイテレータをCLUから。あらゆることの最良の部分をあらゆるところから取り入れたのだ。
そしてどうにかしてそれらが一緒に動くようにしていて、それがあまりにうまく行われているので、そこにそんなものがあるとは気付かないくらいだ。

JavaScriptも「Cの皮を被ったLisp」(Lisp in C's clothing)と呼ばれる。
実の事を言うと、僕も最初はJavaScriptは「汚く書かれたコードしか存在しない」って話を聞いて嫌ってたんだ。そんなに汚く書かれてるならよっぽど酷い言語なんだろう、とか思ってた。
しかし事実は違った。JavaScriptもPythonの競合的な扱いになってるが、基本設計のスジの良さ、ってのはPythonを上回ってる。Pythonにはマトモなレキシカルスコープがない。一方JavaScriptはそれを持っている。それだけでも性能がPythonより上回ってる証明になるだろう。
話によると、JavaScriptの元々の開発者、ブレンダン・アイクSchemeのファンで、Mozilla(旧ネットスケープ)の「ウチに来ればSchemeを使わせるよ」と言う誘いに騙されて(笑)転職、そこで「Webブラウザで動くScheme」を目指した言語処理系JavaScriptを開発する事となる。マーケティング的にC言語系の見た目にせざるを得なかったが。
そんなわけで、実の事を言うと、JavaScriptは言語あるいは言語処理系の設計としては統計処理言語のRに近い(※8)。

 
 
ところで、最近の「プログラミング入門」だと最初にK&R由来の「Hello, World」プログラムを提示するより「数当てゲーム」を実装して見せるケースが多くなっている。
ここで言う「数当てゲーム」とは、

  1. ゲームを始めると、コンピュータは1から100の範囲で乱数を作る。最初、コンピュータはその値を隠す。
  2. プレイヤーは、その隠された値を当てる。
  3. プレイヤーが「答え」として示した値が当たりでなかったとき、コンピュータはその値と隠された値を比較して、「もっと大きい数字です」または「もっと小さい数字です」とヒントを出す。
  4. 正解が入力されるまで、2.と3.を繰り返す。
と言う「つまらん」と言えばつまらんゲームなんだが、一方、Hello World!と表示する「だけ」よりはかなりマシだ。しかもロジック自体は大して難しくもないから実装が簡単になる。
で、通常だと、コンピュータが作った乱数を大域変数にして云々・・・っつー流れになるんだが、このプログラムもキチンとREPLで書いた方がいい。
そして「プログラミング初学者に対して最初のプログラムになり得る」と言う事は、プログラミング経験者にとっては「未知のプログラミング言語を使った最初のプログラム」として適した題材になり得る、って事だ。
要は「リファレンスを調べながらその言語の概要を知る」には良いプログラムなんだよ。
ここにサンプルとしてRacket(Lisp)で書いたコードPythonで書いたコードを挙げておく。両者共基本ロジックは同じだが、細かいトコでは当然違いは出る。
そしてこれらは「未知の言語」に触れた際に、どういうモノの存在をリファレンスでチェックすればいいのか、言わばチェックシート的な役目を果たす。

  1. 連想配列の類のデータ型は存在するのか?そしてその使い方は?
  2. ユーザー定義型はあるのか?そしてその使い方は?
  3. データ型の型変換の方法は?
  4. 条件分岐の代替でパターンマッチはあるのか?
  5. 条件分岐は文なのか、それとも式なのか?
  6. 条件分岐が文だった場合、三項演算子的な代替案はあるのか?
  7. 例外を投げる方法は?
  8. 反復はどういう書き方がスタンダードなのか?
  9. プログラムのエントリポイント記述はどうなってるのか?
  10. 例外処理はどうなってるのか?
全部で10項目程度だが、結構「実際プログラムする際に必要な機能」が網羅されてると思う。「全く知らない言語」で何をどのように書けばいいのか、とリファレンスを調べる際に役立つ指針となるだろう。

RubyだとREPLで組み立てた「数当てゲーム」はこういうコードになるだろう(※9)。
パッと見、「大枠の構文」はPythonに似てはいるが、endだらけだ、ってのが感想になると思う(笑)。
ぶっちゃけ、Rubyを気に入るか気に入らないか、の差は、上にも書いたけど、この大量のendに耐えられるか否か、だろう(笑)。汎用言語だと昨今見かけなくなった形式だが、一方、MATLAB等のニッチな言語ではこういう形式を採用しているのも多い。
Rubyにはハッシュテーブルがある。そして驚く事にRubyにはシンボルがある、んだ。
結果、Pythonの辞書型と違って、Lisp同様、キーや値にシンボルを与える事が出来る。MatzLispの面目躍如だ。
一方、Rubyでは「ソースのどこからでもアクセス出来る」大域変数は$から始める、と言うルールがある($message)。これはちと嬉しくないが、恐らくPerlから導入した文法だろう。しかし、Pythonのように「ローカル関数から大域変数へアクセスする」際に変数をglobal宣言をする、よか遥かにマシだろう。少なくとも、Lispでは文法ではないが、大域変数には耳あて法(*message*)を用いる慣習があるので、この辺のRubyの「文法」は意外と気にならんだろう。
Rubyには構造体がある。RubyはPythonと違って「完全な」オブジェクト指向言語だが、通常のクラスを使う程でもない場合、代替手段として簡単な構造体が使える、ってのは良い事だ。また、RubyはLispと同様、明示的なreturnがなくても「最後の作業の値を返す」性質があり、結果、構造体生成でnewを使おうが何だろうが、勝手に「生成した値を返す」んで凄く嬉しい。returnを書きまくるのは面倒臭いから、だ。
Rubyの入力関数は通常getsで、名称も出力putsと対称的で非常に良い。おすぎとピーコだ(違 
getsはReturnキーを叩いた事により生じた改行文字まで含めた文字列を返す。

irb(main):001:0> gets()
hoge
=> "hoge\n"

従って、通常は文字列末尾の改行文字を削除するchompと組み合わせて使う。

irb(main):001:0> gets().chomp
hoge
=> "hoge"

数字の文字列を整数に変換するにはto_iメソッドを用いるが、欠点は「普通の文字列」を変換しようとして失敗すると0を返してくる辺り、だ。偽値が帰ってくるわけでもなく、例外が投げられるわけでもない。「本当にその文字列が"0"」だったのか、数字じゃない文字列だったのか見分けがつかないんだ。

irb(main):001:0> "hoge".to_i
=> 0

このゲームの入力の想定は1〜100だったから良かったようなものだ。
Rubyにはパターンマッチもある構造体には対応してないらしく今回は使用を見送った。構造化代入が出来なければ使う必要がないから、だ。
Rubyでの条件分岐if〜elsif〜else〜endで、実は文ではなく式だ。つまり、Pythonと違ってその構文自体が値を返す。従ってRubyには三項演算子的なモノは必要ない。厳密な意味だと三項演算子を備えてるが、Pythonのような意味はなく、単なる構文糖衣に過ぎない。
この辺の制御構造の扱いもモロLispって言って良く、好感が持てる。なお、PythonではelifだがRubyだとelsifだ。一文字多い。紛らわしいんで気をつけよう。
Rubyでも例外を投げるには良くあるraiseを使う。ただし、フツーは「何らかの例外と言うデータ型を投げる」んだけど、Rubyでは単なる文字列を投げても良いようだ。っつーかその辺、言語処理系が面倒を見てくれる、っつーか。
Rubyは豊富な反復子を備えている。Pythonは内包表記に集中してるが、Rubyはデータ毎に用意していて、「コンテクストが変われば表現法が変わって当然」と言う立場に立ってるようだ。
REPLのような無限ループをおこなうのなら単にloop doと言う形式に則った方がいいだろう(※10)。
Rubyの例外処理はちょっと珍しいbegin〜rescue〜endと言うキーワードの連鎖になってる。ただ、処理の仕方そのものは、PythonやJavaと大差ない。この辺は大丈夫だろう。

以上が、Rubyの「ザーッと見た」特徴だ。当然「この形式が好き」とか「嫌い」とか出てくるだろう。

続いてJavaScriptはこうだ。と言うか、ゴメン、半分くらい違う。っつーかインチキだ。
いっつも書いてるが、実はJavaScriptには入出力がない(※11)。よって、スタンドアロンのSpiderMonkeyをアテにして書いていて、その拡張を用いている。readlineとかconsole.logと言うのがそれら、だ。これらはECMAScriptの仕様には含まれていない。
よって、上のソースコードで言うと、いわゆる「JavaScriptのプログラム」と言うのはEval(world_go)となり、これがブラウザに搭載されたWeb APIでHTMLとやり取りし、Webページに結果を動的に表示するわけだ。
また、JavaScriptにはPythonのsys.exitにあたる機能がない。言い換えると作ったプログラムを終わらせる方法がないんだ。これも当然と言えば当然で、そもそもJavaScriptプログラムを終了するにはブラウザでページを閉じると言うのが前提で、JavaScript側から勝手にページを閉じれたら困っちゃうでしょう、って話になる。
結果、無理矢理例外を送出して、プログラムを「エラーメッセージ付きで」終了させざるを得なかったわけだ。
他にも、JavaScriptは型変換がいい加減で、数値と(文字列である筈の)数字間の比較・計算が可能だ、と言う厄介な欠陥がある。これはプログラミング素人は「データ型に関して厳密さを嫌う」と言う仮定で取り入れられた機能なんだけど、お陰で厄介なバグが出る原因にもなっている。
まぁ、JavaScriptはあくまでおまけなんで、ここで終了しよう。Python/Racket/Rubyのコードと比較検証してみて欲しい。色んなJavaScriptの「特徴」も分かるんじゃないか。

いずれにせよ、とある言語の「性能」とか「機能」は、もし貴方が既に一個でも(真の高級)プログラミング言語を使いこなせてたら(※11)、「数当てゲームを書く」事によってリファレンスから大体のトコが分かる筈だ。
そうすれば、もっと的確に「この言語が好き」とか「この言語が嫌い」と言えるようになるだろう。
今回は「正しい言語の嫌い方」に付いての指南だ(笑)。

※1: もっとも、Prologみたいに、過去JIS規格が制定されてたのに、人気が無くなって改定せずに消える言語も確かに存在する。

※2: 実はPythonには公式実装以外にも複数実装が存在するが、公式に権威ある仕様があるわけではないので、結果それらの実装は基本的に実験的実装の域を出ない。

※3: Google Chromeで動いてるのがV8Firefoxで動いてるのがSpiderMonkeyと言う名称の実装。
Microsoftの実装名は知らんが、過去「Internet Explorer」の頃はJScriptなるJavaScript互換の処理系とされていた。今のEdgeだとひょっとしたらそのまんまTypeScriptが走ってるのかもしんない。

※4: 正確にはWikipediaが載ってるMediaWiki。他にも、日本で人気があるPukiWikiなんかもPHPで書かれていて、少なくともWiki(WikiWikiWebの略称)と言うWebアプリ分野ではPHPが勝ってる、と言って過言ではない。

※5: いつぞや書いたが、「UNIX」ってOSの特色は基本的に「文字列処理」にあり、結果、UNIXサーバーを使った「Webアプリ」と言うのは何だかんだ言って「GUIアプリ」を作ってるんじゃなくって「文字列処理だらけ」のアプリと言うのが基本だ。
Perlは文字列処理特化言語って言って良い程の性能があり、また、Rubyも元々はかなり「文字列処理」に寄っていた。

※6: 事実、Rubyを使用可能としているレンタルサーバーは無料・有料に関わらず多い。今はどうだか知らんが、かつてはPythonが使用出来るレンタルサーバーを見つけるのは至難の業だった。

※7: 余談だが、以前、珍しくエロゲを買った事があって、その謳い文句は「エロシーンは全編アニメになっています!」だった。
購入してインストールフォルダを覗いてみると、ビデオフォルダがあって、調べてみたら拡張子は変えてたが実質全部mp4の動画で、VLCで再生してみたらゲームをプレイする前にウリのアニメだけは全部観れちゃった、って事があった(笑)。
このように、「コンパイルして全部実行ファイルに纏められる」形式じゃないと、ソフトウェアを売る商売だと色々とマズいんだよ(笑)。ADVなのにシナリオを全部読めちゃう、とか(笑)、フリーソフトウェア/オープンソースは技術者に対しては良くても、Windowsのような「ソフトウェア販売」を重視してるOSだと色々と不都合がある。

※8: 厳密に言うと、「R言語」と言うモノは存在しなく、C言語を開発したAT&Tの作った「S言語」の方言か、あるいはS-PLUSと言う言語処理系の(不完全な)クローン、って考えた方が正しい。
しかし、Rの内部的な「実装」はオリジナルのSと違ってSchemeの影響を受けている。
つまり、「Cの皮を被ったLisp」と言う意味ではRもそうなんだ。

なお、統計分野で、Rがポピュラーになる前のフリーソフトウェアと言えば、XLISP-STATと言うのが有名で、この分野でもLispはブイブイ言ってたわけだ。
また、XLISP-STATの開発者、Luke Tierneyは後に、Rの開発陣に合流している。

※9: 僕個人はPythonはまぁ得意な方かもな、とは言えるけど、実の事を言うとRubyそのものには明るくない。
それは「Rubyを嫌ってきた」わけじゃなくって、Python・Rubyに関わろうか、と思った時期(2000年代末)だと、Pythonが日本では全く人気が無く、出版された本が少なく、かつ安価で古本が得られた事。
一方、Rubyは定番本は高く、値崩れしづらく、大量の面白い本が色々と出まくってた時期だったんだ。結果、貧乏性だったんでRubyまで手が出なかったんだよな。
今、Rubyの人気が落ちてきたとして、「良かった」とするなら、かつて高額でしか入手出来なかった本が今なら安価で入手出来る辺りだろうか。

※10: そもそもRubyだとforwhileの出番そのものが少ない模様だ。
この辺が、「古典的なforwhileにこだわる」Pythonicな連中とRubyistの違いだ。

※11: 入出力は副作用なんで入出力がないJavaScriptは「正しい関数型言語」だとは言える(謎

※12: 当然ここにはC言語は含まない。C言語から「C言語に無い機能」を読み解くのは不可能で、C言語脳には「全部が難読の言語」になるから、だ。
C言語脳のスコープの範囲はせいぜいJavaまで、となる。
  • Xでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

最近の「プログラミング」カテゴリーもっと見る

最近の記事
バックナンバー
人気記事