Некоторое время я очень интересовался теорией языка программирования и процессными исчислениями и начал их изучать. Честно говоря, это то, что я не прочь заняться карьерой. Я считаю, что теория невероятно увлекательна. Один постоянный вопрос, с которым я постоянно сталкиваюсь, заключается в том, имеют ли какое-либо значение PL-теория или исчисление процессов в современной разработке языков программирования. Я вижу так много вариантов пи-исчисления, и есть много активных исследований, но будут ли они когда-нибудь нужны или будут иметь важные приложения? Причина, по которой я спрашиваю, заключается в том, что я люблю разрабатывать языки программирования, и истинная конечная цель - использовать теорию для создания PL. Для материала, который я написал, действительно не было никакой связи с теорией вообще.
Использование Process Calculi и PL Theory для разработки современного языка программирования
Ответы:
Мой ответ на самом деле является лишь разработкой Жиля, которую я не читал до того, как написал свой. Может быть, это все же полезно.
Позвольте мне начать мою попытку ответить на ваш вопрос с разграничения между двумя измерениями работы языков программирования, которые совершенно по-разному относятся к теории языка программирования в целом и исчислению процессов в частности.
Чистое исследование.
Исследования и разработки, ориентированные на продукт.
Последнее обычно происходит в промышленности с целью предоставления языков программирования в качестве продукта. В качестве примеров можно привести команды, разрабатывающие Java в Oracle и C # в Microsoft. Напротив, чистые исследования не привязаны к продуктам. Его цель состоит в том, чтобы понимать языки программирования как объекты внутреннего интереса и исследовать математические структуры, лежащие в основе всех языков программирования.
Из-за расходящихся целей различные аспекты теории языка программирования актуальны как в чистых исследованиях, так и в исследованиях и разработках, ориентированных на продукт. Приведенная ниже картина может дать представление о том, что и где важно.
В этот момент можно спросить, почему эти два измерения так различны и как они, тем не менее, связаны.
Ключевым моментом является то, что исследования и разработки на языке программирования имеют несколько аспектов: техническое, социальное и экономическое. Практически по определению промышленность заинтересована в экономической выгоде языков программирования. Microsoft и др. Не разрабатывают языки по доброй воле, а потому, что считают, что языки программирования дают им экономическое преимущество. И они глубоко исследовали, почему некоторые языки программирования преуспевают, а другие, кажущиеся схожими или с более продвинутыми функциями, не могут. И они обнаружили, что нет единой причины. Языки программирования и их окружение являются сложными, поэтому существуют причины для принятия или игнорирования какого-либо конкретного языка. Но самым большим фактором успеха языка программирования является предпочтительное присоединение программистов к языкам, которые уже широко используются: чем больше людей использует язык, тем больше библиотек, инструментов, учебных материалов и тем более продуктивным программист можно использовать этот язык. Это также называется эффектом сети. Другой причиной является высокая стоимость переключения языков для отдельных лиц и организаций: освоение языка, особенно для неопытного программиста, и когда семантическая дистанция до знакомых языков велика, является серьезной, требующей много времени. Учитывая эти факты, можно спросить, почему новые языки становятся популярными вообще? Почему компании вообще разрабатывают новые языки? Почему бы нам просто не остаться с Java или Cobol? Я думаю, что есть несколько ключевых причин, по которым язык может быть успешным,
Открывается новая область программирования, которая не имеет смещений. Основным примером является сеть с сопутствующим ей ростом Javascript.
Языковая липкость. Под этим я подразумеваю высокую цену смены языка. Но иногда программисты переходят в разные области, беря с собой язык программирования и добиваясь успеха со старым языком в новой области.
Язык подталкивает крупная компания с серьезной финансовой огневой мощью. Такая поддержка снижает риск усыновления, потому что ранние усыновители могут быть достаточно уверены в том, что язык все еще будет поддерживаться через несколько лет. Хорошим примером этого является C #.
Язык может прийти с убедительными инструментами и экосистемой. Здесь также C # и его .Net и экосистема Visual Studio могут быть упомянуты в качестве примера.
Старые языки приобретают новые функции. На ум приходит Java, которая на каждой итерации получает больше хороших идей из традиции функционального программирования.
Наконец, новый язык может иметь внутренние технические преимущества, например быть более выразительным, иметь более приятный синтаксис, печатать системы, которые улавливают больше ошибок, и т. Д.
Учитывая этот фон, не должно вызывать удивления то, что существует некоторое различие между чисто исследованиями языка программирования и разработкой коммерческого языка программирования. В то время как оба стремятся сделать разработку и развитие программного обеспечения более эффективными, особенно для крупномасштабного программного обеспечения, работа над языком промышленного программирования должна быть более заинтересована в содействии быстрому принятию, чтобы достичь критической массы и получить сетевой эффект. Это приводит к исследованию того, что волнует работающих программистов. И это, как правило, такие вещи, как доступность библиотеки, скорость компиляции, качество скомпилированного кода, переносимость и так далее. Исчисление процессов в том виде, в котором мы их практикуем сегодня, мало что дает программистам, работающим над основными проектами (хотя я верю, что это изменится в будущем).
Чистое исследование языка программирования совсем другое. Он работает с упрощенными моделями языков программирования: -calculus - это огромное упрощение функционального программирования. Точно так же -калькулус - это огромное упрощение параллельного программирования. Эти огромные упрощения являются ключом к успешному исследованию. Они позволяют нам сосредоточиться на основных вычислительных механизмах (например,π βсокращение для функционального программирования, разрешение / унификация для логического программирования, передача имени для параллельных вычислений). Чтобы понять, может ли такой язык, как Scala, иметь полный вывод типов, нам не нужно беспокоиться о JVM. Действительно, размышления о JVM отвлекают от лучшего понимания вывода типов. Вот почему абстракция вычислений в крошечные базовые исчисления является жизненно важной и мощной.
Таким образом, вы можете рассматривать исследование языка программирования как огромную песочницу, где люди играют с игрушками, и если они находят что-то интересное, играя с конкретной игрушкой, и тщательно исследуют игрушку, то эта интересная игрушка начинает свой долгий путь к общепринятому промышленному признанию. , Я говорю «длинный путь», потому что особенности языка, впервые изобретенные исследователем языка программирования, обычно проходят десятилетия, прежде чем становятся широко признанными. Например, сборка мусора была задумана в 1950-х годах и стала широко доступна с Java в 1990-х годах. Сопоставление с образцом восходит к 1970 году и широко используется только со времен Scala.
Исчисление процесса - особенно интересная игрушка. Но это слишком ново для тщательного изучения. Это займет еще одно десятилетие чистых исследований. То, что в настоящее время идет в исследовании теории процессов, - это взять одну большую историю успеха в изучении языка программирования, теории (последовательных) типов и развить теорию типов для параллелизма передачи сообщений. По словам Хиндли-Милнера, системы типизации с умеренной выразительностью для последовательного программирования теперь хорошо поняты, повсеместны и приняты работающими программистами. Мы хотели бы иметь умеренно выразительные типы для параллельного программирования. Исследования по этому вопросу начались в 1980-х годах такими пионерами, как Милнер, Сангиорги, Тернер, Кобаяши, Хонда и другие, часто основанными, явно или неявно, на идее линейности, которая исходит из линейной логики. В последние несколько лет наблюдается значительный рост активности, и я ожидаю, что эта восходящая траектория продолжится в обозримом будущем. Я также ожидаю, что эта работа начнёт просачиваться в исследования и разработки, ориентированные на продукт, отчасти по той прагматической причине, по которой молодые исследователи, прошедшие обучение по исчислению процессов, пойдут работать в промышленные лаборатории НИОКР, а также из-за эволюции ЦП и компьютерной архитектуры. из последовательных форм вычислений.
Таким образом, я бы не беспокоился, что вы не найдете передовую теорию языков программирования, такую как исчисление процессов, полезной в вашей собственной работе по созданию языков. Это просто потому, что передовая теория не учитывает проблемы современных языков программирования. Это о будущих языках. «Реальному миру» понадобится время, чтобы наверстать упущенное. Знания, которые вы используете для создания языков на сегодняшний день, являются теорией языка программирования прошлого. Я призываю вас больше узнать об исчислении процессов, потому что это одна из самых интересных областей теоретической информатики.
Наука дизайна языка программирования находится в зачаточном состоянии. Теория (изучение того, что означают программы и выразительность языка) и эмпиризм (то, что программисты управляют или не умеют делать) дают множество качественных аргументов, которые так или иначе взвешиваются при разработке языка. Но у нас редко есть какие-либо количественные причины для принятия решения.
Существует задержка между временем, когда некоторая теория стабилизируется настолько, чтобы инновация могла использоваться на практическом языке программирования, и временем, когда это нововведение начинает появляться на «основных» языках. Например, можно сказать, что автоматическое управление памятью со сборкой мусора было разработано для промышленного использования в середине 1960-х годов, но достигло массового распространения в Java только в 1995 году. Параметрический полиморфизм был хорошо понят в конце 1970-х годов и сделал его в Яву в середине 200-х годов. В масштабе карьеры исследователя 30 лет - это много.
Широкомасштабное промышленное принятие языка - предмет изучения социологов, и эта наука еще в зачаточном состоянии. Рыночные соображения являются важным фактором - если Sun, Microsoft или Apple выдвигают язык, это оказывает гораздо большее влияние, чем любое количество документов POPL и PLDI. Даже для программиста, у которого есть выбор, доступность библиотеки обычно намного важнее, чем языковой дизайн. Это не значит, что языковой дизайн не важен: хорошо продуманный язык - это облегчение! Обычно это не решающий фактор.
Исчисления процесса все еще находятся на стадии, когда теория не стабилизировалась. Мы считаем, что понимаем последовательные вычисления - все модели вещей, которые мы хотели бы назвать последовательными вычислениями, эквивалентны (это тезис Черча-Тьюринга). Это не относится к параллелизму: разные исчисления процессов имеют тенденцию иметь незначительные различия в выразительности.
Исчисление процесса имеет практическое значение. Распространено много вычислений - они вовлекают клиентов, говорящих с серверами, серверы, общающихся с другими серверами, и т. Д. Даже локальные вычисления очень часто являются многопоточными, чтобы использовать преимущества параллелизма над несколькими процессорами и реагировать на параллелизм среды (взаимодействие с независимыми программами). и с пользователем).
Нужны ли научные достижения для создания лучшего программного обеспечения? В конце концов, существует индустрия на миллиард долларов, которая не может отличить пи-исчисление от пирога в небе. Опять же, эта отрасль тратит миллиарды долларов на исправление ошибок.
«Будут ли они когда-нибудь нужны» - это никогда не стоящий вопрос в исследованиях. Невозможно заранее предсказать, что будет иметь долгосрочные последствия. Я бы даже пошел дальше и сказал, что можно с уверенностью предположить, что любое исследование будет иметь последствия в один прекрасный день - мы просто не знаем, когда наступит этот день в следующем году или в следующем тысячелетии.
Я вижу так много вариантов пи-исчисления, и есть много активных исследований, но будут ли они когда-нибудь нужны или будут иметь важные приложения?
Причина, по которой я спрашиваю, заключается в том, что я люблю разрабатывать языки программирования, и истинная конечная цель - использовать теорию для создания PL. Для материала, который я написал, действительно не было никакой связи с теорией вообще.
Это сложный вопрос! Я скажу вам свое личное мнение, и я подчеркиваю, что это мое мнение .
Я не думаю, что пи-исчисление напрямую подходит для обозначения параллельного программирования. Тем не менее, я думаю, что вы обязательно должны изучить его, прежде чем разрабатывать параллельный язык программирования. Причина в том, что пи-исчисление дает низкий уровень - но, что важно, композиционный! --- учет параллелизма. В результате он может выражать все, что вы хотите, но не всегда удобно.
Для объяснения этого комментария необходимо немного подумать о типах. Во-первых, полезные языки программирования обычно нуждаются в некоторой дисциплине типов для построения абстракций. В частности, вам нужен какой-то тип функции, чтобы использовать процедурные абстракции при создании программного обеспечения.
Теперь дисциплина естественного типа пи-исчисления - это некий вариант классической линейной логики. См., Например, статью Абрамского «Реализация процесса» , в которой показано, как вы интерпретируете простые параллельные программы как доказательства предложений линейной логики. (В литературе много работы над типами сеансов для набора программ пи-исчисления, но типы сеансов и линейные типы очень тесно связаны.)
Это просто хорошо из теории типов POV, но это неудобно при программировании. Причина в том, что программисты в конечном итоге управляют не только своими вызовами функций, но и стеком вызовов. (Действительно, кодирование лямбда-исчисления в пи-исчисление, как правило, в конечном итоге выглядит как преобразование CPS.) Теперь типизация гарантирует, что они никогда этого не испортят, но, тем не менее, программисту навязывают много бухгалтерии.
Это не проблема, уникальная для теории параллелизма - мю-исчисление дает хорошее теоретико-доказательное описание последовательных управляющих операторов, таких как call / cc, но за счет явного указания стека, что делает его неуклюжим языком программирования.
Поэтому, при разработке параллельного языка программирования, я считаю, что вы должны проектировать свой язык с абстракциями более высокого уровня, чем в необработанном пи-исчислении, но вы должны убедиться, что он четко переведен в разумное типизированное исчисление процесса. (Хороший недавний пример этого - процессы, функции и сеансы высшего порядка Тонино, Каирса и Пфеннинга : монадическая интеграция .)
Вы говорите, что « истинной конечной целью было бы использовать теорию для создания ПЛ». Итак, вы предположительно признаете, что есть другие цели?
С моей точки зрения, целью теории № 1 является обеспечение понимания, которое может заключаться в рассуждениях о существующих языках программирования, а также о программах, написанных на них. В свободное время я поддерживаю большую часть программного обеспечения, почтовый клиент, написанный много лет назад на Лиспе. Вся известная мне теория PL, такая как логика Хоара, логика разделения, абстракция данных, параметрическая относительность, контекстуальная эквивалентность и т. Д., Пригодится в повседневной работе. Например, если я расширяю программное обеспечение новой функцией, я знаю, что оно по-прежнему должно сохранять первоначальную функциональность, что означает, что оно должно вести себя одинаково при всех старых контекстах, даже если оно собирается сделать что-то новое в новые контексты. Если бы я ничего не знал о контекстуальной эквивалентности, я бы, вероятно, даже не смог бы сформулировать проблему таким образом.
Говоря о вашем вопросе о пи-исчислении, я думаю, что пи-исчисление все еще слишком ново, чтобы найти применение в дизайне языка. На странице википедии по пи-исчислению упоминаются BPML и occam-pi как языковые схемы, использующие пи-исчисление. Но вы также можете взглянуть на страницы своего предшественника CCS и другие исчисления процессов, такие как CSP, исчисление соединений и другие, которые использовались во многих проектах языков программирования. Вы также можете заглянуть в раздел «Объекты и пи-исчисление» книги Сангиорги и Уокера, чтобы увидеть, как пи-исчисление связано с существующими языками программирования.
Мне нравится искать практические реализации исчисления процесса в дикой природе :) (помимо чтения о теории).
- Асинхронные каналы Clojure основаны на CSP: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
- У Голанга также есть каналы, основанные на CSP (я думаю, что это вдохновило Rich Hickey на clojure): http://www.informit.com/articles/printerfriendly/1768317
- Есть парень, который сделал расширение на основе ACP для scala (Subscript), но у меня недостаточно репутации, чтобы опубликовать ссылку ...
и т.п.