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

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

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

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

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

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

Плюсы:

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

Минусы:

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

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

Изменить: Забыл добавить пример вложенности - вот случай в Nemerle:

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

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

Ответы

Ответ 1

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

Для чего я это использую? Два общих опыта.

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

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

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

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

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

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

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

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

Ответ 2

Я говорю, иди за ним.

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

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

  • Получите информацию о своем языке в каменном доме перед разработкой. Удостоверьтесь, что все и все языковые функции раскрыты перед вами - даже то, что вам может понадобиться только в будущем. На мой взгляд, С# медленно попадает в ловушку "oh-just-one-more-language-extension", которая приведет к ее возможной гибели.
  • Обязательно оптимизируйте его. Я не знаю, что вы уже знаете; но если вы не знаете, то учитесь;) Никто не захочет языка, который имеет хороший синтаксис, но работает так же медленно, как реализация IE javascript.

Удачи: D

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

НИКОГДА НЕ РАЗВИВАЙТЕ свой собственный язык.

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

Я просто любопытство!