Який наступний рівень абстракції? [зачинено]

Оскільки мови програмування спочатку використовували лише рядки коду, що виконуються послідовно, і він перетворився на включення функцій, які були одним з перших рівнів абстракції, а потім були створені класи та об'єкти, щоб ще більше його абстрагувати; який наступний рівень абстракції?

Що ще абстрактніше, ніж заняття чи є ще?

Я думаю, у вас є деякі помилки щодо історії обчислень.

Першою абстракцією (у 1936 р.) Насправді став обчислення лямбда церкви Алонцо, яка є основою для концепції функцій високого порядку та всіх функціональних мов, які слідували за цим. Це безпосередньо надихнуло Лісп (другу найдавнішу мову програмування високого рівня, створену в 1959 році), яка, в свою чергу, надихнула все, від ML до Haskell та Clojure.

Другою абстракцією було процедурне програмування. Він вийшов із комп'ютерних архітектур фон Неймана, де писалися послідовні програми, по одній інструкції. FORTRAN (найстаріша мова програмування високого рівня, 1958) була першою мовою високого рівня, яка вийшла з парадигми процедур.

Третя абстракція, ймовірно, була фактично деклараційним програмуванням, спочатку на прикладі Absys (1967), а потім пізніше Prolog (1972). Це основа логічного програмування, де вирази оцінюються шляхом відповідності серії декларацій або правил, а не виконання серії інструкцій.

Четверта абстракція тоді була об'єктно-орієнтованим програмуванням, яке вперше з'явилося в програмах Lisp у 60-х роках, але пізніше було прикладом Smalltalk у 1972 році. Єдино правдива об'єктно-орієнтована абстракція. Я цього не збираюся чіпати.)

Усі інші абстракції, особливо щодо традиційної архітектури комп’ютера фон Неймана, є варіаціями цих чотирьох тем. Я не переконаний, що існує ще одна абстракція поза цими чотирма, яка не є лише варіацією чи їх комбінацією.

Але абстракція - це, по суті, лише спосіб моделювання та опису алгоритму. Ви можете описати алгоритми як ряд дискретних кроків, як набір правил, яким слід дотримуватися, як набір математичних функцій або як взаємодіючі об'єкти. Дуже важко уявити будь-який інший спосіб описати або моделювати алгоритми, і навіть якщо є, я не переконаний у його корисності.

Однак існує модель квантових обчислень. У квантових обчисленнях необхідні нові абстракції для моделювання квантових алгоритмів. Будучи неофітом у цій галузі, я не можу це коментувати.

