orange @[email protected]

このわりとある古典的なBASICインタプリタの実装方法で、中間言語にした後それを外部に保存する機能（コンパイラ）と、その中間言語を実行するインタプリタにわけたら、それはそのまま前者はコンパイラ、後者はVMって呼ばれるだろうしJavaとか.NETとかと同じかも＞＜

英語の本を日本語に翻訳する→コンパイラ
英語の本を日本人にわかるように日本語で読み上げてあげる→インタプリタ

って言えば混乱ないかも？＞＜

たとえば、古典的なBASICインタプリタの実装で、内部的には『まず中間言語に変換してから実行する』って実装ってわりと普通な実装かも＞＜
いちいち別けては言わないけど、あえて『中間言語に変換する部分』だけを指せばそれは（BASICインタプリタ実装の内部の）コンパイラかもたぶん＞＜

ていうか、中間的な存在がある事はあるけど、処理後の対象が仮想機械であるかどうかはそれがコンパイラであるかどうかには関係ないよね感＞＜

Windowsで気軽に自分用自作アプリ(の内の一部のよく手を加えるもの)を普段からVisualStudioからデバッグ実行して気が向いたら後回しにしてた機能を追加する
・・・ってやってるのと同じくらいの気軽さでAndroidでもアプリ作れたらいいのに・・・＞＜

自由にソフトウェアが開発出来ない計算機はフェアじゃない＞＜＃ って事でスマホはAndroidの使ってるけど、Windowsでは自分で使うアプリは自作しまくってるのにAndroidでは結局実用的なアプリ自作してないの、開発環境の使いにくさともうひとつコンパイル遅すぎてめげたのが理由＞＜；

C# 、『勉強』って感じに構えなくてもとりあえず使えちゃうくらい取っ付きやすいよ＞＜
VisualStudioに頼りまくればいわゆるLLの類いよりも易しいよ＞＜

コンパイルの速度が要求されるかどうか、オレンジの実際の感覚では、巨大なもの(巨大なのでいじらない)と小規模なもの(小さすぎて改良の余地が少ない)はそれぞれ頻繁にいじらないので遅くてもよくて、中規模だと弄るので一瞬でコンパイル出来ないとストレスみたいな感じなので、"中規模な"かも＞＜

悟りが開いたっぽさ＞＜；

巨大なプロダクトに厳密にそして慎重にコードを書いて滅多にコンパイルしないならそれはそう＞＜
中規模(？)なアプリを半完成状況から使いながら開発する場面だと、機能ひとつ実装する度に長時間かかるのは億劫かも＞＜

「狭い道を」走りやすい＞＜(多間接だけどどう動くか想像しやすいのでほぼ勘で走れる)
バックがほぼ不可能とはいえ一応出来る＞＜(実際バック込みで使われてるどうがある)

アプリデバッグ実行してて「あ＞＜；」って小さなバグに気づいた時に、手直しして再びデバッグ実行してその部分がちゃんとなおったか見てみるまでに分単位で時間がかかるなんて、Delphiユーザーには信じられない環境＞＜

xコンパイルといるか
oコンパイル通るか

コンパイル速度が要求されるかどうかは場面によるかも？＞＜
DelphiとC# は、よほど巨大なものじゃなければ一瞬でコンパイル出来るので、そこらの起動が遅いインタプリタな環境よりも手直しして実行とかコンパイルといるか試してみるのを気軽に高頻度で試せる＞＜
(という環境にずっと甘えてきたので、気軽にコンパイル試行できない環境はかなりイライラする＞＜；)

x間接
o関節

ていうかなんで日本では、アメリカで使われてる内輪差軽減の為だけの最後尾台車がついてるタイプの多関節トレーラー使わないんだろ？＞＜
あれ、バックがほぼ不可能って欠点がある以外はすごく走りやすいのに＞＜