プログラミングにおけるカスタムデータ型の開発

ユーザーデータ型（PDD）の開発という観点から、プログラミング言語の開発をやめたいと思います。

これらの言語でコードを書く人々のようなプログラマーを意味するユーザーによって、私はすぐに予約をしたいです。 まあ、そしてこのコードに同行するか、単に読む人。



カスタムデータ型は、言語で利用可能なものに基づいてユーザーが作成できるデータ型です。



ユーザーは、これらのタイプのデータが必要です。



ユーザーは、希望する方法でデータを作成できることを望んでいました。 彼らは望み、望み、そして確かに望みます。 より多く、より多様で、より強く。

そのため、プログラムおよびプログラミング言語でカスタムデータ型の開発を追跡することが有用です。

カスタムデータ型の欠如

昔々、ユーザーデータ型はありませんでした。 なんとなくねじれた



コンピューター時代の夜明けには、言語はそれほど熱くありませんでした-機械：あなたは彼らの独裁に従う（そしてそこでは口述は簡単です：バイナリ10進数システムで低ビット数（まあ、またはそれが動作するプロセッサー）とプロセッサー命令）を使用するかしないか。

これらの「暗黒時代」には触れません。

1つ言えることは、そこにはユーザーデータ型はありませんでしたが、プログラマーはどうにか生き残り、何らかの形でプログラムを作成しました。

組み込みデータ型

組み込み型はとても便利です！ 開発者が計画したとおりに使用しながら...



最初の多かれ少なかれ通常の言語はアセンブラーでした（実際には多くのアセンブラーがあり、50年代に登場した言語のバックボーンについて話しています）。 読みやすさに加えて、ユーザーデータの面で多くの新しい機能を追加しました。

最大の紛れもない成果は、変数を作成する能力です！ それ以来、ほとんどすべての言語にそのような機会があります-変​​数を作成する能力。

善意で作られたアセンブラーの2番目に劣らない主要な成果は、すべてのデータ型（プログラマーが必要とするかもしれない）を直接言語に挿入する試みです。

さて、残りはささいなことです-まず第一に、バイナリでだけでなく、16進数、8進数、2進数の10進数システムでも数値を記録する機能。

それから、ユーザーは他に何が必要なのでしょうか？



年が経過し、高レベルの抽象化だけでなく、カスタムデータ型の必要性も高まりました。

そして、1957年はFortranで始まりました。

その上に書かれたコードはほとんど現代言語に似ていましたが、パンチカード上のバージョンはそれを読みたい人に衝撃を与えることができます。

Fortranは、弾道ミサイルの飛行を計算するために必要なものすべてを与えました-整数（intなど）、コンマ（floatなど）、複素数などのデータ。

行ですか？ 誰がパンチカードでそれらを必要としますか？ それらは、Fortranで後で表示されます-20年後にのみ実際の行、およびそれらの模倣-10後に（論理データ型とともに）表示されます。

Fortranは、ほぼ実際のユーザーデータ型を配列として提供しました（その使用法は現代のものとは多少異なりますが）が、これについてはグループユーザーデータの章で詳しく説明します。



しかし、ユーザーは少数です-彼らはより多くのユーザーデータを望んでいます。



そして今、彼は現れます-アルゴル、すでに1958年に、今日読みやすいプログラム。

これは、Algolが現在どこにでもあることの基礎をもたらしただけです-ブール型、文字列、さまざまな整数型、カンマ付きの数値 少し後に、Fortranがこれらすべてを適用しますが、Algolは先駆者でした。

すべての食欲が満たされているように思われますが、ユーザーが必要とする他のタイプは何ですか？ はい、すべてが既に実装されています-ただそれを使用して使用してください。



そして、Fortranでアルゴラのかかとを踏むと、1958年に言語とはまったく別の言語、Lispが登場しました。





Lispは想像を絶する関数を作成できます。 それと一緒に暮らす方法だけ？



