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

E>А опровергнуть это мнение можно только фактами. Которые пока можно найти только в исходниках компилятора Nemerle. Вообще интересный критерий -- пример использования языка искать в компиляторе языка.

Опровергать твое мнение смысла нет. Оно высасано из пальца.

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

ЗЫ

C++ и на сегодня (не смотря на сдачу позиций) второй язык в мэйнстриме. Такая элитарность называется полным успехом которому могут позавидовать любые разработчики языков.

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

E>Так что ты можешь продолжать считать, что я не вижу достоинств в Nemerle, но дело в другом. Хотелось бы увидеть, насколько безопасно закладываться на Nemerle в долгосрочной перспективе. И здесь, представь себе, есть подозрения, что достоинства Nemerle, которые ты с сотоварищи здесь рекламируете, будут со временем становится недостатками. По той простой причине, что требуют для своего успешного применения высокой квалификации. Может быть поэтому интерес к Nemerle проявляют люди и Top-а RSDN-а (им ведь по барабану, какой язык осваивать и на чем писать). Так что я думаю, у Nemerle есть хорошие шансы стать мощным и сложным инструментом (что-то вроде C++), для небольших высококвалифицированных команд.

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

Чем это может быть чревато? Возьмем стабильный (казалось бы) SML/NJ. На нем написан замечательный пакет — NJ Machine Code Toolkit, предназначенный для быстрого создания эмуляторов процессоров. По декларативному описанию системы команд он генерирует декодер (принцип очень похож на yacc), и ассемблер (в смысле, транслятор с ассемблера).

Проблема в том, что NJ Machine Code Toolkit не собирается на современной версии SML/NJ, вызывая местами очень невнятные ошибки компиляции. Нашей группой был потрачен примерно 1 человекомесяц, на то, чтобы сделать его работоспособным. При этом, писали его те же люди, что делали SML/NJ. Причина — та же, читайте первое предложение в ответе. Хотите, чтобы это однажды произошло с вашим кодом?

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

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

Дело то все в том, что простота простоте — рознь. Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста. Простым для человека язык делает сахар. Вот тот же Хаскель нормально читается только потому, что поверх голой комбинаторной логики там сахар, а без него туча дурацких слешей и стрелочек. Ничерта не читается. Но формально — все просто и понятно. Вот в этом и разница.
А теперь вернемся к программисту, который открывает исходный текст на Лисп. Что он там видит? Да что-то вроде сериализованного в строку нетипизированного AST. Программист не думает категориями AST. Если это, конечно, не лисп-программист.

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

"Говорят в Москве кур доят, так что я молоко не буду пить — потому, что птичий грипп" (с).

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

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

Это я прекрасно понимаю (поэтому, например, до сих пор не использую D, т.к. пока нет стабильной версии 1.0 и язык претерпевает постоянные изменения). Я имел в виду момент, когда Nemerle стабилизируется (если он наступит, момент этот).

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

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

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

DG>p.s. Ваш минус в предыдушем посте говорит о том, что вы не желаете/не готовы сравнивать языки по набору _объективных_ критериев, так?
DG>Я понимаю конечно, что выбрав такой набор и сравнив раз и на всегда/выслушав доводы всех заинтересованных, этот раздел форума можно было бы закрывать

DG>На мой взгял, крайне разумным видится оперирование _объективными_ метриками, а не субъективными домыслами взятыми черт знает из какого контекста/измерения, да еще иррациональные.

Угумс. Объективные метрики. Как напишете на N что-нибудь больше 100К строк группой человек не меньше 5, и оно в production уйдет, скажете что-нибудь объективное, ладно? Метрики посравниваем. Или вы не хотите сравнивать языки _объективными_ метриками? Потом интересно будет посмотреть на среднее время исправления дефекта годика через 3 непрерывного maintenance, когда у вас хотя бы 1 ключевой разработчик уйдет. А также на балланс вносимых/исправляемых ошибок. А пока можно что угодно говорить. Не понятно только, зачем.

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

VD>>>>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.
<>
E>Так что мимо кассы. Подобная проблема будет существовать только, если var имеет тип boolean.

