Apa maksud Bill Gosper dengan mengatakan struktur data hanyalah bahasa pemrograman yang bodoh? [Tutup]

Ada kutipan oleh Ralph William Gosper, Jr yang mengatakan:

Struktur data hanyalah bahasa pemrograman yang bodoh.

Apa yang dia maksudkan dengan ini? Sayangnya, yang dapat saya temukan di Google tentang hal itu adalah copy / paste kutipan tanpa henti itu sendiri, tanpa konteks apa pun.

Yah, sepertinya inti dari pernyataan itu adalah:

Struktur data hanyalah ... bahasa pemrograman

Yang benar jika Anda memikirkannya. Bagaimanapun, kompiler mengandalkan transitivitas ini sepanjang waktu; mereka mengambil bahasa pemrograman, mengubahnya menjadi struktur data, melakukan beberapa transformasi pada data itu, dan kemudian mengubah hasilnya menjadi bahasa pemrograman lain.

Bahkan, jika Anda mau, Anda bahkan dapat membuat sesuatu yang gila seperti struktur data C, yang memungkinkan Anda menulis kode C dengan memanggil berbagai metode - misalnya (dalam agak C #, karena itulah yang saya gunakan sekarang):

var C = HorribleCObject baru ();
C.Fungsi <int> ("main", typeof (char [] []), typeof (int))
  .Variabel ("i", typeof (int), 0)
  .Sementara ("i", Func (i) => i <10))
     .Call ("printf", "% d", "i")
     .PostIncrement ("i")
  .EndWhile ();
  .Return (0)
 .EndFunction ();

Sekarang, seperti kutipan lengkap: mengapa sesuatu seperti itu menjadi bodoh dibandingkan dengan (katakanlah) menulis di C sendiri? Seharusnya cukup jelas bahwa ini verbose dan tidak hampir sama terbaca dengan padanannya dalam C (dan, dalam praktiknya, mungkin tidak mendukung cakupan penuh dari apa yang dapat dilakukan C - typedef akan rumit); karenanya, struktur data ini hanyalah bahasa pemrograman "bodoh", yang tertanam dalam bahasa pemrograman "nyata". Logika yang sama dapat digeneralisasikan ke struktur data apa pun yang dapat Anda pikirkan; daftar tertaut hanyalah versi "bodoh" dari Lisp, dan peta hash hanyalah versi "bodoh" dari beberapa Bahasa Pemrograman Hash teoretis (Hasp?).

Masalahnya adalah, kita tidak selalu ingin menulis Pengait untuk berinteraksi dengan peta hash kita. Ini masalah yang dimiliki semua bahasa khusus domain - di satu sisi, DSL yang diimplementasikan dengan baik cukup kuat untuk mengekspresikan semua yang dapat dilakukan oleh model yang mendasarinya; di sisi lain, Anda harus mengimplementasikan DSL di tempat pertama, dan kemudian orang lain harus mempelajarinya. Itu membutuhkan waktu dan usaha yang mungkin tidak ingin mereka habiskan; setelah semua, saya hanya ingin meletakkan hal-hal di peta hash saya dan kemudian memeriksa hal-hal lain di sana, saya tidak ingin mempelajari semua seluk-beluk Pemrograman Berorientasi Hash.

Jadi, cukup banyak tanpa memikirkannya, kami mengambil bahasa pemrograman teoritis yang sangat spesifik dan sangat cerdas ini dan menyaringnya ke beberapa, operasi bodoh yang terkandung dalam struktur data. Daftar tertaut memiliki satu kumpulan kecil metode sederhana; peta hash memiliki beberapa yang lain. Kami mengabaikan operasi lain yang lebih kuat yang berpotensi Anda lakukan di atas struktur data (sebagian besar implementasi LinkedList tidak memiliki fungsi .Map atau .ForEach, misalnya, dan saya bahkan tidak dapat membayangkan apa yang akan Anda lakukan dalam Pengait), mendukung menerapkannya secara eksplisit dalam bahasa pemrograman induk - yang merupakan hal yang paling akrab bagi para programmer.