彼はさらに別のまったく新しいタイプのデータ、実際のユーザーデータタイプを提供しました-関数（C式の形式）は、21世紀の初めからのみ、すべての現代言語にしっかりと入り始めました（主にマルチパラダイム言語PythonとRubyのおかげです）。 Lispを使用すると、マクロ（58番目のeval-sのプログラミングのようなもの）で操作できることを考えると、世界がその準備ができていなかったのは驚くことではありません。

しかし、今や世界はLispの準備ができていますか？ おそらくない。

理由を指摘してください。 Lispは、他の関数型プログラミングと同様に、高度に相互接続されたオブジェクトで動作し、機械式時計の接続されたギアを幾分連想させます。 命令型言語とは異なり、ギアのくさびはメカニズム全体をロックします。 このため、ユーザーのデータ型を含む言語要件はさらに厳しくなります。 Lisp、命令型言語ですぐに発生したこれらの問題は、80年代の終わりまでに悪化しました。

Lispを使用すると、任意のC式を作成できます。 しかし、C式を操作するための標準のシンプルなツールキットである1つのツールキットのみが提供されます。

ユーザーデータを書き込む機会があることがわかりますが、プリミティブを使用する場合と同じように作業することができます。 Lispライクな言語の開発は、これまでのところ、書かれていないC式の良いツールキットが見つからなかったことを示しています。



誰もが長い間幸せではなかった。 ユーザーデータの開発は、10年近く遅れています。

何かが必要な場合は、これらのデータ型を直接言語に追加しました。 しかし、当時、言語は現在ほど速く開発および更新されなかったため、主にカスタムデータ型の作成を模倣することに従事していました。



元のデータ型からの模倣は、機能的にほぼ同じです。 基本的に、当時の模倣は関数によるエミュレーションに基づいていました（手続き型）。

実際のユーザータイプとの主な違いは1つです。データタイプを「わずかに」変更する場合は、すべての機能を書き換える必要があります。 誰もこれをやりたくありませんでした。

したがって、模倣はより柔軟になります。

さて、誰もが知っていると言いますが、ここで重要なことは、説明したシミュレーション手法ではなく、この手法の視野角です。





場合によっては、次の機能のみを使用する必要があります。



最初に、フラグに基づいた構成可能な機能が登場しました。 これは最も簡単な方法ではありませんが、アセンブラーに非常によく似ていて、まだ知られていました。

フラグを渡すことの本質は単純です-数値をパラメーターとして渡すことですが、その数値は一連のバイナリフラグとして表されます。 広範囲に使用されていますが、一連のフラグのような言語には特別なデータ型はまだありません。 代わりに、論理定数のように見える名前付き定数とビット操作-彼らは良い代用品を見つけました。

最も単純な方法-どこでも広く使用されています-パラメーターの構成：構成する必要があるほど、より多くのパラメーターが渡されます。 マイナス記号のみがあります-パラメーターが送信される順序で混乱するのは簡単です。 したがって、これらのメソッドでは最大4〜5個の引数を渡そうとします。

実際のユーザーデータ、特にグループおよび複合データの開発により、より多くの引数について、1つの複雑な引数を渡すことが可能になりました。これは、水平だけでなく垂直にも同じ構成です。

このメソッドの開発は、機能を構成するための埋め込み言語（DSL）の作成と呼ばれます。

シミュレーターの柔軟性の3番目の方法はハンドラーの発明です。ただし、当時は呼び出されませんでした。多くの場合、マニピュレーターの代理でした。リンクやポインターではなく、数字と文字列でした。



組み込みデータ型の時代は終わりを告げていました。

しかし、年が来た1972年、登場... C. そして、恐竜（組み込みデータ型）の優位性の時代はさらに10年間続いたが、カスタムデータ型は太陽の下でそれらの場所に置き始めました。

C自体に含める。



