珍しい従来のデザイン

こんにちは 少し前、私はさまざまなプログラミング言語を駆使することにしました。 少なくとも私はそれらのそれぞれの例を簡単に見て、ウィキペディアと他のブログを調べました。 なんで? 恐らく純粋に好奇心からです。私にとって根本的に新しいものは何も発見していないからです。 だから、トピックに近い。 多くの現代の(そうではない)言語では、 ifwhilecaseなど、多かれ少なかれ標準的な構造が使用されます。 しかし、一部の言語では、これらの構成要素は存在しますが、驚くべき特性と能力を持っています。 以下では、他の言語に存在し、変更された形でのみ存在するプログラミング言語の概念のみを検討します。 ユニークでユニークなコンセプトは考えません。 また、私は主に希少または死んだ言語を検討します。 誰も気にしない、猫へようこそ!



ベータ版



BETAはオブジェクト指向言語であり、Simulaの継承者です。 私が検討する多くの素晴らしい機能があります。 どちらかといえば、ウィキペディアの記事があります。 したがって、ベータ版では、2つの(!)制御構造体(ifとfor)のみがあります。 そして、これは人生に十分です。 if構文は、各thenがifの後に来る式の結果を書き込むことができるため、注目に値します。 これにより、elseブランチを取り除くことができるだけでなく、このアプローチによりケースコンストラクトをシミュレートすることができます。

(if x

// 17 then …

// 33 then …

// y+3 then …

else …

if);



(if (x>0) and (y<0)

// True then …

// False then …

if)






言うまでもなく、素晴らしい言語です! すべての構文は、1 ページで簡単に説明できます 。 BETAは、割り当ての設計でも興味深いものです。 ->のように見え、複数の割り当てを行うことができます:

10->j -> k;

i + 3 * j->k ;






同じ構文を使用して、C ++と同様に、オブジェクトにデータを送信できます。

'Hello, World!'->putline;





しかし、最も興味深いのは、サイクルを実装する可能性です。 たとえば、完全に正当なループは次のようになります。

X -> Root;

L: (if (X-Root*Root -> fabs) > X / 10E6 then

0.5 * (Root + X div Root) -> Root;

restart L;

if);






そして、これらすべては、基本的に新しいものは何もないという事実にもかかわらず、同じループ、代入演算子、ifステートメントです。 一部の制限は単に削除され、新しい制限が追加されました。



エッフェル



この美しいプログラミング言語は、ループ演算子を1つしか持たないという事実によって記憶されていましたが、非常に機能的で最小限です。 ここに彼の定義があります(ウィキペディアから):

from



until



loop



end






loop ... end以外のこれらの部分は必要ありません。 したがって、私たち自身がサイクルを望み通りにしています。 無限ループが必要ですか? ループのみ...終了します。 whileループが必要ですか? until ... loop ... end。

理由はわかりませんが、これらの「デザイナー」が好きです。 結局、条件付きステートメントでオプションのelseブランチを使用し、このメソッドを使用してサイクルを決定しないのはなぜですか?



アイコン



アイコンは超高級言語として位置付けられています。 私のコメントで以下の例を見て、この声明に反対することは困難です。 パスアイコン-文字列を操作する、これは本当に素晴らしい仕事をします。 ここで面白いのは何ですか? はい、ほとんどすべて、私はどこから始めてもわかりません。

アイコンでは、文字列を使用して、論理演算を実行でき、次のように書くことができます

S:="ab"

S:=S || "cd" # S == "abcd"






私にとって、これはPascalやBASICなどの言語で+演算子を使用するよりも論理的です。 確かに、操作の名前-連結も、それ自体を物語っています。 さらに、別の便利な構造があります:単項演算子*。 その後に行がある場合、その行の文字数を返します。

S:="abcd"

write(*S) # '4'






これは、他の言語のlen()関数よりもはるかにエレガントです(名前は異なる場合がありますが、これは重要ではありません)。 このアプローチが他のプログラミング言語で使用されないのはなぜですか? 答えは明らかです:キャラクターの曖昧さ。 C ++やJavaなどの言語はすでに圧倒されていますが、問題の別のパッケージがあります:特定の場所で文字が正確に何をするかを認識する必要があります:乗算、または文字列の長さを返す? それとも恐ろしいことを意味します:

S:="abcd"

S[3:3]:="aaa"

S[*S+1:*S+1]:="y"

write(S) # , !






私はすぐにもっと伝統的なものに移る必要があると感じています...



ファクター



