khurata’s blog

khurata’s blog

さまざまなプログラミング言語(その2)スクリプト言語編

(もともと「Yahoo!知恵袋」の「知恵ノート」だったものを転載しています)
(最終更新日時:2017/4/19)投稿日:2014/1/21

はじめに

 優に数百を数える、多種多様なプログラミング言語……本ノートでは、それらのうち、特に「スクリプト言語」と呼ばれるものを、およそ年代順に概観します。
 コンパイラ言語や、他の代表的なインタプリタ言語については、知恵ノート「さまざまなプログラミング言語(その1)」 https://khurata.hatenablog.com/entry/2019/04/04/073850 をご覧下さい。

 

スクリプト言語とは

 各スクリプト言語について概観する前に、そもそもスクリプト言語とはどういうものであるのかを説明しておきたいと思います。

注意
 scripting language もしくは script language は、日本では light-weight language軽量言語」とか、頭文字を取って LL などとも呼ばれます。
 LL の「軽量」は、日本では、その言語を使ってプログラムを作る労力が軽い、という意味で使われていますが(一般的に、人間がラク出来るプログラミング言語は重い動作になり、軽く動作するプログラミング言語は人間がラク出来ない)、欧米ではむしろ逆の意味であり、LL という言葉は「言語仕様が軽量である」とか、「コンピュータの負担(たとえばメモリ消費量)が軽量である」、という意味で使われています。 つまり、欧米における LL の代表は C であり、ほとんどのスクリプト言語は LL だとは考えられていません。

 scriptスクリプト」は、「脚本」とか、「手書き文字」といった意味です。

 コンピュータを使うためには、何らかのプログラムを作らねばなりませんが、実用的で、きちんとしたプログラムを作るのは、それなりに大変です。 出来合いのプログラムを、ただ利用するだけなら、簡単ですし便利ですが、単一のプログラムだけでは目的が達せられず、いくつかのプログラムを続けて実行して「1つの仕事」をしたい、という事が、ままあります。

 こういう場合、「複数の機能を持つ新しいプログラム」を作るという選択もありますが、「複数のプログラムを続けて実行する、という動作を自動化する」、という考え方もあります。

 複数のプログラムを続けて自動実行するには、「プログラムを呼び出すプログラム」を作れば良いでしょう。 これはもちろん、コンパイラ言語でも作れるのですが、呼ばれる側のプログラムが充分高速であれば、呼ぶ側のプログラムは、さほど高速でなくてもほとんど支障はありません。

 また、「いくつかのプログラムを続けて実行する」という手順においては、各プログラムに与える値を変えていきたくなったり、「ちょっとこっちのプログラムも試してみよう」といった細かい変更要望が出てくる事がよくあります。

 つまり、「プログラムを呼び出すプログラム」は、多くの場合、インタプリタ言語で作る方が、適しているのです。

 このような事情・要請が有って、「プログラムを呼び出すプログラムを作るためのインタプリタ言語」というものが生まれました。 そして、「プログラムを呼び出すプログラム」は、「サクッと書いてサクッと使う」という使い方が多かったため、「緻密なプログラム」ではなく、「手書き(=ラフに、カジュアルに)で手軽に書ける」、「プログラム達という『俳優』を配する脚本である」という感覚から、「スクリプト」と呼ばれるようになりました。

 最初に広く普及したスクリプトは、UNIXシェルスクリプトです。

 shellシェル」とは、OS が提供するプログラムの1つで、人間と OS の仲立ちをするためのものです。