しかし、今のところ、別の組み込みデータ型に戻りましょう。これは、言語の人気が高まっている理由の1つになっています。 Cは低レベルのデータ型を導入しました。これはアセンブラーにあり、最初の高レベル言語である動的型では完全に忘れられていました。 まず第一に、これらは参照とポインタです。 それらにサービングnullデータ型-nullが追加されました。





マスターキーなどの動的なデータタイプは見苦しいですが、どのような隠し部屋にはアクセスできませんか？！



リンクは、このタイプのユーザーデータを同義語として実装するためのオプションの1つと考えることができます。

シノニムの開発は、PCPと変数変数の概念に見られます。名前が呼び出された変数の値に書き込まれている変数または関数の値を返すことができます。

Cでは、関数呼び出しを関数呼び出し（呼び出し）で呼び出すか、コールバック関数（コールバック）を渡すことができます。

これに加えて、動的データ型は、コンパイルされたコードの実行を高速化するのに役立ちます。

これらのプラスには、動的データ型にはもう1つの大きなプラスがあります。これらを使用すると、言語自体に規定されていないものを簡単に実装できます。 動的データを操作するためのツールの助けを借りてのみアクセスできるのは、それらを使用して記述された1つの問題だけです。 しかし、データをシミュレートするときのバイパスの手法は既知です-関数を閉じて、作成されたものへのリンク/ポインターを返す-ハンドラー。 マニピュレーターは、異なる言語のデータの種類の1つであり、まったく異なる方法で呼び出すことができます。

たとえば、PCPではErlangではポートとプロセス識別子というリソースと呼ばれます。 Kobolには、ファイルや画像などのデータ型があります。



ただし、動的データ型は利点だけではありません。 マイナスもあり、時には非常に大きくなります。

動的データ型の使用が言語により自由になればなるほど、次のことができます。

1）言語に固有ではないものを作成する機会の増加（必ずしもこれらが前向きな機会ではない）

2）コンパイラーはユーザーのアクションに介入しなくなり、アクションに対するすべての責任はプログラマーにあります

2）コードの不安定さが急激に増加する

3）名前空間と値へのインジェクションの可能性が劇的に増加します

4）ガベージコレクターの介入が少なくなり、すべての責任はユーザーにあります

さらなる歴史は、動的データを追加する場合、後続の言語の作成者（または既存の言語に追加する場合）がセキュリティと機能のギャップをバランスさせることを示しました。



70年代の終わりが近づいており、これらの基本的な組み込みデータタイプは、実際のユーザーデータに取って代わり、周辺、ルーチンに行き始めました。



しかし、現実には驚くべき驚きが時々あります。

古くて長い間理解されていたデータ型で、さらに多くのデータが見つかることを誰が知っていますか？！





時々、すべてが長い間知られている新しいものを見る必要があるだけです。 たとえば、M＆Mのこのソート



その後、70年代後半に、AWKスクリプト言語（grepユーティリティの開発を使用）が登場し、10年後、それに基づいて1987年にPearlのような言語が登場しました。 そして、とりわけ、彼は正規表現のようなエキゾチックな組み込みデータ型を持っていました（まだ持っています）。

パールは、文字列などの古いデータ型を新しい観点から見るのに役立ちました。 初期言語でこのツールを使用するためのツールは、単純化されたパーサーと見なすことができます。

正規表現言語は、シンボリックデータ型を操作するための非常に柔軟で強力なツールであることが証明されています。

グループデータタイプ

一部のグループは大規模です。 早く彼らと働きたい



実際、グループのデータ型は言語が持つものの多くであり、通常は単相のグループ化です。 多くの場合、これらのデータ型はユーザー定義ではなく、組み込みですが、時には柔軟性が高いためにこれで十分な場合もあります。

Fortranはすでにグループデータ型をサポートしています-これらは配列ですが、現在は少し異なっています。 現代のものと非常によく似た配列は、すでにアルゴルにありました。 パスカルにセットがありました（セット）

Lispにはリスト（リスト）がありました。

