Я деякий час мене дуже цікавила теорія мови програмування та обчислення процесів, і я почав їх вивчати. Якщо чесно, то я б не проти зайнятися кар’єрою. Я вважаю теорію неймовірно захоплюючою. Одне постійне запитання, над яким я продовжую працювати, - це чи теорія PL чи технологічний розрахунок процесу взагалі мають якесь значення в розробці сучасної мови програмування. Я бачу так багато варіантів на Pi-рахунку там, і там є багато активних досліджень, але чи вони коли-небудь знадобляться чи матимуть важливе застосування? Причина, чому я прошу, полягає в тому, що я люблю розробляти мови програмування, і справжньою кінцевою метою було б використання теорії для фактичного побудови PL. Щодо матеріалів, які я написав, насправді взагалі не було кореляції з теорією.
Використання процесових калькуляцій та теорії PL для розробки сучасної мови програмування
Відповіді:
Моя відповідь - це лише розробка твору Жиля, яку я не читав, перш ніж писав свою. Можливо, це все-таки корисно.
Дозвольте розпочати спробу відповісти на ваше запитання з розрізнення двох вимірів роботи мов програмування, які зовсім по-різному стосуються теорії мови програмування взагалі та конкретного обчислення процесу.
Чисті дослідження.
Дослідження та розробки, орієнтовані на товар.
Останнє, як правило, відбувається в промисловості з метою забезпечення мов програмування як продукту. Команди, що розробляють Java в Oracle і C # в Microsoft, є прикладами. Навпаки, чисті дослідження не прив’язані до продуктів. Його мета полягає в тому, щоб зрозуміти мови програмування як об'єкти, що представляють інтерес, і дослідити математичні структури, що лежать в основі всіх мов програмування.
Через різні цілі, різні аспекти теорії мови програмування є актуальними як для чистих досліджень, так і для науково-дослідної роботи, орієнтованої на продукт. На малюнку нижче може бути вказано, що важливо, де.
У цей момент можна запитати, чому два виміри настільки різняться і як вони все-таки співвідносяться.
Ключове розуміння полягає в тому, що дослідження та розробки мови програмування мають багато аспектів: технічний, соціальний та економічний. Майже за визначенням галузь зацікавлена в економічній виплаті мов програмування. Microsoft та інші не розробляють мови з доброго серця, а тому, що вони вважають, що мови програмування дають їм економічну перевагу. І вони глибоко дослідили, чому деякі мови програмування досягають успіху, а інші, здавалося б, подібні або з більш вдосконаленими функціями, цього не роблять. І вони виявили, що немає єдиної причини. Мови програмування та їх оточення є складними, і тому є причинами прийняття чи ігнорування будь-якої конкретної мови. Але найбільшим фактором успіху мови програмування є переважна прихильність програмістів до мов, які вже широко використовуються: чим більше людей використовують мову, тим більше бібліотек, інструментів, навчального матеріалу доступно, і тим продуктивнішим програміст можна використовувати цю мову. Це також називається мережевим ефектом. Ще одна причина - висока вартість перемикання мов для окремих людей та організації: оволодіння мовою, особливо не дуже досвідченим програмістом, і коли семантична відстань до знайомих мов велике, - це серйозне, що забирає багато часу. Враховуючи ці факти, можна запитати, чому нові мови взагалі отримують тягу? Чому компанії взагалі розробляють нові мови? Чому ми просто не залишимося з Java або Cobol? Я думаю, що існує декілька ключових причин того, що мова має успіх,
Відкривається новий домен програмування, який не має змін для переміщення. Основний приклад - Інтернет з супутнім зростанням Javascript.
Мовна клейкість. Під цим я маю на увазі високу ціну на зміну мови. Але іноді програмісти переходять на різні поля, беручи з собою мову програмування та досягаючи успіху зі старою мовою в новому полі.
Мова підштовхує велика компанія з серйозною фінансовою вогневою силою. Ця підтримка зменшує ризик усиновлення, оскільки ранні усиновлювачі можуть бути впевнені, що мова все ще буде підтримуватися через кілька років. Хороший приклад цього - C #.
Мова може поставитись із переконливими інструментами та екосистемою. Тут також можна назвати екосистему C # та її. Net та Visual Studio.
Старі мови підбирають нові функції. На думку спадає Java, яка в кожній ітерації вибирає більше хороших ідей з традиційної програми програмування.
Нарешті, нова мова може мати сутнісні технічні переваги, наприклад, бути більш виразною, мати симпатичніший синтаксис, вводити системи, які сприймають більше помилок тощо.
Враховуючи це, не слід дивуватись тому, що між чистим вивченням мови програмування і комерційною мовою програмування існує певний розрив. Хоча обидві мають на меті підвищити ефективність побудови та еволюції програмного забезпечення, особливо для широкомасштабного програмного забезпечення, робота з промисловими мовами програмування повинна бути більш зацікавлена у сприянні швидкому прийняттю до досягнення критичної маси та отримання мережевого ефекту. Це призводить до фокусування дослідження на речах, які хвилюють працюючих програмістів. І це, як правило, такі, як наявність бібліотеки, швидкість компілятора, якість скомпільованого коду, портативність тощо. Обчислення процесів, як ми його практикуємо сьогодні, мало користі програмістам, які працюють над основними проектами (хоча я вважаю, що це зміниться в майбутньому).
Чисті дослідження мови програмування зовсім інші. Він працює зі спрощеними моделями мов програмування: -calculus - це масове спрощення функціонального програмування. Таким же чином -calculus - це масове спрощення одночасного програмування. Ці масові спрощення є запорукою успішного дослідження. Вони дають нам змогу зосередитись на основних обчислювальних механізмах (наприклад,π β-відведення для функціонального програмування, роздільна здатність / уніфікація для логічного програмування, передача імен для одночасних обчислень). Щоб зрозуміти, чи може така мова, як Scala, мати життєздатний повний висновок про тип, нам не потрібно турбуватися про JVM. Дійсно, що думка про JVM призведе до погіршення кращого розуміння типу виводу. Ось чому абстрагування обчислень на крихітні основні обчислення є життєво важливим і потужним.
Таким чином, ви можете вважати дослідження мови програмування як масивну пісочницю, де люди граються з іграшками, і якщо вони виявляють щось цікаве, граючи з певною іграшкою, і ретельно досліджували іграшку, то ця цікава іграшка починає свій довгий похід до основного промислового прийняття . Я кажу, що триває марш, оскільки мовні особливості, вперше винайдені дослідником мови програмування, як правило, потребують десятиліть, перш ніж набути широкого поширення. Наприклад, збирання сміття було задумано у 1950-х роках і стало широко доступним для Java у 90-х. Зіставлення візерунків починається з 1970 року і широко використовується лише з часів Scala.
Обчислення процесів - особливо цікава іграшка. Але це занадто нове, щоб його ретельно досліджувати. Це займе ще десятиліття чистих досліджень. Зараз у дослідженні теорії процесів - це взяти найбільшу історію успіху дослідження мови програмування, теорію (послідовних) типів та розробити теорію типів для одночасності передачі повідомлень. Системи друку середньої експресивності для послідовного програмування, кажуть Хіндлі-Мілнер, зараз добре зрозумілі, всюдисущі та прийняті робочими програмістами. Ми хотіли б мати помірно виразні типи для одночасного програмування. Дослідження з цього питання розпочалися у 1980-х роках такими піонерами, як Мілнер, Санггіоргі, Тернер, Кобаяші, Хонда та інші, часто засновані явно або неявно, на ідеї лінійності, що походить від лінійної логіки. Останні кілька років спостерігається значне зростання активності, і я очікую, що ця траєкторія вгору продовжиться в осяжному майбутньому. Я також очікую, що ця робота може почати просочуватися до науково-дослідних досліджень, орієнтованих на продукт, частинами з прагматичної причини, що молоді дослідники, які пройшли навчання в обчисленні процесів, будуть їздити і працювати в промислові науково-дослідні лабораторії, а також через еволюцію процесора та комп'ютерної архітектури від послідовних форм обчислення.
Підсумовуючи, я б не хвилювався, що ви не знайдете передової теорії мови програмування, такої як обчислення процесу, корисною для вашої власної роботи з побудови мов. Це просто тому, що передова теорія не стосується проблем сучасних мов програмування. Йдеться про майбутні мови. Мине певний час, щоб "реальний світ" наздогнав. Знання, які ви використовуєте для побудови мов на сьогодні, - це теорія мови програмування минулого. Я закликаю вас дізнатися більше про обчислення процесів, оскільки це одна з найбільш важливих областей усіх теоретичних інформатик.
Наука дизайну мови програмування дуже зароджується. Теорія (вивчення того, що означають програми та виразність мови) та емпіризму (що програмісти керують чи не встигають зробити) дають безліч якісних аргументів для зважування так чи інакше при розробці мови. Але у нас рідко є якісь кількісні причини для рішення.
Існує затримка між часом, коли деяка теорія стабілізується достатньо, щоб інновація була застосована на практичній мові програмування, і часом, коли ця інновація починає з'являтися на "основних" мовах. Наприклад, можна сказати, що автоматичне управління пам’яттю зі збиранням сміття було зрілим для промислового використання в середині 60-х років, але воно досягло лише з Яви в 1995 році. в Яву в середині 200-х. За масштабами кар’єри дослідника 30 років - це тривалий час.
Широкомасштабне промислове засвоєння мови є питанням вивчення соціологів, і наука ще більше зароджується. Ринкові міркування є важливим фактором - якщо Sun, Microsoft чи Apple натискають на мову, це має набагато більший вплив, ніж будь-яка кількість робіт POPL та PLDI. Навіть для програміста, який має вибір, доступність бібліотеки, як правило, набагато важливіша за дизайн мови. Що не означає, що дизайн мови не важливий: добре продумана мова - це полегшення! Зазвичай це не вирішальний фактор.
Процесні обчислення все ще знаходяться на етапі, коли теорія не стабілізується. Ми вважаємо, що ми розуміємо послідовні обчислення - всі моделі речей, які ми любимо називати послідовним обчисленням, рівнозначні (це теза Церкви-Тьюрінга). Це не стосується одночасності: різні розрахунки процесу, як правило, мають тонкі відмінності у виразності.
Процесні розрахунки мають практичне значення. Дуже багато обчислень там розподілено - вони залучають клієнтів, що розмовляють із серверами, сервери, що розмовляють з іншими серверами і т. Д. Навіть локальні обчислення дуже часто багатопоточні, щоб скористатися перевагами паралелізму над декількома процесорами та реагувати на екологічну сумісність (спілкування з незалежними програмами і з користувачем).
Чи потрібні досягнення для покращення програмного забезпечення? Зрештою, там є мільярд доларів промисловості, які не можуть сказати пі-числення з пирога в небі. Потім знову ця галузь витрачає мільярди доларів на виправлення помилок.
"Чи вони коли-небудь знадобляться" - це ніколи не варте питання дослідження. Заздалегідь неможливо передбачити, що матиме довгострокові наслідки. Я б навіть пішов далі і сказав, що це безпечне припущення, що будь-яке дослідження матиме наслідки одного дня - ми просто не знаємо на той час, чи настане цей день наступного року чи наступного тисячоліття.
Я бачу так багато варіантів на Pi-рахунку там, і там є багато активних досліджень, але чи вони коли-небудь знадобляться чи матимуть важливе застосування?
Причина, чому я прошу, полягає в тому, що я люблю розробляти мови програмування, і справжньою кінцевою метою було б використання теорії для фактичного побудови PL. Щодо матеріалів, які я написав, насправді взагалі не було кореляції з теорією.
Це хитро запитання! Я розповім вам свою особисту думку, і наголошую, що це моя думка .
Я не думаю, що пі-числення прямо підходить як позначення для одночасного програмування. Однак, я думаю, ви обов'язково повинні вивчити його, перш ніж розробляти сумісну мову програмування. Причина в тому, що пі-числення дає низький рівень --- але важливо, композиційний! --- рахунок одночасності. Як результат, він може виражати все, що завгодно, але не завжди зручно.
Пояснення цього коментаря вимагає трохи подумати про типи. По-перше, корисні мови програмування, як правило, потребують певної дисципліни типу для побудови абстракцій. Зокрема, вам потрібен певний тип функції, щоб використовувати процедурні абстракції під час створення програмного забезпечення.
Тепер дисципліна природного типу пі-числення є деяким варіантом класичної лінійної логіки. Дивіться, наприклад, статтю Абрамського Процес реалізаційності , який показує, як ви інтерпретуєте прості одночасні програми як докази пропозицій з лінійної логіки. (Література містить багато роботи над типами сеансів для введення програм пі-числення, але типи сеансів і лінійні типи дуже тісно пов'язані.)
Однак я сказав, що дисципліна природного типу пі-числення - це класична лінійна логіка, і це є джерелом труднощів у використанні її безпосередньо як мови програмування. У більшості презентацій класичної лінійної логіки (лінійна) функція типу не є примітивною. Замість цього, ви закодувати типи функцій з допомогою де Морган дуальність .
Це просто чудово з теорії типу POV, але це незручно при програмуванні. Причина полягає в тому, що програмісти в кінцевому підсумку управляють не лише своїми функціональними викликами, але і стеком викликів. (Дійсно, кодування обчислення лямбда в обчисленні пі, як правило, виглядає як перетворення CPS.) Тепер, введення тексту гарантує, що вони ніколи цього не викручують, але, тим не менш, це багато бухгалтерського обліку, що сфокусований на програмісті.
Це не є проблемою, характерною лише для теорії одночасності - mu-обчислення дає хороший теоретико-теоретичний виклад послідовних операторів управління, таких як call / cc, але ціною зробити стек явним, що робить його незручною мовою програмування.
Тож, розробляючи паралельну мову програмування, я вважаю, що ви повинні розробити свою мову з абстракціями вищого рівня, ніж необроблені пікалі, але ви повинні переконатися, що вона чітко переведена на обґрунтований тип тексту. (Приємний останній приклад цього - процеси, функції та сесії вищого порядку Тонхіно, Кайрі та Пфеннінг : монадійна інтеграція .)
Ви говорите, що " справжньою кінцевою метою було б використовувати теорію для фактичного побудови ПЛ". Отже, ви, мабуть, визнаєте, що є інші цілі?
З моєї точки зору, метою №1 теорії є надання розуміння, що може бути міркуванням про існуючі мови програмування, а також про програми, написані в них. У вільний час я підтримую велику частину програмного забезпечення, клієнта електронної пошти, написаного століттями в Ліспі. Уся теорія ФЛ, яку я знаю, такі як логіка Хоара, логіка розділення, абстрагування даних, параметричність реляції та контекстна еквівалентність тощо, корисні у щоденній роботі. Наприклад, якщо я розширюю програмне забезпечення за допомогою нової функції, я знаю, що воно все одно має зберегти оригінальну функціональність, а це означає, що воно повинно вести себе так само, як і у всіх старих контекстах, навіть якщо він збирається зробити щось нове в нові контексти. Якби я нічого не знав про контекстуальну еквівалентність, я, мабуть, навіть не зміг би вирішити проблему таким чином.
Що стосується вашого питання про пі-числення, я думаю, що пі-числення все ще є занадто новим, щоб знайти застосування в мовному дизайні. Сторінка вікіпедії на pi-рахунку згадує BPML та оккам-пі як мовні конструкції з використанням пі-числення. Але ви також можете подивитися на сторінки попереднього CCS та інші обчислення процесу, такі як CSP, обчислення та інші, які використовувались у багатьох розробках мови програмування. Ви також можете подивитися в розділі "Об'єкти і пі-обчислення" книги Сангіоргі та Уокера, щоб побачити, як пі-числення стосується існуючих мов програмування.
Мені подобається шукати практичну реалізацію обчислень процесу в дикій природі :) (окрім читання про теорію).
- Канали асинхронізації Clojure засновані на CSP: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
- У Golang також є канали на основі CSP (я думаю, що це надихнуло Rich Hickey для клоджура): http://www.informit.com/articles/printerfriendly/1768317
- Є хлопець, який зробив розширення на базі АКТ до scala (Підписка), але мені не вистачає репутації, щоб розмістити посилання ...
тощо.