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

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 из-за маленьких мелочей, которых просто нет, если вам известно это соглашение.

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

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

Здравствуйте, yumi, Вы писали:

E>>Хронология здесь не причем.

Y>Спасибо, после выделенного с Вами дальше можно не продолжать беседу.

...и бояре иноземные, Федор, не чета нашим, россейским: мылом моютца и вина вусмерть не пьют, особливо с утра. И наукам разным с младых ногтей обучаются -- то у них "образование" зовется. Одкель даже с холопами своими по культурному разговаривают. Наш-то барин, как что не по нем, так: "Пшел прочь, смерд!" А ихний: "с Вами дальше можно не продолжать беседу". И вот чудно: умишком-то чуешь, что послал он тебя туды же, а на душе все равно приятно...

DS>Для написания языка перепробовал почти полный спектр языков: от ассемблера до Лиспа ("почти" — потому что я считаю Пролог более высокоуровневым языком). К Лиспу я серьезно охладел после того, как однажды при написании игрушки три недели плясал с несколькими бубнами и так и не смог подключить графику.

А как подключить "графику" к вашему языку?

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

Ну, ты даёшь.

У меня наоборот — как выйду поискать про ЯП в интернете, так куча новой информации.

DS>Это совсем немного, у меня на компе — около 150 МБ. Почему я в этом так уверен — просто когда я пытаюсь найти что-то новое, не получается.

Видимо, ты не прочитал эти 150МБ. Я уверен, что не прочитал. Это, всё же, порядка семи с половиной тысяч страниц (~20К на страницу).

Здравствуйте, dmz, Вы писали:

К>>вот с продакшном в клине как-то, я бы постремался

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

тебе чтоль этот линк нужен?

Здравствуйте, c-smile, Вы писали:

CS>Просто оказались в нужное время в нужном месте. Также и например Python — ну ведь VB же голимый и собственно был и сделан в пику Basic'у. Но вишь ты — есть community.

Не вижу ничего общего между питоном и VB. Питон имхо стал популярен благодаря чистому синтаксису (во времена Python 1.5 логичный язык без мусора — это та еще диковинка) и очень мощной стандартной библиотеке.

Здравствуйте, DSblizzard, Вы писали:

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

Я бы на твоем месте ответил на 3 частных вопроса:

— Какова цель проекта (20 слов)
— Кто будет писать на новом ЯП (8 слов)
— Где будет использоваться ЯП через 5 лет (12 слов)

Если уложишься — сам увидишь ответ на все остальные вопросы.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, DSblizzard, Вы писали:

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

M>Не нужно ни писать ни продвигать свои языки программирования.
M>По той причине, что язык, сам по себе — это очень мало.
M>У языка есть шанс, если он востребован в данное время, и над ним работают десятки человек. Впрочем, если он востребован, то над подобными языками уже работают тысячи человек. Шанс исчезающе мал. И ещё меньше шанс того, что вы работаете над действительно востребованым языком.
M>Даже хороший компилятор — это работа для многих людей. Но для языка нужен не только компилятор. Нужна IDE, нужна хорошая документация. Нужно сопровождение, исправление ошибок, развитие языка. И при постоянном развитии ещё больше нужен хороший, быстрый, безбаговый, документированый и пр. и пр. компилятор.
M>И два десятка лет (если все вышеозначенные, и наверное другие, условия выполнены).
M>И первый (а чаще всего и последующие несколько) блинов (языков, то-бишь) будут коммом.

Всё так и не так. Вышесказанное справедливо для языков типа C# или VB.
Но есть также скажем PHP или Ruby которые с точки зрения компиляторостроения и всего прочего — ноль на палочке.
Просто оказались в нужное время в нужном месте. Также и например Python — ну ведь VB же голимый и собственно был и сделан в пику Basic'у. Но вишь ты — есть community.
Т.е. наперед никогда нельзя сказать — пойдет язык или нет.

По делу: скажешь что язык — скажем кому он будет интересен — т.е. где его продвигать.

Здравствуйте, DSblizzard, Вы писали:

DS>Прочел обе и еще пару. Хотелось бы прочитать еще Anatomy of Lisp, но нигде не могу найти.
У нее есть современный аналог: Lisp in Small Pieces — и ее можно найти

5/5
The best book available on Lisp implementation, December 22, 1999
By Peter Norvig (Palo Alto, CA USA)
(REAL NAME)
This is an excellent book on Lisp implementation. You'll get a lot out of it, whether you are interested in writing compilers and interpreters (for Lisp or any language) or whether you just want to see how Lisp works. It is the modern day successor to Allen's "Anatomy of Lisp".

Здравствуйте, DSblizzard, Вы писали:
DS>Как и где продвигать собственный язык программирования? Подойдут как русско- так и англоязычные ресурсы.
"Где" — сейчас прийдет утро и накидают тебе ссылок на хабры, лямбдазеультиматы, слешдоты и пр.
"Как" — я бы продвигал "по аналогии". Подумал бы, на какой известный язык похожа твоя разработка, любителям какого языка она была бы интересна. Кого в первую очередь заинтересуют сильные стороны языка. И уже после этого адресно пиарился бы на ресурсах, посвященных языку-"жертве".

А, ну и на рсдн стоит про твой язык отписать.

