Как на самом деле формируется / создается новый язык программирования?

Как человек, который работает в основном над языковыми проектами, Я думаю, что есть две важные причины создания новых языков: скука и разочарование. Когда программистам скучно, они придумывают всевозможные смехотворно амбициозные проекты, чтобы заполнить свое время, а языки создают почти бесконечно интересные новые задачи. Когда программисты разочаровываются в существующих инструментах, они склонны создавать новые, чтобы заполнить кажущийся пробел. Я считаю, что все языковые проекты, от DSL до языков общего назначения, сводятся в основном к этим двум причинам.

На поверхностном уровне языки развиваются по сравнению с предшественниками, потому что есть пользователи, которые уже знают синтаксис, и существует не так много различных способов, как на самом деле выполнять синтаксис.

На более значимом уровне предыдущие языки могут использоваться повторяющимся образом, что можно было бы упростить, добавив некоторый синтаксис и поведение. Я думаю о том, как можно было бы использовать ООП на C до того, как появился C ++. Или различие между Fortran с GOTO и Algol с блочной структурой. Было больно делать ярлыки, и их можно было генерировать автоматически.

Лично я могу ошибаться, но я не думаю, что языки общего назначения (GPL) будут развиваться намного дальше (не говоря уже о том, что малые языки не будут распространяться).Я действительно думаю, что языки специального назначения (DSL) будут продолжать расти, и я думаю, что одна из ключевых особенностей любой GPL будет заключаться в том, насколько хорошо она помогает создавать новые DSL.

Я думаю, это потому, что существует континуум представлений между проблемной структурой данных, с одной стороны, и языками программирования, с другой. Любые данные, которые считываются какой-либо программой, в некотором смысле выражаются на языке, и эта программа является ее интерпретатором. Так что единственное, что действительно разделяет крайности, - это степень сложности и универсальности его интерпретатора.

Я ищу в DSL свойство минимальной избыточности по отношению к предполагаемой проблемной области. Идея состоит в том, что если есть какие-то требования, и если программа написана (человеком, на клавиатуре) для правильной реализации этих требований, и , то , если в требования вносится единственное согласованное изменение, там это некоторый объем редактирования, который необходимо внести в программу, чтобы правильно реализовать изменение, тогда избыточность языка относительно домен - это размер таких правок, усредненный (каким-то образом) по пространству возможных изменений. Очень простой способ измерить это - использовать программу diff между кодом до и после. Количество различий является мерой избыточности для этого изменения. Это немного многословно, но я хочу минимизировать это, чтобы сказать, что язык хорошо адаптирован к предметной области.

Если избыточность языка сведена к минимуму, это означает, что для реализации функциональных изменений требуется меньше правок, и не только код будет короче, но и, таким образом, меньше шансов внести ошибки .

Как программистов преподают сейчас, эти идеи у них в будущем. Минимизация избыточности исходного кода пока серьезно не ценится. Вместо этого у нас есть такие поводы, как ООП, которые, несмотря на их очевидную ценность, имеют тенденцию приводить к массово избыточному коду. Одним из многообещающих достижений является рост генераторов кода, но они снова рискуют стать сами по себе, а не служат цели уменьшения избыточности исходного кода.

Языки можно (и часто пишут) с нуля. Но языки могут (и часто делают) основываться на концепциях предшествующих языков. Зачем изобретать велосипед, если у ваших ног лежит идеально круглый?

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

Я не думаю, что будет правильным делать огульное утверждение, что все языки строятся на основе какого-то другого языка, который предшествовал ему. Разработчик нового языка, безусловно, должен иметь опыт использования нескольких существующих языков, понимать их сильные и слабые стороны для конкретной цели, а затем разрабатывать свой новый язык, чтобы включить все сильные стороны / великие идеи других и избежать слабостей других настолько, насколько это возможно. Учитесь на чужих успехах и неудачах. (Те, кто игнорирует историю, обречены на ее повторение)