И во всех тех случаях, когда тип неявно приводится к boolean. В С++ это все интегральные типы, а также классы с операторами приведения к интегральным типам.
Если в Яве приведение к boolean может быть только явным — ну что ж, это замечательно.

E>Я хочу сказать, что во многих случаях придется писать ignore. Например, когда объект возвращает ссылку на самого себя для того, чтобы можно было выстраивать цепочку действий. Вот аналоги из C++:
E>

E>std::cout << "total time: " << (start - finish) << " msec" << std::endl;

E>Md5_Hash hash;
E>hash.put( "Message: " ).put( message_id ).put( ", content length: " ).put( content_length );
E>

E>Программист вынужден будет в этих случаях писать ignore. Геморрой на ровном месте.

Во-первых.

Язык С++ унаследовал от С унификацию функций и процедур (функций, возвращающих void), и это является его фундаментальной фичей.
Кстати, иногда довольно неудобно сделанной (шаблоны прокси-функций должны быть заточены отдельно под void(*)(...) и под T(*)(...)).

Естественно, что раз это фича, то ею пользуются. Мотив: "к-сть — с-а т."
В фортране, бейсике (включая vb до vb.net) и паскале (до turbo 6) такие вольности не проходят — и ничего. Тамошняя фича преследует другую задачу — как и в N, контроль за радиусом кривизны рук.

Будет ли много заморочек с написанием заглушек, если Комитет Стандартизации С++ примет эпохальное решение?

cout << a << b << c << _;  // по-конвеерному; сравните с командной строкой del /s *.* > nul
_ = cout << a << b << c;   // по-немерлевски
call(cout << a << b << c); // по-фортрановски

Наверное, нет. Раз уж всё равно ломаем совместимость, то писанина так или иначе будет. И, в общем-то, её будет немного и на читаемость она не сильно повлияет.


Кстати говоря. Хаскелл, в котором побочные эффекты протаскиваются через монады, подчёркивает синтаксисом смысловое различие обычных функций и монадных функций, возвращающих хоть что-то и чисто побочных:
— операторы >> и >>= для построения конвееров,
— dst=fun...; dst<-fun...; fun...; в do-нотации.
И это только привносит ясность, а не оверхедит.


Во-вторых.

Новый язык — новый синтаксис, новые стандарты кодирования.
Ведь не стоит же задача сопровождать сишный код, правда?
Конечно, тут надо выбирать: или мы делаем максимум совместимости и удобства работы с legacy библиотеками (функции которых зачастую возвращают неиспользуемые значения — например, коды ошибок), или пишем библиотеки в соответствие с новой генеральной линией партии. Там, где надо смириться со старым кодом — смиряемся, написав _=... (оверхед минимальный).

E>>>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?
VD>>Это к граблям не приводит.
E>Да уж. Потерянные исключения -- это не грабли.

Как я понимаю, (поправьте, если заблуждаюсь — я не знаток явы), все супер-пупер спецификации вызываемых функций покрываются спецификацией throws Exception у вызывающей функции — поскольку все исключения унаследованы от него.
То есть, на самом деле, функции можно классифицировать как
— в принципе бросающие исключения
— никогда не бросающие
Ценность от такой классификации минимальна: разве что подсказка оптимизатору.

E>Итого получается: реально исправленные проблемы с ==/equals, гипотетическое преимущество в switch/case и такое же гипотетическое преимущество (ли?) по поводу возвращаемого значения. И минус спецификация исключений. Не густо для языка, появившегося на 10 лет позже Java.

Звучит предвзято Синтаксис switch — ублюдочное наследие K&R C — давно пора было устранить. (естественно, это моё ИМХО; наверняка, есть мастера трюкачества со свитчами, которые не променяют его ни на что другое; ну так и goto из той же оперы).

Было бы интересно услышать другое: "вот перечень вещей, которые реально напрягают в Яве, и тудыть-растудыть почему этого не сделали в Немерле?"
Тогда диалог был бы продуктивнее

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

К>Если в Яве приведение к boolean может быть только явным — ну что ж, это замечательно.

А это так и есть.