Здравствуйте, DSblizzard, Вы писали:

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

А зачем это нужно? От этого, IMHO, очень зависит и где и как...

Здравствуйте, Mr.Cat, Вы писали:
MC>"Где" — сейчас прийдет утро и накидают тебе ссылок на хабры, лямбдазеультиматы, слешдоты и пр.

Хм... не накидали. Ну тогда начинай чтоли пиарить на rsdn, а мы по ходу дела подскажем, где еще анонсировать стоит.

eao197,

LCR>>

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

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

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

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

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

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

E>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от
E>Б.Страуструпа,
Да, конечно. C++ был создан в 1983-м году с целью решить вполне конкретные задачи, которые не мог адекватно решить C: абстрактные и пользовательские типы данных, ООП, обощённое программирование. Причём, нужны были также возможность низкоуровневого доступа, и совместимость с унаследованным кодом на C. Ни один из существующих тогда (1983-й если я не ошибаюсь) языков не мог решать все эти задачи так же успешно, как C++. (Lisp, Smalltalk, Forth и т.п. конечно могли многое, но компилировать код на C увы нет).

E>Дж.Госслинга,
Да. На 1995-й год виртуальная машина (секьюрность, переносимость), сборка мусора, чистая объектная система, рефлексия и динамическая загрузка классов — это фичи, в полной мере отсутствующие в С++. Smalltalk не мог выполнять роль Java из-за динамической типизации.

E>А.Хэйлсберга,
Ммм, удовлетворила бы разве что относительно C# >=2.0 — дженерики, лямбды и прочее. Причиной разработки C# называют множество вещей, но кажется главная в том, что Java была разработана не в Microsoft.

E>Г.в.Россума, Я.Матцумото...

Вот здесь сомнительно. "Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language."

Здравствуйте, dmz, Вы писали:

dmz>>>>Haskell — очень хорошо. Lisp не знаю.
dmz>Это да. Они даже линк на скачивание прислать не могут, потому что, видимо, я запрос отправил в выходной.

Они и не собирались присылать — они специально запутали свой сайт

http://clean.cs.ru.nl/Download/main/main.htm

К>Пусть это будет несколько оффтопично, но не мог бы рассказать, какие лично ты видишь проблемы в питоне? Помимо динамической типизации и скорости?

А этого мало?

Отсутствие оптимизации хвосторой рекурсии, что в принципе сводит к нулю и без того чахоточные функциональные возможности. Плохая поддержка SMP (или вообще отсутствующая, даже для stackless питона, что особенно уныло). Плохой GC.

Package hell. Это не совсем про язык, это больше про окружение, но тем не менее.

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

Реализация мне кажется намного более приличной и аккуратной у Lua. Т.е. если нужен динамический императивный язык, то я бы сейчас рассматривал Lua.

Ну и напоследок — разведенный зоопарк с условно совместимыми (и вообще несовместимыми) версиями + package hell приведет к тому к дикому бардаку в продакшене — т.е. мне такого щастья на моих серверах точно не надо. Накатывание питоновского приложения X на сервер, которое потребует другой версии питона, чем там есть — может привести к последствиям. И вообще — какой питон сейчас считать продакшн? Под какой разрабатывать новое приложение, которое будет (допустим) распространяться?

К>Не мог бы ты пояснить эту низкоуровневость? Лучше продемоснтрировать, конечно.

Нет, не мог бы. Это вообще сложноформализуемое понятие, видимо. Но я много писал и на том, и на другом, причем, сходные задачи. И вижу, где писанины больше, а где меньше. А так же отладки, например. Так что пускай это утверждение останется на моей совести.

К>Ну и какие другие? Haskell, lisp?

Haskell — очень хорошо. Lisp не знаю.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>

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

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

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

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

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

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

Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от Б.Страуструпа, Дж.Госслинга, А.Хэйлсберга, Г.в.Россума, Я.Матцумото...

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

Здравствуйте, DSblizzard, Вы писали:

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

Не нужно ни писать ни продвигать свои языки программирования.
По той причине, что язык, сам по себе — это очень мало.
У языка есть шанс, если он востребован в данное время, и над ним работают десятки человек. Впрочем, если он востребован, то над подобными языками уже работают тысячи человек. Шанс исчезающе мал. И ещё меньше шанс того, что вы работаете над действительно востребованым языком.
Даже хороший компилятор — это работа для многих людей. Но для языка нужен не только компилятор. Нужна IDE, нужна хорошая документация. Нужно сопровождение, исправление ошибок, развитие языка. И при постоянном развитии ещё больше нужен хороший, быстрый, безбаговый, документированый и пр. и пр. компилятор.
И два десятка лет (если все вышеозначенные, и наверное другие, условия выполнены).
И первый (а чаще всего и последующие несколько) блинов (языков, то-бишь) будут коммом.

Кодёнок wrote:

> Не вижу ничего общего между питоном и VB. Питон имхо стал популярен
> благодаря чистому синтаксису (во времена Python 1.5 логичный язык без
> мусора — это та еще диковинка) и очень мощной стандартной библиотеке.

Я удержался от подобного поста, но раз уж пошла пьянка...

Да питон стал популярным по одной простой причине: это классный
и мощный язык. С простой и очевидной семантикой и кучей библиотек,
не требующих OLEAutomation для связи с собой.

