Ответ на »сообщение 1162« (Артем)
___________________________

А какая самая агрессивно-одиозная?  0:-)
Если в шутку, то PHP, а если всерьез, то C++.

Ответ на »сообщение 1167« (Сергей Перовский)
___________________________
Инструмент  который не допускает вариативности результатов - это автомат, работающий без вмешательства человека. А если это все таки инструмент, то зоопарк результатов обеспечен.
Наверное человек скорее всего имел в виду количество вариантов для достижения цели.

>>>словарь не кирилл и мефодий придумали зпт а пользователи языка
Словарь (да и синтаксис) славянских языков в основном сложился задолго до Кирилла.
Посмотрите на рукотворные языки, такие как эсперанто или иврит. Если бы авторы ограничились синтаксисом и сотней слов, в надежде, что остальные слова появятся в процессе использования, мы бы имели сотни взаимно непонятных диалектов.
С языками программирования так происходит постоянно.
Да, но есть другая крайность. Раньше в русском было девять падежей и порядка 2000 (двух тысяч! - куда там аглицкому :о) ) глагольных форм. Ими и сейчас можно пользоваться, но в силу ряда исторических и социально-политико-демографических событий и процессов, произошло искусственное "сокращение" языка.
А "зоопарк" в ЯП как раз и возникает, что разные производители имеют преобладание в разных отраслях и "приспосабливают" язык соответственно. Всем оно нужно? КТо-то из производителей "угадывает" (навроде Борланада) - просто в той доле рынка потребностей большая масса народу работает, а кто-то "пролетает"...

Ответ на »сообщение 1156« (Владимир Лось)
___________________________


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


"Удивительный язык" на задворках отрасли скорее всего из-за своей низкоуровневости, чем из-за отсутствия стандарта.

Ответ на »сообщение 1167« (Сергей Перовский)
___________________________
А если это все таки инструмент, то зоопарк результатов обеспечен. Тут мы подходим к такому тонкому понятию, как чувство меры. Зоопарк точному определению не поддается, это вопрос интуиции и опыта. :) Для кого-то ранообразие внутренних DSL вполне приемлемо, а для кого-то даже классы являются излишеством. :)

Ответ на »сообщение 1166« (Владимир Лось)
___________________________
а теперь бибизяне дали запал от водородной бомбы Ну назвать запалом от водородной бомбы функциональные языки трудно. Если бибизяна будет будет в них творить, то программа или просто не будет работать, или будет работать очень медленно. Вот C++ можно назвать таковым запалом. Поэтому одной из целей создания следующей генерации ООП языков, вроде Java и .Net-семейства, была минимизация негативных последствий неквалифицированного программирования. Я и сам стону, когда в C# приходится писать unmanaged code, но понимаю, для чего это все эти танцы с бубном были сделаны - для защиты от бибизян.
Это хорошо если животное "допрёть", что дело "пахнет керосином" и вернётся в "родные места", а если "начнёт творить"? Тут тоже все далеко не так однозначно. Ведь даже квалифицированные программисты когда-то были, как вы говорите, "животными".  Зачем же отказывать кому-то в праве творить? :)  Другое дело, что чье-то творчество со временем улучшается, а чье-то - нет. Но тут ничего не поделаешь - закон природы. :)

Ответ на »сообщение 1161« ()
___________________________
>>>скорее нужен инструмент для многих и который не допускает вариативности результатов
Инструмент  который не допускает вариативности результатов - это автомат, работающий без вмешательства человека. А если это все таки инструмент, то зоопарк результатов обеспечен.

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

Ответ на »сообщение 1164« (Артем)
___________________________
А в Лиспе те же DSL выглядят настолько же ужасно, как и сам язык :) Впрочем, это тоже дело вкуса. Есть ведь люди, кому нравится такой синтаксис. :)
В последние несколько лет начинаю склоняться ко мнению, что всё это не играет никакой роли. Тут и на Си(++)-то две трети народа, что говорит, что "работает на Си(++)", на самом деле и языка не знают, и программировать НЕ УМЕЮТ. А теперь представьте, что таким "спецам" в руки попадает Лисп или Форт... Это в "классических" языках, сами их ограничения (синтаксиса, идеологии, инструментария) служили "тормозом" для "разгула удалой и залихватской безграмотности", а теперь бибизяне дали запал от водородной бомбы... Последствия предугадать не трудно... Это хорошо если животное "допрёть", что дело "пахнет керосином" и вернётся в "родные места", а если "начнёт творить"? В жизни, конечно, всегда есть место подвигу, но лучше быть подальше от таких мест... :о)

