「低コード」はデフォルトで宣言型ですか？
最近、私の肌に浸透しているのは、Salesforceが「宣言型開発」という用語を「低コード」または「ビジュアルコード」という意味で使用していることです。
たとえば、 この記事では、命令型プログラミングと宣言型プログラミングの違いについて説明します ですが、「低コード」ソリューションは宣言型（したがって優れている）であると主張しています。
しかし、私はそれに同意できるかどうかわかりません...実装では、それは命令型プログラミングであるように見えます。
私はここで間違っていますか？テキストを図形で置き換えると、上記の「宣言的」な手順がどういうわけか？
これは、おしゃれな新しい服を着たトランザクションスクリプトだけではありませんか？
TL; DR-ほとんどの人にとって「低コード」は通常「タイピングがほとんど/まったくない」ことを意味し、「宣言的」は少し異なるものを意味します。 Salesforceで許可されているのは「宣言型開発」ではないことに同意します。
私はまた、いくつかの小さな違いを除いて、ロバートの答えにほぼ同意します。 FWIW、「命令型」と「宣言型」という用語は、初期のプログラミング言語にさかのぼります。
「命令型」プログラミング言語は、マシンレベルで実行することを基本的に模倣する言語を説明するために使用されました。つまり、値を計算するコマンドのリストを実行し、値を格納場所に割り当て、値を出力デバイスに送信しました。 。ステートメントは、ループ、if-then-else構造などを実装するための分岐点と条件を含むシーケンスで実行されました。 Fortran 、 [〜＃〜] cobol [〜＃〜] 、 [〜＃〜] algol [〜＃〜] 、-などの言語 [〜＃〜] c [〜＃〜] 、および Pascal はすべて必須でした。あなたがhowを指定したので、それらは「命令的」でした。時々、マシンレベル（すなわちC）で何が起こったかに非常に密接に一致する方法でプログラムは働きました。
「宣言的」プログラミング言語はより抽象的であるはずであり、より詳細に指定したwhat計算したかったが、それがどのように行われたかを示していない。 [〜＃〜] snobol [〜＃〜] や Prolog のような言語はこの方法でした。そのような言語は、実行するためにその下に大きな計算エンジンが必要なため、一般的に解釈されました。その後、それらを実行可能イメージにコンパイルして、計算エンジンがイメージの一部になるのが一般的になりました。
どちらの場合も、プログラムの構成方法を知るためにプログラミング言語の要素がどのように実行されるかを知る必要があるため、2つの用語の二分法は多少失敗します。
私はSalesforceでプログラミングしていませんが、 [〜＃〜] bpel [〜＃〜] でプログラミングしましたが、外観は非常に似ています。基本的に、比較的少ないタイピングでフローチャートを描画します。このアプローチは、1980年代に登場していた初期のグラフィカルプログラミング言語に戻ります。図形のドラッグアンドドロップに多くの時間を費やし、プログラミングステートメントの入力に費やす時間を短縮できるという意味で、これは "低コード"です。作成しているフローチャートは命令型プログラミング言語と同じ要素（ステートメントのシーケンス、値の計算、値の割り当て、分岐点など）を持っているので、それは依然として必須であると私は主張します。
より宣言的なグラフィカルプログラミングシステムがいくつかあります。私は現在 SnapLogic 、 iPaaS を使用しています。これは [〜＃〜] apl [〜＃〜] またはSNOBOLを思い出させますプログラムを構築するために考えなければならない方法で。特定のことを指定する必要がない（つまり、暗黙的に発生するデータアイテムのリストをループする）のは良いことですが、少なくとも私にとっては、より緊急性の高いことを簡単に実行できるようにすることは、より困難な場合があります。アプローチ。
最終的に私はロバートに同意します-重要な質問は、「これを何と呼びますか？」そして、「それで物事を成し遂げることはどれほど簡単ですか？」
私はあなたの批判を共有します、そして、私はロバートの答えに同意しません。ロバートは言う
宣言型プログラミングは、マシンに（方法ではなく）何をすべきかを指示します
コンピュータに何をすべきかを伝えることは、基本的にどのように行うかを伝えることと同じです。唯一の違いは、プログラミング言語の「レベル」です。それは同じパラダイムです。
宣言型プログラミングの本質は、ステップを提供するのではなく、結果として何が欲しいかを伝えることです。そして、これはウィキペディアの定義と一致しています：制御フローの説明の欠如。
SFのグラフィカルな例は、フロー制御を表現するための非常に優れた方法であり、ifステートメントとループを完備しています。
命令型プログラミングは、通常は個々のプログラミング言語の命令を記述することで、マシンに方法でタスクを実行するように指示することに関するものです。また、基本的に方法を説明しているメソッド呼び出しも含まれます。
宣言型プログラミングは、マシンに何をするかを指示し、マシンを動作させますhowそれを達成するために。 .NET FrameworkのLinqと同様に、SQLはこのカテゴリに分類されます。あなたはマシンに何を望むかデータを伝え、それはうまくいきます方法可能な限り最良の方法でデータを取得します。
これらの用語の正確な定義はここでは役に立ちません。実際には多くの実装の詳細と内部で行われた決定（実際how）ユーザーが気にする必要のないもの。
SalesForceがこれを「宣言的」と呼ぶ主な理由は、ビジネスワークフローを説明するためのビジュアルシンボルが含まれていて、ワークフローを正常に作成するためのプログラミングスキルは必要ないためです。基盤となるワークフローエンジンがワークフローを読み取り、実行に必要な機械語命令を作成します。
理論的な観点から見ると、「宣言型」言語は通常チューリング完全ではなく、それが必要ではない、または逆効果でさえある状況で使用されます。たとえば、正しいことを証明する必要があり、問題を停止します。
たとえば、HTMLと古いCSSバージョンは純粋に宣言的であり、「この段落の前に見出しがあります」、「見出しは大きなフォントを取得します」これは情報を表示するのに十分ですが、処理には不十分であるため、JavaScriptを使用して命令型プログラムからドキュメント構造を操作します。
レンダリングエンジンはまだ宣言型ドキュメントツリーと連動しているので、ページのレンダリングには有限の時間がかかることを確認できます。HTMLとCSSだけで「無限ループ」のWebページを作成する方法はありません。 JavaScriptで無限ループを記述できます。レンダリングエンジンを常にビジー状態に保つためにできることは、新しい変更を継続的にフィードすることだけです。
ただし、ソフトウェアスタックの最下部では、CPUは命令を順番に実行する必要があるため、完全に宣言型のスタックを作成することはできません。したがって、宣言型のスタックがある場合は常に、ユーザーが対話する1つのレイヤーになります。
プログラムが必ずしも宣言的ではなく、グラフィックで表される「ビジュアル」プログラミングモデルもあります。画面上のオブジェクトの数は有限であるため、宣言的な「ループあり」ファイル形式で保存できますが、ループを実現して実際に実行するには、ファイルをコンパイルする必要があります。チューリング完全言語が必要な場合は宣言型フレームワークを残します（テキストソースファイルも有限サイズですが、終了しないプログラムを記述できます）。
純粋に宣言的なモデルが機能するユースケースは多数あり、制限から得られる安全性はそれに見合うものですが、それは使用される編集方法とは無関係です。