К>Будет ли много заморочек с написанием заглушек, если Комитет Стандартизации С++ примет эпохальное решение?
К>

К>cout << a << b << c << _;  // по-конвеерному; сравните с командной строкой del /s *.* > nul
К>_ = cout << a << b << c;   // по-немерлевски
К>call(cout << a << b << c); // по-фортрановски
К>

К>Наверное, нет. Раз уж всё равно ломаем совместимость, то писанина так или иначе будет. И, в общем-то, её будет немного и на читаемость она не сильно повлияет.

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

//FIXME: это значение нужно будет сохранить и использовать затем где-то там...
_ = Md5Hash.new.put( something )

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

Не буду утверждать, что это бесполезная фича. Просто ценность ее сомнительна, т.к. по опыту Pascal, C++, Java, Ruby я не помню проблем с потерянными возвращаемыми значениями. Тем более проблем безопасности (мы же здесь про безопасность говорили).

E>>>>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?
VD>>>Это к граблям не приводит.
E>>Да уж. Потерянные исключения -- это не грабли.

К>Как я понимаю, (поправьте, если заблуждаюсь — я не знаток явы), все супер-пупер спецификации вызываемых функций покрываются спецификацией throws Exception у вызывающей функции — поскольку все исключения унаследованы от него.
К>То есть, на самом деле, функции можно классифицировать как
К>- в принципе бросающие исключения
К>- никогда не бросающие
К>Ценность от такой классификации минимальна: разве что подсказка оптимизатору.

У меня противоположное наблюдение. В C++, где инструкции throws даже не проверяются во время компиляции потерять из виду функцию, порождающую исключение, и не поставить try/catch. Соответственно, в процессе работы получить аварийное завершение из-за неперехваченного исключения. Так что по Java-вским спецификациям исключений в C++ и Ruby я скучаю. Другое дело, что в Java очень легко вписать в throws такой список исключений, который вызовет проблемы при расширении и сопровождении. Но это уже другой вопрос. Главное, что throws заставляет разработчика заботится об исключениях, т.е. устраняют потенциальные дыры.

E>>Итого получается: реально исправленные проблемы с ==/equals, гипотетическое преимущество в switch/case и такое же гипотетическое преимущество (ли?) по поводу возвращаемого значения. И минус спецификация исключений. Не густо для языка, появившегося на 10 лет позже Java.

К>Звучит предвзято

Еще более предвзято это звучит после того, как я поговорил со своими коллегами, программирующими исключительно на Java. Они вообще не знают, что такое проблема ==/equals. По своему опыту она существует только в первую пору перехода на Java с C++ (ну или с Ruby).

К>Синтаксис switch — ублюдочное наследие K&R C — давно пора было устранить. (естественно, это моё ИМХО; наверняка, есть мастера трюкачества со свитчами, которые не променяют его ни на что другое; ну так и goto из той же оперы).

Да уж, похоже, что со switch связаны какие-то очень интимные воспоминания

К>Было бы интересно услышать другое: "вот перечень вещей, которые реально напрягают в Яве, и тудыть-растудыть почему этого не сделали в Немерле?"
К>Тогда диалог был бы продуктивнее

Диалог идет о другом. Тема звучит "Почему у Nemerle нет будущего". Я не согласен с автором первого сообщения. Будущее у Nemerle, имхо, есть. Да только совсем не такое радужное, как это рисуется некоторыми горячими головами. И если у кого-то есть желание продвинуть Nemerle в массы, то вместо коллективной медитации "Nemerle крут!" лучше было бы вести объективный разговор о проблемах, с которыми столкнуться программисты взявшись за Nemerle. Gaperton здесь их озвучивал -- обилие макросов, не стабильность языка, отсутствие стандартов.

Поэтому, имхо, те, кто хочет использовать Nemerle в работе (именно в ответственных коммерческих проектах), должно существовать четкое понимание, что ситуация с Nemerle может оказаться похожей на C++: сложность освоения всех тонкостей языка и страшилки вроде Boost-а, в которых только гуру смогут разбираться.

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

K>Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста.

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

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