Ответ на »сообщение 1163« (Lisp Hobbyist)
___________________________
Уважаемый Lisp Hobbyist!
Скажите, в процентном отношении, сколько таких "надстройщиков" языка существует?
И есть ли в конторах средства и время заниматься подобными вещами. Уверяю вас, что в тех местах, где на подобные занятия есть и время, и деньги (и программисты только этим и занимаются, получая при этом ДАЛЕКО не 100 доллярив), скорее всего, потребностей "остального мира", занимающегося той же тематикой, не знают. Действительно универсальных решений даже для "той же ниши" не существует. Как правило это внутрикорпоративные разработки. Правде не всегда те, кто пишет такие "библиотеки" даже отдают себе отчёт, что они пытаются "родить" DSL...

Да, вобщем-то, и не в этом проблема. В наших условиях, слава богу, если хотя бы треть программистов понимала, что хранение данных модели в полях компонентов интерфейса - моветон... А уж потом за библиотеки с DSL-ами можно приниматься... :о)

Ответ на »сообщение 1163« (Lisp Hobbyist)
___________________________
Гораздо интереснее, когда язык начинает расширяться конструкциями, специфичными для конкретных предметных областей, образуя тем самым Domain-Specific Language.
Да мы с Jack of Shadows тут уже переломали копья на эту тему. Я бы, все-таки, предпочел более высокоуровневый и удобоваримый язык с макросами, такой как Nemerle, или систему подсоединения внешних DSL к тому же C#  :)  А в Лиспе те же DSL выглядят настолько же ужасно, как и сам язык :) Впрочем, это тоже дело вкуса. Есть ведь люди, кому нравится такой синтаксис. :)

Ответ на »сообщение 1155« (bb)
___________________________

>>>Так устроены Форт и Лисп (возможно, есть и другие языки такого типа, но я с ними не имел дела).

Можно вспомнить, например, метаалгоритмический язык Рефал, созданный В.Ф.Турчиным в 1966

Я имел в виду другое --- возможность легкого доопределения языка необходимыми конструкциями, которые естественно вольются в языковое ядро и по удобству своего применения не будут отличаться от встроенных. Например, можно представить себе Лисп-ядро, в котором имеется примитив ветвления и безусловного перехода, но нет циклов. Поверх такого ядра с помощью макросов можно надстроить весь спектр циклических конструкций, определенных ANSI CL (т.е. DO, DOLIST, DOTIMES, LOOP и т.п.), а если кому-то нужна еще какая-то экзотика, то добавить ее --- задача достаточно легкая. Как говорится, чтобы никто не ушел обиженным. Но такая раскрутка системы --- только начальный уровень, на котором оценить ее должным образом могут только компиляторостроители (остальным и не надо --- с замечанием о минусах "зоопарка" базовых примитивов я согласен). Гораздо интереснее, когда язык начинает расширяться конструкциями, специфичными для конкретных предметных областей, образуя тем самым Domain-Specific Language. Здесь уже последствия "зоопарка" куда менее страшны, так как предметные области достаточно высокого уровня уже достаточно различны и интеграция на этом уровне нужна куда реже. Например, над Лиспом можно надстроить язык описания прошивок ПЛМ. С одной стороны, такие описания можно "скормить" подсистеме генерации файлов для программатора, а с другой --- использовать в программе-симуляторе. Причем в этом языке, в отличие от того же Verilog, будет доступна вся мощь лисповских макросов, которые, например, могут пригодиться для параметризации компонент вместо внешних программ-генераторов.

В Рефале аналогов этому я не видел.