その前に、私は主に中立的な方法で構文構造の異常なバリエーションについて書きました。読者は言語に良いアイデアが埋め込まれているかどうかを自分で決めることができます。 しかし、構文を歪める必要がない方法については、ここで書きます。 代表的な例:Factorの条件付きifステートメント。 FortのようなFactorの主な仕様は、スタックに関連付けられた逆表記です。 このため、条件はifステートメントが呼び出されるに評価されます。 演算子を伝統的に書くと、

IF THEN 1

ELSE 2

END IF






私の意見では、これは嫌です。 Fort開発者は別のソリューションを見つけましたが、それははるかに優れています。 IFは条件とthen-branchを分離します。 だから

IF

1

ELSE 2

END IF






しかし、ファクターは反対の方向に進むことにしました。 階乗を計算する例のみを示します。

: tail-factorial

dup 0 =

[ drop ]

[ [ * ] [ 1 - ] bi tail-factorial ]

if ;






質問:何か理解できますか? 私は一度に一つのことしか理解していません-当時も他にもありませんし、両方の分岐の後であれば隠れていました! 意味? コードを読んで、読んで、読んで...そして最後に、これらが条件文の分岐であることに突然気づきます。 フォートでは、目の前にあるもの、つまりサイクルまたは状態がすぐにわかります。 また、フォートでは、プログラムの論理構造がよりよく見えますが、ファクターでは、角括弧のみが表示されます。 彼らは賢明でした、彼ら自身はあまりにも賢明でした...



エイダ



この強力で複雑なプログラミング言語では、配列の割り当て全体と改善された開始...終了ブラケットを覚えています。 それらから始めます。 パスカルを教えていた頃、私は自分が望む場所で変数を宣言できなかったことにひどく悩まされていました。 地獄では、この問題は解決されています。 begin ... endの前に、宣言部を挿入できます。ここで、このブロックでのみ使用されるすべての変数とデータを定義します。 例:

declare

i : integer;

begin

-- , i

end;

-- i !






2番目の興味深い点は、配列の割り当て全体です。 2つの同一の配列aとbがあるとします。 すべてのデータをaからbにコピーする必要があります。 Adaでは、このプロセスはb:= aと書くことで1ステップで実行できます。 しかし、一つだけあります。配列が同じであることをコンパイラがどのように認識するのでしょうか? これを行うには、ベースタイプを作成し、Test_Arrayと呼びます。

type Test_Array is array (1..50) of Integer;





ここで、aとbをこのタイプのインスタンスとして宣言します。

a, b : Test_Array;





コンパイラーは、配列が型の意味で同一であることを記憶しており、a:= bのような操作を許可するようになりました。 地獄では、OOPコンセプトの趣味が非常に感じられます。

別の非常に興味深いこと:集約。 しかし、多くの言語では、集計には近似の類似物すらありません。また、集計の説明はそれほど単純ではありません。 したがって、私は好奇心を対応する記事に送ります。



自分から



私は自分のアイデアを一般に公開しようと思います。 まず、ifステートメントが1つの条件ではなく、コンマで区切られた条件のリストを受け入れるようにしませんか?

if 1, 2, ... , N then

...

end if






少なくとも1つの条件が偽の場合、elseブランチが実行されます(存在する場合)。 なぜこれが必要なのですか? then-branchを実行するために真でなければならないいくつかの条件があるとします。 次に、次のように書きます

if (1) and (2) and (3) then ...





ここで、各条件がかなり複雑であり、翻訳者がそれらを正しく理解できるように、オペランドを持つ個別の論理演算子を括弧で囲む必要があると仮定します。 結果として、山のように括弧で囲まれたものが得られます。 もちろん、そのような状況は非常にまれであり、1000件のうち約1件で発生しますが、発生した場合...私の提案によりブラケットの負荷を減らすことができ、これにより1か月でプログラムをよりよく理解できるようになります。 一般に、ifの後の条件のリストは、そのようなホラーを書く可能性を減らします:

if (figureX > leftLimit && figureX < fightLimit && figureColor == GREEN)





条件が異なる行にレイアウトされている場合でも、セミコロンオプションはよりエレガントに見えます(ただし、それは好みの問題です)。

if (figureX > leftLimit,

figureX < fightLimit,

figureColor == GREEN) ...






コミュニティがこの考えを積極的に受け入れるとは思わない、私自身はそれを主張しない。 しかし、これはすべての新しいものと概念で起こります。 この考え方は、条件を記述するときに不幸なプログラマーが文字通りかっこでdrれているPascalのような言語に適しています。




All Articles