K>Дело то все в том, что простота простоте — рознь. Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста. Простым для человека язык делает сахар.

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

(c)Klapaucius

K>>Дело то все в том, что простота простоте — рознь. Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста. Простым для человека язык делает сахар.

Т>

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

(c)Klapaucius

После Лиспа, Хаскеля и Эрланга практически любой код (кроме K и J, конечно ) читается легко Если он, конечно, не левой задней пяткой написан

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

K>>Дело то все в том, что простота простоте — рознь. Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста. Простым для человека язык делает сахар.

Т>

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

(c)Klapaucius

Это не так. Когда приходится по работе просматривать тысячи строк кода за день, становится ясно, что реально влияет на читабельность, а что — ерунда на самом деле. Ну вот, например, вот это

some_function( parm1, parm2 )
{
   code, code, code
}

хорошо, а вот это

some_function (parm1, parm2) {
   code code code
}

плохо. Фокус в том, что для распознавания образов (просто вычленить границы блоков и имена переменных из потока) в первом случае требуется чуть меньше мозговой энергии и концентрации внимания. Не все замечают этот "чуть", но после работы на maintenance в течении нескольких лет (когда приходится много разного кода смотреть) люди обычно это замечают.

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

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

G>Угумс. Объективные метрики. Как напишете на N что-нибудь больше 100К строк группой человек не меньше 5, и оно в production уйдет, скажете что-нибудь объективное, ладно? Метрики посравниваем. Или вы не хотите сравнивать языки _объективными_ метриками? Потом интересно будет посмотреть на среднее время исправления дефекта годика через 3 непрерывного maintenance, когда у вас хотя бы 1 ключевой разработчик уйдет. А также на балланс вносимых/исправляемых ошибок. А пока можно что угодно говорить.

Уже написали. Сам компилятор это не маленький проект живущий с 2005 года которым пользуется куча народа. Над ним сейчас работает человек 10. Покрайней мере 6 постоянно. И число только прибывает.

Баги фиксятся оперативно. Причем не только "основными разработчиками". Я лично не один бак пофиксил.

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

G>Не понятно только, зачем.

Ну, так вы с eao197 этим и занимаетесь. Цель вот только не понятна.

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

E>Однако не понятно, как такие ошибки влияют на безопасность?

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

E>Я хочу сказать, что во многих случаях придется писать ignore.

У тебя фобия за фобией. Ты пыташся усмотреть громадную проблему там где ее нет. Я вот поглядел на код интеграции Немерла со Студией над которым я сейчас тружусь и посчитал сколько в нем ignore-ов и "_ =". Оказалось 12 штук на 58 файлов (130 Kb). Не думаю, что кто-то так сильно пострадает от подобного "оверхэда". Зато все игнорирование значений описывается явно и программист читая код не пропустит его. Если это ошибка, то ее будет легко выявить.

E> Например, когда объект возвращает ссылку на самого себя для того, чтобы можно было выстраивать цепочку действий. Вот аналоги из C++:

E>

E>std::cout << "total time: " << (start - finish) << " msec" << std::endl;

E>Md5_Hash hash;
E>hash.put( "Message: " ).put( message_id ).put( ", content length: " ).put( content_length );
E>

E>Программист вынужден будет в этих случаях писать ignore. Геморрой на ровном месте.

Да это ужасный код стант просто в сто раз лучше если в начале строки написать:

hash = hash.put(...

или

_ = hash.put(...

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

В библиотеках дотнета не так много нужных классов чьи методы на право и на лево возвращали бы никчемные значения. Сразу в голову приходит только один StringBuilder. А ублюдочные переоеределения операторов сдвига для вода/вывода вообще не нужны. $"..." и sprintf в сто раз удобнее.

В общем, проблем это не вызвает, а от ошибок по невнимательности спасает.

VD>>Ошибка — эта очень частая.

E>May be. Тем не менее к безопасности это вряд ли имеет отношение.

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

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

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

Что за любовь спорить с очевидными вещами и выискивать проблемы там где их никогда не было?

Как говорится в рекламе какой-то колбасной фирмы "Пааапробуй!", а потом будешь рассуждать. А то очередной поток домыслов выслушивать очено не хочется.

E> С таким же успехом программист может поставить ignore там, где ему нужно было сохранить значение. Запись:
E>

E>ignore( str1.Replace( "some", "other" ) );
E>

E>остается синтаксически валидной, но вот смысла в ней совершенно нет.

Нда. Клинический случай. Ты сам то не понимашь, что вписывая ignore или "_ =" человек делает осознанный выбор? Да и читая код этого нельзя не заметить. А вот конструкция:

string str1 = "some";
str1.Replace("... some ...", "other");

выглядит на первый взгляд совершенно нрмально. И написать ее по незнанию или невнимательности совершенно элементарно.

E>Да уж. Потерянные исключения -- это не грабли.

Нет никаких потерянных исключений. У тебя очередные фобии. Иди обсуди этот вопрос в Философию. Мне он не интересен. Я исключения перехватываю 1-2 раза во всей программе и ошибок у меня с ними нет. Явские маньякальные идеи "невыпускать исключения из функции" мне кажутся тупиковым путем. Намного большей проблемой является игнорирование исключений:

try
{
    ...
}
catch { }

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

E>Итого получается: реально исправленные проблемы с ==/equals, гипотетическое преимущество в switch/case и такое же гипотетическое преимущество (ли?) по поводу возвращаемого значения. И минус спецификация исключений. Не густо для языка, появившегося на 10 лет позже Java.

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

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

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

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

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

K>В том то и дело, что в Ada в некоторых случаях нельзя, но если очень хочется, то можно. А потом Ариан 5 падает. Так что такое нельзя не считается.

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

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

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

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

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

Дык, а почему нет ? Мне уже стало интересно.

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

Да ладно "вряд-ли". Как только (и если) выйдет стандарт на Немерле и его станартную либу, можно будет запретить его макросы к употреблению коде стандартом, делая исключения для корпоративного фреймворка, к правке которого будут иметь допуск единицы. И вот тогда все мои возражения уйдут на второй план — чорный змий макросов будет постевлен под надежный контроль.

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

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

G>Фокус в том, что для распознавания образов (просто вычленить границы блоков и имена переменных из потока) в первом случае требуется чуть меньше мозговой энергии и концентрации внимания. Не все замечают этот "чуть", но после работы на maintenance в течении нескольких лет (когда приходится много разного кода смотреть) люди обычно это замечают.

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

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

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

E>//FIXME: это значение нужно будет сохранить и использовать затем где-то там...
E>_ = Md5Hash.new.put( something )
E>

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

Ты путатешь одну вещь. Одно дело не писать вообще, а другое "очень легко написать что-нибудь такое". Написав, ты сделал осознанное действие, не так ли?

E>Диалог идет о другом. Тема звучит "Почему у Nemerle нет будущего". Я не согласен с автором первого сообщения. Будущее у Nemerle, имхо, есть. Да только совсем не такое радужное, как это рисуется некоторыми горячими головами. И если у кого-то есть желание продвинуть Nemerle в массы, то вместо коллективной медитации "Nemerle крут!" лучше было бы вести объективный разговор о проблемах, с которыми столкнуться программисты взявшись за Nemerle.

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

E>Gaperton здесь их озвучивал -- обилие макросов, не стабильность языка, отсутствие стандартов.

Позиция Гапертона, предлагающего запретить ядерное оружие в виде макросов, безусловно выглядит благородно. Мы все его поддерживаем, дружно хлопаем в ладоши и скандируем — "СКАЖЕМ НЕТ ЯДЕРНОМУ БЕЗУМИЮ"!

Лично я за запрещение любого оружия массового поражения, к которому, например, относится visitor pattern. Никогда не видел его разрушительную силу в действии? А я видел. Врагу не пожелаю. Так что нам теперь запретить использование паттернов совсем? А ведь макросы как раз и есть ни что иное как реализации паттернов. Если процедура — это реализация алгоритма, используюшего из контекста вызова только передаваемые параметры, то макросы, использующие контекст вызова на 100% — это уже полноценная реализация паттернов. Т.е. библиотека макросов — это всего лишь навсего библиотека паттернов. То, чего нам всем на сегодняшний день так не хватает.

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

Что там у нас ещё было? Не стабильность языка и отсутствие стандартов?

С нестабильносью у нас всё хорошо. Язык пока находится в стадии разработки.

Что касается стандартов, то может ты мне покажешь стандарт на Руби, ПХП, Перл, Паскаль, Дельфи, Питон и прочие любымие тобой и другими программистами языки? Может мы вспомним стандарт C++ и востребованные жизнью расширения разработчиков компиляторов? Может стоит упомянуть, что комитет по стандартизации фактически загоняет своей стандартизацией C++ в могилу?

E>Поэтому, имхо, те, кто хочет использовать Nemerle в работе (именно в ответственных коммерческих проектах), должно существовать четкое понимание, что ситуация с Nemerle может оказаться похожей на C++: сложность освоения всех тонкостей языка и страшилки вроде Boost-а, в которых только гуру смогут разбираться.

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

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

IT>Ты путатешь одну вещь. Одно дело не писать вообще, а другое "очень легко написать что-нибудь такое". Написав, ты сделал осознанное действие, не так ли?

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

IT>Я бы даже сказал, что лучше не вести разговор aka трепаться, а реально что-то делать руками. Например, помочь немерлистам довести язык до релиза.

Так что вы здесь делаете? Вместо того, чтобы доказывать, что у Nemerle есть будущее взяли бы и сделали это будущее. Мне, например, хватает того, что есть в C++, Ruby, D, Java и Scala. Нафига еще один язык, лично мне не понятно. Может быть под .NET ничего более стоящего просто нет?

E>>Gaperton здесь их озвучивал -- обилие макросов, не стабильность языка, отсутствие стандартов.

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

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

IT>С нестабильносью у нас всё хорошо. Язык пока находится в стадии разработки.

IT>Что касается стандартов, то может ты мне покажешь стандарт на Руби, ПХП, Перл, Паскаль, Дельфи, Питон и прочие любымие тобой и другими программистами языки?

Да. Ruby: http://www.ruby-lang.org. Единая реализация Ruby для туевой хучи платформ и единая версия стандартной библиотеки.

E>>Поэтому, имхо, те, кто хочет использовать Nemerle в работе (именно в ответственных коммерческих проектах), должно существовать четкое понимание, что ситуация с Nemerle может оказаться похожей на C++: сложность освоения всех тонкостей языка и страшилки вроде Boost-а, в которых только гуру смогут разбираться.

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

С меня хватило чтения документации по Nemerle после появления супер-темы "Nemerle рулит!". Общее впечатление я получил, для более детального нужно программировать на Nemerle. А вот здесь не обесудьте, во-первых, сам язык, как говорится, не торкает. Все, что вы так цените в Nemerle у меня в распоряжении уже было два года назад -- Ruby. Во-вторых, .NET может быть для кого-то и есть вся вселенная, но это не мой случай. Так что я лучше потрачу это время на программирование на каком-нибудь кроссплатформенном языке (вроде C++, Ruby, Java или Scala). Ну и в-третьих, ваша оголтелая Nemerle-тусовка совсем отбила желание смотреть в сторону Nemerle, еще тогда, когда я пытался объяснить, что создание синтаксических макросов способно приводить к конфликтам (как раз в тот момент попытался примерить Nemerle к SObjectizer).

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

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

Влад тебе уже привёл пример из реального проекта — 12 случаев на больше чем 50 исходных файлов проекта.

E>Так что вы здесь делаете? Вместо того, чтобы доказывать, что у Nemerle есть будущее взяли бы и сделали это будущее.

А мы и делаем, ты за нас не переживай.

E>Мне, например, хватает того, что есть в C++, Ruby, D, Java и Scala. Нафига еще один язык, лично мне не понятно. Может быть под .NET ничего более стоящего просто нет?

Так и чего ты тут тогда трёпом занимаешься? Оставь нас убогих в покое. Или всё же дело не в N? Боюсь, что если бы Влад с таким же упорством продвигал Scala, то ты был не прочь заменить её на N. Правильно?

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

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

Господи, Чернобыль то тут причём. Ты в курсе почему рванул 4-й реактор? Тебе не известно, что он и не был никогда мирным атомом, а обыкновенной ядерной бомбой. Что в нём были допущены серьёзные технологические (читай дизайнерские, архитектурные) просчёты? Что в ночь взрыва над ним ставили эксперименты зелёные молодые специалисты вчерашние студенты?

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

IT>>Что касается стандартов, то может ты мне покажешь стандарт на Руби, ПХП, Перл, Паскаль, Дельфи, Питон и прочие любымие тобой и другими программистами языки?

E>Да. Ruby: http://www.ruby-lang.org. Единая реализация Ruby для туевой хучи платформ и единая версия стандартной библиотеки.

И всё, только на Руби?

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

E>С меня хватило чтения документации по Nemerle после появления супер-темы "Nemerle рулит!". Общее впечатление я получил, для более детального нужно программировать на Nemerle. А вот здесь не обесудьте, во-первых, сам язык, как говорится, не торкает.

Я посмотрел пару твоих примеров на Руби. Ну что тебе сказать? По-моему, г-но редкостное. Тормознутое в придачу. Использовать рубироид в коммерческих проектах я не рекомендую никому. Да и сам язык не торкает

E>Все, что вы так цените в Nemerle у меня в распоряжении уже было два года назад -- Ruby.

Да ты шо? И макросы были? А чего же ты их тут тогда зашёл попинать?

E>Во-вторых, .NET может быть для кого-то и есть вся вселенная, но это не мой случай. Так что я лучше потрачу это время на программирование на каком-нибудь кроссплатформенном языке (вроде C++, Ruby, Java или Scala).

Слушай, я тебя умоляю, иди и потрать, а? Ну пожалуйста!

E>Ну и в-третьих, ваша оголтелая Nemerle-тусовка совсем отбила желание смотреть в сторону Nemerle, еще тогда, когда я пытался объяснить, что создание синтаксических макросов способно приводить к конфликтам (как раз в тот момент попытался примерить Nemerle к SObjectizer).

Ну да. А потом мы удивляемся от чего взрываются Чернобыли.

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

IT>Влад тебе уже привёл пример из реального проекта — 12 случаев на больше чем 50 исходных файлов проекта.

Пример не видел
Ну и нафига делать фичу, которая используется в 12 случаев на 50 исходных файлов? И насколько критична она там вообще?

E>>Мне, например, хватает того, что есть в C++, Ruby, D, Java и Scala. Нафига еще один язык, лично мне не понятно. Может быть под .NET ничего более стоящего просто нет?

IT>Так и чего ты тут тогда трёпом занимаешься?

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

IT>Боюсь, что если бы Влад с таким же упорством продвигал Scala, то ты был не прочь заменить её на N. Правильно?

Если бы VladD2, то очень вероятно. Он умеет опошлять хорошие вещи.

IT>Господи, Чернобыль то тут причём.

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

IT>Ты в курсе почему рванул 4-й реактор?

А ты знаешь засекреченные подробности эксперимента, производившегося в ночь на 26-е апреля на этом энергоблоке?

IT>Тебе не известно, что он и не был никогда мирным атомом, а обыкновенной ядерной бомбой. Что в нём были допущены серьёзные технологические (читай дизайнерские, архитектурные) просчёты? Что в ночь взрыва над ним ставили эксперименты зелёные молодые специалисты вчерашние студенты?

А тебе известно, что Nemerle разрабатывают молодые специалисты и вчерашние студенты?

IT>>>Что касается стандартов, то может ты мне покажешь стандарт на Руби, ПХП, Перл, Паскаль, Дельфи, Питон и прочие любымие тобой и другими программистами языки?

E>>Да. Ruby: http://www.ruby-lang.org. Единая реализация Ruby для туевой хучи платформ и единая версия стандартной библиотеки.

IT>И всё, только на Руби?

Тоже самое ты можешь найти и для Перла и для Питона.

IT>Я посмотрел пару твоих примеров на Руби. Ну что тебе сказать? По-моему, г-но редкостное. Тормознутое в придачу. Использовать рубироид в коммерческих проектах я не рекомендую никому. Да и сам язык не торкает

То же самое я думаю про большинство увиденных примеров метапрограммирования и pattern-matching-а на Nemerle. Так что мы квиты.

E>>Все, что вы так цените в Nemerle у меня в распоряжении уже было два года назад -- Ruby.

IT>Да ты шо? И макросы были? А чего же ты их тут тогда зашёл попинать?

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

E>>Во-вторых, .NET может быть для кого-то и есть вся вселенная, но это не мой случай. Так что я лучше потрачу это время на программирование на каком-нибудь кроссплатформенном языке (вроде C++, Ruby, Java или Scala).

IT>Слушай, я тебя умоляю, иди и потрать, а? Ну пожалуйста!

Договорились.

E>>Ну и в-третьих, ваша оголтелая Nemerle-тусовка совсем отбила желание смотреть в сторону Nemerle, еще тогда, когда я пытался объяснить, что создание синтаксических макросов способно приводить к конфликтам (как раз в тот момент попытался примерить Nemerle к SObjectizer).

IT>Ну да. А потом мы удивляемся от чего взрываются Чернобыли.

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

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

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

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

IT>>Господи, Чернобыль то тут причём.

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

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

IT>>Ты в курсе почему рванул 4-й реактор?

E>А ты знаешь засекреченные подробности эксперимента, производившегося в ночь на 26-е апреля на этом энергоблоке?

А ты знаешь?

IT>>Тебе не известно, что он и не был никогда мирным атомом, а обыкновенной ядерной бомбой. Что в нём были допущены серьёзные технологические (читай дизайнерские, архитектурные) просчёты? Что в ночь взрыва над ним ставили эксперименты зелёные молодые специалисты вчерашние студенты?

E>А тебе известно, что Nemerle разрабатывают молодые специалисты и вчерашние студенты?

Не надо передёргивать. Они точно такие же студенты, каким в своё время был Страуструп, только получивший свой Ph.D. и начавший работать на C с классами. А у пульта управления реактора в ту ночь стояли необученные новички, которых допускать к экспериментам в тех условиях нельзя было по инструкции.

E>>>Да. Ruby: http://www.ruby-lang.org. Единая реализация Ruby для туевой хучи платформ и единая версия стандартной библиотеки.

IT>>И всё, только на Руби?

E>Тоже самое ты можешь найти и для Перла и для Питона.

Т.е. единая реализация. Оно конечно не стандарт совсем, но рубироиду с питоном можно, нельзя только Немерле и Владу

IT>>Я посмотрел пару твоих примеров на Руби. Ну что тебе сказать? По-моему, г-но редкостное. Тормознутое в придачу. Использовать рубироид в коммерческих проектах я не рекомендую никому. Да и сам язык не торкает

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

Я с тобой квитаться не собираюсь. Я не хожу по форумам и не кидаюсь какашками в кого ни поподя просто так ради спорта.

E>>>Все, что вы так цените в Nemerle у меня в распоряжении уже было два года назад -- Ruby.
IT>>Да ты шо? И макросы были? А чего же ты их тут тогда зашёл попинать?
E>А макросы в нормальном языке и не нужны. Так что попинать их не грех. Но я уже сказал, что хотел.

Т.е. макросов не было? Ты их никогда не использовал, но твоё мнение о них единственно верное.

E>>>Ну и в-третьих, ваша оголтелая Nemerle-тусовка совсем отбила желание смотреть в сторону Nemerle, еще тогда, когда я пытался объяснить, что создание синтаксических макросов способно приводить к конфликтам (как раз в тот момент попытался примерить Nemerle к SObjectizer).

IT>>Ну да. А потом мы удивляемся от чего взрываются Чернобыли.

E>Угу, они взрываются от того, что разработчики SQL враперов и текстовых редакторов считают, что они знают, как писать софт для атомных электростанций.

Разработчики SQL враперов и текстовых редакторов понятия не имеют как писать софт для атомных электростанций. А когда они о чём-то не имеют понятия, то не лезут к другим со своими советами, суждениями и козявками.