Мои пять козявок на тему Почему у Nemerle нет будущего - Компьютерные священные войны

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

K>Вы считаете, что Nemerle это очень сложный язык для сильно умных?

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

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

У Nemerle очень сильный упор делается в метапрограммирование. Даже многие фичи языка реализованы через макросы. Наверное для разработчиков языка и компилятора это выглядит очень здорово. Так же могут думать и некоторые разработчики библиотек, которым нужна compile-time генерация кода. Ну и разных пуристов и исследователей языков в эту же группу можно добавить.

Но что получает тот, кому не нужно делать свой компилятор, кому не нужно разрабатывать фреймворки с кодогенерацией, которому по барабану, насколько маленький код самого компилятора? Сборную солянку из императивных, функциональных и объектно-ориентированных возможностей, да еще и с супер-мета-программированием в придачу. Даже если она удачно приготовлена все равно разработчикам нужно привить вкус и хороший тон, чтобы в нужном месте применять pattern-matching, в нужном OOP, в нужном метапрограммирование. Т.е. нужно учится, учится и еще раз учится.

Безусловно, кто-то будет этому рад и сможет использовать все возможности Nemerle в полном объеме без ущерба для себя и своих проектов. Так было с Lisp-ом, со Smalltalk-ом, так есть с C++. Я думаю, что так будет с Nemerle. Но может быть здесь так же сработает закон потребления пива и 80% возможностей Nemerle потребуется всего лишь 20% его аудитории. А оставшимся 80% пользователей нужны будут всего лишь 20%, как то вывод типов и локальные функции (для уменьшения объема кодирования в обычных условиях). Но ведь есть еще 80% неиспользованных возможностей -- их обязательно нужно будет как-то использовать. И может быть кто-то сможет объяснить, какие факторы не позволят функциональность Nemerle употребить во вред?

K>Вы считаете, что Oberon не получил распространение тоже потому, что он для сильно умных?