次に、ハッシュテーブル、関連付けられた配列、ベクトル、ヒープ、キュー、スタック、ツリー...

何かが埋め込まれ、何かがカスタムデータタイプを使用してシミュレートまたは作成されました。

グループデータタイプのさらなる開発は、開発の2つの異なるブランチにつながりました

1）各グループのデータ型でその機能を使用する必要性は最も満足のいくものではなかったので、同じ方法で作業したいと思いました。 命令型言語のこのための主なツールは、コレクションとイテレータです。 主に2000年代初期に追加されました。

2）80年代、データの増加に伴い、グループのデータ型を操作するためのツールを拡張する必要性が飛躍的に高まりました。 データベースが登場し、それらとともにクエリとクエリ言語の両方が登場しました。 80年代半ばに、構造化照会言語（SQL）が支配的になりました。 文字列のパーサーと同様に、クエリ言語は、グループデータ型に使用されたツールをプリミティブクエリ言語と見なすことができることを明確にしました。 原則として、データベースは言語から取り出され、言語ではデータベースを操作する方法しかありません。したがって、本格的なユーザーデータ型とは見なされません。 柔軟性があるため、これは重要ではありません。

実ユーザーのデータ型

さまざまな言語の組み込みデータ型の時代には、非常にエキゾチックな組み込みデータ型のサポートがあります。

たとえば、Cでは、このタイプのデータは列挙型でした。 スカラーと呼ばれていましたが、Pascal（1970）によって最初に導入されたCが先行していました。





指で子供にも説明しやすい列挙とは



列挙は実際のユーザーデータ型です！ Xiはこのために記念碑を建てる必要があるように思われます。 いいえ、墓石かもしれません。

実際、ユーザーは転送を作成することができます。 しかし、Cでそれらを操作するものは何もありません（Pascalには基本セットがありました）。 何もありません。 転送を作成できますが、それらを使用することはできません。

Cが主流であったため、このデータ型を他の言語に追加したいと思った人はほとんどいませんでした。 C ++ 11でのみ、列挙を操作するための少なくともいくつかのツールキットが登場しました。

この例は、Lispの開発と同様に、ユーザー定義のデータ型だけでなく、それらを操作するツールを持つことの重要性を示しています。

複合データ型

エントリは非常に多様です。 まだそれらを使用する方法を学びます



しかし、Cには別の実際のユーザー定義データ型がありました。 それはずっと以前に発明されましたが、60年代前半に登場したKobolに戻りました（言語自体は1959年に作成されました）。

これは、C構造体で呼び出されるレコードです。

レコードは、異種データ型のグループにすぎません。

記録には記録ツールが付属しています。 たとえば、Cは、レコードを操作するための標準的な最小標準を完全には提供しません（たとえば、片側のみの初期化）。

録音を真似せずに、実際のリストとツリーを作成するのは簡単です。

すべてが再び言語になっていますか？

いいえ、再びいいえ。

カスタムデータ型を用意するだけでは十分ではありません。 PDDと同様にPDDで作業するためのツールがあるだけでは不十分です。 別のことが前面に出てきます。

誰も作成されていないデータ型のツールキットを提供しません！

さて、記録をサポートする言語は、Lispが陥った言語と同様のintoに陥りました-あなたはあなた自身のデータを作成し、それらを扱うことができます-基本的なセットだけです。

さらに悪いのは、Lispの状況だけです。この言語ではすべてがC式であり、C、Kobolなどでは、レコードは独立したタイプであり、さらに、小さなツールキットではありますが、独自のタイプです。

幸いなことに、このデッドロックの解決策は長く知られており、関数を使用してユーザーデータ型の操作をシミュレートします。



プログラマがカスタムデータ型の重要性を認識したのは、レコード/構造（Cを含む）のおかげです。

同時に、まだ作成されていないデータ型を操作するためのツールの深刻な不足が明確に示されました。



そして答えはそうでした。 驚いたことに聞こえますが、Cが作成される数年前のことでした。彼はヨーロッパにいて、Simula（1967）と呼ばれていました。 そして、Cがユーザーデータ型用のツールの不足で窒息し始めたとき、C ++（1983年）はSimulaから最高のものを採用し、Cに構文を適用しました。

オブジェクト

オブジェクトはすべてを実行できます。 自分自身と自分自身の上



オブジェクトは別のタイプのユーザーデータです。 レコードよりも大幅に優れた機能を備えています。

これにより、彼は単に大人気を得る機会を得ました。

皮肉なことに、オブジェクトのないCの数年前に出てきたSimulaのように、C ++の数年前に、Smoltolkは1980年にパラダイムを「すべてのオブジェクト」と宣言しました。

しかし、Smalltalkはあまり人気がなく、C ++が停滞のレベルに達するまで待たなければならず、その後1995年にJavaは再び「すべてのオブジェクト」パラダイムを誇らしげに頭上に上げることができました。

オブジェクトがレコードとそれほど変わらないので、なぜオブジェクトがそれほど優れているのか。 実際、メソッドを追加した同じエントリ。

まず、オブジェクト自体を操作するためのツールは、構造体を操作するためのツールよりもはるかに豊富で強力です。

そして第二に、まだ作成されていないオブジェクトを操作するためのツールも存在しませんでした。

オブジェクトに作成されていないデータ型のツールがあり、レコードにない場合は、「2番目」はどこにあるのかを尋ねます。 そしてまだ、第二に！ 記録については、このツールキットを模倣する必要がありましたが、オブジェクトについては、このツールキットをオブジェクト自体の内部に単純に実装できます！

また、突然ユーザーデータタイプをわずかに変更する必要が生じた場合、オブジェクトのツールキットを使用して、継承によって子孫を作成し、その動作を修正するのが便利でした。

オブジェクトのブームと完全な使用は、現在停滞につながっています。

オブジェクトのさらなる発展を妨げるものは何ですか？

覚えているように、新しいオブジェクトのツールキットの実装は完全にプログラマーにあり、言語ではありません。そのため、コードの再利用のレベルはそれほど大きくありません。

同様に重要なのは、親密さが増すことです。 オブジェクト自体がすべてを実行しますが、オブジェクトからすべてを実行する必要はほとんどありません。 逆に、自分ですべてを実行する能力を持っている場合、このオブジェクトは他の人に何もしません。 たぶんですが、そうではありません。

一部には、インターフェイスとミックスイン（ミックスイン、特性）の導入が問題の解決に役立ちます。

インターフェイスは、Delphiによって最初に導入され（1986年にはObject Pascalとしても）、後にJavaとC＃で導入されました。 そして、これは理解できます-彼らはオブジェクト言語のリーダーでした。

しかし、驚くべきことに、オブジェクトをLisp（Flavors、CLOS）（CLOSはCommon Lispの一部）にアタッチしようとすると、後で異なる言語に追加されたサブアイテム/特性が現れました。

ただし、インターフェイスや不純物などの抽象的なヘルパーでさえ、たとえば「finalized」（final）とラベル付けされた古いオブジェクトに対して常に役立つとは限りません。部分的に、ハイブリダイゼーションの問題はプロトタイプ継承（1980年代半ばにSelf言語（同じSmalltalkの方言）によって発見され、主に10年後にJava Scriptのおかげで人気を得た）に基づいて解決できますが、この方法にはクラス継承に関する欠点があります。

興味深いのは、1980年にSmalltalkに組み込まれたメタクラスのサポートであり、現在はPythonなどのいくつかの言語でサポートされています。メタクラスはクラスをオブジェクトとして使用します（再帰的アプローチなど）。これにより、オブジェクトをオブジェクトとして操作するためのツールが大幅に改善されます。

そもそも、新しいオブジェクトの作成ではなく、デザインパターン（パターン）を使用したシステムデザインへの有能なアプローチです。

