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

К>Если в Яве приведение к 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-а, в которых только гуру смогут разбираться.