Нет. Есть такой феномен: популярность получают языки, которые создаются для работы, для удовлетворения своих собственных сиюминутных нужд. C, C++, Perl, Python, Ruby, Java (наверное и C# сюда же попадает). Как только к языку прикладывается какая-то наука (Pascal, Oberon) или комитет (Ada), как все сразу портится.

Чем это объясняется я не знаю, но факты упрямая вещь.

K>Чем руководствуются создатели Оберона мне совершенно не понятно. Тоесть я догадываюсь, что они ориентируются на пуристов, но и с этим мне не все ясно.

У меня такое же впечатление. Они занимаются исследованиями.

K>А то что создатели Немерле не выставляют себя умниками и не делают эзотерический язык, лично для меня видно и из материалов сайта и из дизайна самого языка.

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

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

K>Простите, я не улавливаю.
K>Вы считаете, что Nemerle это очень сложный язык для сильно умных? Позвольте спросить, а какой тогда простой?

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

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

K>>Вы считаете, что Nemerle это очень сложный язык для сильно умных?

E>Нет, я так не считаю. Но я думаю, что Nemerle делает очень простым написание сложных (в смысле запутанных, сложных для сопровождения) программ. Но об этом здесь, помнится, Gaperton уже говорил.

E>Я думаю, что если что-то может быть понято или использовано неправильно, то оно обязательно будет понято и использовано неправильно. Успех Java показывает, что подавляющему большинству разработчиков, не желающих вникать в тонкости языка и правильных способов его использования, нужно что-то, максимально усложняющее отстреливание ног разработчиков. Но при этом дающее некоторые преимущества в простоте реализации каких-то часто встречающихся задач.

Конечно нужно. А некоторые еще и осознают, что нужно именно это.

Частью мотивации при разработке Java было обеспечение "безопасности" разработки.

Guess what? Эрланг разрабатывался целиком из этих соображений. Это заказ индустрии. Задача Ericcon CS Lab была поставлена так — разработать язык, в которым будут невозможны классы ошибок, наиболее распространенные по статистике телекомовского софта, разработанного в Эрикссон. Т.е. постановка была такая — чтоб ноги было отстрелить сложно или невозможно. В результате, в языке отсутствуют потенциально опасные конструкции или конструкции с малопредсказуемым временем работы.

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

Это заказ военных. Старушку в метро, помнится, чуть удар не хватил, когда она обложку книги ("Язык Ада") увидела. И правильно, а каково тем, кому писать на нем приходится?

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

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

G>Конечно нужно. А некоторые еще и осознают, что нужно именно это.

G>Частью мотивации при разработке Java было обеспечение "безопасности" разработки.

G>Guess what? Эрланг разрабатывался целиком из этих соображений. Это заказ индустрии. Задача Ericcon CS Lab была поставлена так — разработать язык, в которым будут невозможны классы ошибок, наиболее распространенные по статистике телекомовского софта, разработанного в Эрикссон. Т.е. постановка была такая — чтоб ноги было отстрелить сложно или невозможно. В результате, в языке отсутствуют потенциально опасные конструкции или конструкции с малопредсказуемым временем работы.

Все это так. Но здесь могут последовать возражения, что Nemerle всполне себе безопасный, managed язык. Вполне как та же Java. Так что я бы сделал упор не на проблемы, которые язык допускает в run-time (вроде повисших указателей в C/C++), а на проблемы при сопровождении кода. Т.е. Nemerle может и не позволяет отстрелить себе ногу, но зато можно так завязать себе шнурки, что потом можно будет этот узел только методом Александра Макидонского разрубить.

Собственно поэтому я и думаю, что у Nemerle есть шансы повторить историю Lisp-а.

G>А из каких соображений разрабатывался Немерле? Интересы какой группы людей были учтены при его разработке? Сдается мне — интерес инженера, который хочет хрень написать позаковыристее, штоб круто было.

Нет, не инженера, а ученого. У них это в крови, собственно и работа у них такая.

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

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

G>>Конечно нужно. А некоторые еще и осознают, что нужно именно это.

G>>Частью мотивации при разработке Java было обеспечение "безопасности" разработки.

G>>Guess what? Эрланг разрабатывался целиком из этих соображений. Это заказ индустрии. Задача Ericcon CS Lab была поставлена так — разработать язык, в которым будут невозможны классы ошибок, наиболее распространенные по статистике телекомовского софта, разработанного в Эрикссон. Т.е. постановка была такая — чтоб ноги было отстрелить сложно или невозможно. В результате, в языке отсутствуют потенциально опасные конструкции или конструкции с малопредсказуемым временем работы.

E>Все это так. Но здесь могут последовать возражения, что Nemerle всполне себе безопасный, managed язык. Вполне как та же Java.
Ну так это, кстати, будут совершенно правильные замечания

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

E>Так что я бы сделал упор не на проблемы, которые язык допускает в run-time (вроде повисших указателей в C/C++), а на проблемы при сопровождении кода. Т.е. Nemerle может и не позволяет отстрелить себе ногу, но зато можно так завязать себе шнурки, что потом можно будет этот узел только методом Александра Макидонского разрубить.

Ну, собственно, на это я упор и сделал выше по ветке. Честно говоря, у меня нет цели убедить людей на Немерле не писать

. Даже наоборот — пусть пишут, это хорошее упражнение. Мое мнение другое — хорошему языку макросы не нужны, там должно быть и без них комфортно. Если от макросов есть заметный плюс — что-то не так с самим языком. Инженеры из моего отдела придерживаются такого же мнения.

E> ...
Далее +1.

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

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

K>>Простите, я не улавливаю.
K>>Вы считаете, что Nemerle это очень сложный язык для сильно умных? Позвольте спросить, а какой тогда простой?

L>Тут нет противоречия.
L>Посмотрите на lisp, проще не придумашь при всем желании, только вот когда читаешь какую-нить книжку по нему, крыша почему-то начинает плавиться.
L>Также и с неменле — язык то простой, но система макросов может его полностью преобразить и сделать на базе него совершенно другой язык, и есть очень большие сомнения, что разработчики макросов не сделают из простого немерле неповоротливого монстра.

Уже делают. И Питоновские конструкции то туда добавили, и list comprehensions, и все что в других языках заметили — вот увидите, скоро это будет современный PL/1 или второй boost. Остановить бардак в таком случае способно только введение открытого стандарта на язык и библиотеку, как это произошло с Лиспом. Только вряд-ли это случится.

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

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

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

1. Максросы немерле так или иначе являются локальными
Но иногда возникает необходимость сохранить информацию между вызовами макроса. Существует ли способ это зделать?
Напримр написать макрос которые будет частично достраивать класс.
Так чтоб каждый вызов добавлял что нибудь.

http://rsdn.ru/Forum/Message.aspx?mid=2054093&only=1

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

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

K>>Что она дает разработчикам Nemerle?
K>>Мой ответ на все три вопроса — "ничего".

E>Ой ли? Имхо, она говорит, что "Ребята, вокруг много людей, которые совсем не такие умные как вы. Если вы хотите, чтобы Nemerle пошел дальше, чем научная работа и не повторил судьбу Oberon-ов, Modul-ов и пр., то будьте проще и люди к вам потянуться".

Ну кстати, причина появления ужасного и трудно поддерживаемого промышленного кода (в просторечии — legacy code), вовсе не в том, что какие-то люди глупее других. Это распространенное заблуждение.

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

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

E>...

K>>Вы считаете, что Oberon не получил распространение тоже потому, что он для сильно умных?

E>Нет. Есть такой феномен: популярность получают языки, которые создаются для работы, для удовлетворения своих собственных сиюминутных нужд. C, C++, Perl, Python, Ruby, Java (наверное и C# сюда же попадает). Как только к языку прикладывается какая-то наука (Pascal, Oberon) или комитет (Ada), как все сразу портится.

E>Чем это объясняется я не знаю, но факты упрямая вещь.

E>...

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

--
Mikl

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

L>Посмотрите на lisp, проще не придумашь при всем желании, только вот когда читаешь какую-нить книжку по нему, крыша почему-то начинает плавиться.

У меня не начинает.

Моя крыша натренирована использованием и анализом исходников библиотек из boost. imho после этого расплавить крышу практически ничем невозможно. Разве что прологом, хаскелом, Curry(пролог+хаскел) и им подобным вещам, но с ними, как и с лиспом, я познакомился несколько раньше чем с boost(хотя в хаскел я сильно не углублялся, испугался потенциальной возможности расплавить крышу окончательно). И это знакомство кстати значительно облегчило понимание метапрограммирования на шаблонах.

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

Дело в том, что макросы Nemerle спроектированы совершенно иначе и для других задач, и им нет абсолютно никаких аналогов в C++.

А ведь на нем пишут и будут писать еще очень долго. Да и boost в своих разработках используют очень многие C++ программисты и компании. Я удивляюсь — почему же C++ + boost еще не убил например Adobe? Ведь если верить здешним товарищам-провидцам, отметившимся в этой теме, у него есть для этого все возможности и основания. Возможности Nemerle по усложнению кода ничто по сравнению с бустом и C++. Особенно это касается метакода. Именно метакод на Nemerle гораздо проще, читабельнее и компактнее.

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

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

Сделать на базе Nemerle совершенно другой язык невозможно. Единственное что можно — встроить в него другой язык, и то точка встраивания будет обладать уникальнами свойствами и будет хорошо различима. Можно например представить себе такую ситуацию — некий идиотъ непонятно зачем решил встроить в Nemerle Lisp, посмотрев на intelib.org. Так как он идиот, то делает это так:

macro lisp(code : Token) syntax("l", code)
{
 // .. bla-bla-bla
}

В итоге идиот теперь может писать так:

module M
{
  Main() : void
  {
    // такой макрос можно использовать только в контексте выражений
    l (defun hello-world () (System.Console.WriteLine "ain't me an idiot?"));
    hello_world();
  }
}

Одна только проблема — идиотизм этого товарища сразу же станет очевиден. Во-первых dsl в виде лиспа в Nemerle совершенно не нужен и не к месту. Во-вторых все идентификаторы с имененм l тут же станут невалидными. При встрече с ними компилятор будет сообщать недовольным коллегам идиота о существующем макросе, который ввел это ключевое слово.

Кстати, встретив в коде такую конструкцию любой человек, хотя бы слегка знающий Nemerle, поймет что где-то есть макрос, определяющий ключевое слово l и просто поищет по файлам проекта строку "l". Я уже не говорю о том, что макрос не может просто затесаться в проект где-то в прикладном коде. Макросы компилируются всегда отдельно, в отдельную сборку, не содержащую прикладного кода и подключаются как обычные сборки. Подключение некой левой сборки с макросами не может пройти незамеченным при более-менее вменяемой организации процесса разработки. В конце концов сторонние макросы(т.е. не стандартные) можно вообще запретить ключом компилятора.

Gaperton здесь абсолютно не прав. Питоновский синтаксис и list comprehensions в Nemerle невозможно было добавить помощью макросов(питоновский синтаксис абсолютно невозможно, а list comprehensions невозможно в том виде, в котором они присутствуют в Nemerle), не говоря уже о "том, что в других языках увидели". Для list-comprehensions действительно использованы макросы, но лишь как инструмент для кодогенерации(так как это просто удобнее писать и отлаживать, чем при непосредственном внедрении в компилятор), их синтаксис же жестко вшит в компилятор,и никакими макросами меняющими синтаксис там не пахнет.

Я вообще не понимаю эту тенденцию демонизации Nemerle. Абсолютно без всякого знания предмета осуждения, высказываются мысли о тех или иных фатальных недостатках Nemerle, и идея о необходимости или неизбежности смерти Nemerle. Честное слово мне это напоминают инквизицию. Собралась некая группа инквизиторов и клянут на чем свет стоит некую ужасающую "ересь Nemerle". Особенно отличился в этом Гапертон, высказавший мысль, что увлечение Nemerle это симптом некой болезни и что людей с любым упоминанием Nemerle в резюме не стоит брать на работу.Такие заявления по-моему это элементарное неуважение к участникам форума.

Видимо в Microsoft не знали о том, какую страшную ересь они спонсируют в лице проекта Nemerle. А совет Гапертона очень бы пригодился Microsoft Research, когда они принимали решение взять на стажировку главного разработчика Nemerle(в качестве PhD-студента).

По-моему именно подобные инквизиторы и иные беспросветные ретрограды, которых в обилии можно встретить в том числе на rsdn и есть главное препятствие для Nemerle. Извините, но вы просто реально достали. Именно вы и подобные вам являятесь главной и единственной угрозой будущему Nemerle. Просто поразительно насколько глубокое неприятие вызывает он у некоторых товарищей. Не нравится Nemerle — отойдите в сторону и не мешай развиваться ему и заинтересованной в нем прослойке программистов. Ваши пророчества и размышления на тему Nemerle никому не нужны. Удовлетворяйте нужду собственного самоутверждения в другом месте и по другому поводу.

Если Nemerle не приобретет популярность, то на его месте просто будет другой похожий язык. Microsoft и Sun в очередной раз навяжут свое развитие темы современных императивных языков, на этот раз с элементами ФЯ и расширяемости. А ведь Nemerle мог бы быть прекрасной и гораздо более лучшей альтернативой C# N.0.

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

L>>Посмотрите на lisp, проще не придумашь при всем желании, только вот когда читаешь какую-нить книжку по нему, крыша почему-то начинает плавиться.

VK>У меня не начинает.

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

Хочется продолжения банкета?

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

VK>Не может. Во-первых в Nemerle нельзя изменить синтаксис, только дополнить. Во-вторых относительно большие возможности дополнения синтаксиса есть только на уровне выражений. И то необходимо ввести некий уникальный идентификатор с которого начинается макрос. А top-level синтаксис ты вообще сильно не расширишь, сколько не старайся.

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

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

E>Но я думаю, что Nemerle делает очень простым написание сложных (в смысле запутанных, сложных для сопровождения) программ.

E>Я думаю, что если что-то может быть понято или использовано неправильно, то оно обязательно будет понято и использовано неправильно. Успех Java показывает, что подавляющему большинству разработчиков, не желающих вникать в тонкости языка и правильных способов его использования, нужно что-то, максимально усложняющее отстреливание ног разработчиков. Но при этом дающее некоторые преимущества в простоте реализации каких-то часто встречающихся задач.

Такое мнение существует, но я считаю его не верным. Расширение языка макросами не позиционируется как средство решения рядовых проблем и предназначены преимущественно для разработчиков библиотек, использeющих кодогенерацию. Таких как IT.
Рядовой программист столкнется с достаточно высоким порогом вхождения, когда станет пробовать макрорасширения, кроме того такие поытки можно и следует пресечь техническими средствами.
Без использования макросов язык предоставляет даже меньше возможностей отстрелить себе ногу, чем C#.
Что касается запутанных программ, то написать их также легко и на Java, что многие постоянно демонстрируют.
В то же время, на Nemerle, как мне кажется, гораздо легче написать НЕ запутанную программу, чем на Java. Но это только мое мнение.

E>У Nemerle очень сильный упор делается в метапрограммирование.

Это заблуждение. Для решения подавляющего большинства задач метапрограммирования не требуется.

E>Даже многие фичи языка реализованы через макросы.

Для программиста это не имеет никакого значения.

E>Наверное для разработчиков языка и компилятора это выглядит очень здорово.

Да.

E>Так же могут думать и некоторые разработчики библиотек, которым нужна compile-time генерация кода.

Скорее всего.

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

Я так не думаю. Пуристы делают подчеркнуто симплистичные языки вроде Java и Oberon — такие вещи они считают злом.
Что касается исследователей языков, то для них это давно пройденый этап.

E>Но что получает тот, кому не нужно делать свой компилятор, кому не нужно разрабатывать фреймворки с кодогенерацией, которому по барабану, насколько маленький код самого компилятора? Сборную солянку из императивных, функциональных и объектно-ориентированных возможностей,

Мультипарадигменный язык. Как C++, C#, Python, Ruby etc. Как или лучше, в основном. Хотя это тоже дело вкуса.

E>да еще и с супер-мета-программированием в придачу.

Чем это хуже возможностей метапрограммирования, но не супер?

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

Вы правы на все 100%. Но разве есть язык, при программировании на котором учиться и учиться не надо?

E>Безусловно, кто-то будет этому рад и сможет использовать все возможности Nemerle в полном объеме без ущерба для себя и своих проектов. Так было с Lisp-ом, со Smalltalk-ом, так есть с C++. Я думаю, что так будет с Nemerle. Но может быть здесь так же сработает закон потребления пива и 80% возможностей Nemerle потребуется всего лишь 20% его аудитории. А оставшимся 80% пользователей нужны будут всего лишь 20%, как то вывод типов и локальные функции (для уменьшения объема кодирования в обычных условиях).

Вернее всего так и есть.

E>Но ведь есть еще 80% неиспользованных возможностей -- их обязательно нужно будет как-то использовать. И может быть кто-то сможет объяснить, какие факторы не позволят функциональность Nemerle употребить во вред?

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

E>Есть такой феномен: популярность получают языки, которые создаются для работы, для удовлетворения своих собственных сиюминутных нужд. C, C++, Perl, Python, Ruby, Java (наверное и C# сюда же попадает). Как только к языку прикладывается какая-то наука (Pascal, Oberon) или комитет (Ada), как все сразу портится.

Мне кажется это упрощенная трактовка фактов. Язык, к которому вообще не прикладывалась наука вообразить довольно сложно. Вы, возможно, имели в виду академические языки? По моему, академические языки Вами небыли названы. Это prolog или haskell. Для академического языка задается строгий формализм. Pascal — это средство популяризации структурного программирования. Oberon -очередной манифест пуризма. К науке они имеют точно такое же отношение как Java или C#, но, наверное, несколько большее, чем Perl.
И насчет языков Ада. Я сильно сомневаюсь, что на Ada пишут меньше, чем на Ruby.

E>Чем это объясняется я не знаю, но факты упрямая вещь.

Факты — упрямая вещь. Вот только куда девать эти гекатомбы наколеночных языков? Я говорю о том, что невозможно предсказать, какой из языков сделанных на коленке станет популярным. А большинство именно такие. Nemerle в том числе, кстати. Ни на академический, ни на комитетский этот язык совершенно не похож.

K>>Чем руководствуются создатели Оберона мне совершенно не понятно. Тоесть я догадываюсь, что они ориентируются на пуристов, но и с этим мне не все ясно.

E>У меня такое же впечатление. Они занимаются исследованиями.

Все исследования в этой области относятся к 60-м годам. Oberon это не научное явление, а целиком и полностью инженерное. У меня впечатление, что это неудачная попытка сделать язык простой как две копейки. Ну а java — удачная. Смысла в этом немного, по моему. Все равно сложность языка обычно теряется например даже рядом со сложностью платформы.

E>Про то, что создатели Nemerle выставляю себя умниками я и не утверждал. Мое мнение в том, что они делают язык для людей своего уровня. А таких немного по определению.

А что, те, кто делают языки "для работы, для удовлетворения своих собственных сиюминутных нужд", рассчитывают на людей не своего уровня? Как то это все противоречиво.

Я вообще сам считаю, что nemerle с макросами это мощьная, сложная и достаточно опасная штука. Но написание макросов Nemerle это уже первый дан и выше. Почти у каждого языка есть опасный более высокий уровень сложности.
Nemerle только с теми макросами, что входят в стандартную библиотеку — довольно безобидная штука, но при этом весьма выразительная.
Кроме того, слухи о мощи макросов Nemerle обычно сильно преувеличены и превратились в какие-то истории ужасов.
Синтаксис на отступах к ним отношения не имеет. list comprehension и такие вот строки $"" — частично реализуются макросом, а частично компилятором. Никаких сокрушительных изменений в синтаксисе на них, пожалуй, не сделать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Guess what? Эрланг разрабатывался целиком из этих соображений. Это заказ индустрии. Задача Ericcon CS Lab была поставлена так — разработать язык, в которым будут невозможны классы ошибок, наиболее распространенные по статистике телекомовского софта, разработанного в Эрикссон. Т.е. постановка была такая — чтоб ноги было отстрелить сложно или невозможно. В результате, в языке отсутствуют потенциально опасные конструкции или конструкции с малопредсказуемым временем работы.

G>Язык Ада разрабатывалась из немного других соображений — словить на этапе компиляции как можно больше ошибок, надавать программеру по рукам, не пропустить ничего, штоб враг не прошел.

В том то и дело, что в Ada в некоторых случаях нельзя, но если очень хочется, то можно. А потом Ариан 5 падает. Так что такое нельзя не считается.
Да и вообще, есть мнение, что столько ошибок на этапе компиляции сколько Haskell ни один другой язык не обнаружит. И что, Haskell при этом немощный и ограниченный? Вам виднее, конечно.

G>А из каких соображений разрабатывался Немерле? Интересы какой группы людей были учтены при его разработке? Сдается мне — интерес инженера, который хочет хрень написать позаковыристее, штоб круто было.

Такие инженеры для себя языков уже сами понаписали. К дикому восторгу множества других инженеров. Конкретных имен я называть не буду, а то сочувствующие придут сюда и тема провалится прямо в адъ.
Учитывая, что на этих языках каждый второй программирует и ориентируясь на Ваши предположения о фокус группе (или как там ее?), то Nemerle примут в мэйнстрим на 1-2-3, надо только инженеров в известность поставить, ознакомить с перспективами, которые теперь открываются для их таланта. Но вообще врятли.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Остановить бардак в таком случае способно только введение открытого стандарта на язык и библиотеку, как это произошло с Лиспом. Только вряд-ли это случится.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Epigram и Cayenne обнаружат. Но это совсем академические языки.

Но вобще конечно Haskell — пример почти максимально того, что может статический язык без макросов.

if/while/for/foreach/and/or и прочие такие конструкции в нем делаются без макро-средств.
Но в некоторых случаях удобство Template Haskell и подобных средств невозможно переоценить.
Правда рядовому кодеру конечно Template Haskell не нужен совсем — просто не должно быть под него задач.

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

E>Ой ли? Имхо, она говорит, что "Ребята, вокруг много людей, которые совсем не такие умные как вы. Если вы хотите, чтобы Nemerle пошел дальше, чем научная работа и не повторил судьбу Oberon-ов, Modul-ов и пр., то будьте проще и люди к вам потянуться".

Дык, дело в том, что Немерле отнють не путитанский язык вроде Оберона и у него нет элитарных замашек которые явно просматриваются у Хаскелей и Лиспов. Базовая часть языка проста и очень логична. Зная C# можно легко и бытро освоить Немерле. Более того практически уверен, что с нуля изучить Немерле будет даже проще чем Шарп. Ведь язык лучше преспособлен для изучения. Его легко можно изучать в ограниченном режиме. Тонкости вроде чудес паттерн-матчинга или макросов можно иузучать по ходу дела. А на первых порах можно обходиться и без них.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Нет, я так не считаю. Но я думаю, что Nemerle делает очень простым написание сложных (в смысле запутанных, сложных для сопровождения) программ. Но об этом здесь, помнится, Gaperton уже говорил.

Поздравляю вас с Гапертоном с вступлением в редя поклонников Оберона. Ведь Оберон пожалуй единственный язык который имеет минимум средств для написания запутанных программ.

И как вы оба умудрялись столько лет программированть на С++ — непревзойденном в плане запутывания языке.

E>Я думаю, что если что-то может быть понято или использовано неправильно, то оно обязательно будет понято и использовано неправильно.

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

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

Ява отнюдь не примитивный язык. Ява 1.5 вообще-то еще тот монстрик. Вложенные классы с замыканиями, безымянные классы, дженерики, сахар вроде foreach... Вот Оберон другое дело. Вот в нем почти ничего нет. Даже ООП по сути представлен паттернами, а не поддерживается языком напрямую. О замыканиях вообще и говорить не приходится. Вот только популярны стали Ява и Шарп, в коих "запутывающего" куда больше.

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

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

E>У Nemerle очень сильный упор делается в метапрограммирование.

Это, кстати, не так. Упров в нем нет. В нем просто гормонично развиты несколько парадигм, в том числе и метапрограммирование. Я сейчас работаю над интеграцией Немерла с VS 2005 и пока что мне не понадобилось написать ни одного макроса.

E> Даже многие фичи языка реализованы через макросы.

Да, именно так. Только не надо записывать это в минус языку. Язык от этого ни сколичко не страдает. Более того он от этого только выигрывает. Если в обычных услвоиях введение фичи в язык требует годов, то при наличии таких макросов как в Немерле фичу можно реализовать и опробировать в течении недели-другой. Более того фича не навязыается окружающим.

E> Наверное для разработчиков языка и компилятора это выглядит очень здорово. Так же могут думать и некоторые разработчики библиотек, которым нужна compile-time генерация кода. Ну и разных пуристов и исследователей языков в эту же группу можно добавить.

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

Простой пример (чтобы не быть голословным). Оператор foreach в Немерле несомненно позаимтвован из C# (и опосредовано из Питона). Однако гибкость макросов позволила со временем расширить функциональность foreach сделав его в разы мощьнее. Так foreach в руби позволяет осуществлять сопоставление с образцом и даже вводить допольнительные проверки для элемента перебераемой последовательности.

// простой вариант, но уже удобне чем в C# за счет отсуствия
// необходимости указывать тип элемента.
foreach (x in collection) 
    WriteLine(x);

// Сопоставление с образцом позволяюще отфильтровать из
// последовательности все элементы реализующие интерфейс ISomeInterface
foreach (x is ISomeInterface in collection) 
    WriteLine(x);

// В общем-то тоже сопоставление с образцом, но вырожденный случай.
// Его можно воспринимать как просто красивю синтаксическую находку - 
// встравание проверки прямо в тело цикла. Экономится строчка без 
// малейшей потери читаемости.
foreach (x when x != null in collection) 
    WriteLine(x);

// Сложный вариант сопоставления с образцом с использованием вариантов
foreach (SomeVariant.Value1(name, AnotherVariant.Some1(size)) as x in collection) 
    WriteLine($"x containes name=$name size=$size");

// Вариант сопоставления с образцом со множеством образцов.
foreach (x in collection) 
{
    | SomeVariant.Value1("SomeName", AnotherVariant.Some2(weight)) as x =>
        WriteLine($"x containes name="SomeName" weight=$weight");
        
    | SomeVariant.Value1(name, AnotherVariant.Some1(size)) as x =>
        WriteLine($"x containes name=$name size=$size");
    | => ()
}

Удобно это? Несомннено! Понятно ли это? По-моему очень даже понятно!
Полезно ли это пользователям языка? Никаких сомнений! И все это мы имеем именно потому, что сам язык является "конструктром Лего" и авторы языка могут осуществлять задуманное значительно быстрее и проще.

E>Но что получает тот, кому не нужно делать свой компилятор, кому не нужно разрабатывать фреймворки с кодогенерацией, которому по барабану, насколько маленький код самого компилятора?

Он получает мощьный и удобный язык. И это очень не мало!

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

Конечно можно подходить и с этой стороны. Тогда правда все языки которые ты лично исползуешь (С++ и Руби) являются классическими представителями таких сборных солянок. Так что тебя это так возмущает в Немерле и совем не трогает в С++ и Руби?

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

С тем же упехом вместо эпитетов "сброная солянка" можно исползовать "поддержка современных парадигм программирования" и картина из мрачной и угрюмой сразу превращается в красочную и веселую.

Ну, что скажите мне на милость, плохого в том, что я могу выбрать наиболее подходящий стиль для той или иной задачи. Задача хорошо решается методами ООП? Отлично! У нас есть классы, интерфейсы, наследование и инкапсуляция. Задачу тяготеет к обработке иерархий или списков? Тогдща в нашем распоряжении варианты и паттерн-матчинг. Задача требует кучи монотонной тупой ручной работы? Метапрограммирование в нашем распоряжении.

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

Вот тут не могу не согласиться. Но это ведь общее требование. Хороший код писать всегда сложнее чем плохой. Хороший программист учился, учится и будет учиться в будущем.

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

Научитсья читать паттерн-матчинг в варианте Немерла для программиста занкомого с C++ или C# доволько просто. Так что проблем в восприятии не возникает. Писать грамотный паттер-матчинг сложнее, ведь это по началу и не требуется! Мы же ведь можем использовать Немерле как C#. Потом мы осваиваемся и потихоничку переходим к использованию новых (неизвестных нам, императивным программистам, ранее) возможностей.

E>Безусловно, кто-то будет этому рад и сможет использовать все возможности Nemerle в полном объеме без ущерба для себя и своих проектов.

+1

E> Так было с Lisp-ом, со Smalltalk-ом, так есть с C++.

Я понимаю желание поставить Немерле в этот, в общем-то достойный список, но все же не вполне с ним согласен.

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

С++ в из этого ряда явно вырывается. Он довольно ординарен в плане восприятия. Но у С++ другая беда. При общей синтаксической дистрофии язык просто напичкан граблями, недоработками и прощетами. Язвк "поймал струю" в том плане, что то дал людям то, что было востребовано в те времена. Но время идет и потребоности возрастают, и С++ попросту перестал их удовлетворять.

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

E> Я думаю, что так будет с Nemerle. Но может быть здесь так же сработает закон потребления пива и 80% возможностей Nemerle потребуется всего лишь 20% его аудитории. А оставшимся 80% пользователей нужны будут всего лишь 20%, как то вывод типов и локальные функции (для уменьшения объема кодирования в обычных условиях). Но ведь есть еще 80% неиспользованных возможностей -- их обязательно нужно будет как-то использовать. И может быть кто-то сможет объяснить, какие факторы не позволят функциональность Nemerle употребить во вред?

На этот вопрос отвечали уже сто раз. Не позволят следующие вакторы:
1. Безопасность зяка.
2. Относительная сложность создания макросов.
3. Необходимость создани отдельного проекта для макосов.

Хотя конечно с дуру сам знашь что можно. Вот например катаясь на парашюте за моторной лодкой на пляже можно конечно развязать крепления и грохнуться с 70 метров в воду (что почти 100% смерть). Но вряд ли кто-то решится на такое. Вот если бы крепления были хлипкие и люди вылетали из парашюта непроизвольно, то смертей было бы море. Но тогда атракцион скорее всего закрыли бы.

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

K>>Вы считаете, что Oberon не получил распространение тоже потому, что он для сильно умных?

E>Нет. Есть такой феномен: популярность получают языки, которые создаются для работы, для удовлетворения своих собственных сиюминутных нужд. C, C++, Perl, Python, Ruby, Java (наверное и C# сюда же попадает). Как только к языку прикладывается какая-то наука (Pascal, Oberon) или комитет (Ada), как все сразу портится.

Ну, вторую версию (ту что вошла в стандарт) С++ как раз разрабатывал комит. Да и Паскаль сыскал невероятную популярность в свое время. Так что ты лукавишь.

Но главное заключается в том, что ты уходишь от смысла вопроса. Смысл этого вопроса я вижу в том, что Оберон как раз замечательно удовлетворяет вашему с Гапертоном мнению о том, что в языке не должно быть ничего что может быть неоднозначно истолковано и что может запутать код. Оберон прост как три копейки. Напротив C++, Perl, Python, Ruby, Java и C# (без каких бы то нибыло наверное) как раз не удовлетворяют вашим критериям. И они как не странно популярны. Причем до сих пор популярность С++ очень высока, а уж этот язык точно обладает массой средств запутывания не говоря уже об откровенных граблях и просчетах.

E>Чем это объясняется я не знаю, но факты упрямая вещь.

За-то я заню. И Klapaucius видимо тоже. От того задал тебе вопрос с подтекстом. Жаль что ты этот подтекст упорно не хочешь замечать.

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

E>Про то, что создатели Nemerle выставляю себя умниками я и не утверждал. Мое мнение в том, что они делают язык для людей своего уровня. А таких немного по определению.

Они неплохо программируют на МЛ. Так что язык подходящий им уже был. Просто они увидили реальные потребности программистов (по крайней мере немалой их части) и попытались сделать язык так как они это видят. Мне кажется у них получилась очень неплохая работа.

... << RSDN@Home 1.2.0 alpha rev. 637>>

От:	eao197	http://eao197.blogspot.com
Дата:	11.08.06 06:38
Оценка:	+1 -1

	От:	Klapaucius
	Дата:	11.08.06 07:44
	Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	11.08.06 08:40
Оценка:	17 (3) +2 -1

	От:	Lloyd
	Дата:	11.08.06 08:59
	Оценка:	+2

От:	Gaperton	http://gaperton.livejournal.com
Дата:	11.08.06 09:30
Оценка:	+1 -1

	От:	Vermicious Knid
	Дата:	11.08.06 16:45
	Оценка:	74 (4) +4 -1

	От:	граммофон
	Дата:	11.08.06 22:24
	Оценка:	1 (1) +2

От:	VladD2	www.nemerle.org
Дата:	12.08.06 16:19
Оценка: