Когда новый язык - подходящий инструмент для работы?

Question

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

• Создан на основе .NET или имеет реализацию .NET
• Имеет мало зависимостей от среды выполнения .NET как во время компиляции, так и во время выполнения (это важно, поскольку один из основных вариантов использования находится во встроенной разработке, где среда выполнения .NET полностью настраивается)
• Имеет компилятор, который на 100% состоит из кода .NET без неуправляемых зависимостей
• Поддерживает вложение произвольных выражений (см. Ниже)
• Поддерживает пользовательские определения операторов
• Поддерживает вывод типа
• Оптимизирует хвостовые вызовы
• Имеет явные неизменяемые / изменяемые определения (приятность - я полюбил это, но могу жить без него)
• Поддерживает реальные макросы для сильного метапрограммирования (абсолютно необходим)

Основными двумя языками, с которыми я работал, являются Boo и Nemerle, но я также играл с F #.

Основные претензии к Nemerle: у компилятора есть ужасные сообщения об ошибках, реализация глючит до чертиков (компилятор и библиотеки), макросы могут применяться только внутри функции или как атрибуты, и это довольно сильно зависит от зависимостей (хотя и не Достаточно того, что это торговец).
Основные претензии к Boo: Нет вложения произвольных выражений (разборщик), трудно писать макросы, нет специального определения оператора (потенциальный разборщик).
Основные жалобы на F #: уродливый синтаксис, сложный для понимания метапрограммирование, несвободная лицензия (epic dealbreaker).

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

Плюсы:

• Получить точный синтаксис, который я хочу
• Получите время выполнения заказа, которое будет намного быстрее; трудно измерить, но я не удивлюсь, увидев 1,5-кратную производительность разработчиков, особенно из-за тестовой инфраструктуры, которую это может включить для определенных проектов
• Я могу легко добавить пользовательские функции в компилятор, чтобы они хорошо играли с моим временем выполнения
• Я получаю что-то, что разработано и работает точно так, как я хочу - насколько это звучит как NIH, это облегчит мою жизнь

Минусы:

• Если это не получит популярность, я застряну с бременем обслуживания. Я знаю, что, по крайней мере, я могу покончить с людьми из Немерле, так как я думаю, что все хотят чего-то более профессионального, но это требует деревни.
• Из-за первого мошенничества я опасаюсь использовать его в профессиональной обстановке. Тем не менее, я уже использую Nemerle и использую свой собственный модифицированный компилятор, так как они не поддерживают его вообще.
• Если это не получит популярности, найти разработчиков будет гораздо сложнее, в такой степени, что Пол Грэм может даже не потворствовать.

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

Редактировать: Забыл добавить пример вложенности - вот пример в Nemerle:

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

Редактировать # 2: подумал, что не мешало бы привести пример типа кода, который будет преобразован в этот язык, если он существует (одного ответа С. Лотта может быть достаточно, чтобы напугать меня до конца) , Код интенсивно использует пользовательский синтаксис (код операции:: =, цитата и т. Д.), Вложение выражений и т. Д. Хороший пример можно посмотреть здесь: здесь .

Answer 1

К сожалению, нет метрик или историй о неудачных языках. Просто удачные языки. Очевидно, что неудачи превосходят число успехов.

На чем я основываю это? Два общих опыта.

1. Один или два раза в год я вынужден терпеть удар по продукту / языку / инструменту / структуре, которые полностью изменят все. Мой ответ был постоянным в течение последних 20 лет. Покажите мне кого-то, кто нуждается в поддержке, и моя компания поддержит их. И это все. Никогда не слышу от них снова. Допустим, я слышал 25 из них.

2. Один или два раза в год мне приходится работать с заказчиком, который осиротел. В какой-то момент в прошлом некоторые умные программисты создавали инструмент / framework / library / package, который использовался внутри для нескольких проектов. Затем этот программист ушел. Никто не может понять эту чертову вещь, и они хотят, чтобы мы заменили / переписали это. К сожалению, мы не можем понять это также, и наше предложение состоит в том, чтобы переписать с нуля. И они жалуются, что их гений создал набор приложений за несколько недель, и мы не можем потратить месяцы на их переписывание на Java / Python / VB / C #. Допустим, я написал около 25 таких предложений.

Это только я, один консультант.