Struktur data pada dasarnya adalah perpanjangan bodoh dari bahasa induknya ke dalam ruang masalah yang secara konseptual mereka wakili. Ekstensi yang cukup pintar akan membutuhkan bahasa pemrograman baru dan spesifik, dan kebanyakan orang tidak ingin mempelajarinya.

Struktur data adalah REPRESENTASI dari bahasa pemrograman. Tapi bukan yang "tajam".

Ini bisa dilihat dari "diagram simpul" seperti yang ada di artikel wiki di bawah ini:

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

Namun demikian, struktur data INCOMPLETE sebagai bahasa pemrograman, karena tidak memiliki sintaks dan pemikiran lengkap yang dapat dipahami oleh seorang programmer. "Bahasa" struktur data dapat dibandingkan dengan seorang anak yang mengatakan sesuatu seperti, "Aku, dingin. Dapatkan mantel."

"Bahasa" retak, tetapi bisa dipahami. Anak itu mengatakan bahwa dia kedinginan, dan ingin lebih banyak pakaian sebagai penutup. Ucapan anak adalah versi "bodoh" dari bahasa Inggris, dan juga struktur data dalam kaitannya dengan bahasa pemrograman.

Saya percaya bahwa yang dimaksudkan oleh Bill Gosper adalah bahwa semua struktur data hanyalah konstruksi pemrograman dengan penerapan yang terbatas . Ini juga terkait dengan gagasan bahwa "Desain bahasa adalah desain perpustakaan dan desain perpustakaan adalah desain bahasa" [1].

Salah satu cara berpikir tentang masalah ini adalah dengan mempertimbangkan struktur data hanya berdasarkan algoritmik. Lupakan persyaratan penyimpanan atau ketik anotasi untuk saat ini karena ini hanyalah tambahan.

Misalnya, Anda bisa mengodifikasi array asosiatif (disebut a mapdalam beberapa bahasa) dengan dua cara: Baik dengan menggunakan semacam indeks yang disimpan dalam memori atau dengan menggunakan ekspresi case sederhana.

Di Haskell Anda bisa mengodifikasi array asosiatif sebagai struktur data ...

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

... atau dengan menggunakan ekspresi case ...

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

... atau bahkan lebih langsung ...

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

Sangat mudah untuk melihat bahwa mirroring antara struktur data dan kode ini dimungkinkan dengan melihat pada kalkulus lambda. Nilai apa pun dapat diwakili oleh fungsi dalam kalkulus lambda dan kalkulus itu sendiri bersifat universal (turing lengkap).

[1] Kutipan ini berkat Bjarne Stroustrup.

Pertimbangkan Javascript, di mana semua data adalah kode. Pertimbangkan LISP, di mana semua data adalah kode dan semua kode adalah data.

Pada awalnya, akhir, dan di mana-mana di antara keduanya, data hanyalah bit. Yang kami coba untuk ontologisasi bit dengan teks dan simbol untuk membuatnya mudah dibaca manusia dan dapat ditransformasikan oleh manusia adalah lapisan abstraksi yang membutuhkan a) Anda belajar bahasa definisi dan b) Anda mempelajari kebocoran abstraksi.

Misalnya, dalam C #, mempelajari perbedaan antara struct dan kelas mengharuskan Anda mempelajari perbedaan dalam perbandingan kesetaraan antara tipe nilai dan tipe referensi. Setiap ontologi data membutuhkan seperangkat aturan sendiri yang harus Anda pelajari dan patuhi. Dan, seperti bahasa apa pun, ini memungkinkan Anda untuk dengan cepat mencapai gagasan umum, tetapi semakin dekat Anda ingin mendekati kebenaran sebenarnya dari masalah tersebut, semakin Anda hanya perlu melihat biner itu sendiri.

Akhirnya, ketika seseorang mempertimbangkan B-tree atau struktur data yang serupa, menavigasi struktur pohon dan melakukan jenis operasi lain di atasnya memerlukan jenis sintaksis khusus yang tidak perlu ditransfer ke pohon, struktur, atau bahasa.