DSblizzard,

DS>Повторю ссылку на всякий случай:
DS>http://files.rsdn.ru/48064/Drive%2022.04.09.zip

DS>Серьезно говорить о продвижении того, что я написал, пока рано, я интересовался больше теоретически, на будущее. Большое спасибо всем, кто ответил, напишу несколько более подробно, как и почему я решил создать ЯП.

Разумеется, чем тебе заниматься, решаешь ты и только ты. Я просто бы хотел предостеречь тебя от мартышкиного труда, от которого ни ты, ни окружающие кайфа не словят. Идея создания Ъ-суперъ-пуперъ-языка время от времени посещает всех, кто поработав какое-то время с мейнстримовыми и не-совсем-мейнстримовыми ЯП обнаруживает, что они обладают ненулевой степенью кривизны, и начинает фантазировать на тему улучшений и обобщений. Это хороший знак, это означает, что у человека есть фантазия и исследовательская чёрточка в характере. Только хватать бензопилу и бросаться валить лес очень часто оказывается не самым лучшим вектором приложения сил.

Вот, смотри, что пишет один энтузазист:

Ребята, а давайте залудим ЛЯП!

Поскольку посетители LtU такие продвинутые в языках программирования, почему бы нам не сбацать "Лучший Язык Программирования" (The (Ultimate) programming language), сокращённо — ЛЯП. Давайте запостим все наши предложения сюда чтобы сделать ЯП, одинаково хороший для всех. Это будет эксперимент, сдобренный толстым слоем фана. Я могу сделать компилятор, если мы продвинемся до некоторого "стандарта". Я прошу прощения, если такое уже предлагалось (и очевидно не материализовалось, иначе бы я знал о таком языке).

Мои самые базовые требования — следующие два:

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

2. Самый низкий уровень ЛЯП-а должен уметь быть прямо преобразован в железо, то есть это должен быть некоторый вид ассемблера, чтобы позволить желающим совершать Очень Низкоуровневое Программирование. Но ЛЯП вместе с тем должен быть достаточно изменчивым, чтобы обеспечить возможность строить Многослойные Абстракции, так что любой может выбрать подходящий Уровень Абстракции для своей предметной области.

А вот один из лучших ответов, который я имел удовольствие читать (от товарища Frank Atanassow):

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

Перед тем, как ты погрузишься в изобретение Твоего Языка Программирования (далее ТЯП), задай себе несколько вопросов:

1. Какую задачу новый язык решает? Как сформулировать ответ наиболее точно?

2. Как я могу продемонстрировать красоту решения зтой задачи с помощью нового языка? Как сформулировать ответ наиболее точно?

3. Существуют ли другие решения? Решают ли другие языки эту задачу? Как? Какие преимущества твоего решения? Преимущества их решения? Какие недостатки у твоего решения? Недостатки их решения?

4. Как я могу продемонстрировать, что моё решение не может быть выражено в терминах другого языка? То есть, каково уникальное свойство моего языка, которое отсутствует в других, благодаря чему это решение стало возможным?

5. Какие части моего языка существенны для этого уникального свойства?

Если ты отвечаешь на 1 как "он чище", можешь отваливать. Если отвечаешь "он имеет чрезвычайно маленькое ядро, так что всё на свете можно определить с его помощью", всем на это пофиг. (Ну, на самом деле мне может быть не пофиг, однако ты никогда не убедишь меня заинтересоваться, если не сформулируешь некоторые вещи математически строго. Мы уже знаем про базис из одного единственного комбинатора для нетипизированных вычислений. SKI уже известен несколько десятков лет. Для типизированных языков всё несколько сложнее, но тоже маловероятно, что будет иметь смысл.)

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

Если ты отвечаешь на 3 как "я не знаю", значит у тебя маленький кругозор. Всегда существует более одного решения. (Поверь мне; я больше никогда не пишу "the solution to this problem is...", и когда я встречаю это словосочетание и не вижу доказательство единственности, то автор зачастую не знает ещё целую кучу решений.) Если твой ответ включает только языки с какой-либо одной парадигмой, то же самое. Вперёд изучать Scheme, Prolog, ML, Haskell, Charity, Lucid, Synchrone, Obj, Erlang, Smalltalk. Посмотри на Epigram или Coq или HOL или LEGO или Nuprl. Помимо Java, все они существенны и важны. Если ты свободно владеешь всеми этими языками, твоя позиция намного прочнее. Если же ты программировал только на C/C++/Java, Lisp и скриптовых языках, ты всю жизнь смотрел на парад с галёрки. Perl, Python, Ruby, PHP, Tcl и Lisp — это всё один и тот же язык. (Scheme выделяется на их фоне благодаря гигиеническим макросам и продолжениям.)

Если у тебя нет ответа на 4, то твоё решение на самом деле библиотечное, а не языковое. Фактически, люди на LtU — это самые лучшие кадры чтобы спроектировать хорошие библиотеки, и библиотеки в среднем гораздо ценнее, чем собственно языки. Дизайн библиотек также даётся намного легче, и ты не спустишь в трубу дофига своего время на синтаксис. (Да, ты убъёшь много времени лишь на синтаксис. Ты убъёшь почти всё своё время лишь на синтаксис.)

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

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

Да, я знаю, что следующие слова будут пропущены мимо ушей, но: не соблазняйтесь изобретением нового синтаксиса. Выберите стиль какого-нибудь другого языка. Java, Lisp, Python, Haskell — не важно. Просто решитесь раз и навсегда и закройте тему. Если вклад вашего языка чисто синтаксический — вам ничто не поможет.

Думайте о фичах языка в терминах асимптотической сложности — не в терминах времени/памяти, а в терминах сложности. (Я бы сказал "семантики", но это уже ругательство.) Изменения в синтаксисе могут снизить сложность лишь в константу раз. Хорошая фича способна изменить сложность в n^2 или в n*log(n) или в n раз. Хорошая фича увеличивает модульность делая локальным то, что раньше было глобальным. Самые лучшие фичи делают это без особых жертв для других фич (например, типобезопасность).

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

И да наступит здесь конец сего Урока...

Между прочим в дискуссии упоминается и твоё улучшение Лиспа:
DS>У языка унифицированный префиксный синтаксис:

def( f(X)
    ret(X)
)

и ответ, почему получится хуже:

"Я определённо нахожу foo() намного читабельнее, чем (foo)"

Возможно вы просто привыкли к языкам-отпрыскам Алгола?

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

Это также усложнит парсинг.

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

Автор: Lazy Cjow Rhrr
Дата: 04.12.06

?