次に何が起こりますか？ 質問は修辞的です。

オブジェクト、構造などの強力なユーザーデータ型に代わるものはありますか？はい、オブジェクトよりも優れています！オブジェクトを将来どのように開発できるかを理解することは、彼らをよく見る価値があります。

代替品を検索

キリストとクリシュナが一緒に。命令型と機能性を一緒にすることができ



どこに代替の検索で見て？

今日、宣言型（HTMLなど）および論理型言語（Prologなど）には代替が含まれていません。それらは、プログラマではなく、コンパイラ/インタプリタが機能するという事実に基づいています。

ここで、

1）カスタムデータ型を追加することをあきらめて、別の言語（たとえば、HTML + Java Script）との共生を開始する必要があります

。2）他のプログラミングパラダイムを接続します。



ところで、他のパラダイムを接続することを犠牲にして、マルチパラダイム言語を持つのは何が良いのでしょうか？ Python（1991）とRuby（1994）はそうは思わなかった。

そして、彼らは正しかった。すべてのLispを提供するのが簡単な場合-シンプルさが必要な場合に関数型プログラミングパラダイムを適用するのが便利な場合-残りの場合には手続き型があります-オブジェクトはうまく対処できます。

新しいユーザーデータは追加されておらず、コードの記述効率が大幅に向上しているようです。

そして、2011のヤードで、C ++であっても、Lispのラムダ関数が登場しました。

Rockは2003年からJavaから成長し、オブジェクトも機能であるという前提を受け入れました。



メタプログラミングは良いです。ただし、原則として、組み込みデータ型を拡張（より柔軟に）したり、新しいコードを生成したり、一般化を作成したりすることができます。組み込みデータ型で動作します。これまで、ビルトインでのみ。しかし、カスタムデータ型がなくても、プログラミングルーチンをなくすという点で、メタプログラミングには未来があります（すでに多くの点で現在も存在しています）。

代数データ型

ATDはとても美しいので、フレームに挿入して吊り下げたいと思います。そして時々、そこを離れて二度と触れないでください



。

Standard MLは、1990年に代数データ型（ATD）を初めて導入しました。

代数データ型は、最も強力なユーザーデータ型の1つです。それらは、ラムダ計算で数学者ヒンドリーとミルナーによって発見されました。

ADTは「オールインワン」-ユニタリデータ型（null型）、列挙（enum型、bool型）、保護された基本型（リンクではなくリソースなど）、スイッチ型（Cのようなもの-ユニオン）、リストのような構造、ツリー構造、関数、タプル、レコード、オブジェクトのような構造（オブジェクトではない）。そして、これらすべての組み合わせ。

これはオブジェクトよりもはるかに優れています！少なくとも、さまざまなカスタムデータタイプ自体を作成するという観点からは、もちろんそうです。

他の観点からのみ、標準MLとそれ以降のOKamlaの両方のこのデータ型は非常に少ないです。

ADTと同様にADTを操作するためのツールは、レコードを操作するだけではなく、オブジェクトを操作するよりもはるかに少ないです。

第二に、まだ作成されていないデータ型を操作するツールがありません。また、オブジェクトとは異なり、samopisnyツールキットを隠す場所はありません。模倣するだけです。

スタンダードMLの子孫であるKamlは、二度と考えることなく、自分自身にオブジェクトを追加し、オカムレになりました（1996年まで）。そして並行して、OKamlは、ユーザーデータを操作するためのツールの実装をパラメトリックモジュールで隠す、より機能的な代替ソリューションの開発を開始しました。そして、15年にわたって、Okamlはオブジェクトにふさわしい機能的な代替物を構築しました。まだ興味深いアプローチがあります-覚えているように、未書き込みのADTデータ用のツールの不足の問題を取り除くために、パラメトリックモジュール機能が導入されました。パラメトリックモジュール自体のみがADTとほとんど変わりません。書かれていません...モジュール。直接再帰！