А VB как язык (не как технология) — это просто кусочек какашки.
Собственно, почему его C-шарпом и заменяют.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, c-smile, Вы писали:

CS>>Просто оказались в нужное время в нужном месте. Также и например Python — ну ведь VB же голимый и собственно был и сделан в пику Basic'у. Но вишь ты — есть community.

Кё>Не вижу ничего общего между питоном и VB. Питон имхо стал популярен благодаря чистому синтаксису (во времена Python 1.5 логичный язык без мусора — это та еще диковинка) и очень мощной стандартной библиотеке.

А что в VB такого "грязного"?

Смотрим сюда:
http://merd.sourceforge.net/pixel/language-study/syntax-across-languages-per-language/VisualBasic.html
А теперь смотрим сюда:
http://merd.sourceforge.net/pixel/language-study/syntax-across-languages-per-language/Python.html

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

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

Несколько лет назад я захотел написать программу искусственной жизни, симулирующей бактерию. Скоро понял, что для написания серьезной развивающейся программы требуется развивающийся язык и C#, на котором я тогда писал, для этой цели подходит плохо. О Лиспе я тогда не знал, если бы знал, все могло бы сложиться совсем не так. Да и слава Богу, что не сложилось.
Для написания языка перепробовал почти полный спектр языков: от ассемблера до Лиспа ("почти" — потому что я считаю Пролог более высокоуровневым языком). К Лиспу я серьезно охладел после того, как однажды при написании игрушки три недели плясал с несколькими бубнами и так и не смог подключить графику. К тому же в это время узнал, что некоторые известные лисперы переходят на Питон и рекламируют его, решил попробовать.
В Питоне меня не устраивает разный подход к передаче параметров — списки передаются по ссылке, а простые переменные — по значению. При рефакторинге это создает серьезные проблемы, когда элементарное значение решаешь превратить в список.
При создании языка оказалось, что передавать одни значения мало, нужны их адреса и адреса даже важнее, по понятной причине — по адресу можно получить значение, а по значению адрес — нет. Пришлось эмулировать систему указателей из низкоуровневых языков. Только указатели помощнее, позволяют обращаться к узлам дерева и не только по номерам, но и по тэгу (типу). Вот основная структура данных:
[Тип Структура1 Структура2 ..], где Структура — такая же основная структура, либо конечный ее вид — [Тип Значение].
Потенциально это позволит динамически создавать и удалять определения функций. Преимущества ленивых вычислений вы и сами знаете, передачу по ссылке решил использовать, потому что она больше соответствует особенностям моего мышления, чем функциональное программирование.
У языка унифицированный префиксный синтаксис:
def( f(X)
ret(X)
)

=(X 4)
loop(
if(
<(X 2)
cout("<2")
else
cout(">=2")
)
=( X -(X 1) )
break( ==(X 0) )
)
Интерпретатор написан на Питоне 2.6.
Интерпретатор пока работает с черепашьей скоростью, а так как я хотел написать следующую версию языка на первой версии, то это представляет огромную проблему. Как ее решить, я еще не придумал. Я против оптимизации, смешанной с кодом / встроенной в код.
В процессе создания начало складываться ощущение, что почти все современные языки, включая и Питон 3.0, устарели. Программист не должен заботиться о том, где расположены его данные, его должны интересовать только сами данные. Видимо, следующая версия моего языка будет более декларативной — constraints & logic, эволюционные вычисления, pattern matching/recognition или еще что-нибудь большое и светлое.
Хотелось бы знать, есть ли те люди, которых заинтересовал мой язык или которые хотели бы написать свой, или которые уже писали что-то подобное и могли бы поделиться опытом.

DS>В Питоне меня не устраивает разный подход к передаче параметров — списки передаются по ссылке, а простые переменные — по значению. При рефакторинге это создает серьезные проблемы, когда элементарное значение решаешь превратить в список.
DS>При создании языка оказалось, что передавать одни значения мало, нужны их адреса и адреса даже важнее, по понятной причине — по адресу можно получить значение, а по значению адрес — нет. Пришлось эмулировать систему указателей из низкоуровневых языков. Только указатели помощнее, позволяют обращаться к узлам дерева и не только по номерам, но и по тэгу (типу). Вот основная структура данных:

По моему, все это говорит о том, что вы не разобрались в предмете. Если такая передача параметров (совершенно естественная) почему-то мешает, это, скорее всего, говорит о проблемах дизайна. Т.е. на фичу языка особенность передачи параметров слабо тянет.
Если нужен частый рефакторинг с изменением типов, то это сразу наводит на мысли, что просто нужен язык с сильной статической типизацией. Который будет это вылавливать на этапе компиляции и ошибки типов просто не пройдут. Например, питоноподобным языком со статическими типами является Boo. Есть языки и более высокого уровня, которые использовать для решения такого рода исследовательских задач было бы резоннее. Почему они не рассматривались?

DS>В процессе создания начало складываться ощущение, что почти все современные языки, включая и Питон 3.0, устарели. Программист не должен заботиться о том, где расположены его данные, его должны интересовать только сами данные.

А какие языки рассматривались, позвольте спросить?

И с какой стати, в питоне кого-то особенно интересует, где расположены его данные (которые расположены на хипе, кроме примитивных типов — но это совершенно неважно) ?

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