Действительно, одной особенно печальной ситуацией была компания, у которой весь портфель программного обеспечения для ИТ был написан одним умным парнем с собственным языком и инструментами. Он не ушел, но он понял, что его язык и набор инструментов отстали от времени - современное состояние изменилось, а он - нет.

И движение было - конечно - в неожиданном направлении. Его язык и инструменты были в порядке, но мир начал принимать реляционные базы данных, и у него не было абсолютно никакого способа обновить свое барахло, чтобы отойти от плоских файлов. Это было то, чего он не предвидел. Действительно, это было то, что он не мог предвидеть. [Вы не попадете в эту ловушку, не так ли?]

Итак, мы поговорили. Он переписал многие приложения в Plain-Old VAX Fortran (да, это давно.) И он переписал его, чтобы использовать простые старые реляционные средства SQL (в то время Ingres).

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

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

Answer 2

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

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

Если вы дадите ему шанс, вы не будете разочарованы.

Answer 3

Когда я впервые начал свою карьеру в начале 90-х годов, казалось, что это было повальное увлечение всех, кто разрабатывает свои собственные языки. Мои первые 3 работы были с компаниями, которые сделали это. Одна компания даже разработала собственную операционную систему!

Из опыта я бы сказал, что это плохая идея по следующим причинам:

1) Вы потратите время на отладку самого языка в дополнение к основам кода поверх него
2) Любые разработчики, которых вы нанимаете, должны пройти курс изучения языка
3) Будет сложно привлекать и удерживать разработчиков, поскольку работа на проприетарном языке - это тупик для чьей-либо карьеры

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

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

Answer 4

Я говорю, пойти на это.

• Это был бы потрясающий опыт, независимо от того, будет ли он на производстве или нет.
• Если вы компилируете его в IL, вам не нужно беспокоиться о невозможности повторного использования ваших скомпилированных сборок с C #
• Если вы считаете, что у вас есть веские претензии в отношении языков, перечисленных выше, вполне вероятно, что многие будут думать как вы. Конечно, на каждые 1000 заинтересованных лиц может быть 1 желающий помочь вам сохранить его, но это всегда риск

Но вот несколько вещей, о которых следует помнить:

• Получите спецификацию вашего языка STONE перед разработкой. Убедитесь, что все языковые функции определены заранее - даже вещи, которые вы можете захотеть только в будущем. По моему мнению, C # медленно попадает в ловушку «о-просто-еще-один-языковой-расширение», которая приведет к его возможной гибели.
• Обязательно сделайте это оптимизированным. Я не знаю, что вы уже знаете; но если вы не знаете, то учитесь;) Никому не нужен язык, который имеет хороший синтаксис, но работает так же медленно, как реализация JavaScript в IE.

Удачи: D

Answer 5

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

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

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

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

Answer 6

НИКОГДА не разрабатывайте свой собственный язык.

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

Случаи, когда это не применимо, в значительной степени характерны, если вы Ларри Уолл, ребята из AWK или часть значительной группы людей, посвятивших себя тестированию границ программирования. Если вы относитесь к какой-либо из этих категорий, вам не нужен мой совет, но я сильно сомневаюсь, что вы нацелены на нишу, где нет подходящего языка программирования для задачи И характеристик людей, выполняющих задачу.

Answer 7

Scala имеет компилятор .NET. Я не знаю, статус этого, хотя. Это своего рода гражданин второго сорта в мире Scala (который больше ориентирован на JVM). Но может быть хорошим компромиссом принять компилятор .NET вместо создания нового языка с нуля.

Scala довольно слаб в отделе метапрограммирования ATM. Вполне возможно, что необходимость в метапрограммировании несколько уменьшается благодаря другим возможностям языка. В любом случае, я не думаю, что кому-то было бы грустно, если бы вы реализовали для него функции метапрограммирования. Также на подходе есть инфраструктура подключаемого модуля компилятора.

Answer 8

Написание собственного языка - нелегкий проект. Особенно тот, который можно использовать в любых «профессиональных условиях»

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

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

Answer 9

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

Возможно, вы захотите объединить два ваших любимых языка (в моем случае C # и Scheme ) и использовать их вместе.

С профессиональной точки зрения это, вероятно, не очень хорошая идея.

Answer 10

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

Я просто курьез!