Как отмечалось в других ответах, создание нового языка никак не связано с эффективностью реализации других языков. Новые языки и новые реализации одного и того же языка обычно заменяют, а не расширяют предыдущие примеры. Даже производительность одной реализации языка по сравнению с другой реализацией может значительно отличаться: вспомните компиляторы Borland C++, которые обгоняли другие компиляторы C++ той же эпохи, или сравните производительность виртуальной машины Java версии 1.0 с более поздними реализациями, в которых были добавлены дополнительные возможности повышения производительности, например, компилятор Hotspot.

Используя пример с автомобилем: поскольку Ford Model T был автомобилем и изрыгал черный дым, а Tesla Roadster является автомобилем и появился после Model T, правда ли, что Tesla Roadster также должен изрыгать черный дым просто потому, что он является автомобилем и появился после Model T? Конечно, нет. Tesla - это совершенно иное воплощение идеи автомобиля. Его дизайн отражает многое из того, чему научились со времен создания Model T, но это не Model T.

Я проголосовал за некоторые ответы выше, но также обратите внимание, что класс языков Lisp на самом деле некоторым образом побуждает программиста эффективно создавать новую языковую функцию всякий раз, когда это необходимо, создавая новый диалект лиспа. Вы можете спорить о том, в чем разница между созданием собственной новой функции и созданием новой языковой функции, но это утверждение Lispers.

Как на самом деле формируется / создается новый язык программирования?

Это многоступенчатый процесс:

1. Остроумные теоретики типов и другие профессионалы постоянно предлагая новые языковые функции. Вы можете прочитать о них в таких местах, как Proceedings of the ACM Symposium on Principles of Programming Languages ​​(POPL) , который проводится ежегодно с 1973 года.

2. Многие из этих предложений фактически реализованы в некоторых исследовательский язык ; некоторые языки исследования, которые я лично считаю многообещающими, включают Coq и Agda. Haskell - это бывший исследовательский язык, который добился большого успеха. Исследовательский язык, который привлекает 10 пользователей, часто считается успешным его дизайнерами. Многие языки исследований никогда не заходят так далеко.

   От исследования до развертывания Я знаю две модели:

3. Модель A: Приходит талантливый любитель и синтезирует целый набор существующих функций, возможно, включая некоторые новые идеи, на новом языке.У любителя есть талант, харизма и, возможно, потрясающее приложение. Так рождаются C, Perl, Python, Ruby и Tcl.

4. Модель P: Талантливый профессионал жертвует карьерой ради создания и распространения нового языка. У профессионала есть талант, глубокие познания в данной области и, возможно, потрясающее приложение. Так родились Haskell, Lua, ML, Pascal, Scala и Scheme.

   Вы предлагаете другую модель:

5. Модель E: Талантливый человек, будь то любитель или профессионал, расширяет или изменяет другой язык. Есть встроенная база пользователей, которые могут быть заинтересованы в расширении. Может быть, пользователи смогут исследовать новые идеи, не платя больших затрат на переход. Так рождаются C # и C ++.

Я определяю профессионала как человека, которому платят за знание языков программирования, за передачу этих знаний и развитие новых знаний в языках программирования. К сожалению, это не то же самое, что проектирование и реализация новых языков, и не то же самое, что создание реализаций, которые могут использовать многие люди. Вот почему большинство успешных языков программирования разрабатываются и создаются любителями, а не профессионалами.

Было довольно много интересных исследовательских языков, которыми пользовались сотни или даже тысячи пользователей, но они так и не добились большого успеха. Среди них, наверное, один из моих любимых - Icon . Я утверждал в другом месте , что на самом деле никто не знает, почему языки становятся популярными.

Расширяют ли новые языки родительские?

На самом деле это очень редко. C ++ - самый популярный пример, и, возможно, Algol-W или PL / S приблизились к нему.Но гораздо чаще использовать родительский язык только для вдохновения, а некоторые языки (на ум приходит Python) признают несколько «родителей» в качестве источников вдохновения.

Разве это не делает каждый последующий язык медленнее и не требует больше памяти?

Не обязательно. C ++ медленнее и использует больше памяти не потому, что он унаследован от C, а потому, что он был разработан с течением времени до такой степени, что только очень опытный пользователь может надежно написать код C ++, который работает так же быстро, как аналогичный C код. (Я хочу быть предельно ясным: дело не в том, что C ++ не может быть быстрым; дело в том, что стоимость кода C всегда очевидна из чтения источника, а стоимость кода C ++ иногда совсем не очевидна из чтения источника. ) Для получения дополнительной информации об эволюции C ++ прочтите книгу Джима Уолдо Эволюция C ++ .