(参考 https://khurata.hatenablog.com/entry/2019/04/04/053104

 UNIX では、シェルに対してコマンド文字列を1つ1つ打ち込む事によって、目的のプログラムを1つ1つ指定・起動します(コマンドは、プログラムの名前と、プログラムに与える値(パラメータ)から成っています)。

 いくつかのプログラムを続けて使いたい場合は、コマンドを続けて記述したテキストファイルを作り、それをシェルに与えます。 そうすると、シェルはそのテキストファイルを読み取り、中に書かれたコマンドを順次実行してくれます。
 実行する内容を変えたい時は、テキストファイルを書き換えれば良いだけです。 このテキストファイルこそが、まさにシェルスクリプト、「シェルに与え、シェルが実行するスクリプト」なのです。

 シェルスクリプトは大変便利だったため、後に出た OS の多くが、シェルにスクリプト実行機能を備えました。 MS-DOSWindowsコマンドプロンプトで使える「バッチ」も、UNIXシェルスクリプトには遠く及ばない貧弱さではあるものの、シェルスクリプトの一種です(後述)。

 現在、多くのスクリプト言語に共通する特徴として、「処理系がインストールされているプラットフォームでのみ動作する」、「ハードウェア寄りのプログラミングは苦手」、「文字列処理が得意」、「インタプリタであり処理速度は期待できない」、という点が挙げられます(例外もありますが)。

 

shell script「シェルスクリプト

 MS-DOSWindows のバッチもシェルスクリプトであるが、単に「シェルスクリプト」と言う場合、通常は UNIX(1971年公開)や Linux(1990年代~)のシェルスクリプトの事を指す。

 UNIXシェルスクリプトは、シェルにコマンド群を与える事から始まったが、その後、長年にわたって様々な改良が重ねられた結果、それなりに強力なプログラミング言語になった。 「UNIX/Linux を使う最大の理由の1つは、シェルスクリプトだ」と言う人がいるほどである。

 また、UNIX/Linux のシェルには、様々な「派生」があり、シェルスクリプトも、シェル毎にいくつかの種類や方言が存在する。 主なものとしては bash csh が挙げられる。
MS-DOSWindows もシェルの「着せ替え」は可能だが、ほとんど行われていない)

 

AWK「オーク」

 1977年に UNIX 上で作られた、文字列処理を目的としたスクリプト言語

 もともとは sedgrep などの文字列処理ツールを拡張したものに過ぎなかったが、その簡便さゆえに人気が高く、拡張・強化が繰り返された結果、単なる文字列処理ツールにとどまらないプログラミング言語となった。

 正規表現連想配列の便利さは、AWK 登場当時に有った C などのコンパイラ言語を圧倒した(この強力さは、後に Perl へと受け継がれた)。 もちろん処理速度ではコンパイラ言語には遠く及ばないものの、さほどシビアな高速処理が必要でない場面では好んで使われた。

 後に、MS-DOS など他の OS にも広く移植され、多くの派生 AWK が生まれた。

 

batch「バッチ」

 現在、「バッチ」と言えば、拡張子 .bat の、MS-DOS(1981年~)や Windows(1985年~)でしか使えない「コマンドの羅列」ファイルが連想されるが、「MS-DOSWindows のバッチ」は先に述べたようにシェルスクリプトの一種であって、本来の意味での「バッチ」(一括型処理)ではない。

 batch とは「ひとまとまり(の物)」という意味であり、元々は「パン1斤」とか、「カード1束」を表す言葉であった。

 高価で巨大な「メインフレーム」と呼ばれるコンピュータが主役だった頃、つまり1960年代から1980年代にわたり、メインフレーム OS に仕事をさせる方法には、主に「対話型処理」と「一括型処理」の2つがあった。

 conversational processing対話型処理」(もしくは会話型処理)は、人間が1つずつコマンドを与え、それを OS が逐次解釈して仕事を進める方式である。 しかし、当時コンピュータは大変高価であり、それを人間の応答速度に合わせて使うのは、非常にコストパフォーマンスが悪いと考えられていた。

 対して batch processing一括型処理」は、あらかじめコマンドの羅列をまとめておき、そのひとまとまりを OS に与える方式である。 このひとまとまりの事を「ジョブ(もしくはバッチジョブ)」、その一部を「ジョブステップ」などと呼ぶ。

 この「ジョブ」を記述するための言語が JCL(job control language)である。 JCL はコンピュータの機種毎に多少の違いがあるが、1つの JCL に通じていれば、他の JCL を理解するのは難しくない。

 一括型処理は、対話型処理のような無駄が少ない上、何日もかかるような大規模な処理を人間が付いていなくても連続自動運転できる利点があるが、途中でエラーがあると停止してしまい、柔軟な対応が出来ないのが欠点である。

  MS-DOSWindows の「バッチ」は、上記囲みで説明した「バッチ」から、名前だけ拝借したものである。 いくつかのコマンドをひとまとめにした、という意味では、「バッチ」と言えなくもないが、OS から見た仕事の単位、その仕組みや成り立ち、運用のスタイルなどから考えると、メインフレームの「一括型処理」とは全くの別物であり、あくまで「MS-DOSWindowsシェルスクリプト」である。