Для багатьох найчистішою формою абстрагування коду в сучасну епоху бінарного програмування є "функція вищого порядку". В основному, сама функція розглядається як дані, а функції функцій визначаються так, як ви б їх бачили в математичних рівняннях з операторами, що визначають результат їх операндів і заздалегідь визначений порядок операцій, що визначають "вкладення" цих операцій. Математика має дуже мало «імперативних команд» у своїй структурі; два приклади, які я можу придумати, - це "нехай x має деяке значення або будь-яке значення, яке відповідає деякому обмеженню", і "кусочно функції", в яких вхід визначає вираз, необхідний для отримання результату. Ці конструкції легко представити як власні функції; "функція" x завжди повертає 1, а "перевантажує" функції визначаються з точки зору того, що передається їм (що на відміну від об'єктно-орієнтованих перевантажень можна визначити на основі введення значень), що дозволяє "частково" оцінювати названу групу функцій, навіть з точки зору самих себе. Таким чином, програма усуває поняття імперативів на низькому рівні, а натомість фокусується на "оцінці себе" за даними вхідних даних.

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

Функції вищого порядку тепер є частиною багатьох імперативних мов; Ламбда-оператори .NET в основному дають можливість "анонімного" функціонального введення в іншу "функцію" (реалізована в обов'язковому порядку, але теоретично цього не повинно бути), завдяки чому можна досягти високонастроюваного "ланцюжка" дуже загальних "функцій" для досягнення бажаний результат.

Інша абстракція, яка зазвичай зустрічається в останньому раунді мов програмування, - це динамічне введення змінних, що базується на концепції "набору качок"; якщо вона схожа на качку, плаває, як качка, летить як качка і чхає, як качка, можна назвати її качкою. Не має значення, чи це насправді крижанка чи полотно. Це може питання , якщо це на самому справі гусака або лебедя, але знову ж це може не має значення , якщо все , що ви дбаєте про те , що він плаває і літає, і свого роду виглядає як качка. Це вважається кінцевим у спадковому об'єкті; вам байдуже, що це таке , окрім того, як давати ім’я; що важливіше, що це робить. У таких мовах є в основному лише два типи; "атом", єдиний елемент інформації (одне "значення"; число, символ, функція, що б там не було) та "кортеж", що складається з атома і "вказівника" на все інше в кортежі. Як саме ці типи впроваджені у двійковій системі під час виконання, не має значення; використовуючи їх, ви можете досягти функціональності практично кожного типу, про який ви можете придумати, від простих типів значень до рядків до колекцій (що, оскільки значення можуть бути різними "типами", дозволяє "складні типи", також "об'єкти").

Можна визначити доменні мови, такі як SQL, як вищий порядок абстрагування. SQL - це дуже цільова мова, яка абстрагує від таких операцій, як зберігання та забезпечує функції вищого рівня, засновані на теорії наборів. Також розглянемо, скільки сьогодні основних мов орієнтовано не на конкретну архітектуру, а на віртуальну машину (наприклад, JVM або .NET CLR). Для прикладу C # складається в IL, який інтерпретується (або частіше JIT'd - Just In Time Compiled-- до нативного втілення) за допомогою нативного двигуна виконання.

Про концепцію DSL використовувались для створення мов дуже високого рівня, які можна використовувати без особливого технічного досвіду для створення робочої програми. Подумайте, чи хтось зміг описати свої сутності та взаємодії наближеними до простої англійської мови та в операційному середовищі, впораючись із усім, від представлення простого інтерфейсу користувача, до зберігання даних у якійсь базі даних. Як тільки ці операції стануть абстрагованими, ви можете уявити собі, наскільки легко може бути програмування.

Сьогодні існують такі, як JetBrains MPS (це інструментарій для опису DSL або мовного генератора). Microsoft пройшла короткий набіг (і дуже багатообіцяюче, що я можу додати) у цей простір з його мовою M (мова M була настільки повною, що мова була визначена в M).

Критики концепції вказують на попередні невдалі спроби усунути програмістів із завдання розробляючих програм, відмінність робочих стіл DSL (як називає їх Фаулер) полягає в тому, що розробники все ще братимуть участь у кодифікації концепцій, які доменні експерти можуть використовувати для вираження потреби свого домену. Так само, як виробники ОС та мови створюють інструменти, які ми використовуємо для програмування, ми використовуємо DSL для надання інструментів для бізнес-користувачів. Можна було б уявити DSL, які описують дані та логіку, тоді як розробники створюють інтерпретатори, які зберігають та отримують дані та застосовують логіку, виражену в DSL.

Я заперечую, що метаструктури, модулі, фреймворки, платформи та послуги - це все більш високі рівні, ніж класи. Моя ієрархія абстракцій системи програмування:

• послуги
• платформи, стеки рішень
• рамки
• модулі, пакети
• метаструктури: метакласи, функції вищого порядку, дженерики, шаблони, риси, аспекти, декоратори
• об'єкти, класи, типи даних
• функції, процедури, підпрограми
• структури управління
• рядки коду

Метаструктури , такі як метакласи , функції вищого порядку та генеричні засоби, явно додають абстракцію до основних класів, функцій, типів даних та екземплярів даних. Риси, аспекти та декоратори - це новіші механізми комбінування функцій коду та аналогічно «прискорення» інших класів та функцій.

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

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

Стеки рішень або платформи, як правило, поєднують у собі декілька рамок, підсистем або компонентів у середовищі для вирішення кількох проблем.

Нарешті, є сервіси - часто розгорнуті у вигляді веб- або мережевих служб. Це архітектури, фреймворки, стеки рішень або можливості додатків, що поставляються як цілі пакети. Їх внутрішні часто часто непрозорі, в першу чергу викриваючи адміністратор, програмування та користувальницькі інтерфейси. PaaS і SaaS - поширені приклади.

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

Я думаю, що помилково шукати лише нові рівні абстракції . Усі, які я перераховував вище, існують роками , навіть якщо вони не всі були такими відомими чи популярними, як зараз. І за ці роки покращені абстракції на кожному рівні кодування покращилися. Зараз у нас є загальні колекції загального призначення, а не лише масиви. Ми перебираємо колекції, а не лише діапазони індексів. У нас є розуміння списків та список фільтрів та операцій з картою. Багато функцій мови можуть мати змінну кількість аргументів та / або аргументи за замовчуванням. І так далі. Ми збільшуємо абстракцію на кожному рівні, тому додавання більше рівнів не є необхідним для підвищення загального рівня абстракції.

Наступна абстракція після занять - це мета-класи . Це так просто;)

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

Я здивований, що ніхто не згадав про теорію категорій.

Найбільш фундаментальною одиницею програмування є функція, заснована на типах. Функції зазвичай позначаються як f: A -> B, де A і B - типи. Якщо ви об'єднаєте ці речі, які я називаю типами та функціями, то разом правильно ви отримаєте щось, що називається категорією. На цьому не потрібно зупинятися.

Візьміть ці речі, категорії та запитайте себе, який би був правильний спосіб співвіднести їх між собою. Якщо ви зробите це правильно, ви отримаєте щось, що називається функтором, який переходить між двома категоріями і зазвичай позначається як F: C -> B. Ще раз вам не доведеться зупинятися.

Ви можете взяти всіх функторів і скласти їх правильно, і якщо ви все зробите правильно, ви почнете цікавитись, як співвідносити двох функторів один з одним. У цей момент ви отримуєте щось, що називається природним перетворенням, mu: F -> G, де F і G - функтори.

Мої знання в цей момент нечіткі, але ви можете продовжувати це робити і продовжувати підніматися по сходах абстракції. Об'єкти та заняття навіть не наближаються до опису того, наскільки високо можна піднятися по сходах абстракції. Є багато мов, які можуть обчислити вищезазначені поняття, і найвизначнішою з цих мов є Хаскелл. Тож якщо ви дійсно хочете дізнатись, що таке насправді абстракція, тоді перейдіть, вивчіть деякі Haskell або Agda, HOL або ML

Я думаю, що акторська модель відсутня у списку кандидатів.

Ось що я маю на увазі під акторами:

• незалежні утворення
• які отримують повідомлення, а при отриманні повідомлення можуть
• створювати нових акторів,
• оновити деякий внутрішній стан для наступного повідомлення,
• і надсилати повідомлення

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

Коротке обговорення / вступ: http://youtube.com/watch?v=7erJ1DV_Tlo

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

З конкретних інструкцій, що виконуються одна за одною, ми переходимо до функцій / підпрограм , які інкапсулюють або абстрагують логічне групування вказівок в один елемент. Тоді у нас є об'єкти або модулі , які інкапсулюють підпрограми, що стосуються певної логічної сутності або категорії, тому я можу групувати всі рядкові операції під Stringкласом, або всі загальні математичні операції під Mathмодулем (або статичний клас, такими мовами, як C #) .

Отже, якщо це наш прогрес, що буде далі? Ну, я не думаю, що у вас є чіткий наступний крок. Як відповіли інші, ваша прогресія стосується лише імперативних / процедурних стилів програмування, а інші парадигми не поділяють ваші концепції абстракції. Але якщо у мене є щось, що може логічно поширити вашу метафору, це послуги .

Служба подібна до класу в тому сенсі, що це сутність, яка виявляє функціональність, але вона передбачає набагато суворіше розмежування проблем, ніж зворотній зв'язок з об'єктами, які ви самі придумали. Вони відкривають обмежений набір операцій, приховують внутрішню логіку і навіть не обов'язково працюють на одній машині.

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

Нові форми абстракції приховують від вас роботу низького рівня. Названі процедури та функції приховують від вас адреси програм. Об'єкти приховують динамічне управління пам’яттю та деякі типові «if заяви».

Я б припустив, що наступним рівнем практичних абстракцій, які приховуватимуть низькорівневу дружність від вас, є ті з функціональних реактивних програм . Подивіться на "сигнали" у чомусь на зразок http://elm-lang.org/, які приховують зворотні виклики та оновлення залежностей, якими вам доведеться явно керувати в JavaScript. FRP може приховати велику складність міжпроцесорних і міжмашинних комунікацій, які необхідні і в масштабних Інтернет-програмах, і у високопродуктивних паралелізмах.

Я майже впевнений, що саме цим ми будемо хвилюватися протягом наступних 5 років.

Теорія наборів - як частково реалізована в реляційних базах даних, але також і в мовах статистики, таких як SAS і R, забезпечують інший, але, можливо, більш високий рівень абстрагування, ніж ОО.