Изначально Java была медленной из-за своевременной компиляции и других дурацких вещей в реализации. Они также обременяли себя этой динамической загрузкой классов, что очень сложно сделать быстро (потому что класс может быть расширен динамически в любой момент). Кенни Задек, Роджер Гувер и Дэвид Чейз создали действительно быстрый компилятор машинного кода для Java без загрузки динамических классов.

В качестве контрпримера, я думаю, что программы Scheme работали быстрее и использовали меньше памяти, чем программы на Лиспе, которые им предшествовали - отчасти потому, что Гай Стил - блестящий дизайнер и блестящий разработчик. (Редкая комбинация.)

Но есть что-то в том, что вы говорите: люди, которым не хватает опыта для создания хорошего компилятора с нуля или которым не хватает опыта для разработки всего языка с нуля, вполне могут взломать реализацию чего-то, не слишком отличного от родитель.В таких случаях весьма вероятно, что в итоге получится язык, который менее хорошо спроектирован, менее хорошо реализован, медленнее и использует больше памяти, чем его предшественник. (Известно, что Тони Хоар сказал, что Алгол 60 был улучшением большинства его преемников [sic]).

Также верно и то, что чем позже разрабатывается язык, тем больше вычислительных ресурсов доступно по той же цене. Ранние компиляторы C должны были эффективно работать всего в 128 КБ ОЗУ. Сегодняшние компиляторы C ++ не сталкиваются с такими ограничениями, и для них есть все основания использовать больше памяти: действительно дешево заполнить машину гигабайтами ОЗУ, а ограничение их использования всего лишь мегабайтами ничего не сохраняет; больший объем памяти уже оплачен.

Резюме: Языки возникают потому, что люди хотят улучшить программирование, и у них появляются новые идеи. Языки зарождаются, когда кто-то берет целую кучу идей, новых и проверенных, и синтезирует их в единое целое. Это большая работа. Один из способов облегчить работу - использовать не только проверенные функции , но и проверенные проекты одного или нескольких языков-предшественников. Такой дизайн создает впечатление «родительского», но фактическое расширение или почти расширение (в случае C ++, расширяющего C) встречается редко. Затраты времени и места не обязательно увеличиваются по мере развития языков, но часто люди создают языки, усложняя существующие проекты, и чем сложнее дизайн, тем сложнее его эффективно реализовать. Поэтому нет ничего необычного в том, что программы, написанные на новом языке, кажутся медленнее или используют больше памяти, чем аналогичные программы, написанные на языке предков. Наконец, как и в случае со всеми другими формами программного обеспечения, компиляторы, разработанные и построенные недавно, обычно используют больше ОЗУ и ЦП, чем компиляторы, созданные десять лет назад, просто потому, что большие объемы ОЗУ и циклов ЦП доступны по заниженной цене.

Языки не являются медленными, медленными являются реализации [создаваемые компиляторами на ассемблере]. Теоретически, вы можете иметь интерпретатор C++, который работает медленнее, чем компилятор PHP или что-то еще. Языки также не потребляют память, а реализации потребляют память.

Проект является языком, когда грамматика (или синтаксис) отличается. (Вы можете иметь и язык, и фреймворк в одном проекте)

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

Существует большая разница, которая может быть неочевидной, между утверждением, что язык построен на концепциях предшественника, и фактическим построением на нем. C компилируется в ASM, поэтому он построен на нем, но не обязательно вместе с ним. Часто (большинство?) Компиляторы C на самом деле написаны на C. C ++ построен на C, он поддерживает полный спектр C и добавляет к нему множество вещей. Java - это совсем другое дело, как и .NET. Они «компилируются» в псевдо-ASM, называемый IL для .NET и ByteCode для Java. Оба требуют выполнения какого-либо другого шага или виртуальной машины (виртуальной машины).

Разработчики языков должны принимать во внимание популярность. Я не сомневаюсь, что популярность C # в значительной степени объясняется тем, что его нет такое большое отличие от синтаксиса Java, который не слишком отличается от C, и так далее.

