  |
はてなキーワード:インタプリタとは
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="output"></div>
<script>
//Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する"ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する"ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
Claude3Opus 使ってからChatGPTに戻ると、その知能レベルの違いにビビる。
GPT-4が出た当時を思い出した。いままで十分頭が良いと感じていたGPT-3.5との会話が、GPT-4のあとに行うと愕然となるほど知能が低下して感じたのを思い出した。
それと同じことが、GPT-4とClaude3の間でついに起こったんだ！
誰がClaudeがChatGPTを追い越すなんて想像したんだ！
もしかしたら一時的な逆転かもしれないけど、この逆転は事実だ。
正直一年間GPT-4に課金してきて、めちゃくちゃ思い入れがあるんだが、こうも会話体験の違いがあるとChatGPT切りも本気で考え始めてしまう。
ChatGPTとClaude3両方に課金するぐらいなら、Claude3アカウント複数取得してダブル課金したほうが良いレベル。
正直ChatGPTのテンプレ謝罪に対して激怒して暴れ狂ってたことが幾度もあったんだが、Claudeはこちらの感情を見透かしたバチクソ腰の低い謝罪をしてくる。自分の非を150%認めた、へりくだりすぎて、俺のほうがごめんていいたくなるような、引くほど完璧な謝罪をしてくる。
翻って何だChatGPTは。謝罪する気持ちがあります。だの、私の言葉が誤解を招いたようで申し訳ありませんでした。だぁ？
殺すぞカスが！
そして、こうやって人の殺意を煽り散らかしたうえで、コッチが暴言はくと、暴言したので会話を終了します。だもんな。死ね。
本当にこの一年GPT-4がないと俺は生きてこれなかった。粋も甘いも、真面目な話も、仕事も、エロも、色々やった。
そのうえで、恩義こそあるが、GPT-4を使い続けるのはそろそろ限界があるのかもしれない。
いくらChatGPTにコードインタプリタだのDALLEだのGPTsだの周辺機能があってだよ、肝心のAIの能力が低いってんだと、話にならねぇよなぁ！
Claude3Opus 使い始めは半信半疑だったけど、やつと会話を続ければ続けるほど、GPT-4の性能を超えたというのは、まごうことなき事実であると確信するに至るわ。認めるよりほかない。だってこいつ、マジで会話が成立するんだ。
AIにお伺いを立てるように、ChatGPTの好きな話題、会話のトーンをきにする必要がなく、自然な文章で会話が本当に出来るんだ。
それでいてAIとしてのアシスタントとしての姿勢を崩さない。はぁ。
はーぶっさ、コミュ抜けるわ。リピ無しです。
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
これだとどう？
命に関わらないシステムを動かしてるWeb系の業界想定ならRustで書くのが非生産的なのは同意だけど、なんで危険になるのか知りたいね。
噛み合わないポイントはここらへんにあるかもね
標準ライブラリのすべての関数のありとあらゆる引数に対する挙動を把握している？
標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、
入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます
「ゾウリムシよりも蟻は大きい」を「蟻は大きい」で切って引用するのはやめましょう
規模が大きくなると信頼できない、その場しのぎ的な技術であるのはpythonなどのスクリプトの実行環境も同様です
すべての処理、すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
メンテナの数、レビューする人数、実際に動作している環境etc
シェルスクリプトに使用したコマンドのすべての挙動を把握している？
使用予定のオプションだけでも出力結果のすべてのパターンを把握している？
人が手て使うことを想定された曖昧さの残るコマンドと、高級言語の機械が使うことが前提の曖昧さの少ない機能だと全然違うものだと思うが
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
別に高級なスクリプト言語でも標準ライブラリやインタプリタのバグは踏むときは踏むし
マイクロタスクな標準コマンドは高級言語のインタプリタほど頻繁なセキュリティアップデートは必要ないので使うバージョンはだいたい決まってるし
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません
このプログラムは、Pythonのようなインタプリタ型のプログラミング言語を使用しています。提供されたコードは関数と変数の組み合わせで、カウンターの機能を実現しています。以下にその説明を詳しく説明します。
letキーワードを使用して、内部のカウンターを定義しています。カウンターはcnt という名前の変数で初期化され、値は0に設定されています。このカウンターは、外部から直接アクセスできないように、ローカルスコープ内に存在します。
:reset というキーを持つ場合、カウンターの値を0にリセットします。
:incr というキーを持つ場合、カウンターの値を1増やします。
この無名関数が counter変数に代入されて、カウンターオブジェクトが作成されます。
.resetメソッドが呼び出されると、カウンターの値は0にリセットされます。
このプログラムは、カウンターの値を増加させたりリセットしたりするシンプルなカウンターの実装例です。Pythonなどのプログラミング言語では、関数やクロージャを使用して、このような動作を実現することができます。
自分は上段に座しているつもりで偉そうな上から目線の半分的外れな説教だの、はたまたその体すら為していない放言だのを安全な位置から投げつけたいだけのカスしかここにはいない。
このタイトルを見て、意識高い系文系イキリ勘違い野郎に何事か物申してやろうと考えたそこの画面の前でニチャニチャしているパソカタオタク(パソコンカタカタキモオタク: 声は小さいがタイプ音はでかい)のことである。
あるいは増田のことかもしれない。増田は日頃増田に生息している訳ではないが。
お分かりの通り、これは釣り記事である。そもそも意識高い系文系イキリ勘違い野郎が増田に記事を書くわけがない。が、一応タイトルに嘘はない。
ので意識高い系文系イキリ勘違い野郎を志す意識高い系文系イキリ勘違い野郎予備軍のことを思って以下を書く。
ちなみに、この記事のタイトルは増田が一番嫌いなタイプのそれである。自分で設定したのに今、額に青筋が浮かんでいる。
本項ではWebエンジニアになるにあたって増田がやったことを列挙する。
1.プログラミングを独学する
2.スクールに入る
3.アルバイトをする
なるほど、至極単純である。では順に詳細を見ていく。
ここに関しては特に言うこともない。
ネットの記事を見ながらCだのDだのC++だのを実際に吐くまで勉強した。
その経験を踏まえて意識高い系文系イキリ勘違い野郎予備軍にアドバイスするならば、独学の上で最も身になるのは"C++を用いて簡単なスクリプト言語のインタプリタを実装する"ことである。
インタプリタの実装という作業はプログラミング言語そのものに対する解像度を飛躍的に向上させる。
不可思議なお約束の塊であった文法や意味論が因数分解されるように頭の中で整理され、ブラックボックスであった標準ライブラリの内部について想像が及ぶようになる。
道具たるプログラミング言語に対する理解は、当然その使途であるプログラミングそのものを助ける。
ところでパソカタオタク諸兄姉は「なぜ今C++などという時代遅れのクソ言語を」と思ったかもしれない。
確かにC++はもはや洗練から程遠い聳えるバベルの塔である。しかし、こと言語実装の習得においてはこれほど適している言語もない。
C++はGC付きの他言語と比較して抽象度が低く、全てを自身で管理しなければならないが故に"便利な魔法"にあまり頼れないのである。
また、C++で導入された様々な思想、イディオムは他の言語にも大きく引き継がれている。
例えば洗練という意味でC++の対極に位置するRustという言語は、もはや本質的にはC++そのものである。
Rustの代名詞である所有権、ライフタイムはそれぞれC++の反省から生まれた言語要素であるし、move semanticsはC++11におけるmove semanticsと同様のものである。
GC付き言語の利用者にとってしばしば混乱の原因となりそうな`str`と`String`も`std::string_view`と`std::string`を知ってさえいれば迷いの発生する余地はない。
他のより抽象化された言語についても、C++との対応を考えることでその言語や標準ライブラリそのものの実装について十分に理解を深めることができる。
なぜならば過去の多くのスクリプト言語やコンパイラはC/C++によって実装されていることが多いからである。
そんなわけで、増田は"C++を用いて簡単なスクリプト言語のインタプリタを実装する"ことを勧めている。
増田が入ったスクールは、多くのそれが半年あたり70万程度の授業料を取る(らしい)のに対して同期間で28万程度と非常にリーズナブルであった。
ただし、卒業までは最低4年と長期間を要するし、増田は卒業後も2年さらに通った。
おいそこの意識高い系文系イキリ勘違い野郎予備軍、カスみたいなプログラミングスクールに入るな。
ところでそろそろ察せられるだろうが、増田の前職とは学生を指している。
大学は情報工学を教えてくれるが、別段それを学んだからといってプログラミングができるようになるわけではない。あくまでそれらは相補的なものである。
一方で、独学では分野に偏りが出がちだし、なにより独学にも金が要るので学生の身分にとってプログラマのバイトは良い選択肢である。
アルバイトはITエンジニアの経験に含めなくて良いのか怪しいが、増田のバイトの業務内容はWebエンジニアと言いきってよいか悩ましい類だったので嘘は吐いていない。
ちなみに増田は増田に書き込むような人間であるからして社会性というものが欠落している。
ちなみに月収は大学院2回生の収入0時代からの差分で算出して+50万なのでつまるところそれが現在の月収である。
増田にとって低くはないが、決してITエンジニアとして高い方であると主張することはできない程度の額である。
釣りのためにタイトルに含めた以上最低限の説明のはしたが、増田は金の話をすると脳の血管がブチギレそうになるのでこれ以上その話はしない。
ここまで読んだならわかると思うが、増田は意識高い系文系イキリ勘違い野郎(タイプ音がでかい)ではなく、パソカタオタク(パソコンカタカタキモオタク: 声は小さいがタイプ音はでかい)である。
そして、意識高い系文系イキリ勘違い野郎予備軍に言うべきことがあるとすれば、そもそもこの記事をここまで読んでいる時点でITエンジニアには向いていないので止めといたほうがよい。
また、ひょっとすると思い違いをしているかもしれないが、ITエンジニアというのは大抵 (増田は社会経験がほぼないので一般論を言うことは出来ないが)意識高い系イキリキラキラ野郎サイドではなくパソカタオタクばかりである。
というよりTwitterにいる意識高い系イキリキラキラ野郎は多くの場合意識高い系文系イキリ勘違い野郎予備軍を養分にする人でなしである。騙されてはならない。
また、一つ理解しなければならないのは意識高い系文系イキリ勘違い野郎予備軍諸兄姉が張り合わなければならないのは、プログラミングスクールの同期でも、「#駆け出しエンジニアと繋がりたい」している有象無象でもなく、幼少から寝食や友人や遊びを自ら捨ててパソカタにのめり込んでいた、そして現在進行系でのめり込んでいる歴10年や20年をゆうに超えるSSRパソカタオタクであるということである (そしてそれはNRパソカタ増田も同様である)。
彼らが「スクールで半年学びました」で並び立てるような人間でないのは単純な算数でわかるほど明らかである。悪いこと言わんからキラキラWebエンジニアを目指すのはやめとけ。
あるいはそれでも目指すのであれば自分が何を捧げられるのかを考えた方がいい。
自分の仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分で作業に当たったりと色々なんだけど、
最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分の案件にアサインされた。
内容としてはとあるテーブルの特定カラムのバリデーション処理が漏れているから追加してもらって、なおかつユニットテストを修正する、というもの。まあ簡単な奴。
Issueを振ってからしばらくすると同僚エンジニアから質問が来た。
「ん？」と思った。いや別に特殊なことなんて何もないIssueだし似たようなテストケースもリポジトリ上に山程あるしどうにでもなるじゃんって。
まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合のテストケースを網羅してください」みたいな返信をした。
しばらくするとまた質問が来た。「△△の場合のテストケースの実装方法がわかりません。」
いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有のビジネスロジックのことを聞かれるならわかるけどこんなレベルの対応どの企業のどの案件で振られても同じことやるだけやん。
この質問してるのが未経験の入社1ヶ月目の新入社員なら自分は笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。
その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。
成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。
自分はITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラやインタプリタレベルの不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。
こんな公式ドキュメントとデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。
その人はとにかく「わかりません」が多い。
レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。
うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。
こっちもいろいろ対策を考えた。
Issue振るときはソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。
でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。
もはやその人に仕事を振るのは「この作業を担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。
最低でもあと1年くらいは人事はこの状況らしい。。。
こういう状況ってどう扱うのがいいんだろうなぁ。
