Що мав на увазі Білл Госпер, кажучи, що структура даних - просто дурна мова програмування? [зачинено]

Є цитата Ральфа Вільяма Госпера, молодшого, який говорить:

Структура даних - це просто дурна мова програмування.

Що він мав на увазі під цим? На жаль, все, що я можу знайти в Google про це, - це невблаганна копія / вставки самої цитати, без будь-якого контексту.

Що ж, здається, що серце твердження таке:

Структура даних - це просто ... мова програмування

Що цілком вірно, якщо задуматися. Адже компілятори весь час покладаються на цю транзитивність; вони беруть мову програмування, перетворюють її в структуру даних, роблять деякі перетворення на цих даних, а потім перетворюють результат на іншу мову програмування.

Насправді, якщо ви хотіли, ви навіть можете зробити щось божевільне, як структуру даних C, що дозволяє писати код C, викликаючи різні його методи - наприклад (на зразок C #, тому що це я зараз використовую):

var C = новий HorribleCObject ();
C.Function <int> ("головний", typeof (char [] []), typeof (int))
  .Variable ("i", typeof (int), 0)
  .Доки ("i", Func (i) => i <10))
     .Call ("printf", "% d", "i")
     .PostIncrement ("i")
  .EndWhile ();
  . Повернення (0)
 .EndFunction ();

А тепер, що стосується повної цитати: чому б щось подібне було дурним порівняно з (скажімо) написанням у самій С? Це повинно бути досить очевидним, що це багатослівно і не настільки розбірливо, як його еквівалент у C (і, на практиці, може не підтримувати повний обсяг того, що може зробити C - typedefs було б хитро); отже, ця структура даних є лише "дурною" мовою програмування, вбудованою в "справжню" мову програмування. Ця ж логіка може бути узагальнена до будь-якої структури даних, про яку ви можете придумати; пов'язані списки - це лише "дурна" версія Lisp, а хеш-карти - просто "дурна" версія якоїсь теоретичної мови програмування Hash (Hasp?).

Річ у тому, що ми не завжди хочемо писати Hasp для того, щоб взаємодіяти з нашими хеш-картами. Це проблема, якою володіють усі мови , що належать до домену - з одного боку, добре реалізований DSL є достатньо потужним, щоб виразити все, що лежить в основі основної моделі; з іншого боку, вам потрібно реалізувати DSL, в першу чергу, а потім інші люди повинні це навчитися. Для цього потрібен час і сили, які вони, мабуть, не хочуть витрачати; врешті-решт, я просто хочу помістити речі в свою хеш-карту, а потім перевірити, чи є там інші речі, я не хочу вивчати всі тонкощі орієнтованого на хеш програмування.

Тож, майже не замислюючись над цим, ми беремо ці теоретичні високоспецифічні та дуже розумні мови програмування та відганяємо їх до кількох дурних операцій, втілених у структурі даних. Зв'язаний список має одну невелику колекцію простих методів; на хеш-карті є деякі інші. Ми ігноруємо інші, більш потужні операції, які ви потенційно могли б виконувати над структурою даних (наприклад, більшість реалізацій LinkedList не мають. на користь чіткої їх реалізації на батьківській мові програмування - з чим збираються ознайомитися більшість програмістів.

Структури даних - це, по суті, нерозумне поширення їхньої батьківської мови на проблемний простір, який вони концептуально представляють. Для досить розумного розширення потрібна нова, конкретна мова програмування, і більшість людей не хочуть цього вивчати.

Структура даних - ПРЕДСТАВЛЕННЯ мови програмування. Але не особливо "гострий".

Це можна побачити з "діаграми вузлів" на зразок тієї у статті вікі нижче:

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

Тим не менш, структура даних є НЕПРАВНИМ, як мова програмування, оскільки їй не вистачає синтаксису та повних думок, які були б зрозумілі програмісту. "Мова" структури даних може бути порівняна з дитиною, яка сказала щось на кшталт "Мені, холодно. Одягнись".

"Мова" розбита, але може бути зрозуміла. Дитина каже, що "він / йому холодно, і він хотів би більше одягу, як покриття". Висловлювання дитини - це "дурна" версія англійської мови, а також структура даних стосовно мови програмування.

Я вважаю, що Білл Госпер задумав - це те, що всі структури даних - це просто програми програмування з обмеженою застосованістю . Це також пов'язане з ідеєю, що "Мовний дизайн - це дизайн бібліотеки, а дизайн бібліотеки - це дизайн мови" [1].

Один із способів мислення з цього питання полягає в розгляді структур даних лише на алгоритмічній основі. Забудьте про вимоги щодо зберігання або введіть анотації на даний момент, оскільки вони просто допоміжні.

Наприклад, ви можете кодифікувати асоціативний масив (який називається a mapв деяких мовах) двома способами: або за допомогою якогось індексу, що зберігається в пам'яті, або за допомогою простого виразу регістру.

У 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] Цитата - завдяки Б'ярну Струструп.

Розглянемо Javascript, де всі дані - код. Розглянемо LISP, де всі дані - це код, а весь код - дані.

На початку, наприкінці та скрізь між ними дані - це лише біти. Те, що ми намагаємось отологізувати біти з текстом і символами, щоб зробити їх легко читатими і перетворюваними на людину, є шаром абстрагування, який вимагає: а) Ви вивчаєте мову визначення;

Наприклад, у C #, вивчення різниці між структурою та класом вимагає вивчити різницю в порівнянні рівності між типами значень та типовими стандартами. Кожна онтологія даних вимагає власного набору правил, яких ви повинні вивчити та дотримуватися. І, як і будь-яка мова, вона дозволяє швидко дійти до загальної ідеї, але чим ближче ви хочете підійти до фактичної істинності питання, тим більше вам слід просто дивитися на бінарне.

Нарешті, коли розглядається B-дерево або подібна структура даних, для навігації по структурі дерева та виконання інших видів операцій над ним потрібен спеціалізований синтаксис, який не обов'язково переноситься через дерева, структури чи мови.