Делюсь опытом.

1) Не надо что-то делать, если есть возможность этого избежать. Неделание — лучше чем делание.

2) Надо четче ставить цели. Кому и зачем нужен язык. Почему не подходят существующие. То, что озвучено про питон, извините, выглядит смехотворно. Т.е. у питона есть проблемы, конечно — но вот вышеприведенное не проблема совершенно. Если же вы настаиваете, что это проблема — приведите сравнительные кейсы. Т.е. как нечто делается на питоне делается плохо, на вашем языке — хорошо, и почему так.

Здравствуйте, dmz, Вы писали:

dmz>2) Надо четче ставить цели. Кому и зачем нужен язык. Почему не подходят существующие. То, что озвучено про питон, извините, выглядит смехотворно. Т.е. у питона есть проблемы, конечно — но вот вышеприведенное не проблема совершенно. Если же вы настаиваете, что это проблема — приведите сравнительные кейсы. Т.е. как нечто делается на питоне делается плохо, на вашем языке — хорошо, и почему так.

Пусть это будет несколько оффтопично, но не мог бы рассказать, какие лично ты видишь проблемы в питоне? Помимо динамической типизации и скорости?

Здравствуйте, dmz, Вы писали:

dmz>Плюс я считаю его низкоуровневым по сравнению с некоторыми другими языками. При этом, если более высокоуровневый язык показывает лучшую производительность и масштабируемость — то надо задуматься, имеет ли право на жизнь менее высокоуровневый?

Не мог бы ты пояснить эту низкоуровневость? Лучше продемоснтрировать, конечно.
Ну и какие другие? Haskell, lisp?

dmz>Haskell — очень хорошо. Lisp не знаю.

В смысле — haskell, ocaml и прочие ml-и, clean.

Неправильно распарсил вопрос сначала.

Здравствуйте, dmz, Вы писали:

dmz>>Haskell — очень хорошо. Lisp не знаю.

dmz>В смысле — haskell, ocaml и прочие ml-и, clean.

вот с продакшном в клине как-то, я бы постремался

dmz>Неправильно распарсил вопрос сначала.

Ничего страшного

dmz>>>Haskell — очень хорошо. Lisp не знаю.

dmz>>В смысле — haskell, ocaml и прочие ml-и, clean.

К>вот с продакшном в клине как-то, я бы постремался

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

Здравствуйте, dmz, Вы писали:

dmz>По моему, все это говорит о том, что вы не разобрались в предмете.
Есть такое. Чтобы написать язык, нужна семантика. Прежде чем задать семантику, нужно удостовериться, что она логична и удобна. Чтобы в этом удостовериться, нужно написать значительный объем кода с ее использованием. Чтобы написать гарантированно правильный код, не противоречащий семантике, нужна ее реализация. Для реализации нужна спецификация. В общем, замкнутый круг и не понятно, с какого звена начинать. Скорее всего, это порочный подход, но я начинаю с реализации. Для облегчения изменения семантики начали появляться метавозможности и сейчас, например, смена передачи по значению / по ссылке происходит с помощью изменения одного идентификатора в программе.

dmz>Если такая передача параметров (совершенно естественная)
Не согласен, что она естественная, кому как. Удобная — да, но только до определенной сложности решаемой задачи.

dmz>Если нужен частый рефакторинг с изменением типов, то это сразу наводит на мысли, что просто нужен язык с сильной статической типизацией.
Пробовал C++. Замкнутый мирок шаблонов меня никак не устраивал. Конкретные примеры привести не могу, но у меня часто возникала ситуация, когда из ф-и нужно было возвратить результат такого типа, который не устраивал компилятор.

dmz>Например, питоноподобным языком со статическими типами является Boo. Есть языки и более высокого уровня, которые использовать для решения такого рода исследовательских задач было бы резоннее. Почему они не рассматривались?
С опасением отношусь к нераспространенным языкам. В принципе, все что я делаю сейчас, можно написать и на них и, возможно, в пять раз быстрее, но если мой проект выйдет на серьезный уровень, то рано или поздно понадобятся возможности, которых в них нет.
Чувствую, что назревает вопрос: какого черта я тогда говорю о своем языке, который еще вообще нигде не используется. Просто я рассчитывал, что у кого-то будет интерес другого рода, не практический, а исследовательский.
Еще про нестандартные языки: если я реализую проект на Лиспе и решу перенести, скажем, на С, это значит, что мне сначала придется реализовывать на С Лисп, либо полностью переделывать дизайн. Или я что-то упустил?