Microsoft による「軽率な名前の拝借」は、右記の質問者のような混乱を生んでいる。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1336230918

 

HyperTalk「ハイパートーク

 1987年に発表された、Macintosh 用の GUI プログラミングツール HyperCard で使われるスクリプト言語。 なお HyperCard は、コンシューマー(一般民間)向けの商用ソフトウェアとしてはじめてハイパーテキストを実現したプログラミング環境でもある。

 HyperCard 上の「プログラム部品」(カードと呼ばれる)には、それぞれの部品の動作を示すためのプログラムを付属させる事が出来る。 このプログラムを記述する言語が HyperTalk である。 Apple は、VisualBasic が1991年にやったような事を、4年も先んじて実現していたのだ。

 

Tcl「ティクル」

 1988年頃、アプリケーション組み込み用スクリプト言語として開発された。 当時、アプリケーションの機能拡張・設定用に、各アプリケーションに組み入れられていたスクリプト言語は、アプリケーションそれぞれで独自のものであったため、それを共通化しようというのが Tcl の開発動機である。

 その後、Tk という GUI ライブラリと組み合わせた、Tcl/Tk と呼ばれる使い方が人気を呼び、Tcl はアプリケーション組み込み言語にとどまらない、GUI プログラミング言語として定着するかに見えた。

 しかし、Tk の方は他の言語と組み合わせた Perl/TkRuby/Tk といった使い方が生まれたものの、「本家本元」である Tcl は、2013年現在、あまり人気があるとは言えない。

 

Perl「パール」

 1991年に公開された汎用・文字列処理用スクリプト言語。 もともとはレポート作成ツールであったが、その後、CsedAWK などのいくつかの言語の機能・特徴を採り入れ、文字列処理を強力にこなせるスクリプト言語になった。

 インターネットが普及するにつれ、文字列処理を主とするサーバサイドのウェブプログラミングに好んで使われるようになり、「CGI と言えば Perl」という構図が一時期強く定着した。 この事が、他のスクリプト言語もサーバサイド・プログラミングに使っていこうという動きの端緒になった。 Perl は「サーバサイド・スクリプトの始祖」だと言える。

 「強力な文字列処理を簡易に実現する」事にかけては大変に進化している。 今となっては古い言語でありながら、「やりたい文字列処理をすぐに書ける言語」として根強い人気を誇り、ほとんどのプラットフォームに処理系が存在する。

 有志により様々なライブラリが開発・頒布されており、オブジェクト指向も導入され、処理速度の遅ささえいとわなければ、非常に広い用途に対応出来る。
(近年は PHP にかなり押されてしまった感があるが、ウェブアプリケーションに限らない、より広い用途においては、もっと「良い地位」を占めても良いのではないかと個人的には思う)

 

Python「パイソン」

 1991年頃に公開された汎用スクリプト言語。 インストールするだけで、ほとんどの機能が使えるようになるという思想「Battery Included」(電池が付属しています)に基づき、XML、ネットワーク、GUIDB、などの多岐に渡るライブラリが標準で装備されている。
LinuxPython に至っては OS システムコールするためのライブラリまで付いている)

 他の多くの言語が、ブロック構造を記述するために特定の記号を使うのに対して、Python は見た目のインデント字下げ)がそのままブロック構造になる。

 欧米では Perl と並んで、好んで使われるスクリプト言語であり、欧米 Linux コミュニティの標準言語の1つみたいにもなっている。 しかし日本国内では必ずしも人気があるとは言えない(Ruby があるためかも知れない)。

 2007年頃には、JIT コンパイルJavaScript の項を参照)機能を持つ PyPy「パイパイ」という「亜流」が発表された。 本家 Python の約5倍の処理速度だそうである。

 

