Liscript-Web REPL:キス、自転車、掘削機





少し前に、私はLiscriptと呼ばれるLispに似た言語のインタプリタを書きました。 カーネル、TCO、GUI、REPLボットなどの実装機能に特化したHabréの記事をいくつか公開しました。 最近、REPL Webインターフェースを追加しました(記事の最後のリンク)。



キスと掘削機はそれと何の関係がありますか? ほとんどの人は、KISS(シンプルにバカにしてください-シンプルにしてください、バカにしてください)、YAGNI(あなたはそれを必要としません-建築宇宙飛行士についてさまざまな程度の壮大な人々の声明のような略語を知っていると思います」すべてをできる限り簡単にする必要がありますが、簡単ではありません」など



穴を掘るという仕事があるとします。 ソリューションのオプションは何ですか? シャベルを手に取って自分で掘るのは安くて陽気ですが、長い間、おそらく最適ではありません(シャベルの所有レベルとピットのサイズによって異なります)。 Tajiksにアウトソースします(このオプションについては言及しませんでしたが、ここでは検討しません)。 掘削機を使用するのは迅速かつ効果的ですが、高価です:ガソリン/家賃、さらに庭の門に行くという事実ではないので、フェンスを取り壊す/復元する必要があります また、モデル(場合によっては100,500のオプションから)を決定する必要があり、自分でモデルを管理する場合は、そのすべてのレバーとペダルを理解する必要があります。



もちろん、あなたがプロの掘削機である場合、あなたは1日に200個のピットを掘るか、または1つになるように努力し、最初のタスク(穴を掘る)は必要ありませんが、スキルのトレーニングまたはデモンストレーションとしては、選択は明らかです(それだけが残っています)モデルの問題)。 しかし、専門家でさえ、シャベルで花を植えます。



一般的に、タスク用のツールの選択と、プロジェクト中にネコの下で選択した特定の(物議を醸すと思われる)決定について。



単一リンクリストの実装


Liscriptにはポイントペア(consセル)がないため、コードとその中のデータの両方の主要な構造はリストです。 Javaバージョンのインタープリターでは、フィールドcarおよびcdrを使用して独自の最も単純なクラスを作成しました。 LinkedListやArrayListなどの標準Javaコレクションを使用できます。ほとんどの場合、割り当てとガベージコレクターとの関係の点で最適化されています。 しかし、2番目のオプションにリファクタリングすることは難しくありませんが、私は自分の自転車を選びました。



トークナイザー/レクサー/パーサー


これは興味深い例です。 入力テキスト/行を読み取って、完成したAST(抽象構文ツリー)に変換し、テキストからトークンを抽出して階層構造に整理する必要があります。 タスクはよく知られているだけでなく、構文解析と構文解析の広大な理論、およびwww.antlr.orgなどのさまざまなパーサーの多くのライブラリー実装があります。複数行の文字列リテラルとコメントを検討してください。 さらに、これらの3つのバイクがあります:Haskell実装(既製の多くのソリューションにもかかわらず:parsec、atparseparsecなど)、Java実装のコア、およびコードテキストを構文的に強調表示するSwing GUI。



WEBバックエンド



ケース履歴:これは、無料の料金プランであるHerokuを選択したアプリケーションのホスティングとして、私の最初のWebプロジェクトです。 1つのJavaチャットのビルドシステムのうち、MavenではなくGradleからアドバイスを受けました。さまざまな魅力的な言葉で動機付けをしました。 HerokuでGradleアセンブリオプションを選択し、ディスクにダウンロードしたデモではRatpackを使用したと信じていました(Mavenアセンブリの例が何であるかはわかりませんが、同じである可能性があります)。 私は他のWebサーバー(および一般的なWebテクノロジー)の経験がなかったため、このデモ例を使用するか、Jettyをインストールするかを選択する必要がありました。準備ができて調整されたラットパックですが、どういうわけかそれを処理します。 見つかった例の中から2番目のオプションを選択しました。3分の2はGroovyでしたが、最終的には長い同期操作を実装する方法を見つけ出し、ページレンダリングではすべてが簡単でした。



WEBフロントエンド



ここでは、一般的に、この地域は長年にわたって急速に発展しているため、最も多様な技術を選択するための選択肢の海があります。 そして、さまざまなフレームワークの謝罪者は、彼らの選択がより良い/より効率的/より有望であり、それが「2017年にWEBを書く」ための唯一の方法であることを全世界に(そしてお互いに)証明します。 純粋に実用的なタスクを解決するには、REPLのWebインターフェイスを記述するための穴掘ります。





ご想像のとおり、私はもちろん3番目のオプションを選択しました:)。 jQuerryを使用しなくても、このマシンも学習する必要があるためです。 Babel / Webpack、およびフロントでトレンディな別の100,500語なし。 IEをはじめとするさまざまなブラウザのデバッグの喜びを経験した私の人生で初めて、CSS定数をファイルの先頭で宣言するのではなく、CSS定数をハードコードすることを余儀なくされました。さまざまなトレンディなフレームワークが提供するフォーマットは、言及されたフレームワークの使用を暗示しています。



しかしもちろん、私はあなたにとってサイクリストのように頑固ではなく、掘削機ではありません。 Webインターフェースのいくつかのタスクで、既製のライブラリーを選択しました。



分割パネル


REPLには、本当に必要でした。 強力なWeb GUIフレームワークはそれらを構成に実装しますが、重機を除いて、より小さな既製の実装を調べ、3-4を試した後、まだ1つを選択しました。 それはjQuerryを引き寄せますが、私はあまり好きではありません(もう何も必要ありません)が、インターフェースの応答性の点でははるかによく反応します。 時間/欲求があれば、jQuerryなしで自転車で書き換えることができます。



コードの強調表示


ここで私は幸運だと思います-この問題を解決するために、すぐに壮大なcodemirror.netライブラリを見つけ、その機能を見つけ、私の言語とデザインテーマの構文用のプラグインを作成しました。 このライブラリはシンプルで軽量であり、静的テキスト領域とユーザーコード編集時のダイナミクスの両方で適切に機能するため、自転車パーサー/レクサーを作成しませんでした。



おわりに



もちろん、私が上で下した決定は、少なくとも議論の余地があり、曖昧であることを認識しています。 可能性のある(そして一部のポジションからさらに優れた)ことは、既製の技術ツールを使用することでした。 パーサー/レクサーを書くことで何が得られましたか? 有限状態マシンで同様のバイクを作成した経験、何が起こっているかを完全に制御し、簡単にカスタマイズできる可能性。 何が失われますか? 既存の既存のパーサーを理解しておらず、それらを習得しておらず、将来それらを使用する必要がある場合は、ゼロから学習することを余儀なくされます。 また、個々のローカルタスクのオプションごとに同じ判定が行われます。 しかし、そのような場合は、選択する必要があるため、すべての長所と短所を比較検討し、結果を考慮する必要があります。 これについてどう思いますか?



Liscriptホームページ

オンラインREPL



All Articles