そして、この15年間で、Okamlは、作成されていないデータ型用のツールが不足しているという問題を解決する別のオプションを見つけました。彼はそれをオプション（バリアント）と呼びました。これは似たように見えますが、ADTではなく異なるデータ型です。これはスイッチングデータタイプであり、同時に混合を含む任意の比率で共有できます（ATDataは比率で共有することも、混合することもできません）。比例的に共有できるのは良いことです（インターフェイスまたは特性を使用してのみオブジェクトを達成できますが、完全ではありません）。ミキシングはしばしば魅力的です（オブジェクトではこれを行いません）まだやるべきことがあります。このデータ型は未開発です。シンプルな開発パスのうち、ツールキットセットのバリアントを操作するためのこれまでにないツールキットを追加します。

型クラスと組み合わせた代数データ型

,



90 , , , 1998. .

, . . ( ) , . – (class).

- , (roles) , /.

型の単純なクラスのインターフェイス、複雑なクラスの不純物。

さらに、複雑なクラスの場合、混合物との類推は適切ではなくなります。複雑なクラスは、データに完全に接続する必要はなく、エントリポイントで結合するか、許可されている場合はいくつかのエントリポイントの1つで結合する必要があります。

さらに、クラス（インスタンス）の実装を使用すると、クラスの作成よりも後に記述されたコードだけでなく、以前に作成されたデータ（完成したオブジェクトに動作を追加できるかのように）とツールを共有できます。オブジェクト言語で類推すると、まず、オブジェクトにインターフェースと不純物ではなく、不純物とインターフェースにオブジェクトを結合することでこれを実現します（これはパールの役割の一部です）。

しかし、Haskellはそこで止まりませんでした。彼はさまざまなデータ型の自動派生クラスを実装しました。



これは、オブジェクトに埋め込まれているよりも、ユーザーデータ型の可能性の点で間違いなくはるかに重要です。



Haskellは活況を呈しています。現在、代数データ型は大したことのほんの一部です。

現在、データファミリ、一般化代数データタイプ（GADT）、実存的、マルチランクを作成することが非常に可能です。

型クラスは静止していません。現在では、マルチパラメーター、関数依存、品種クラスを使用することが可能です。

メタプログラミングのコンテキストでADTと同様にADTを操作するためのツールは拡大しています。

この新しい機能の多くは言語の拡張機能として存在し、2014年には言語標準の一部になる可能性があります。

おわりに

歴史は、カスタムデータ型の緊急の必要性を公然と示してきました。

カスタムデータ型はますます必要になります。すべてがより多様です。一般化されたタイプのユーザーデータと、プログラマーによってのみ作成されるものの両方で機能するツールを深くサポートします。

ユーザーデータ自体にsamopisnyツールキットを隠すことに成功すると、ユーザーデータの急速な成長が始まりました。

ただし、歴史が示しているように、言語が人気を得るためには高度な技術を備えているだけでは不十分な場合があります。 Cが出現する前のSimulaでのオブジェクトの発明（オブジェクトが存在しなかった）は、Simula自身にとってブレークスルーになりませんでした。

歴史は、誰も見ないものを足元で見つけることも有用であることを示しています。いくつかのパラダイムの組み合わせとこれを個別に達成すること（Ruby、Python、..）、低レベルの動的データ型の発見（C）、パーサーでの作業（Pearl）のような文字列での作業の一般化-これらの言語と一般的なプログラミング。

Lispライクな言語は、まだ作成されていないデータ型のツールキットを見つけますか？

オブジェクトは開発中に停止しますか？そうでない場合、彼らはどこに行くのか-ロック言語の道に沿って？ルビー？真珠？

代数データ型の黄金時代はいつ来るのでしょうか？バリアントデータ型を開発する機会はありますか？

Haskellクラスは他の言語で借用されますか？Haskellはどこに行きますか？

時間が表示され、質問に答えます。