AppleScript「アップルスクリプト

 1993年に発表された、Mac OS 専用のスクリプト言語。 HyperCard で使う事も出来る。

 Mac OS 上で動作するプロセス(アプリケーション)を連続して実行するという主目的はシェルスクリプトに近いが、AppleScript の作成方法は Mac OS のバージョンにより異なっており、シェルスクリプトのようにプレーンテキストとして作成出来るようになったのは Mac OS X からである。

 

Lua「ルア」

 1993年に発表された、C プログラムに組み込んで使うためのスクリプト言語。 C のような「ガチガチのコンパイラ言語」が不得手とする連想配列や文字列処理を「側面支援」する。 特にゲーム製作者に好んで使われるとされるが、実際の適用例はゲームだけにとどまらず非常に幅広い。

 他の同時代のスクリプト言語と比べて言語仕様が簡素で、実行が高速である(変数に型のないスクリプト言語では最速と言われている)。

 

PHP「ピーエイチピー」

 HTML に組み込んで使う「サーバサイドの簡易 HTML 拡張言語」として1995年に作られたスクリプト言語。 HTML に書き足して動的なウェブページが作れるという簡便さにより、Perl に取って代わるサーバサイド・スクリプト言語の地位を獲得した。

 後のバージョンでは、HTML 拡張言語の域を脱しただけでなく、相次ぐ機能拡張により、大規模なサーバ・アプリケーションの UI 構築にも充分耐える言語になっている。

 もともとの簡便性を今も引き継いでおり、習得しやすいので非常に人気が高い。 2013年現在、日本のウェブシステムの UI は、ほとんど PHP で作られているといっても言い過ぎではない。

 

Ruby「ルビー」

 1995年に発表された汎用スクリプト言語。 ここで紹介するスクリプト言語の中で、唯一、日本人の個人により作られたものである。 開発者いわく、「プログラミングのストレスを極力少なくするような言語仕様にした」そうだが、開発者個人の思想の「押しつけ」と見る向きもある。

 記述量が少なく済み、プログラマ側の労力は少ないが、反面、コンピュータによる実行速度は、他のスクリプト言語よりやや劣ると言われる。

 PerlPHP が「後付け」でオブジェクト指向を組み入れたのに対し、Ruby始めからオブジェクト指向言語である。
 2004~2005年に、Ruby による実地的なプログラミング記述の「パターン」を、より少ない記述量で書けるようにしたライブラリ(※) Ruby on Rails が発表されたことにより、国内外で一気に普及した(こういう芸当が出来たのも、Ruby が始めからオブジェクト指向だったからである)。
 Ruby は、用途面から見れば PerlPython と競合する―しかも後発である―が、それでも生き残り続けているのは、Ruby on Rails(とオブジェクト指向)の功績が大きい。

※実のところ、Ruby on Rails は単なるライブラリと言うよりも、実地的プログラミングの知見を集積し利用可能にしたフレームワークと言うべきである。

 「方言」として派生した Ruby の中には、JIT コンパイルJavaScript の項を参照)で高速化を図ったものもいくつかある。

 

JavaScript「ジャヴァスクリプト

 LISP の「方言」として独立した Scheme 言語をウェブブラウザで動くようにしたスクリプト言語 LiveScript(1995年~)として誕生した。 後に、機能追加や規格標準化が進んで ECMAScript となった。 現在の JavaScript は、ECMAScript の1実装という位置付けである。
 ちなみに Flash の主要言語である ActionScript(後述)も ECMAScript の1実装であるし、Windows で使える JScript(後述)も同様である。

 なお、JavaScript という名称は、当時流行していた Java にあやかっただけであり、Java とは全く関係無い、違う言語であるので注意されたい。
