OberonCore

На сайте, посвященном Оберону, звучит двусмысленно. Но смысл понятен.

Не буду повторяться про две разных простоты, уже было сказано:
http://www.inr.ac.ru/~info21/princypKalashnikova.htm

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

Если мне нужно создать распределенный сервис, я не возьму оберон, я возьму скорее всего erlang.

Если мне нужно на кластере посчитать какую-нибудь газодинамическую задачу, то я не возьму ерланг, я возьму какой-нибудь C99 или С++ или фортран с каким-нибудь OpenMP или MPI.

Если мне нужен карманный высокоуровневый язык для какого-либо решения (например для нового микроконтроллера), то я не возьму С++, я возьму Оберон (не Оберон-2 и производные), потому что реализовать компилятор его под силу одному человеку в реальные сроки и будет полный контроль над ситуацией.

Если мне нужно написать парсер/транслятор с языка, для которого нет EBNF нотации (а таких полно в rfc), я возьму Haskell+parsec, потому что я точно знаю что в этом случае я не упрусь в какие-то ограничения языка или библиотеки. Т.е. задача будет выполнена в разумные сроки.

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

Если же нам нужна высокая надежность встраиваемой системы, то я наверно предпочел бы SPARK(Ada), как и поступила NASA:

Простите, а чем, для решения всего этого набора задач, не устраивает просто наличие Linux (gtk|qt|upp|...) + g++ (stl|boost|upp|...) ?
... + Хром для пошарить в Интернет?...

По моему, коментарий совершенно не в тему. При чем тут линукс и какие-то гуишные либы вообще?

Но вы же перечислили задачи, которые собрались решать разными наборами инструментов? Я перечислил свои.
В lbook у меня стоит Линукс. И работаю я сейчас в Сети на Линуксе. На работе я читаю pdf и отлаживаю (через OpenOCD) свои встроенные системы - тоже на Линуксе. И документацию веду на ООфисе на Линуксе. А на каком языке всё это написано - сказать?

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

Предполагалось что для написания карманного языка предлагается использовать что? линукс? с++? g++? boost? Распределенный сервис будем писать на gtk, а обсчитывать газодинамику на кластере будем на upp? Лабу по Тер.Верам напишем конечно же на хроме, а как же иначе? Ну и заключительный аккорд -- ПО для лунного модуля (т.е. mission critical задач) будем писать на C++.

Ну, собственно ваши ответы это яркая иллюстрация к статье, прям таки пример, как НЕ НУЖНО делать. Инструмент должен быть адекватен задачи. Универсальный инструмент одинаково плох для любой задачи. Я С++ не считаю универсальным инструментом, поэтому я и не считаю его плохим инструментом. Для своих задач он очень даже ничего. Однако не стоит его пихать туда, где есть более адекватные задаче инструменты.

Например voip'ный софтфончик. Тут без С++ никуда. Из достойных альтернатив разве что Си Однако Си я достойной альтернативой не считаю. Там уж очень просто прострелить себе ногу два раза. Простое переименовывание файлов исходников из .с в .cpp может помочь выловить массу ошибок.

Однако, зачем мне C++ например при написании распределенного сервиса (при условии что над ним уже не трудится пачка высоквалифицированных специалистов пишущих на С++)? Тем более что неизвестно жизнеспособна ли бизнесидея вообще. Лучше написать на erlang'e. Это проще, быстрее (написать), поддерживаемей наконец. Дешевле в сопровождении и масштабировании.

Ну и т.п.

Все эти соображения и примеры -- сиюминутного, случайного характера (MPI для фортрана и т.п.).

Касательно идеи "инструмента под задачу" - есть ещё очень веское контр-соображение.

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

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

Ну, кому сиюминутные, а кто на полный рабочий день годами с этим работает

Зависит от того, чем собственно коллектив занимается. Если коллектив, как часто бывает, пилит/поддерживает/развивает допустим некий распределенный сервис. Годами. Т.е. это не сиюминутная задача, а задача с характерным временем порядка 5-10 лет. То да, набор инструментов будет узок. Например тот же erlang + C для написания портов да драйверов (в терминах ерланга, а не оси, это другие порты и драйверы).

Задача по сути одна, и инструмент по сути один. Логично, правда ведь?

Если сегодня я пишу софтфон под симбиан (это С++ без вариантов), потом пишу гейт xmpp<->smpp, потом пишу компилятор/анализатор кода, потом тот же софтфон под андроид, а потом уже его же под винду, вопрос -- как тут обойтись одними и теми же инструментами? И нужно ли? Что тут общего?
Да даже взять три софтфона: под симбиан, андроид и винду -- между ними (несмотря на общие используемые протоколы) общего нет практически НИЧЕГО. Разные API, разный GUI, разное даже поведение и интеграция в систему. Нет, конечно можно выпендриться и протащить там везде свой собственный SIP-стэк. В симбиане проблем с этим будет поменьше, в андроиде побольше. Но можно. Однако качество решения в этом случае будет неизменно хреновым. Вне зависимости от затраченных усилий.

Задачи разные, и инструменты разные.

Важно найти баланс между первым и вторым случаем. Быть может я не точно вначале выразился. Задача -- это не сиюминутная задача. Это задача стратегическая. А инструмент это не один инструмент, это набор инструментов. При этом не следует бояться экспериментировать с новыми инструментами. Обычно в приличных конторах есть спец. отдел который как раз экспериментирует, оценивает перспективность того, или иного документа. Догматизм вроде "всегда и навеки используем только Borland C++ Builder!" ни к чему хорошему не приводит. Я это проходил. Вместо "Borland C++ Builder" можно подставить что угодно. BlackBox, erlang, C#, brainfuck.

Над простым базовым языком можно строить не только библиотеки-каркасы, но и DSL под задачу.

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

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

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

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

И таких, да, большенство. Иначе монстры вроде C# не выростали бы и столь массово не применялись бы. Да и делфи как бы не маленький язык. По моему, с шарпом может потягаться по сложности современная делфи.

Но я не сказал бы что это плохо. Так есть. Это психология оседлого образа жизни.

Мне не то чтобы очень просто переключаться с инструмента на инструмент, искать инструмент под задачу, но мне это ужасно интересно

Вам адназначна - сюда: http://www.forth.org.ru !

Я давно уже сформулировал тройку качеств, которые мне нужны от базового языка:
- простота;
- жёсткость;
- расширяемость.

Лиспы, Форты прекрасно катят по двум пунктам, но вот в виду отсутствия скелета мне не подходят

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

Крупная инженерия не может быть только из "гибких материалов".

Гм. А какие расширения языка (видимо язык это CP) вы используете?

Вы можете ОРГАНИЗОВАТЬ/ВВЕСТИ в них тот уровень степени жёсткости, который вам необходим ао проектируемой системе.

Я имею в виду готовность к компонентности и extensible OOP, в терминах Шиперски, а не расширяемость синтаксиса.