web-dev-qa-db-ja.com

データ構造は単なる愚かなプログラミング言語だと言って、ビル・ゴスパーは何を意味しましたか？

Ralph William Gosper、Jr による引用があります：

データ構造は単なる愚かなプログラミング言語です。

これはどういう意味ですか？悲しいかな、私がそれについてGoogleで見つけることができるのは、文脈なしの引用自体の執拗なコピー/貼り付けです。

data-structuresquotations
16
missingfaktor

まあ、それは声明の中心部のようです：

データ構造は...プログラミング言語です

あなたがそれについて考えるならば、それは全く真実です。結局のところ、コンパイラーは常にこの推移性に依存しています。彼らはプログラミング言語を受け取り、それをデータ構造に変換し、そのデータに対していくつかの変換を行い、その結果を別のプログラミング言語に変換します。

実際、Cデータ構造のようにクレイジーなものを作成したい場合は、さまざまなメソッドを呼び出すことでCコードを記述できます-たとえば（ちょっとC＃では、これが今使用しているものだからです）。

 var C = new HorribleCObject（）; 
 C.Function <int>（ "main"、typeof（char [] []）、typeof（int））
 .Variable （ "i"、typeof（int）、0）
 .While（ "i"、Func（i）=> i <10））
 .Call（ "printf"、 "％d "、" i "）
 .PostIncrement（" i "）
 .EndWhile（）; 
 .Return（0）
 .EndFunction（）;

さて、完全な引用についてですが、C自体で（たとえば）書くのに比べて、なぜそのようなことがばかげているのでしょうか。これは冗長であり、Cでの同等の機能ほど読みにくいことは明らかです（そして、実際には、Cができることの完全なスコープをサポートしていない可能性があります。typedefは扱いにくいでしょう）。したがって、このデータ構造は、「実際の」プログラミング言語に埋め込まれた、単なる「愚かな」プログラミング言語です。同じロジックを、考えられるあらゆるデータ構造に一般化できます。リンクリストはLISPの単なる「愚かな」バージョンであり、ハッシュマップは理論的なハッシュプログラミング言語（Hasp？）の単なる「愚かな」バージョンです。

ただし、ハッシュマップとやり取りするために、Haspを常に記述したいとは限りません。それはすべての問題です ドメイン固有の言語 が持っている-一方では、適切に実装されたDSLは、基礎となるモデルが実行できるすべてを表現するのに十分強力です。一方、DSLを最初に実装する必要があり、それから他の人々がそれを学ぶ必要があります。これには、おそらく彼らが使いたくないと思われる時間と労力が必要です。結局のところ、ハッシュマップに物を置いて、そこにある他のものを確認したいだけなのです。ハッシュ指向プログラミングの複雑さをすべて学びたくありません。

それで、ほとんどそれについて考えることなく、これらの理論的に非常に具体的で非常にスマートなプログラミング言語を取り上げ、データ構造に組み込まれたいくつかの愚かな操作にそれらを蒸留します。リンクリストには、単純なメソッドの小さなコレクションが1つあります。ハッシュマップには他にもいくつかあります。データ構造に対して実行できる可能性のある他のより強力な操作は無視します（たとえば、ほとんどのLinkedList実装には.Mapまたは.ForEach関数がありません。また、Haspで何を行うか想像もできません）。親プログラミング言語でそれらを明示的に実装することを支持して-ほとんどのプログラマーはこれに精通しているでしょう。

データ構造は、基本的に、それらが概念的に表す問題空間への親言語の愚かな拡張です。十分にスマートな拡張には新しい特定のプログラミング言語が必要であり、ほとんどの人はそれを学びたくないでしょう。

10
Tacroy

データ構造は、プログラミング言語の表現です。しかし、特に「鋭い」ものではありません。

これは、以下のWiki記事にあるような「ノード図」から見ることができます。

http://en.wikipedia.org/wiki/Root_node#Terminology

それでも、データ構造は、プログラミング言語としては不完全です。プログラマにとって理解しやすい構文と完全な思考が欠けているためです。データ構造の「言語」は、「私、寒い。コートを着なさい」のようなことを言った子供と比較されるかもしれません。

「言語」は壊れていますが、理解できます。子どもは「寒いので、お洋服をかぶってほしい」と言っています。子供の発話は英語の「愚かな」バージョンであり、同様にプログラミング言語に関連するデータ構造です。

2
Tom Au

ビルゴスパーが意図したのはすべてのデータ構造はプログラミングの構成要素であり、適用範囲が限られているであると私は信じています。これは、"言語設計はライブラリ設計であり、ライブラリ設計は言語設計である" [1]という考えにも関連しています。

この問題について考える1つの方法は、単にアルゴリズムに基づいてデータ構造を検討することです。これらは単なる補助的なものであるため、今のところ、ストレージ要件やタイプアノテーションについては忘れてください。

たとえば、連想配列（一部の言語ではmapと呼ばれる）を次の2つの方法でコード化できます。

Haskellでは、連想配列をデータ構造として体系化できます...

let assocArray = [("a", 1),("b", 2),("c", 3)]
let key = "b"
lookup key assocArray

...またはケース式を使用して...

let key = "b"
case key of 
  "a" -> 1
  "b" -> 2
  "c" -> 3

...またはさらに直接...

let key = "b"
if key == "a" 
  then 1 
  else if key == "b"
    then 2
    else if key == "c"
      then 3
      else undefined

ラムダ計算を見ると、データ構造とコード間のこの種のミラーリングが可能であることは容易に理解できます。どの値もラムダ計算の関数で表すことができ、計算自体は普遍的です（完全なチューリング）。

[1]引用はBjarne Stroustrupに感謝します。

1
Rehno Lindeque

すべてのデータがコードであるJavascriptを検討してください。すべてのデータがコードであり、すべてのコードがデータであるLISPを考えます。

初め、終わり、そしてその間のすべてにおいて、データは単なるビットです。テキストとシンボルでビットをオントログ化して、人間が読みやすく、人間が簡単に変換できるようにすることは、a）定義言語を学び、b）抽象化の漏れを学ぶ抽象化の層です。

たとえば、C＃では、構造体とクラスの違いを知るには、値型と参照型の等価比較の違いを知る必要があります。すべてのデータオントロジーには、学習して順守する必要のある独自のルールセットが必要です。そして、他の言語と同じように、それはあなたが一般的な考えにすばやく到達することを可能にしますが、問題の実際の真実に近づきたいと思うほど、あなたはバイナリを自分でもっと見るべきです。

最後に、Bツリーまたは類似のデータ構造を検討する場合、ツリーの構造をナビゲートして他の種類の操作を実行するには、ツリー、構造、または言語間で必ずしも転送できない特別な種類の構文が必要です。

0
Legatou