hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
カール・シューリヒト 略歴と業績
パウル・ファン・ケンペンの退団後、1943年から1944年までドレスデン・フィルハーモニー管弦楽団の第一客演指揮者を務めた。第二次世界大戦末期（1944年8月）には、アドルフ・ヒトラーが承認したゴットベグナーデテン－リストの最も重要な指揮者に含まれていたため、本国戦線を含む戦時中の派兵を免れた。1944年10月1日にシューリヒトはドレスデン・フィルハーモニー管弦楽団の首席指揮者に就任した。音楽評論家のカール・ラウフは、その年の7月に『ドレスドナー・ツァイトゥング』紙にカール・シューリヒトに関して陶酔的なコメントを書いている。彼を「我々の時代の最初の指揮者」の一人とみなし、ドレスデンの音楽文化について十分な見識を持っていることを証明しているとした。
カール・シューリヒト 略歴と業績
多くの音楽家が兵役に召集されたため、ドレスデンでは十分な練習をすることができなくなった。1940年代には、ナチス・ドイツ体制との相違が増大し、例えば、政治的圧力により1933年9月に離婚したユダヤ人の元妻 の海外移住を支援した。シューリヒトは1944年に収容所に送られることになり、知り合いのゲシュタポの兵士から事前に警告を受け、1944年11月にドイツを出国しスイスに亡命した。音楽ライターのフレート・ハーメルは、これはドイツからの追放に他ならないと語っている。編集者のトマス・カイルベルトは、シューリヒトの政権に対する態度を、国内亡命（Innere Emigration）とし、歴史家のマリアンネ・ブダーはトーマスカントルであるギュンター・ラミンの「困難な状況」と比較している。音楽学者ハンス・ハインツ・シュトゥッケンシュミットは、「好ましくない作曲家」を指揮していることに体制への抵抗を見出すことさえできるとした。一方、音楽史家のフレート・K.・プリーベルクは、シューリヒトが1944年までナチスの体制下で恩恵を受けていたとの見解から、彼の経歴をより批判的に捉えている。
カール・シューリヒト 略歴と業績
シューリヒトはスイスに移住し、1944年末にヴァレー州のクラン＝モンタナに定住した。ルツェルン音楽祭で知り合ったスイス人のマリア・マルタ・バンツとチューリッヒで結婚した。エルネスト・アンセルメ の誘いを受けてスイス・ロマンド管弦楽団を指揮し、数年間で60回以上のコンサートに出演した。マーラーやブルックナーを多く取り上げたことで、保守的な地方の音楽家の批判に囲まれた 。
1946年にザルツブルク音楽祭が再開された際、シューリヒトはウィーン・フィルハーモニー管弦楽団とベートーヴェン、ブラームス、ブルックナー、モーツァルトを演奏した。1955年3月、だらけたウィーン・フィルの演奏態度に腹を立てたシューリヒトは、ブルックナーの交響曲第9番を情熱的に指揮して、見事にオーケストラを立ち直らせた。こうしたことがあって、口さがないウィーン・フィルの楽団員もシューリヒトには一目置いて、「偉大な老紳士」と称して特別に敬愛していたという。1956年と1958年 にはウィーン楽友協会でフルトヴェングラー記念コンサート、ザルツブルク・モーツァルト週間を指揮した。
カール・シューリヒト 略歴と業績
モーツァルトの生誕200年にあたる1956年1月27日に、ウィーン・フィルの戦後初のアメリカ・カナダ演奏旅行に同行するはずだったエーリヒ・クライバーがチューリッヒで急逝した。ウィーン・フィルは首席指揮者として、前日にザルツブルクのモーツァルテウム大ホールで成功を収めたシューリヒトを選出する。シューリヒトは指揮者のアンドレ・クリュイタンスと共に、戦後初めてウィーン・フィルハーモニー管弦楽団とアメリカとカナダをツアーし、12のコンサートを開き（ワシントンのDARコンスティテューション・ホールとニューヨークのカーネギー・ホールなど） 大成功を収めた。この時、ベートーヴェン、ベルク、ブルックナー、ハイドン、メンデルスゾーン、モーツァルト、ヨハン・シュトラウス、ウェーバーが演奏された。このツアーから、シューリヒトとウィーン・フィルの蜜月が始まった。12月10日の人権デーに合わせて、国連総会にも登場。1957年、シューリヒトはヨハン・シュトラウスのワルツ『美しく青きドナウ』でフィルハーモニー舞踏会を開き、1958年にはウィーン・フィルと再共演し、スイス、フランス、オーストリア、スペインで大規模なヨーロッパツアーを行った。以後、シュテファン大聖堂での演奏会（モーツァルト『レクイエム』）など、両者の黄金時代が続いた。1960年、1961年、1964年、1965年にまたもザルツブルク音楽祭に客演。彼が国際的な名声を獲得したのはこの時期だけである。
1950年代と1960年代には、シュトゥットガルト放送交響楽団を何度か指揮した。また、NDR交響楽団、フランクフルト放送交響楽団、ベルリン・ドイツ交響楽団、バイエルン放送交響楽団とも共演した。
1957年にイリノイ州ハイランドパークのラヴィニア音楽祭でシカゴ交響楽団に、タングルウッド音楽祭でボストン交響楽団に客演する。1963年と1965年には渡英し、ロンドンのロイヤル・フェスティバル・ホールでロンドン交響楽団を指揮した。
シューリヒトは1943年からレマン湖畔のコルソー・シュル・ヴヴェイに別荘を所有していた が、1967年1月7日にスイスの病院で死去した。86歳没。1965年にザルツブルク音楽祭でウィーン・フィルを指揮したのが最後の演奏会となった。2011年、彼の骨壷はヴィースバーデンの北の墓地の名誉の墓に移された。
カール・シューリヒト レパートリー・評価
シューリヒトはバッハからマーラー、ドビュッシー、ストラヴィンスキー、ディーリアスまでレパートリーが広い が、特にウィーン古典派と後期ロマン派に傾倒しており、モーツァルトやブルックナー、ベートーヴェン、ブラームスの交響曲の演奏が知られている。また、グスタフ・マーラーへ大いなる音楽的な情熱を注いでいた。若い時代の一時期を除くとオペラの指揮はほとんどなく、リヒャルト・ワーグナーの作品にはあまり熱心ではなかった。同時代の指揮者としては例外的に歌劇場との関係も薄いが、そのことに関しては彼自身も遺憾であったと述懐している。
ザルツブルク音楽祭でのベルリン・フィルやウィーン・フィルとの積極的な共演で世界的に有名になり、ブルーノ・ワルターやヴィルヘルム・フルトヴェングラー だけでなく、クレメンス・クラウス、アルトゥーロ・トスカニーニ、オットー・クレンペラーに肩を並べると言われるようになった。
シューリヒトはかなり高齢になってから世界的名声を得た人であり、特に晩年はリウマチの悪化により、杖をつきながらかなり長い時間をかけて指揮台に登場した。しかしひとたび指揮台に上がると、年齢を全く感じさせない輝かしい生命力が、彼の指揮姿からもその音楽からも湧き出て、聴く者に（そしてオーケストラの楽員にも）大きな感銘を与えた。
カール・シューリヒト レパートリー・評価
シューリヒトの演奏スタイルは、基本的にテンポが非常に速く、リズムは鋭く冴えており、響きは生命力に満ち、かつ透明度の高いものであった。彼の楽譜の読みはどの指揮者よりも個性的で、ある時はザッハリヒに厳しく響かせたり、ある時はテンポを動かしながらロマンティックに歌わせるなど、決して一筋縄ではいかない意外性があったが、音楽全体は確信と明晰さにあふれていた。また、同じ曲でも決して毎回同じようには指揮せず、演奏するたびに新鮮な感動と発見を聴き手に与えた。
カール・シューリヒト レパートリー・評価
シューリヒトは指揮者として客観性を重視していた。シュトゥットガルトの音楽編集者ゲッツ・ティームは、彼のリズムの明快さをピエール・ブーレーズと比較している。彼のモットーは「何かを創造することは、それを使用することより優れている」。音楽学者ベルナルド・ガヴォティは、作品に忠実で、適切で、融通無碍であると評している。1955年、彼は連載「偉大な解釈者（Die großen Interpreten）」でシューリヒトを肯定的に評価した。彼は、シューヒリヒトを、聴き手の感覚のあらゆる能力に対応できる「現代の3、4人の最も偉大な指揮者」の1人に数えている。音楽学者のリヒャルト・シャールとヴィリー・タッポレットは「解釈において堅固な精神性が牽引している」のだと語っている。音楽学者のマティアス・マイヤーは、シューリヒトの解釈を「バランスがとれて完璧」と呼んだ。また、オペラ演出家のルドルフ・シュルツ＝ドーンブルクはシューリヒトについて次のように述べている「このそびえ立つ小柄な男の仕事ぶりと音楽作りは、作曲家の作品に対して完全に一歩下がった芸術的な謙虚さに特徴があった」。
カール・シューリヒト 受賞歴
ヴィースバーデン市には「カール・シューリヒト通り」がある。また、ヴィースバーデンのクアハウスには、カール・シューリヒト・サロンとクリスチャン・ツァイス・ザールの前の記念碑がある。
カール・シューリヒト 作曲作品
シューリヒトはピアノソナタ、室内楽、歌曲、管弦楽曲を作曲している。以下の作品はヴィースバーデンの Drei-Lilien-Verlag から出版されている。
その他に以下の作品がある。
カール・シューリヒト 家族と遺産相続争い
1955年の遺言で、カール・シューリヒトは全財産を4番目 の妻（1944年以降）マルタ・シューリヒト＝バンツ（1916-2011）に遺贈した。後にヘルムート・ヴァイスバッハに訴訟を起こされた。ヨハネス・シューリヒト（Johannes Schuricht、1916年生まれ、後にヘルムート・シューリヒトと名乗る）は、1908年から1922年までのフレデリケ・ハイネマンとの結婚生活の間に生まれた息子で、ハンス・ヴァイスバッハの養子である。
シューリヒトは、子供の父性を常に疑っており、生前、娘婿と孫への養育費を3万スイスフランに制限していた。ヴォー州民事裁判所は1969年に原告に有利な判決を下した。マルタ・シューリヒトは、1971年にスイス連邦最高裁判所が「父親が離婚した妻とその息子の子供の養育費として支払った金銭は補償の対象にならない」との理由で却下した判決を不服として抗告した。(BGE 97 II 209)
カール・シューリヒト レコーディング
EMIやデッカ、コンサート・ホール・ソサエティ盤など多数のスタジオ録音が残されているが、放送用録音の発掘も現在盛んに行われている。
BASIC
BASIC（ベーシック）は、手続き型プログラミング言語のひとつ。
名前は「beginners' all-purpose symbolic instruction code」のバクロニムである。日本語では「初心者向け汎用記号命令コード」を意味する。
BASIC 概要
誕生したのが1964年（昭和39年）であり、当時普及していたプログラミング言語FORTRANにいくつかの点で似ている。
構造化前のBASICと、構造化後のBASICという、構文の様式が大きく異なる2種類のBASICが存在している。
構造化されていないBASIC (Unstructured BASIC)
1970年代 - 1980年代のコンピュータ（マイクロコンピュータやパソコン）で初心者向け・教育用のプログラミング言語として、非常に広く使われた。行番号とGOTO文（大域ジャンプ）を用いるものであり、分岐やループでは常にジャンプ先の行番号を意識しなければならず、構造化プログラミングが不可能である。行番号とGOTOを用いたプログラミングは、スパゲティプログラムとなりがちで、コードの再利用性が低いうえにバグを誘発しやすく、熟練したプログラマにとってもプログラムのデバッグや安全な機能拡張は困難だった。のちに構造化プログラミングに対応したPascalやC言語が登場・普及して比較されるようになると、BASICは激しい批判を浴びるようになり、実用的なプログラミング用途では廃れていった。
BASIC 概要
構造化されたBASIC (Structured BASIC)
順次実行・選択・反復といった制御構造を利用する構造化プログラミングを実現できるように、行番号およびGOTO文を廃止したものである。構造化BASICとも呼ばれる。いくつかの流派で成立したが、特に1991 - 1993年頃に正式に規格として制定されたFull BASICの仕様は構造化がしっかりしてあり、他の点でも改良が加えられてある。このFull BASICの仕様とは互換性がないものの、別の構造化BASICとしての発展を遂げたVisual Basic（VB）を基準（ベース）に、オブジェクト指向にも完全対応したモダンな言語のひとつとしてVisual Basic .NET（VB.NET）がある。
構造化以前のBASICの行番号とGOTO文については、#構造化以前のBASICの節で解説する。また、BASICの基本的な予約語や、ステートメントとコマンドの区別（ステートメントはPRINT, FOR NEXT, IFなど、コマンドはRUN, LIST, SAVEなど）についても、同節で解説する。
BASIC 概要
歴史
最初のBASICは、1964年、米国ダートマス大学で、数学者ジョン・ケメニーとトーマス・カーツがもともと教育目的を想定して開発したものである。このBASICを「ダートマスBASIC」という。行番号の使用や構文は、当時主流だった言語FORTRANの影響を受けている。彼らはこれで金儲けをする気はなかったことが、広範な利用を促し、普及することになった。このダートマスBASICはコンパイラだった。BASICはGEとの提携を経て大学の外にも普及し、1970年代後半以降のマイコン、パーソナルコンピュータなどの多くの機種で次々と採用された。この頃のBASICのほとんどはインタプリタ方式でマザーボード上のROMにあらかじめ書き込まれた状態で供給されていた。一部のBASICはインタプリタ方式でもROMに書き込まれておらず補助記憶装置から読み込まれたり（たとえば日本ではシャープのMZ-80シリーズなど）、あるいはコンパイラ方式のBASICで高速で実行できるものも開発・供給された。
BASIC 歴史
1964年、ダートマス大学にて、ケメニーとカーツにより、教育用などを目的としてダートマスBASICが開発された。これは同時期にともに開発された、タイムシェアリングシステムDTSS上のラインエディタ（テレタイプ端末環境）で利用されるよう設計されていた。
BASICは、GEとの提携を経て、学外にも普及した。ダートマス大学のオリジナルはコンパイラだったが、パソコンなどの商用版では基本機能を最小限にしたうえでインタプリタとして実装されることが多く、独自の発展を遂げた。
多数の方言の登場と標準化できなかった経緯
BASIC 歴史
BASICの方言（異仕様）は、1970年ころ、GEがBASICの第4版を使っているころに現れ始めた。新しいバージョンを待たず、ver.5を用いたマシンをGEがリリースしたころからである。ケメニーとカーツの2人が「BASIC the Sixth（BASIC 第六版）」をリリースした1年後くらいに、ズレが生じはじめた。当時のBASICの異バージョンはGordon Eubanks（シマンテック社のCEO）によるもので、彼は1970年にBASIC-Cを開発した。（なお、BASIC-Eは現在のJavaのような技術を用いており、命令文は一種の中間コードに変換された後に機械語に変換されるものである。）Eubanksも彼の開発したBASIC-Eについては法的に保護せず、次のCBASICでそのような措置をとった。CBASICは彼の会社 Compiler Systems社から販売された。あまりにも次々とBASICの異バージョンが現れるので、ANSIも1974年にBASICの標準化の必要性を感じ始めた。ANSI内に標準化委員会が立ちあがり、BASICの2つの標準、「ミニマルBASIC（minimal BASIC）」と、もう一方は「スタンダード BASIC（Standard BASIC）」を作成しようと取り組んだ。だがBASICの標準化は難しく、委員会が長年かけて「標準化」の仕事を完了したころには、とうにBASICは世界中で広く使われており、実際上標準BASICは現れなかった。
BASIC 歴史
「世界初」のパーソナルコンピュータとされているのはMITS社のAltair 8800であり、1975年、このAltair 8800向けにハーバード大のビル・ゲイツ、ポール・アレン、モンティ・ダヴィドゥフの3人がAltair BASICを開発し、MITS社との契約のもと配布された。1976年4月11日にはスティーブ・ウォズニアックによって開発されたパーソナルコンピュータ・キットApple Iがアップル社から発売され、このマシンのために同じくウォズニアックが開発したInteger BASICが供給され（当初はデータレコーダのカセットテープの形で供給され、後にApple IIが発売されてからROM版も供給された）、翌1977年6月にはキットタイプではない完成品タイプのApple IIが発売となり、それにもやはりINTEGER BASICが、だが今度は最初からROMに書き込まれた形で搭載された。
1970年代末から1980年代初頭にかけては、少数のエレクトロニクス好きたちは、8ビットCPUのコンピュータをキットなどから自作しその上でTiny BASICを動かしたり、スタートレックなどのゲームを動かすことなどを楽しんでいた。
BASIC 歴史
だが大多数はコンピュータを実務に使いたいと感じており、キットではなく最初から完成品の、動作することが確実なコンピュータを求めていた。メーカー側はそうした要望に応えてターンキーシステムを開発しそれにBASICインタプリタをROMに書き込んだ形で搭載するようになり、BASICは一気に当時のマイクロコンピュータ（パーソナルコンピュータ）の標準言語の地位を獲得した。この時に搭載されたBASICインタプリタはほとんどがマイクロソフト製で、同社躍進のきっかけとなった。また、マイクロソフト製BASICは中間コードを使用する構造になっており、汎用機を再現した極めてエミュレータに近いランタイム形式の実行環境でもあったため、当時の互換性が皆無なコンピュータ事情の中でも、スクリプト自体の移植は容易だった。
BASIC 歴史
その後、パソコンに操作を提供するのにも使われ、しばしばROM-BASICとしてハードウェアに組み込まれた。電源投入後にエディタ込みで利用できることから、現在における、シェル、インタフェースとしての役割ももち、ローダなどの役割も担った。入力の効率化のため、省略形式での入力や、1980年代後半には、ラベル、インデントへの内部的な対応、C言語への橋渡し、日本では漢字の利用など、様々な機種ごとの独自の発展を遂げた。当時のPCの処理速度は遅いので、処理の高速化が必要な部分はデータ形式でアセンブリ言語による処理を呼び出すなどの手法もとられた。
1980年代後半から1990年代前半ころにはC言語がパーソナルコンピュータのユーザにも少しずつ知られるようになり、BASICの代わりにC言語を使うことが増えていった。
一方で1990年代などでもプログラミングの専門家ではない数学者が、あいかわらず行番号を使用する数値計算用のBASICを開発（UBASIC）していた。
BASICは1970年代後半から1980年代にかけて、当時黎明期にあったパーソナルコンピュータ（マイクロコンピュータ）の各機種に続々と搭載され、業界の発展にも貢献した。
BASIC 歴史
だが、BASICを最初に開発したダートマス大の2人は今で言う「パブリックドメイン」でいいと考えており、また標準化団体のANSIも後手にまわり、BASICには「方言」が乱立した。
マイクロコンピュータやパーソナルコンピュータに標準搭載されたBASICは、たいてい各メーカーの各機種ごとに独自拡張が行われた（おもに画面操作やI/Oの直接操作などについて、独自の仕様が次々と導入された）。コモドール社のPET 2001のCommodore BASICに類似したシャープのS-BASIC、SEGAのベーシックカートリッジ、次第にシェアを増やしたマイクロソフト製のBASIC（MBASIC、BASICA、G-BASIC、GW-BASICの移植版）や、その命令体系を引き継ぎ実装したものである、F-BASIC、Hu-BASIC、カタカナで表現するG-BASIC（前述のマイクロソフトの物とは異なる）以外にも、C言語を意識したX-BASICなど、さまざまなBASICを各社が独自に開発した。
この結果、「あるパソコンのBASICで書かれたプログラムは、他のパソコンではそのままでは動かすことができない」という状態になった。
初期のTiny BASICはともかくとしても、BASIC実装処理系のメイン・メモリの制限により言語仕様が極めて制限された実装が存在した。
BASIC 歴史
処理プログラムの大きさや速度の制限を改善あるいは回避するテクニックを紹介する。いくつかは、ソースの読みやすさを犠牲にするようなテクニックでもあった。
ただし、中間コードを採用している処理系では、?と入力してもPRINTに展開されるので、結果は変わらない。また、REMを'と書くのはかえってサイズが増える。
次のようなコンパイラがある。
しかし、パソコンに内蔵または標準添付されていたインタプリタと違い、コンパイラは別売であったり、高価であったり、実行にはランタイムライブラリを必要であったりする場合があった。このことから、BASICインタプリタによる開発に習熟したユーザーは、より高速で柔軟なプログラムを求めて、機械語（アセンブリ言語）や、C言語などに移行していった。
また、コンパイラと称していても、実際はインタプリタとソースコードを同梱した実行ファイルを作るだけ、というものもある。中間表現と、そのインタプリタ、という構成のものもある。
急速に広まったBASICだが、構造化機能の無いBASICは教育に使うな、などとコンピュータサイエンティストの一部から酷評されたりもした。1975年にはすでに、エドガー・ダイクストラから激しく批判された"How do we tell truths that might hurt?"などが知られる。
BASIC 歴史
行番号とGOTO文は特に激しく批判された。（構造化前の）BASICのIF文とGOTO文を組み合わせて使用する文（「IF .... THEN GOTO ...」）を頻発せざるを得ず、IF + GOTO文を増やすほどスパゲティプログラムになってしまうことはしばしば指摘された。
さらにBASICには局所変数（ローカル変数）が無いなど、他にも問題は多い。つまり、プログラムのどこからでもアクセス可能な大域変数（グローバル変数）しかなく、これもまたスパゲティプログラムを誘発する要因である。
BASIC 歴史
BASICの標準化が望まれたが、マイコン・パソコンの急激な普及で標準化は後手後手にまわり、各メーカーの独自拡張はすでに各機種のROMに書き込まれていて後から書き換えるわけにもいかず、後手にまわってしまった標準化団体も一部のメーカーだけを優遇するわけにもいかず結局、「どの機種のBASICでも、共通で使われている、ごく基本的な機能」に絞った小規模の仕様だけが「標準」として制定されるにとどまった。ANSI X3.60-1978「American National Standard for the Programming Language Minimal BASIC」は、日本では JIS C 6207-1982「電子計算機プログラム言語 基本BASIC」として規格化された。制定直後にJISの分類の再編があり、電気電子のCから情報のXに移動してJIS X 3003となったが、次節のFull BASICのJIS化の際に改訂として同じ番号を使うという形で旧規格として消滅した。
すでに多数の重要な機能は、各機種のBASICの「方言」として実装されて後からそれを削るわけにもいかず、結局、各社は高度な機能は方言で実装しつづけ実際上はBASICの標準化は失敗したままに終わった。
BASIC 歴史
日本では1990年代後半から、高等学校や大学入試センター試験の数学に、標準化された基本BASICの範囲で書かれたプログラミングが扱われるようになった。
ダートマスBASICは、他のBASIC（ケメニーらは「ストリート」BASIC、と呼んだ）とは異なって既に1970年代後半から構造化などが進んでおり、ANSIでは新しい規格の策定も進んでいたが、これをパソコン向けにアレンジしたTrue BASICが、1984年に開発された（日本ではクレオから発売）。構造化の他、行列演算の機能など、学術的（特に数学的）な方面の拡張も特徴である。そしてTrue BASICとほぼ同一の構造化BASICであるFull BASICがISO/IEC 10279 (Information technology−Programming languages−Full BASIC) がINCITS/ISO/IEC JTC 1によって1991年に規格化された。また日本でもJISによる翻訳として、JIS X 3003-1993『電子計算機プログラム言語 Full BASIC (The Programming Language Full BASIC)』が1993年に規格化された。
Full BASICの主な特徴
BASIC 歴史
構造化に対応する制御文を追加した（DO〜LOOP、DO WHILE〜LOOP WHILEなど）
IF文が多行に渡るブロックIF（IF〜THEN〜ELSE〜ENDIF）も可能となった
LETを省略できないようにした（True BASICではOPTION NOLETまたはNOLETを実行すると省略可能）
スコープの概念を取り入れた
外部副プログラム（EXTERNAL SUB〜END SUB）や外部関数（EXTERNAL FUNCTION〜END FUNCTION）の中でローカル変数が使用できるようになった
副プログラムと関数は戻り値を戻すかどうかで区別される
再帰処理の実装が容易になった
計算精度や丸めの方法を規定した
配列の添字を1から始めるようにした（OPTION BASE命令で0から始まるようにすることも可能）
行列演算機能
構文のアドホックな所などを極力排除した
予約語を極力少なくした
I/Oを直接操作するなどシステムに干渉する命令は持たないようにした（True BASICでは拡張ライブラリとして提供）
グラフィック命令を規定した。なお、(0, 0) が、デフォルトでは、コンピュータ系に多い左上ではなく数学などで伝統的な左下である（変更できる。高機能なBASICに多かった、任意にスクリーンとウインドウのそれぞれの座標を設定できるタイプである）
BASIC 歴史
Minimal BASICの上位互換である
パソコン向けのそれまでのBASICとは命令の互換性が低い
サブルーチン（GOSUB〜RETURN）は規格として残ってはいるが、使用は推奨されない
マイクロソフトはFull BASIC規格の策定には参加しなかったが、1985年にFull BASICに類した構造化や特徴を追加した独自規格のQuickBASICを発売した。これは自社のDOS用のGW-BASICの上位互換で、コンパイラ並に動作を高速にした上にコンパイルもできるようにしたもので、Version4.5まで発売した後に1991年のVisual Basicへと繋がっていった。
QuickBASICとの互換性を考慮した自由なBASICとしてQB64やFreeBASICがある。
BASIC 歴史
MS-DOS上で動作するGUI拡張環境として、1985年にMicrosoft Windows 1.0が登場し、のちに独立したオペレーティングシステム (OS) としても普及を始めた。GUIオペレーティング環境はコンピュータの操作に直感性をもたらしたが、Windows上で動作するGUIアプリケーションソフトウェアは、ボタンのような画面上に表示された視覚的なGUI部品（ウィジェット、コントロール）をユーザーがマウスで操作することに反応して動作する、イベント駆動型のプログラムである。Windowsアプリケーション向けのプログラミング言語や開発環境とし、マイクロソフトはC/C++を用いた開発ツール（Microsoft C/C++、のちのMicrosoft Visual C++）だけでなく、構造化BASICを用いた開発ツールとして「Visual Basic」(VB) も提供した。VBは前述のQuickBASICから発展したもので、Rapid Application Development (RAD) 方式の本格的な統合開発環境 (IDE) でもあり、生産性と直感性に優れていた。
Windows自体はC/C++を使って開発されていたが、BASICを見捨てることはしなかった。既存ユーザが受け入れやすい選択肢を提供することで、ユーザが他社に逃げてしまうことを防いだ。
BASIC 歴史
Visual Basicでは、業務用のソフトウェア、プロフェッショナル用のソフトウェアなども多数開発されるようになり、C言語やC++同様に、プロでもその気になればまともに使える言語になった。なお、C/C++は言語仕様上、そもそもGUIプログラミングや統合開発環境との親和性、コンパイル速度などに問題があった。プロパティなどの便利な機能をサポートし、またシンプルな言語仕様を持つVBのほうがGUIプログラミングに向いていた、という側面もある。VBは後発のDelphiやC++Builderの設計思想にも影響を与えている。
また、「PC/AT互換機とWindowsの組み合わせ」というプラットフォームが一般化したことで、「BASICの方言の乱立」の問題が解消されていくことになった。Windowsが走るマシンであれば、どのメーカーが製造したパソコンであろうが、MicrosoftのVisual Basicが「標準的なBasic」という位置づけになっていき、いわば「標準語」のようなものが定まった。ただしVisual Basicは、Windowsというプラットフォームに依存する言語、開発環境であり、MacintoshやLinuxといったプラットフォームでは使えないものであった。
BASIC 歴史
なお、VBのサブセットであり、アプリケーションを制御するためのドメイン固有言語・マクロ記述言語としてVisual Basic for Applications (VBA) も登場し、主にMicrosoft Office (MS Office) 向けに提供されている。Officeに統合開発環境が標準的に組み込まれており、専業のアプリケーション開発者以外の一般ユーザーにも利用可能であることからエンドユーザー・コンピューティングの普及に寄与し、事務作業の効率アップやプログラミングの入門にも使われることになった。ただし、VBAのマクロ機能を悪用したコンピュータウイルスも出現し、利便性と引き換えにセキュリティホールの温床にもなったことから、Office 2007以降の既定のファイル形式ではVBAは使えなくなっており、また既定でVBAは無効化されている。
VBから発展したVB.NETは、C#とともに登場したモダンなオブジェクト指向言語であり、アプリケーションの開発および実行に.NET Framework環境を必要とする。のちにMonoや.NETにも移植され、WindowsだけでなくLinuxやmacOSでも利用可能なクロスプラットフォームな言語となった。Xamarinを利用することでAndroidやiOSで動作するアプリケーションも開発することができる。
地位の低下
だが大学ではBASICの使用は構造化BASICも含めて減っていった。大学では、構造化言語の中でも、特定メーカーに依存せずプラットフォームを超えて使え、方言が乱立しなかったC言語を教えることが一般化した。また、特定のOSやCPUアーキテクチャに依存せず、無料で使えるJavaなどの洗練された後発言語の普及により、BASICは開発環境としては選択肢のひとつでしかなくなっていった。
なお、コンパイラで開発した場合、実行ファイルとは別に、巨大なランタイムライブラリが必要となる処理系が多い。このため配布に必要なファイルのサイズが大きくなり、敬遠されることもある。
もともとVB.NETは姉妹言語のC#やF#と比べて、新しい言語機能のサポートが遅れる傾向にあったが、マイクロソフトは2023年2月、VB.NETには今後新しい言語構文を追加せず、安定性に重きを置く方針であることを発表した。VB.NETのサポート自体は継続されるが、言語の進化は止まっている。
プログラミング言語の人気度 (popularity) を示す指標のひとつとしてTIOBEインデックスが存在する。この指標は実際の言語利用状況とはやや異なるが、2023年9月現在、PythonやC系統の言語が上位を独占する中、Visual Basicは一定の地位を維持している。TIOBEが発表した2021年11月のランキングでは、トップ10は上から順に、Python、C、Java、C++、C#、Visual Basic、JavaScript、アセンブリ言語、 SQL、PHPとなっていて、つまり2021年11月時点でVisual Basicは6位だった。一方、RedMonkによる2021年6月のランキングでは、VBは20位以内にも入っておらず圏外だった。
構造化ということを意識していなかったパソコン用のROM/Disk-Basic環境で、構造化プログラムを記述するために作られたプリプロセッサである。アスキーの書籍の形（アスキー書籍編集部編著「構造化BASIC RATBASのすすめ」 (ISBN 978-4-87148-152-6) ）で、1985年に公開された。これは、独自の構造化された構文で記述されたソースプログラムを処理し、行番号やGOTO文を使うROM/Disk-Basicに変換するプログラムで、すべてBasicで記述されていた。RATBASという名前は構造化FortranのRatforなどに倣ったものである。RATBASは、スタンドアローンのBasicプログラムと、μ-UXの外部コマンドとして作成されたサブセット版がある。μ-UXとは、年刊AhSKI!の1984年号に掲載された、Disk-Basicで記述されたUnix風のオペレーティング環境であるUni+を拡張したものである。
海外ではボーランドが独自にALGOL風の拡張を施したTurbo Basicを発売した。
現在、BASICもオブジェクト指向化が見受けられる。その代表例がVisual Basic .NETやREALbasicやActiveBasicやFreeBASIC等で、四者とも既に完全なオブジェクト指向言語になっていると言える。
BASIC 構造化以前のBASIC
構造化以前のBASICは、行番号とGOTO文があることが特徴のひとつである。
BASICのエッセンスを説明し簡単なプログラム例を示すために、BASICのステートメントとコマンドについて説明する。
本来のBASIC、ダートマスBASICではステートメントとコマンドを明確に区別する。ダートマスBASICのルールを説明する。
行番号を持ち、プログラム本文の中に書かれるコード行はステートメント（文、statement）と呼ぶ。
たとえば次のようなキーワード（予約語）から始まるものがステートメントである。
処理系に指示を与えるワード（プログラムの外の命令）はコマンド（命令、command）と呼ぶ。
たとえば次のようなワードである。
きわめてシンプルな例を挙げる。
画面に次のように入力したとする。
するとBASICの処理系は、行番号10から40までの文をプログラムとして扱う。次にRUNと入力し（すると「40 NEXT」の次の行に「RUN」と表示され）リターンキーなどを押すと、行番号10の行すなわち「10 REM 5つ数える」から順に実行され、行番号20から行番号40まではループとして扱い5回繰り返す。この場合の出力は次のとおり。
BASIC 構造化以前のBASIC
なお、「REM」はステートメントであり、ソースコードを読む人のための注釈文（英: remark）の文頭に置かれる。REMで始まる行はプログラムの実行結果に何ら影響を与えない。
また、前述のプログラムに編集を加えたい場合は、続いて例えば次のように入力する。
このように入力すると、行番号10の文は書き換えられ（つまり上書きされ、以前のものは消え）、20行目と30行目の間に行番号25の「 25 IF I = 3 THEN GOTO 40」が挿入された、とBASICの処理系は判断する。 そしてRUNと入力すると、やはり行番号10から実行し、出力は次のとおり。
BASIC 構造化以前のBASIC
GOTO文（GOTO <行番号>）があると、<行番号>で指定された行番号にジャンプしてその行を実行する。たとえば「GOTO 250」と書かれていたら、行番号250にジャンプする。行番号は、テレタイプ端末時代に処理系と一体の行指向テキストエディタで扱うのに便利であったので採用されてしまった。ジャンプ先をただの数字（行番号）で示すので、ある程度以上の行数を書くとGOTO文が増え、直観的には分かりづらい行だらけになる。アルファベットなども使って意味付けされた単語（ラベル）で行き先を指定するジャンプではないので、一行ずつ焦点を当てると、どういう意図で書かれたコードなのかが不明瞭な行ばかりになってしまう。また、通常ある程度以上の規模のプログラムは分岐判断が多数含まれるので、IFとGOTOを組み合わせた文を多数使うことになり、ある程度の行数以上のプログラムを書くとスパゲティプログラムになりやすい。だが現在でも互換性のために両者を残している処理系もある。ラベルを用いて「GOTO *LABEL」のように指定できる実装もある。
BASIC 具体例
Webブラウザ上でBASICの動作をエミュレートするWebサイト・Webサービスが公開されている。手軽に最低限の雰囲気を理解することができる。
構造化以前のBASICが動作していたコンピュータ実機の新品販売は、ほとんどは終了となっている。
以下、シャープのBASICは「コモドール系」と呼ぶことも可能ではある
S-BASIC - （1978年 -。シャープ MZ-80用BASIC。シャープ純正BASIC。MZ-80はCommodore PETの影響を受けておりBASICもPETに似ているが、それでもシャープが自力開発したもの。命令セットは互換性のため後継製品もそれに準拠して独自拡張した物となっている。
SP-5030 （1978年12月 -。MZ-80K, Cなど用BASIC。データレコーダ用のカセットテープで供給された）。「SP-5030」が言語の品番かカセットの品番かはやや曖昧。「MZ-80 SERIES BASIC解説」が付属した。
SB-5520 （MZ-80B用など）
BASIC 具体例
QuickBASIC （1985年 - 。Visual Basicの原型となった構造化BASIC）
QBasic （QuickBASICの簡易版、Windows 95 / 98のCD-ROMに英語版が付属）
Microsoft BASIC Professional Development System （QuickBASICの進化形で、標準でISAMデータベースが構築でき、MS-MASM、MS-C、Quick C、MS-FORTRAN等との言語混在開発が可能な、プロユースの構造化BASIC）
これらは命令セットの仕様が共通なだけで、必ずしもマイクロソフト製というわけではない。
1980年代などのパソコンの復刻版。
マイクロソフトBASIC・ならびにその類似系
独自系
Full BASIC系（規格準拠）
旧式構文系
Android OS上で動くBASIC。
iOS上で動くBASIC。
インタプリタ
インタプリタ（英: interpreter）とは、プログラミング言語で書かれたソースコードないし中間表現を逐次解釈しながら実行するプログラムのこと。「インタープリタ」「インタープリター」などと表記することもある。
インタプリタは、およそ次のいずれかの動作をするプログラムである。
このように程度の差はあるが、ソフトウェアがソフトウェアを実行するという形になる。
インタプリタ
いずれにしても、「インタプリタ型言語」などという分類は本来は存在しない。単にそれぞれの言語の代表的な処理系の実装がインタプリタであったというだけで、理論上はどの言語であってもインタプリタとコンパイラのどちらでも作ることができる。しかし、どちらの実装が主力であるか、などといった観点から、「インタプリタ型言語」や「コンパイル型言語」と区別されているのが現実である。インタプリタは実行中何度もプログラムを再解釈するため、ダイナミックディスパッチやダイナミックバインディング、リフレクション、動的型付けのような機能を実現することが容易である。一方、コンパイラは事前にCPUで実行できるように変換するだけで実行には関与しないため、実行中に振る舞いを変更したいときはそのためのプログラムを別途用意しなければならないケースがほとんどである。さらに、自前の言語から既存の何らかの表現に変換するには、その表現と対応付けるための知識と技術が必要であり、言語機能が大規模化や複雑化するほど、既存の表現との互換性をできるだけ確保しながら、自前の言語での振る舞いを実現することは難しくなる。中間表現も自前であれば、変換する手間はずっと楽になる。
インタプリタ 仕組み
インタプリタは各仮想命令に紐づく命令ボディとディスパッチ機構をもち、ホストマシン上で実行可能になっている（例: x86マシンコードbinファイル）。仮想命令群からなるコードを引数としてインタプリタが実行されると、仮想命令に基づいて制御が移行され対応する命令ボディが実行される。これを繰り返すことでインタプリタはコードを実行する。
命令ボディ（英: instruction body、命令本体とも）は仮想命令をホスト言語でエミュレートするコードである。命令ボディがホストマシンで実行されることで仮想命令が事実上実行される。すなわち命令ボディは仮想命令の実装である。例えば二項和仮想命令 ADD2 に対応してC言語で書かれた push(pop() + pop()) は命令ボディである。
ディスパッチ（英: dispatch）は仮想命令に基づいた命令ボディから命令ボディへの制御移行メカニズムである。ディスパッチの最もシンプルな例はSwitch文（Jump命令）である。ある仮想命令の実行後、次の仮想命令に対応する命令ボディへ制御を移す（Jumpする）ことでその仮想命令実装が実行される。
インタプリタ 誤解
プログラミング言語処理系の実装には、インタプリタとコンパイラの2つがある、とされてきた。インタプリタは実行を行うが、コンパイラは実行を行わない、という差がある。
インタプリタは、インタプリタが提供する言語のプログラム文を1文ずつ、インタプリタを実装した言語の機能を呼び出していく（単純な）方式が一般的であった。コマンドラインインタプリタではこれに加えて、別のプログラムに処理を委ねて一つの機能を実現する。
この時代のインタプリタの長所と欠点については、およそ次のような解説がされることが一般的であった。
（短所）実行速度が遅い。（ループ（＝繰り返し）の箇所などでは）1度構文解釈した文でも、毎回（あらためて、最初から）解釈と実行を行うので、コンパイラ方式に比べて実行速度が遅くなる。（ループを全く含まないような、全ての命令が一回だけ解釈され、一回だけ実行されるような（ある意味、特殊な）プログラムであれば、解釈+実行のトータルの時間は、インタプリタでもコンパイラでもさほど差は生じない。だが、実用的なプログラムは一般的に、多数のループを含んでおり、そうしたプログラムではインタプリタのほうが実行を完了するまでの時間が多くかかり、特に、ループ回数が多ければ多いほど（古典的な、単純な）インタプリタの相対的な遅さは顕著になってくる。→#長所と短所
インタプリタ 誤解
その後、そうした欠点を解消すべく、（1990年代ころになって）毎回毎回、（高級言語から）機械語に変換するのではなく、中間言語に変換することで高速化をはかるインタプリタなどが作りだされた。
改良の結果、古典的な意味での「インタプリタ」と「コンパイラ」の双方の性質を備えたようなインタプリタが登場し、複雑化してきている。
（近年の）インタプリタがおこなう、（旧来の）コンパイラが行っているような変換のひとつとしては、高速化などを目的とした、実行時コンパイラによる動的コンパイルを挙げることができる。
インタプリタ 歴史
インタプリタという手法、すなわち、「そのハードウェアが直接解釈するのではないプログラム」を受け取り、「プログラムで実装された抽象的な、あるいは仮想上のコンピュータで解釈実行する」というプログラムの実行法は、コンピュータが登場した時から、ないしそれ以前からある。
万能チューリングマシンは、「どんなチューリングマシンについても、それを模擬できるチューリングマシン」というもので、ある種のエミュレータないしインタプリタであり、考察されたのは電子式のコンピュータの誕生する以前である。
インタプリタ 歴史
EDSAC（実用的な機能を持ったプログラム内蔵方式の世界初の電子計算機とされている）において既に、ある種のインタプリタが実装されていたことが記録に残っている。同機におけるプログラミングの技法が書かれた The Preparation of Programs for an Electronic Digital Computer の chapter 2 の § 2-22 Interpretive subroutines で説明されているが、複素数演算などのサブルーチンを明示的にサブルーチンとして呼ぶのではなく、通常の加減算などと同様の形式のプログラムをインタプリタで解釈してそれらのサブルーチンを利用する、というものである。また日本においても、パンチカードを入力としてパッチパネルの配線によるプログラミングで処理するような機械で、配線によってある種のインタプリタのようなものを実装し、パンチカードの内容をデータとしてではなくプログラムのように扱う、というような例があると言われている。
最初の Lisp インタプリタはスティーブ・ラッセルが IBM 704 上に実装した。これにはエピソードがあり、ジョン・マッカーシーが「Lisp の論文」で「数学的」に示したものだったのであるが、マッカーシー自身は実装できるものだとは考えていなかった。それを、論文を読んだ、院生であったラッセルが、実装可能だと言って数学的な記述から変換して機械語で実装してみせたという。
1960年代には（現在のJavaなどと同様な）、プログラミング言語から中間表現にコンパイルし、それをインタプリタで実行する、というような手法も一般的になった（pコードマシンを参照）。
インタプリタ 長所と短所
プログラム開発中、プログラマは頻繁にソースコードに手を加える。コンパイラの場合、ソースコードを変更するたびにコンパイルし、リンクして実行ファイルを完成させないと、そのプログラムを実行できない。プログラムが大きくなると、ビルドの完了を待っている時間が長くなる。一方、インタプリタではソースコードをそのまま実行するか中間表現に変換するだけなので、ほとんど待つ必要がなく、修正がうまくいったかどうかのテストをより素早く確認できる。
この特性を利用したプログラムとしてREPLがある。入力を受け取る（Read）、入力の評価（Eval）、評価結果を提示する（Print）を繰り返す（Loop）、テスト環境の一つである。評価はインタプリタに限らずコンパイラで行なわれるかもしれないが、ユーザからの入力は常にソースコードの断片であり、それを逐次実行するという点で一種のインタプリタということもできる。実際、その挙動はソースコードを指定せずに起動したBASICなどのそれとよく似ている。しかし、テスト環境も兼ねているため、エラーが起きた場合のメッセージが詳細であることが多い。関数型言語や論理型言語では、通常は機械語にコンパイルする処理系であっても用意される。
インタプリタ 長所と短所
AOTコンパイラ方式では事前に生成された機械語実行ファイルがユーザーに配布される。機械語はプロセッサアーキテクチャに依存するため、このバイナリは特定のプロセッサでしか動作しない（可搬性が低い）。
一方インタプリタ形式ではソースコードとインタプリタが配布される。インタプリタは機械語実行ファイルであるため環境に依存するが、ソースコードには環境に依存しない言語を採用できる。その場合環境に合わせたインタプリタを事前配布しておけば、アーキテクチャに依存しないプログラムの配布が可能である（可搬性が高い）。またインタプリタの代わりにJITコンパイラを用いても同様の利点が得られる。同一動作の保証はインタプリタ実装に依存しており（JITであればコンパイラ）、互換性バグの例として表計算マクロやWebページ（HTML）が挙げられる。
AOTコンパイラ方式では1つのバイナリを実行するだけでプログラムが機能する。一方インタプリタ方式では、まずインタプリタをインストールしその上でソースコードを動かす必要がある。その結果全体のプログラムサイズが大きくなり、ユーザーの手間が増える場合がある（複雑性が高い）。またJITコンパイル方式でも同様の複雑性が生まれる。
インタプリタ 長所と短所
インタプリタ用コード（高級言語コードあるいはバイトコード）は機械語バイナリより容易に解読できる（可読性が高い）。ゆえに配布後のデバッグや修正が容易な一方、知的財産保護上の問題を起こしうる。そのための暗号化・難読化を考慮した言語・システムが存在する。またJITコンパイル方式でも同様の可読性に関する特性が現れる。
インタプリタ方式の実行速度はコンパイラ方式の実行速度よりも遅い傾向がある。
コンパイラではプログラム内の文の解析を実行前に1回だけ行うが、単純な実装のインタプリタではそれを文ごとに実行時に毎回行うため、実行性能が低くなる。単純な実装のインタプリタでは変数にアクセスする際も識別子とメモリ上の位置のマッピングを確認しなければならず、しかもそれを実行中に何度も行わなければならないので、遅くなる。
またディスパッチはインタプリタが本質的に抱えるコストである。コンパイル方式では事前（コンパイル時）にディスパッチ相当の命令ボディ整列がおこなわれるため、実行時にディスパッチコストが発生しない。ゆえにインタプリタ方式ではディスパッチコスト×命令数分の追加コストが本質的に掛かる。
インタプリタ 長所と短所
ディスパッチは分岐予測を難しくする。ゆえにパイプライン方式を採用するCPUにおいて速度へ影響を与える。影響の大きさは分岐予測器の性能に左右され、2000年代以前のCPUではインタプリタの低速度がこのペナルティによって引き起こされるとされていた。予測器の性能が上昇した2010年代以降のCPU（例: x86 Haswell）ではその影響は小さい。
インタプリタによる開発の速さとコンパイラによる実行の速さの間で、様々な妥協案が考案されてきた。一部の LISP 処理系などでは、インタプリタのコードとコンパイルされたコードが相互に呼び出しあうことができ、変数も共有できる。そのため、あるルーチンをインタプリタで評価しデバッグした後、先行してコンパイルして実行性能を高めつつ、他のルーチンを開発し続けることができる。多くのインタプリタはソースコードをそのまま実行するわけではなく、よりコンパクトな内部形式に変換している。多くの BASIC インタプリタは予約語を1バイトのトークンに置換し、それをジャンプテーブルのインデックスとして使用する。PBASIC など一部のインタプリタでは、バイト単位ではなくビット単位でプログラムの短縮を行っており、例えばコマンドを5ビットで表し、一般に16ビットで表される定数をその数値の大きさに対応して可変長（3、6、10、18ビットなど）で表し、アドレスオペランドとして「ビットオフセット」を用意している。多くの BASIC インタプリタは独自にトークン化された内部表現を保存し、読み込むことができる。
インタプリタがコンパイラと同様の字句解析と構文解析を行い、その結果生成された抽象構文木を解釈することもある。
プログラムの実行時間はコンパイラよりもインタプリタの方が長いが、コンパイル時間と実行時間を合計すればインタプリタでの実行時間よりも長くなることがある。プロトタイピングとテストにおいては、この差が重要となる。
その他の技法に制御フロー解析や静的単一代入がある。
インタプリタ バリエーション
それ自体はインタプリタの手法とも言えるしコンパイラの手法とも言える。そのどちらと言うよりも、中間表現の1種類というべきかもしれない。仮想関数テーブルやテーブルジャンプによるフロー制御に似ていなくもない。
スレッデッドコードは、呼び出されるべきサブルーチンのアドレスのみが順番に羅列されたものである。「直接スレッディング」の場合は、そのアドレスが指す先は機械語のサブルーチンである。他にもいくつかのバリエーションがある。「サブルーチン・スレッディング」は最も違うタイプのバリエーションで、アドレスのみではなく、機械語のCALL命令として羅列するので、ハードウェアのプロセッサで直接実行できる。これは実行のオーバーヘッドは極小だが、メモリ効率は悪い。サブルーチン・スレッディング以外のスレッデッドコードは、きわめて単純なインタプリタで実行できる。Forthでは「内部インタプリタ」と呼んでいる（これは、Forth言語自体を実装しているインタプリタである「外部インタプリタ」と対になっている）。
インタプリタ バリエーション
ソースコードを実行可能な形にするには、まず、ソースコードを構文木に変換する必要がある。構文木のまま、インタプリタ型の処理系で実行する処理系もあるが、構文木をさらに、中間コード（バイトコードなど）などの中間表現に変換してから実行する物もある。中間コードをバイトコードと呼んでいる処理系ではそのインタプリタをバイトコードインタプリタと呼ぶ。Java や .NET Framework のように、中間コードの仕様を公開しファイルに書き出すものもあるし、仕様は公開せず処理系内部だけで使用するものもある。動的コンパイルを使っているインタプリタは、内部で実機の機械語に変換し実行する。
インタプリタ バリエーション
インタプリタとコンパイラの間には様々な中間的実装が存在し、それぞれにプログラム実行前に行われる解析の度合いが異なる。例えば Emacs Lisp はバイトコードにコンパイルされ、LISP のソースを高度に圧縮し最適化した表現にしているが、それは機械語コードではない（したがって特定のプラットフォームに依存しない）。この「コンパイル」されたコードを解釈するのがバイトコードインタプリタである（それ自体は C で書かれている）。この場合のコンパイルされたコードは仮想機械の機械語コードであり、仮想機械はハードウェアで実装されておらず、バイトコードインタプリタとして実装されている。同様の手法は Open Firmware システムで使われている Forth コードでも使われている。ソース言語は「Fコード」（バイトコードの一種）にコンパイルされ、それを仮想機械が解釈実行する。他にPコードマシンなどがある。
コントロール・テーブルはコンパイラを通さなくとも生成でき、バイトコードインタプリタと同様の方法でカスタマイズされたインタプリタでの適切なアルゴリズム的制御構造を記述できる。