The ascent of scripting languages
The ascent of scripting languages
When you say “scripting language” these days, most programmers think of Perl, Python,
Ruby, PHP, ASP, or JavaScript. But the history of scripting languages starts much
earlier than any of these.
今日、“スクリプティング言語” (scripting langauge) といったとき、大部分のプログラマー
は Perl や Python、Ruby、PHP、ASP、JavaScript といったものを思い浮かべるでしょう。しか
しスクリプティング言語の歴史はこういった言語よりもはるかに昔に始まっていたのです。
The Early Days: JCL
At least as early as 1964, programmers realized that having to do everything in code,
including copying files, was too tedious. So IBM introduced a “job control language”
(JCL) on the OS/360. In this language, you could copy a file from one location to
another using only 9 lines (punched on cards, of course), as compared to writing a
Fortran programming that would be much more complex. JCL was also used to run
programs in batch mode, specify their parameters, and branch based on their result.
少なくとも1964年の初めには、プログラマーたちはファイルのコピーも含めたすべてのことをコ
ードで行う必要があることがとてもうんざりすることなのを認識していました。そこで IBM は
OS/360 で “job control language” (JCL ジョブ制御言語)を導入しました。この言語ではよ
り複雑なフォートランプログラムを書くのに比べると、たった9行だけでファイルをある場所か
ら別の場所へコピーすることが可能でした(もちろんカードにパンチします)。JCL はバッチモー
ドでのプログラムの実行にも使われましたプログラムに対するパラメータを指定し、その実行結
果に基づいて分岐するといったことを行いました。
I remember when I was a lowly operator on a Data General Eclipse system, and I needed
to load the contents of a tape into a file on an IBM 4331 in another department. I
strolled over to their operations window with the tape in hand. When I finally got an
operator's attention, I asked him to “please run this tape into a disk file for me.”
He stared at me and said, “Where's your JCL?” I replied, “JC who? On the DG, I
can just enter a command on the console to do that.” He looked smug and said, “
That's impossible. You can't read a tape without JCL.” So, I had to research the
required JCL and punch the cards. Which goes to show how command line interpreters on
minicomputers had already advanced beyond mainframe batch jobs by the late seventies.
わたしは自分が Data General Eclipse system の下っ端オペレーターであったときにあるテー
プの内容を別の部署にあった IBM 4331 のファイルにロードしなければならなかったときのこと
が忘れられません。わたしはそのマシンの操作ウィンドウの前をテープを抱えてうろうろしてい
たのですが、ようやくのことで一人のオペレータの注意をひいて彼に尋ねました。「申し訳ない
のですが、このテープをファイルに移してもらえないでしょうか」彼はわたしをにらんでこう言
いました「あなたの JCL はどこですか?」わたしはそれにこう答えました「JC 誰ですって? DG
では、コンソールでコマンドを入力するだけでできることなんですけど」彼は勝ち誇った風な様
子で言いました「そんなことは不可能ですね。JCLがなければテープを読むことはできませんよ」
ということで、わたしは必要なJCL を調べて、その内容をカードにパンチしなければならなかっ
たのでした。1970年代の終盤には、ミニコンピューター上のコマンドラインインタープリターは
メインフレームのバッチジョブをすでに凌駕するものであったのです。
Scripting Command Line Interpreters
Command line interpreters, such as DG's CLI, DEC's MCR and DCL, and more famously
Unix's Bourne Shell not only accepted simple commands to perform (what at the time
seemed like) complex operations, they also provided a way to execute a series of those
commands stored in a file. DG called them “macros”, DEC called them “command files”,
and Unix called them “shell scripts”. These early scripting languages also provided
local variables and flow control mechanisms, so it wasn't long before they began to be
used for even more complex operations that used to require compiled programs.
DG の CLI、DEC の MCR やDCL、そしてさらに有名な Unix の Bourne Shell などといったコマ
ンドラインインタープリターは(当時としては、ですが)複雑なオペレーションをこなすための単
純なコマンドを受け付けるだけでなくそういったコマンドの並びを格納したファイルを実行する
方法も提供していました。DG はそういったファイルを「マクロ」(“macros”) と呼び、DEC で
は「コマンドファイル」(“command files”) と呼び、そして Unixでは 「シェルスクリプト」
(“shell scripts”) と呼んでいました。これら初期のスクリプティング言語はローカル変数や
フロー制御機構も備えていましたから、それらの言語がコンパイルされたプログラムを必要とす
るようなより一層複雑なオペレーションに使われるようになるのにもそれほど時間が必要ではあ
りませんでした。
When I was first introduced to Unix systems back in 1984, I was thrilled with the C
language, the Bourne shell, and powerful utilities like awk and sed. But there was
one thing that bothered me: their syntaxes were similar, but not identical － and the
overlap in problem domain was significant. I thought, wouldn't it be cool if you
could have one language that addressed the combined problem domain in a consistent
syntax? But I was too busy to do anything about it.
わたしが最初にUnixシステムを導入した頃の1984年に戻りましょう。わたしは C や Bourne
shell、そして強力なユーティリティである awk やsed を楽しんでいました。けれどもわたしを
うんざりさせるような一つのことがらがあったのです:これらの構文はどれも似たようなものな
のに、どうして全く同じではないのだろう －そして、問題領域でそれぞれがオーバーラップし
ていることも明白でした。わたしは考えました。一貫した構文でもって結びついた問題領域
(combined problem domain) に対処できる言語が一つあれば、それは cool じゃないだろうかと。
But I was too busy to do anything about it.けれどもそのときそこで何かをするにはわたし
はとても忙しかったのです。
Perl
A few years later, Larry Wall found the time to do something about it: the Perl
language. Perl combines the ease of shell scripting with powerful features borrowed
from C and various Unix utilities. Immediate and easy access to regular expressions,
lists, associative arrays, the ability to treat any value as a string, no need for
scaffolding (not even a “main()” declaration), automatic resource management, eval
(the ability to execute a string as code at runtime), and the ability to combine
different programming paradigms freely are some of the language's strengths that
combine to make “easy things easy and hard things possible.” And you can choose
from a number of ways to do the same thing, a principle known as TIMTOWTDI (There Is
More Than One Way To Do It).
数年ののち、
Larry Wall found the time to do something about it: the Perl language.
Perl は C や各種のUnixユーティリティから拝借した強力な機能を備えたシェルスクリプトを簡
単に使えるように組み合わせました。正規表現やリスト、連想配列 (associative arrays) にす
ばやく簡単にアクセスでき、任意の値を文字列として扱えて、scaffolding の必要はなく
(main() の宣言すらありません)、自動的にリソース管理を行い、eval (実行時にコードとして
文字列を実行する能力) があり,異なるプログラミングパラダイムを自由に組み合わせる能力は
“easy things easy and hard things possible” (簡単なことは簡単に、難しいことを可能に)
するために combine する Perl という言語の強み (strengths) です。
そしてあなたは TIMTOWTDI (There Is More Than One Way To Do It)
として知られる原則に則って、同じ事を行う複数のやり方の中から選択することができます。
Object-orientation can be a good approach for managing complexity, but languages that
force the use of object-oriented notation usually add unnecessary complexity to almost
every project. When Perl added support for objects, it did so in an optional way that
can be freely mixed with non-OO code so that complex modeling can be achieved when
needed, but otherwise not required. The syntax for objects was initially a bit of a
kludge, but that seems sufficiently remedied in Perl 6.
オブジェクト指向は複雑さを管理できる優れた手法ですが、オブジェクト指向的記述を強制する
言語は一般的にはほとんどすべてのプロジェクトに対して不必要な複雑さを追加するようなもの
でした。Perl にオブジェクトのサポートが追加されたとき、非オブジェクト指向コードと自由
に混ぜることができるようなこのため、オブジェクト指向なコードが必要となったときには複雑
なモデリングを achived 可能でしたがそれ以外のものは要求されませんでした。オブジェクト
のための構文は当初は少々見づらいものでしたが、Perl 6 で一新されたようです。
Tcl
About the same time (late 1980's), John Ousterhout created the TCL scripting language.
It's an interesting functional language in its own right, but its enduring
contribution to scripting languages has been the Tk, a framework for enabling
cross-platform graphical user interfaces that can be used from within many popular
scripting languages.
時を同じくして(1980年代終わり)、John Ousterhout は TCL というスクリプティング言語を作
り出しました。Tcl はそれ自体が interesting functional language ですが、スクリプティン
グ言語が Tk を得ることに貢献しています。Tk はクロスプラットフォームなグラフィカルユー
ザーインターフェースを可能とし他のポピュラーなスクリプティング言語の中で使うことができ
るフレームワークです。
Python
Guido van Rossum was also at work in the late 1980's on a new scripting language:
Python. Unlike Perl, Python's philosophy is that there should be only one clear way
to do something. This philosophical rigidity is reflected in the language's syntax.
Rather than curly braces to group statements, indentation (significant white space)
is used. Rather than a semicolon to terminate statements, the end of line is used.
These rules may prevent clever programmers from writing code that is easily
misunderstood, but they also limit flexibility of coding style.
Guido van Rossum も1980年代の終わりに新しいスクリプティング言語 Python の作業を進めて
いました。Perl とは異なり、Python の哲学は there should be only one clear way to do
something (何かを行う明快な手段はただ一つあればよい) です。この哲学は言語の構文に
rigidity に反映されています。複数の文をまとめるのにカーリーブレースではなくインデント
(空白を使って表されます) を用います。文を終端するのにはセミコロンではなく行末を使いま
す。これらの規則は clever なプログラマーたちが誤解されやすいコードを書いてしまうことか
ら守ります。しかしそれらの規則はまた、コーディングスタイルの柔軟性を制限することにもな
りました。
On the other hand, Python does not limit the choice of programming paradigm. It
readily supports structured, functional, object-oriented, and aspect-oriented
programming － and allows you to mix those styles.
一方で、Python はプログラミングパラダイムの選択を制限していません。構造化プログラミン
グ、関数型プログラミング、オブジェクト指向プログラミング、そしてアスペクト指向プログラ
ミングを readily にサポートしていて、さらにこれらのスタイルを混ぜることも許しています。
Python gave us the term duck typing (although some earlier languages also provided
forms of this). If a class provides the methods expected for an interface, then it
meets the requirements for that interface － whether or not it is derived from any base
class of that interface. The name comes from the duck test: “if it looks like a
duck, swims like a duck, and quacks like duck, then it probably is a duck”. In
Python, if an object implements the methods we want to call, then it qualifies as a
receiver. This seemingly simplistic form of typing easily enables polymorphism
without requiring inheritance － thus eliminating the need for complex inheritance
hierarchies.
Python はダックタイピング (duck typing。ただし一部の言語にはPythonよりも早くにこれを提
供していたものがありました)という用語をわたしたちにもたらしました。あるクラスがあるイ
ンターフェースで期待されるメソッドを提供しているのならば、そのインターフェースのベース
クラスから派生しているかどうかには関係なくインターフェースに対する要求を満たしていると
するものです。ダックタイピングと言う名前はダックテスト (duck test) から来ています:“if
it looks like a duck, swims like a duck, and quacks like duck, then it probably is a
duck”. (もしそれがアヒルような外見で、アヒルのように泳ぎ、アヒルのように鳴くのなら、
それはおそらくアヒルだろう) Python では、あるオブジェクトがわたしたちが呼び出したいメ
ソッドを実装していたならばそのオブジェクトはレシーバーとなることが許されます。これは継
承を要求することなしに、つまり複雑な継承の階層の必要性を取り除いて多態 (polymorphism)
を簡単に可能にする simplistic form のようなものです。
Ruby
I may not be qualified to write objectively about Ruby, because it's currently my most
favorite programming language. Yukihiro Matsumoto, affectionately known to the Ruby
community as “Matz”, released Ruby to the public in 1995. His design philosophy
focuses on creating a language for human programmers, rather than for the machine.
The result is based largely on Perl and SmallTalk, with nods to other languages. It
follows the POLS (“Principle of Least Surprise”) － so where it may be minutely
inconsistent, it usually does what the programmer expects. Ruby also embraces Perl's
concept of TIMTOWTDI － you can probably find eight or more ways to perform even the
simplest operation.
Ruby は現時点でのわたしの一番好きなプログラミング言語であるので、Ruby について
objectively に書くことができないかもしれません。Ruby コミュニティでは“Matz”として親
しまれている まつもとゆきひろ氏は1995年に Ruby を公にリリースしました。彼の設計哲学は、
プログラマーである人間のための言語を作るのであって機械のために作るのではないということ
に焦点を当てています。その結果は (nods to other languages しつつ) Perl と Smalltalk に
大きく影響を受けたものです。POLS (“Principle of Least Surprise” 驚き最小の原則) に従
い(そのために細かいところで一貫性を欠くこともありますが)、通常はプログラマーが予期した
ことを行います。Ruby は Perlのコンセプトの TIMTOWTDI も embrace しますあなたは単純な操
作一つに対してさえ八種類以上のやり方を見つけることができるでしょう。
Ruby is one of the more thoroughly object-oriented languages around. Almost anything
can be treated as an object, even literals － which provides amazing expressiveness.
Nevertheless, you aren't required to explicitly use classes at all, unless you want to.
If you define a function that isn't in a class, it actually extends the global Object
class. You don't have to be aware of that, and yet you can also use that fact to your
advantage.
Ruby はとことんオブジェクト指向をつきつめた言語の一つで、リテラルすらも含むほとんどす
べてのものをオブジェクトとして扱うことが可能です。これは amazing expressiveness をもた
らします。それでいて、あなたが望まない限りにおいてクラスの使用を強制されることはありま
せん。クラスに属さない関数を定義したとき、それは実際にはグローバルな Object クラスを
extend しています。あなたはそれを気にする必要はなく、それをあなたの advantage として使
うこともできます。
Ruby uses duck typing, like Python. Ruby also allows any class to be reopened and
extended. For instance, you can add your own methods to String and Integer, or
override the ones that are predefined. This makes most OO purists wet their pants.
Potentially it's a truly dangerous capability, but in the right hands at the right
time it can be amazingly powerful.
Ruby は Python と同様にダックタイピングを使っています。Ruby では任意のクラスを reopen
したりextend できます。たとえば、String クラスや Integer クラスにあなたの書いたメソッ
ドを追加することができますし、すでに定義されているものをオーバーライドすることも可能で
す。これはオブジェクト指向 purists を wet their pants させるものです。潜在的にこれはと
ても危険な機能ではあるのですが、正しい時と場所で使えば信じられないほど強力なものになり
ます。
Because of its great flexibility, Ruby is inherently multi-paradigmatic. It's
possible to write Ruby code that reads like Lisp, Java, or even Pascal. You can tune
for readability, performance, minimum code, cleverness, or just about any other
emphasis you'd like to achieve.
その great な柔軟性故に、Ruby はその本質からマルチパラダイム的です。そしてそれにより、
Lisp のように読める Ruby のコード、Java のように読める Ruby のコード、さらには Pascal
のように読める Ruby のコードすら書くことが可能です。あなたはこの能力で 読みやすさ
(readability) を向上させることができますし、パフォーマンスの向上やコードの最小化
(minimum code)、cleverness (巧妙さ?) を増すため、あるいはその他あなたが強調する
achieve したいものについて。
And since we've been talking about Ruby, now might be a good time to throw in a
continuation (pardon the pun).
わたしたちは Ruby についてはすでに述べましたから、
To be continued…
つづく。
There is so much more ground to cover, and I've probably already exhausted your
attention span. So, I'll continue this thread in a later post on the use of scripting
languages and the web. I have also neglected to talk about scripting languages
embedded in applications. There are many scripting languages that I won't be able to
cover, and many distinguishing features and capabilities that I won't have space to
discuss. But I hope you'll find this overview helpful.
This post is part three of a series on the history of programming languages. For the
first two parts, see:
* The Early History of Programming Languages
* An introduction to object oriented languages