dmz>А какие языки рассматривались, позвольте спросить?
Дельфи — у меня еще тогда была такая идея: реализовать интерфейс ввода в СУБД, чтобы облегчить/устранить парсинг и "бесплатно" приобрести некоторые другие полезные возможности. Потом я от нее отказался, а недавно нашел в инете сайт, где программист именно так написал язык. От Дельфи отказался из-за ее глюкавости.
C# — факт, что для создания любых данных в программе нужно объявлять класс, сразу заставил меня искать другой язык.
С++ — объединение низкоуровневости с монстрообразностью и постоянными ударами по рукам, когда хочется сделать что-то по-настоящему интересное и мощное. Когда я только начинал на нем писать, была идея создать встроенный язык, для обработки которого использовался бы сам С++. Как я был наивен в этом плане! С++ — последний язык, который подходит для таких целей.
Ассемблер — слишком низкоуровневый (сложно реализовывать нетривиальные алгоритмы), почти ни с чем не совместим, большое количество исключений в дизайне языка и архитектуре процессора, серьезные баги в МАСМе. Несмотря на все это, какое-то время был моим любимым языком и оказал на меня огромное влияние.
Лисп — писал я на нем очень мало, 99% времени потратил на изучение языка и культуры. После прочтения книги "If it works, it's not AI" (или что-то в этом роде) и, в частности, фразы "В своем новом проекте они решили избавиться от "Lisp handcuffs" и использовать С++", я тоже решил на нем не писать, но сомнения терзают до сих пор.
Специализированные языки — SML, Scheme не использовал.

dmz>И с какой стати, в питоне кого-то особенно интересует, где расположены его данные (которые расположены на хипе, кроме примитивных типов — но это совершенно неважно) ?
Я не о куче, а о логической организации данных.

dmz>Делюсь опытом.
dmz>1) Не надо что-то делать, если есть возможность этого избежать. Неделание — лучше чем делание.
А как же приобретение опыта? Одними книжками сыт не будешь.

dmz>2) Надо четче ставить цели. Кому и зачем нужен язык. Почему не подходят существующие. То, что озвучено про питон, извините, выглядит смехотворно. Т.е. у питона есть проблемы, конечно — но вот вышеприведенное не проблема совершенно. Если же вы настаиваете, что это проблема — приведите сравнительные кейсы. Т.е. как нечто делается на питоне делается плохо, на вашем языке — хорошо, и почему так.
Надеюсь, в обозримом будущем я смогу аргументированно ответить. А пока еще рано. Сейчас я точно знаю только, чего я не хочу.

DS>Пробовал C++. Замкнутый мирок шаблонов меня никак не устраивал. Конкретные примеры привести не могу, но у меня часто возникала ситуация, когда из ф-и нужно было возвратить результат такого типа, который не устраивал компилятор.

Haskell, OCaml ?

dmz>>1) Не надо что-то делать, если есть возможность этого избежать. Неделание — лучше чем делание.
DS>А как же приобретение опыта? Одними книжками сыт не будешь.

Но раз речь зашла о продвижении в массы...

Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Если ты просто не можешь привыкнуть к Лиспу, то может быть сначала узнать о других попытках улучшения синтаксиса Лиспа: Лисп без скобок?

Еще вот.

Здравствуйте, DSblizzard, Вы писали:
DS>У языка унифицированный префиксный синтаксис:
DS>def( f(X)
DS> ret(X)
DS>)

DS>=(X 4)
DS>loop(
DS> if(
DS> <(X 2)
DS> cout("<2")
DS> else
DS> cout(">=2")
DS> )
DS> =( X -(X 1) )
DS> break( ==(X 0) )
DS>)

В добавок к уже сказанному. Думаю, первый вопрос, на который тебе нужно ответить (самому себе) — чем твой язык лучше, чем scheme, common lisp или clojure (с этой троицой очень рекомендую познакомиться, раз уж тебя занесло в унифицированный синтаксис и префиксную нотацию).

Здравствуйте, Mr.Cat, Вы писали:

MC>чем твой язык лучше, чем scheme, common lisp или clojure

Вот это действительно нокаутирующий вопрос. Единственный плюс, который я вижу в своем языке по сравнению с перечисленными — в нем нет макросов. Мощная штука, спору нет, но как можно к ней относиться как к полноценной части языка, когда профи на Лиспе рекомендуют поменьше их использовать?

Спасибо за участие, но я читал это сообщение. Я вообще прочитал или просмотрел уже практически все, что есть в англоязычном инете по созданию ЯП и трансляторов. Это совсем немного, у меня на компе — около 150 МБ. Почему я в этом так уверен — просто когда я пытаюсь найти что-то новое, не получается.

"Я определённо нахожу foo() намного читабельнее, чем (foo)". И это сообщение я читал. И именно из-за него я решил принять такой синтаксис. Этот программист выражает интересы большинства. Правда, настоящее большинство все равно уже потеряно, потому что +(1 2) гораздо неудобнее, чем 1 + 2. В общем, пришлось пойти на компромисс. Если я решу, что возможности языка важнее, определение ф-и будет выглядеть так:

(def f[X]
  (ret X)
)

Здравствуйте, DSblizzard, Вы писали:

MC>>чем твой язык лучше, чем scheme, common lisp или clojure

DS>Вот это действительно нокаутирующий вопрос. Единственный плюс, который я вижу в своем языке по сравнению с перечисленными — в нем нет макросов. Мощная штука, спору нет, но как можно к ней относиться как к полноценной части языка, когда профи на Лиспе рекомендуют поменьше их использовать?

Профи на Лиспе рекомендуют их использовать ровно там, где надо, где без них уже никак. Макросы, вводят новый уровень абстракции. Без макросов, вышеперечисленные языки теряют всю свою мощь, именно макросы в связке с префиксной нотацией, позволяют легко и изящно оперировать кодом, как данными. Рекомендую ознакомиться с Practical Common Lisp (Peter Seibel) и On Lisp (Paul Graham), вот вторая книга и даст понять, где и когда использовать мощь макросов, а первая книга, это базовый туториал, чтобы понять вторую книгу