Изучать недостатки нового языка уже сложно, так что всем будет легче, если синтаксис не слишком отличается от других языков.

Что касается скорости, она не зависит от языка, а зависит от компилятора, используемого для преобразования этого языка в другой язык, который может быть прямым машинным кодом или сборкой, или, в случае C #, Java и т. Д., Байтовым код, который затем запускается на виртуальной машине.

Ваш последний вопрос тоже интересен. C # и .NET - совсем разные звери. Когда язык (например, C #) нацелен на .NET, создается компилятор, который может преобразовывать этот язык в байт-код, который может работать на этой виртуальной машине. Это означает, что код C # .net вполне может вызывать сборки, например, написанные на VB.NET.

То же самое относится к Java и Scala, которые написаны для JVM. Scala - это функциональный язык, а Java - язык ООП, но оба могут с радостью вызывать друг друга, поскольку, в конце концов, это просто байт-код, работающий на виртуальной машине.

Надеюсь, это ответ на ваш вопрос.

Мне кажется, есть два основных способа создания новых языков:

1) кто-то решает, что ему нужно сделать какую-то конкретную работу, и язык специального назначения поможет ему в этом. Этот человек (и, возможно, некоторые другие пользователи) находят язык полезным и начинают расширять его для других целей. В конце концов, язык поддерживает достаточно много вещей, чтобы его можно было считать языком общего назначения.

2) кто-то, разбирающийся в языках программирования, решает, что в существующем языке есть проблемы, которые можно решить с помощью нового подхода (это может быть радикальное изменение или постепенное изменение по сравнению с предыдущим). Новый язык разрабатывается с нуля, чтобы быть языком общего назначения. Это может быть описанием того, как появились Java или C#.

Большинство языков будут иметь некоторое сходство с другими (например, ваш пример с печатью), потому что эти операции довольно полезны в любом вычислительном контексте.

Затем есть языки вроде FORTH или APL, которые я просто не могу объяснить...

На самом деле новые языки могут быть намного быстрее. Например, C/C++ или даже Java могут быть намного быстрее рукописного ассемблера. Go/Haskell/..., которые могут быть легко экранизированы, могут быть намного быстрее ассемблера на современном оборудовании - то, что код на ассемблере "на 25% быстрее", чем однопоточная программа на Haskell/Go, если вы можете включить переключатель, который делает Haskell/Go в 4 раза быстрее (то есть. 3x по сравнению с оптимизированным ассемблером) на Core Quad, не говоря уже о том, что в коде гораздо меньше ошибок?

Есть исследования, что платформы с GC на самом деле быстрее - поскольку у программистов больше времени на оптимизацию программ/поиск других ошибок, а не на поиск утечек памяти - хотя "идеальные" программы будут медленнее.

Также вы можете иметь много реимплементаций языка:

• На основе родного кода (ассемблер)
• На основе низкоуровневого языка (C, LLVM)
• На основе кроссплатформенного фреймворка (Java, parrot)
• На основе интерпретатора
• На основе одноплатформенного фреймворка (. Net - да, я знаю о mono ;), но он все еще в основном одноплатформенный)

Например, Ruby имеет Ruby MRI (интерпретатор), JRuby (Java), .Net (IronRuby) и т.д.. Обычно они сильно отличаются по скорости работы. C имеет множество компиляторов и теоретически может иметь интерпретатор. В Haskell есть генератор нативного кода (GHC & co.), низкоуровневый язык (GHC -fvia-c и новый GHC + LLVM) и интепретатор (ghci).

Языки обычно создаются:

1. Автору нравится язык A и B, поэтому он объединяет их в язык C

2. У автора есть совершенно новая идея (например, объекты, утиная типизация), которая не может быть выражена в существующих языках/новая идиома, которая не может быть выражена так же хорошо в существующих языках, поэтому он создает новый язык с совершенно новой особенностью.

3. Авторы считают какую-то функцию ужасной и хотят от нее избавиться (по любым причинам). Как enum в старой Java.

В первом и третьем случае новый язык "наследует" от одного или нескольких языков (обычно многих). Но обычно это их комбинация.