言語設計原則
うまく設計されたドメイン固有の言語、または一般的な言語は、迅速かつ簡潔な方法で自分の考えを表現するだけでなく、フィードバック応答を簡単に理解する能力を持つ人々に権限を与えます。 新しいアイデアをテストし、中間結果を理解する—それは直接あなたが反復することができますどのくらいの速に影響を与えるので、研究するこ 高速イテレーションを使用すると、一見しただけでは動作しないパラメータを含むより広い範囲のパラメータをテストすることができ、調査しているドメ したがって、言語設計は、非線形の方法で問題を解決するために必要な合計時間だけでなく、多くの場合、解決策を見つけるための鍵となります。
重要な質問が出てくる—良い言語とは何ですか？ すべてのドメイン固有の言語が従うべきガイドラインはありますか？ 私たちは、二つの基本的な原則があると信じています:
- 人々は、彼らが作っているものへの即時の接続を必要とします
この原則は、最初に公にBrettビクター、人間とコンピュータの相互作用の先見の明によ この原則に違反すると、ユーザーが解決しようとしている実際の問題からユーザーが遠ざかり、その結果、理解が低下し、間違いの数が増えます。 - 人々は、彼らが使用しているツールによって制限することはできません
人々は明らかに彼らの表現力を制限するツールを拒否する傾向があります。 これが、ウェブサイト作成者、ゲーム作成者、ビジュアルプログラミング言語など、多くのWYSIWYGソリューションが追いつくことがない正確な理由です。 WYSIWYGテキストエディタよりも複雑なDSLは、ユーザーに事前定義された高レベルコンポーネントのセットがあまりにも限られているため、この原則に簡単に違反する可能性があります。 たとえこれらのコンポーネントをコードを書くことによって拡張することができたとしても、基礎となるプログラミング言語に頼る必要性は設計を損ない、あまり技術的でない聴衆にとっては使用できなくなります。
原則違反
これらの原則のいずれかの違反は、常に最適ではない解決策につながります。 グラフィックデザインをもう一度考えてみましょう。 Photoshopを使用することは、HTML、Sass、JavaScriptコードを書くよりも常に優れていますか？ 間違いなく これらの解は、それぞれ第一および第二の原理に違反する。 Photoshopは、事前定義された、ほとんど拡張可能なツールの限られたセットでWYSIWYGデジタルキャンバスを提供します。 一方、HTML、Sass、JavaScriptはテキストインターフェイスを提供するため、ユーザーを実際の作成から遠ざけますが、表現力に厳しい制限を設定しません。 二つのユースケースを考えてみましょう：
- ウェブサイトのデザイン。 メニューバーには5つの均等に配置された項目があります。 新しいアイテムを追加してwebサイトのカラーパレットを変更する場合は、HTMLの単一行とsassのカラー変数を変更するだけです。 ウェブサイトがどれほど複雑であっても、すべての要素は自動的に更新されます。 新しいメニュー項目を作成し、要素を配置するための配置ツールを使用し、手動で色を変更し、おそらくより複雑なウェブサイトの領域でいくつかの変
- 芸術的な絵。 テキストエディター内でHTML、SVG、Sassを使用して芸術的なビジョンを表現することはほとんど不可能です。 プロセスがより創造的で発見可能であればあるほど、WYSIWYGツールセットとインスタントフィードバックループがより重要になります。
両方のアプローチを融合させることは可能でしょうか？ それは可能であるだけでなく、すでに正しい方向に向かっている解決策があります。 Mac OS用の究極のデザインツールキットとなったSketchについて考えてみてください。 なぜ多くの人がPhotoshopよりもそれを好むのですか？ 答えは驚くほど簡単です—スケッチは、Photoshopよりも少ないそのユーザーの表現力を制限します。 これにより、再利用可能な設計要素を作成し、sassと同じように、対話型のWYSIWYG環境でパラメータを一括更新することができます。 デザイナーの経験をさらに向上させるには、他にも多くの方法があります。 さらにインスピレーションのために、ブレット*ビクターから別の話を見て、動的なビジュアライゼーションを描画します。
Dslの呪い
完璧なドメイン固有言語の非常に基本的な原則を知っている場合、利用可能なドメイン固有のツールはまだありませんか？ なぜ私たちは無制限のWYSIWYGの世界に住んでいないのですか？
ドメイン固有の言語は、データを操作して理解するための比類のない方法を提供しますが、ソフトウェアの設計パターンを静かに密輸しています。 お互いに話すことができない多くの小さなDslの存在は、機能不全で断片化されたソフトウェアの世界に長い視点でつながります。
現実の世界では、ドメイン間に一定の協力があります。 画像操作は、機械学習やバイオインフォマティクスのニーズによく使用され、ますますアーキテクチャや車両設計の重要なツールになっています。 急速なIoTの開発により、より小型で自律的なデバイスが実現し、早期の疾患検出、健康監視システム、またはインテリジェント都市のための新しい世界が開かれます。しかし、ソフトウェアの世界ではほとんど協力していません。
しかし、ソフトウェアの世界ではほとんど協力していません。 ソフトウェア開発者は同じコードを何度も何度も書いているため、開発コストが高く、革新が停滞しています。 お気に入りのグラフィックスソフトウェアからシェイプエディタを取得し、ニーズに合わせて微調整し、機械学習ツールで接着し、3D印刷のニーズに合わせてAI支援された3Dモデリングツールを作成することはできません。 代わりに時間の、あなたは現在、このようなタスクを達成するために数日または数ヶ月を必要としています。 同様の機能を実装するライブラリを見つけたとしても、”制限なし”の原則に従い、真に柔軟な環境を提供するためには、ユーザーがモデルの構築方法を微 その結果、既存のコンポーネントを改善したり、データを操作する新しい方法を発明したりする代わりに、開発者は新しいアプリケーションごとに既知のソリ
ルナ、言語
第一の原則に従うためのドメイン固有の言語のガイドラインは明確です。 人々とその創造物との間の即時の接続を提供するためには、ドメイン固有の言語は、単一の、スムーズな経験で豊富なデータの可視化と直感的なデータ操作を組 しかし、それを正しく行う方法は経験則ではありません。 これは、特定のドメインとユーザーの好みに強く依存しており、第二のパラダイム、コンポーネントをカスタマイズする機能がさらに重要になります。しかし、第二の原則に従うことはより難しいです。
どのように我々は言語を設計し、それが人々の表現力を制限しないことを確認することができますか？ どのようにして、ユーザーがカスタム再利用可能なコンポーネントを作成し、既存のコンポーネントを深く変更することができますが、インターフェイ アイデアは、ユーザーが視点を段階的に変更できるようにすることです。 基礎となるプログラミング言語に頼るのではなく、文字通りすべてのコンポーネントに飛び込み、同じ（または非常に類似した）言語を使用してサブコンポー ネストされたコンポーネントにさらに飛び込むことで、ユーザーは要求に応じて抽象化の高レベルから低レベルに徐々に進むことができます。これはまさにLunaが行うことです。
これは、三つの主要な概念に基づいて構築されました：
- データの可視化と操作環境
最高の視点から、ルナは、対話型で拡張可能なWYSIWYGコンポーネントを使用してデータを視覚化し、操作することができます。 さらに、Lunaは、新しいコンポーネントを簡単に定義し、既存のコンポーネントを変更し、コミュニティと共有する方法を提供します。 - データフローグラフ
文字通り、高レベルのコンポーネントがデータフローグラフを形成して一緒に配線されている方法を確認するためにズームアウ それらを再配線したり、新しいコンポーネントを挿入してグラフの動作を再定義したりできます。 Lunaは、高から低まで、抽象化のすべてのレベルに広がるコンポーネントを提供します。 統計関数の上にキャンバスをペイントすることから、ビットごとの演算子 - ネストされたデータフローグラフとコード表現
Lunaのすべてのコンポーネントは、例外なく、他のコンポーネントから構築されています。 あなたは常に抽象化の所望のレベルまでのすべての方法を潜り、あなたのニーズにそれを微調整することができます。 また、複数の接続されたコンポーネントを新しい、より強力なコンポーネントに折りたたんで、他のユーザーと共有することもできます。 さらに、Lunaは、データフローグラフからコードへ、またはその逆への表現を切り替える非常にユニークな機能をユーザーに提供します。 それは非常に重要な真実を意味します—グラフはコードと同じくらい強力です。
Lunaは、視覚的に豊かなドメイン固有の言語を構築し、ホストするための統一された環境として設計されました。 これは、ドメイン間の境界をぼかし、異なる分野のツールがシームレスに通信し、共存することを可能にします。