(誰かが「鯛」と「鯛焼き」くらい違うと言っていたが、本当にその通りである)

 当初は、HTML に組み込んで使う「ウェブブラウザ用の簡易言語」に過ぎなかったが、規格標準化が進んだ結果として、Adobe Photoshopテキストエディタなどの様々なアプリケーションにも組み込まれる汎用スクリプト言語になった。

 登場してから数年の間は、「クライアント(ウェブブラウザ)側で HTML をイジるだけの言語」として使われていたが、Google 社が「Google マップ」で披露した Ajax というプログラミング技術で「主役級」として使われた事により、ウェブアプリケーション構築用言語として一躍脚光を浴びた。

 Ruby と同様に、JavaScript は始めからオブジェクト指向言語である。 その拡張性を利用して、prototype.jsjQuery などの優れたライブラリが作られ、これらが Ajax と共に JavaScript の利用を大きく後押しした。 LISP の「大きな拡張性と思想」が、約40年を経て、やっと実用的になった、と言えるかも知れない。

 2006年頃からは、JIT コンパイルという機能が多くの JavaScript 処理系に搭載された。 JIT とは Just In Time の略であり、「その時その場で」という意味である。 これは、スクリプト実行時に、「勝手に」コンパイルする事によって、スクリプト言語の使いやすさと、コンパイラ言語の高速さを両立するという機能である。

 近年は Node.js という、サーバサイドで使える JavaScript が「C10K問題を克服した」などの点で注目を集めつつある。 HTML5 の主力開発言語でもあり、今後さらに注目され発展していくだろう。

 

ActiveScript「アクティブスクリプト

 名前が似ているため、ややもすると混同してしまいがちだが、ActionScript(後述)とは全く違うので要注意。

 Windows 98(1998年~)以降の Windows は、WSHWindows Script Host)と呼ばれる「スクリプト言語の実行環境」を持っている。 ActiveScript は、この WSH 上で実行できるスクリプト言語総称である。

 Windows が標準で持っている ActiveScript には、JScriptVBScript(いずれも後述)とがある。

 また、Microsoft 以外から、ActiveScript として動作するスクリプト言語が数多く発表されている。 たとえば ActivePerlActivePython は、PerlPython を ActiveScript として動作するようにしたものである。

 

JScript「ジェイスクリプト

 Microsoft が、JavaScriptWSH に移植(その際、独自拡張)したスクリプト言語。 Windows に移植された ECMAScript である、とも言える。

 WindowsInternet ExplorerJavaScript の有効・無効を設定するには、「アクティブスクリプト」の有効・無効を変更する、という、一見わけの分からない事をしなければならないが、これは、「Internet Explorer で使える JavaScript」は「JScript(という ActiveScript)」だからである。

 他ブラウザの JavaScript に比べると、独特の「方言」が多いため、ウェブ・プログラマからは好まれていない。 ActiveX オブジェクトが使える強みはあるが、Windows でしか使えないので、このせっかくの特徴はウェブ・アプリケーションにおいては無力である。

 また JScript は、Windows 8/RT 以降の「Windows ストアアプリ」開発言語としても使われる。

 

VBScript「ヴイビースクリプト

 VisualBasic っぽい簡単な文法で、ActiveX オブジェクトが扱える強力な WSH 専用スクリプト言語

 Windows のほぼ全ての機能が使えるため、企業の Windows PC 管理者にとって必須のスクリプト言語となっている。 実は JScript も機能的には同等なのだが、JScript は HTML と共に IE で使うというイメージが強く、VBScript のような使われ方はあまりされない。

 また VBScript は、VisualBasic 近縁の言語(VBA など)と似ており、関連付けて学習しやすい。 Windows ヘビーユーザなら知って損は無いスクリプト言語であろう。

 

ActionScript「アクションスクリプト

 名前が似ているため、混同してしまいがちだが、ActiveScript とは全く違う

 Adobe Flash の動作を記述するため、2000年に発表されたプログラミング言語。 実際にはコンパイラ言語であるが、言語仕様面では ECMAScript の拡張であるため、スクリプト言語の範疇として扱われる。

 当初は、ECMAScript として「素直」なプロトタイプベースのオブジェクト指向言語だったが、後に Java 的なプログラム記述を目指して、クラスベースのオブジェクト指向っぽい言語に変わっていった。

 2013年現在、Apache Flex(旧 Adobe Flex)の主力言語でもある。

 

Windows PowerShell「ウインドウズパワーシェル」

 WSH に取って代わるための Windows 管理用スクリプト環境として、Windows 7(2006年~)から標準搭載された。 WSH に比べて機能面では格段に進歩している。 ただし、非常に多機能であるため、学習は容易ではない。

 

おわりに

 筆者の力不足から、取り上げる事の出来なかったスクリプト言語も多々ありますが、比較的よく話題にのぼる言語の概観としては、こんなものではないか……と思います(現在9907字)。
(転載以上)