Здравствуйте, DSblizzard, Вы писали:
DS>Единственный плюс, который я вижу в своем языке по сравнению с перечисленными — в нем нет макросов.
Многие сочли бы это минусом. Кто-то — исключительно с точки зрения "наличие лучше, чем отсутствие", кто-то просто привык к макросам и с подозрением относится к языкам без оных.

Не знаю, правильно ли я делаю, чтопытаюсь увести разговор в сторону лиспов. Просто когда я увидел пример кода, первая мысль была — "да это же лисп". Поэтому сравнение с лиспами напрашивается у меня (возможно, не только у меня) само собой. Т.е. например:
— Scheme — это минималистичное ядро языка, плюс гигиенические макросы и континуации.
— Clojure — это (насколько я понял) многопоточность, stm, тесная интеграция с java (т.е. упор не на дизайн языка, а на качество реализации).
— Твой язык — это ...

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

DS>Мощная штука, спору нет, но как можно к ней относиться как к полноценной части языка, когда профи на Лиспе рекомендуют поменьше их использовать?
Ну смотря в каком контексте даются такие рекомендации, применительно к решению каких задач. Например, если хочется построить DSL поверх лиспа — лучше от макросов не отказываться.

Здравствуйте, dmz, Вы писали:

dmz>Haskell, OCaml ?

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

Прочел обе и еще пару. Хотелось бы прочитать еще Anatomy of Lisp, но нигде не могу найти.

Здравствуйте, eao197, Вы писали:

E>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от Б.Страуструпа, Дж.Госслинга, А.Хэйлсберга, Г.в.Россума, Я.Матцумото...

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

Здравствуйте, yumi, Вы писали:

E>>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от Б.Страуструпа, Дж.Госслинга, А.Хэйлсберга, Г.в.Россума, Я.Матцумото...

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

Хронология здесь не причем. Особенно это касается первых версий Java и C# -- на тот момент они вообще не предлагали ничего нового (оберонщики и приверженцы ObjectiveC до сих пор считают, что Java была испорченной версией их языков и даже использовала их технологии у себя внутри). Так что такие успешные мейнстримовые языки, как C++, Java, C#, Python и Ruby всего лишь являются очень понравившейся многим упаковкой для чужих идей. И я не вижу, почему такая же ситуация не может произойти с новыми языками в будущем. Взять, к примеру, Scala.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>DSblizzard,

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

Мы же с вами про Forth?

LCR>1.

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

LCR>2.

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

Здравствуйте, eao197, Вы писали:

E>Хронология здесь не причем.

Спасибо, после выделенного с Вами дальше можно не продолжать беседу.

Здравствуйте, yumi, Вы писали:

E>>Хронология здесь не причем.
Y>Спасибо, после выделенного с Вами дальше можно не продолжать беседу.

А со мной будешь? Моя русский каросый!

Возьми один из следующих языков: C#, Nemerle, Scala, Ruby, Python, и попробуй дать вразумительные ответы на эти вопросы, которыми их авторам якобы следовало задаться перед созданием.

Здравствуйте, Кодёнок, Вы писали:

Y>>Спасибо, после выделенного с Вами дальше можно не продолжать беседу.
Кё>А со мной будешь? Моя русский каросый!

С тобой, тем более. К тому же, JFYI, русский не мой родной язык. Так что, твоя шутка для меня звучит как оскорбление.

Кодёнок,

Кё>А со мной будешь? Моя русский каросый!

Кё>Возьми один из следующих языков: C#, Nemerle, Scala, Ruby, Python, и попробуй дать вразумительные ответы на эти вопросы, которыми их авторам якобы следовало задаться перед созданием.

Хм, не скажу про всю Одессу, но про Scala кое-что можно возразить.

И про Nemerle — информация о типах в макросах ещё не встречалась ни в Лисп, ни в Dylan, ни в PLOT, и по очевидным причинам эта фича не может быть выкушена оттуда и добавлена в уже существующий язык

.

Mr.Cat,

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

MC>Еще вот.

Да, видел я сайт и презентацию языка PLOT. Однако, думаю ты согласишься, что вклад этого языка чисто синтаксический. И, кроме того, это (пока?) чисто мысленный эксперимент без имплементации вообще. Поэтому у него, увы, будущее в тумане.

Здравствуйте, Mr.Cat, Вы писали:

MC>информации ты пока совсем немного дал
Информации немного в основном потому, что сделал еще не очень много.

MC>- Твой язык — это ...
Ленивые вычисления, программирование задач, в которых требования изменяются так быстро, что жесткие структуры данных не имеют особого смысла, совмещение декларативного и императивного стиля.
Но пока выполнена только первая часть, да и то не полностью. Вот еще несколько деталей:
Возможно присваивание значения результату функции:
=(x() X)
Не припомню, чтобы я видел язык, где такое реализовано. Для обращения к глубинам какой-либо структуры приходится писать две ф-и — геттер и сеттер. По-моему, не слишком удобно. Я понимаю, что это помогает сокрытию данных, но здесь речь не об этом. Мой способ и сокрытие данных в принципе не противоречат друг другу.
Переменные имеют следующие области видимости: программа, ф-я со вложенными ф-ями, тело ф-и. Некоторые ф-и будут иметь два варианта, деструктивный и недеструктивный, какая именно будет вызываться, будет определяться первым параметром: f(ds X), f(nd X).
Элементы программы максимально атомизированы. Например, переменная не связано жестко ни со своим значением, ни с именем, мы можем сменить имя и при этом это будет та же переменная. Та же философия атомизации, возможно, приведет к именам из нескольких слов. К сожалению, это не будет выглядеть как f n x, потому что программист где-нибудь забудет, к чему относилось n — к f или x: f_n(x), f(n_x). Это будеть выглядеть так: ir(f n)(x)
Указатели будут реализованы прозрачно, а точнее, с изменяемой прозрачностью. Т. е. обычно они не будут видны, но когда понадобятся — их можно будет получить и использовать.
Но семантику я пока оставил на потом. Первоочередная цель — оптимизация.
Вот более приличная версия, чем та, которую я оставил раньше, правда, еще нет сборки мусора и обработки ошибок:
http://files.rsdn.ru/48064/Drive%200.rar

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>>>

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

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

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

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

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

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

E>>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от
E>>Б.Страуструпа,
LCR>Да, конечно. C++ был создан в 1983-м году с целью решить вполне конкретные задачи, которые не мог адекватно решить C: абстрактные и пользовательские типы данных, ООП, обощённое программирование. Причём, нужны были также возможность низкоуровневого доступа, и совместимость с унаследованным кодом на C. Ни один из существующих тогда (1983-й если я не ошибаюсь) языков не мог решать все эти задачи так же успешно, как C++. (Lisp, Smalltalk, Forth и т.п. конечно могли многое, но компилировать код на C увы нет).

Не C. А Simula. Проблема была в том, что Simula предоставляла необходимые абстракции, но не давала должной эффективности. Язык C вылез просто как удобная платформа для эффективной реализации идей. (Как JVM в случае со Scala). Тем более, что обобщенное программирование, множественное наследование и обработка исключений появились в C++ уже впоследствии, в районе 1988-1989-годов. Т.е. через десять лет после начала работ над C with Classes.

При этом, если взглянуть на упомянутые вопросы:
1. Тут вроде бы ответ есть.
2. Никакой красоты.
3. Существуют. Та же Simula. И недостатки лежат не в самом языке Simula, а в деталях реализации.
4. Нельзя продемонстрировать. То, что позволял делать C with Classes, позволяли делать и другие языки. Различия только в степени эффективности.

E>>Дж.Госслинга,
LCR>Да. На 1995-й год виртуальная машина (секьюрность, переносимость), сборка мусора, чистая объектная система, рефлексия и динамическая загрузка классов — это фичи, в полной мере отсутствующие в С++. Smalltalk не мог выполнять роль Java из-за динамической типизации.

А как же Objective-C и Modula с Oberon-ами? Приверженцы этих языков очень сильно убеждены, что Java -- это вовсе не C++, а сильно испорченные C++ным синтаксисом их творения.

E>>А.Хэйлсберга,
LCR>Ммм, удовлетворила бы разве что относительно C# >=2.0 — дженерики, лямбды и прочее. Причиной разработки C# называют множество вещей, но кажется главная в том, что Java была разработана не в Microsoft.

Ну вот в том-то и дело. Очень яркий пример, когда язык не добавляет ничего нового. Просто является несколько другой реализацией уже известных идей (С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi) + перегрузка операторов (хорошо известная по C++ и куче других языков)). Зато это отличная площадка для дальнейшего развития в свою сторону.

Почти то же самое произошло и с C++, и с Python, и c Ruby.

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

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

eao197,

E>>>Очень бы хотелось узнать, удовлетворили бы тов.Frank Atanassow ответы на эти вопросы от
E>>>Б.Страуструпа,
LCR>>Да, конечно. C++ был создан с целью решить вполне конкретные задачи, которые не мог адекватно решить C: абстрактные и пользовательские типы данных, ООП, обощённое программирование. Причём, нужны были также возможность низкоуровневого доступа, и совместимость с унаследованным кодом на C. Ни один из существующих тогда (1983-й если я не ошибаюсь) языков не мог решать все эти задачи так же успешно, как C++. (Lisp, Smalltalk, Forth и т.п. конечно могли многое, но компилировать код на C увы нет).

E>Не C. А Simula. Проблема была в том, что Simula предоставляла необходимые абстракции, но не давала должной эффективности.
см. ниже
E> Язык C вылез просто как удобная платформа для эффективной реализации идей. (Как JVM в случае со Scala). Тем более, что обобщенное программирование, множественное наследование и обработка исключений появились в C++ уже впоследствии, в районе 1988-1989-годов. Т.е. через десять лет после начала работ над C with Classes.
E>При этом, если взглянуть на упомянутые вопросы:
E>1. Тут вроде бы ответ есть.
E>2. Никакой красоты.
Ну как же? Специально поднял книжку Страуструпа, там вон что написано:

class  complex {
    double  re, im;
    public:
    complex(double  r, double  i) { re=r; im=i; }  //constructomplexromwocalars
    complex(double  r) { re=r; im=0; }         //constructomplexromnecalar
    complex() { re = im = 0; }  //defaultomplex: (0,0)
    friend  complex  operator+(complex, complex) ;
    friend  complex  operator-(complex, complex) ; //binary
    friend  complex  operator-(complex) ;  //unary
    friend  complex  operator*(complex, complex) ;
    friend  complex  operator/(complex, complex) ;
    friend  bool  operator==(complex, complex) ;       //equal
    friend  bool  operator!=(complex, complex) ;       //notqual
//...
};

Красота!

E>3. Существуют. Та же Simula. И недостатки лежат не в самом языке Simula, а в деталях реализации.
E>4. Нельзя продемонстрировать. То, что позволял делать C with Classes, позволяли делать и другие языки. Различия только в степени эффективности.

Я повторю тут твою фразу выше:
E>... А Simula. Проблема была в том, что Simula предоставляла необходимые абстракции, но не давала должной эффективности...
И следовательно, не предоставляла решения указанных задач. Ибо в данном случае, под глаголом "решает" конечно же имеется ввиду вопросы практического решения, ибо с теоретическими решениями давно всем всё ясно.
Более того:

From the earliest days of Simula, containers (such as lists) had been intrusive: An
object could be put into a container if and only if its class had been (explicitly or
implicitly) derived from a specific “Link” or “Object” class containing the link
information needed by the compiler.

Simula containers and arrays had this irregular treatment of built-in and user-defined
types (only some of the latter could be in containers) and of containers and arrays (only
arrays could hold fundamental types; arrays couldn’t hold user-defined types, only
references to user-defined types).

В C++ этих бородавок по крайней мере нет (но, конечно, дофига своих собственных).

У Objective-C насколько мне помнится были те же самые проблемы с производительностью, "благодаря" которым он почти впал в забвение (второе рождение ему подарила Apple своей Cocoa). То есть решение как-бы есть, но воспользоваться им Страуструп не мог — тормоза-с...

E>>>Дж.Госслинга,
LCR>>Да. На 1995-й год виртуальная машина (секьюрность, переносимость), сборка мусора, чистая объектная система, рефлексия и динамическая загрузка классов — это фичи, в полной мере отсутствующие в С++. Smalltalk не мог выполнять роль Java из-за динамической типизации.

E>А как же Objective-C и Modula с Oberon-ами? Приверженцы этих языков очень сильно убеждены, что Java -- это вовсе не C++, а сильно испорченные C++ным синтаксисом их творения.

E>>>А.Хэйлсберга,
LCR>>Ммм, удовлетворила бы разве что относительно C# >=2.0 — дженерики, лямбды и прочее. Причиной разработки C# называют множество вещей, но кажется главная в том, что Java была разработана не в Microsoft.

E>Ну вот в том-то и дело. Очень яркий пример, когда язык не добавляет ничего нового. Просто является несколько другой реализацией уже известных идей (С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi) + перегрузка операторов (хорошо известная по C++ и куче других языков)). Зато это отличная площадка для дальнейшего развития в свою сторону.

E>Почти то же самое произошло и с C++, и с Python, и c Ruby.

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

C++ и Python я бы вычеркнул. Про C++ я сказал выше, а у Питона на момент создания не было альтернатив, он же метил на "language for everyone". Lisp не может претендовать на "language for everyone" из-за свободы, которую он даёт. А свобода — явно не для всех, иначе можно было бы ограничиться просто indentation-фронтендом для всех.

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

Ну вот и ответ: на пункт 3 ответ был отрицательный, и новые фичи невозможно было добавить в уже существующий язык Miranda, поэтому новый язык и взял старт. И вообще:
1. Haskell решает задачу построения таких абстракций, которые трудны/невозможны в других языках, задачу практического применения чистого функционального программирования и ленивых вычислений.
2.

-- Primes list
primes = nubBy (((==0) .) . (flip mod)) [2..]

-- Fibonacci list
fibonacci = 0 : 1 : zipWith (+) fibs (tail fibs)

-- Fork processes, print their results
main = do
    prim   <- run primes
    fibs   <- run fibonacci
    mapM_ print $ zip prim fibs

3. Миранда, LazyML и другие клоны ML, Clean, Lisp, Scheme — все они не годились по разным причинам.

...in particular, we sought the freedom for anyone to extend or modify the
language, and to build and distribute an implementation.

— цитата из "History of Haskell"
4. Такой комбинации фич как в Haskell пока нет нигде.
5. Важна именно комбинация чистоты, ленивости и системы типов (не самой примитивной вдобавок

).

Так что, никаких противоречий

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Так что, никаких противоречий

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

А вот по поводу предложения

-- я полностью согласен!

eao197,

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

Да, тем более как растёт популярность языков (и не только языков) уже неоднократно обсуждались здесь, так что поддерживаю!

Здравствуйте, eao197, Вы писали:

E>(С# 1.0 -- это та же самая Java + делегаты (хорошо известные Хэйлсбергу по Delphi)

В Дельфи нет делегатов. Там обычные указатели на методы.

E> + перегрузка операторов (хорошо известная по C++ и куче других языков)).

+ value типы с автобоксингом + foreach + ref/out параметры + свойства + наверняка еще что то забыл. Каждая фича по отдельности — где нибудь да была, а вот в совокупности ...