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

Здравствуйте, 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, Вы писали:

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

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

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

VK>По-моему именно подобные инквизиторы и иные беспросветные ретрограды, которых в обилии можно встретить в том числе на rsdn и есть главное препятствие для Nemerle.

Думаю, он не шутит.

VK>Извините, но вы просто реально достали.

Не извиняю. Это твои проблемы, что там тебя "достали" или нет. Достали — не читай, никто не заставляет.

VK>Именно вы и подобные вам являятесь главной и единственной угрозой будущему Nemerle.

Честно? Мне и таким как я плевать на Немерле с высокой колокольни.

VK>Просто поразительно насколько глубокое неприятие вызывает он у некоторых товарищей. Не нравится Nemerle — отойдите в сторону и не мешай развиваться ему и заинтересованной в нем прослойке программистов.

Объясни мне пожалуйста, каким именно образом я мешаю развиваться твоему Немерле, на который мне плевать.

VK>Ваши пророчества и размышления на тему Nemerle никому не нужны. Удовлетворяйте нужду собственного самоутверждения в другом месте и по другому поводу.

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

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

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

Здравствуйте, 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 выставляю себя умниками я и не утверждал. Мое мнение в том, что они делают язык для людей своего уровня. А таких немного по определению.

Здравствуйте, 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.

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

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

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

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

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

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

Не везде и не всем нужны простые люди. В некоторых задачах они просто опасны. Нужны умные. И умным нужен адекватный инструмент. Это вообще душераздирающее зрелище, когда умный коллектив решает умную задачу, пользуясь при этом, например, глупой Java или глупым C++. При этом расходуется неоправданно много сил и средств на борьбу с недопустимым уровнем глупости инструмента. При этом, сама задача по природе своей настолько умная, что только умный коллектив с ней и справится, соответственно, использовать глупый инструмент в рассчёте на то, что с ним справится глупый и легкодоступный на рынке труда кодер, просто нелепо — этот кодер не справится с задачей независимо от инструмента.

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

Причём, умные люди тоже бывают разные. Одни и без инструмента обойдутся — сами себе идеальный инструмент играючи создадут из подножного корма. Другие возьмут Common Lisp или ещё какую подобную тяжелую артиллерию. Те, кто менее опытен, но не менее умён, уже, увы, остаются без игрушки — и как раз им Nemerle и пришелся очень вовремя, как манна небесная. Конечно же приятно помечтать, что все вдруг станут умными и хорошими, такими, как они, и тогда Nemerle и все другие подобные технологии мигом станут популярными (ну, у Nemerle будет шанс исчезнуть в силу резкого падения популярности платформы .NET). Но ведь это только мечты, большинство людей умными не станут никогда. Так зачем же пытаться загнать умных в рамки большинства, отобрать у них хороший инструмент и сделать простую и примитивную долбилку для идиотов?

Здравствуйте, 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>>

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

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

Т>

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

(c)Klapaucius

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

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

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

some_function (parm1, parm2) {
   code code code
}

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

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

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

E>Модула, Эйфель, Оберон, Пролог и Ада не только нравится, но и используется кучей программистов-практиков. Которые, в отличии от тебя, деньги на собственном софте зарабатывают, а не редакторы для януса или плагины для VS пишут. Тем не менее, популярными они не стали. При том, что так же являются хорошими языками, с кучей достоинств. Так что о верности или неверности моего утвердения в отношении Nemerle можно будет судить только когда Nemerle станет заметным явлением не только в рамках RSDN.

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

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

Это как раз без проблем

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

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

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

Нет там ничего подобного. Мануал ты читал или по диагонали, или просто ничего в нем не понял.
Может быть, тебе просто не хочется признаться даже самому себе, что ты потратил время и силы на Руби зря?

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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>>

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

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

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

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

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

Здравствуйте, 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>Здравствуйте, VladD2, Вы писали:

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

E>Можно примеры, где бы Nemerle был безопаснее Java?

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

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

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

VD>1. Приведение типов. В немерле паттерн-матчинг кроме функции сопоставления с образцом за одно выполняет функцию блока защиты. Причем операторов приведения возвращающих null в случаее неудачи вобще нет.

А что есть? Насколько помню, в Java операции приведения не возвращают null в случае неудачи.

VD>2. Нет старой сишной проблемы возникающей в switch если забыть закрыть case break-ом. В C# такой проблемы тоже нет, но там это достигается обязательностью break в конце case.

Понятно.

VD>Я не против критики, если она критика. Я против домыслов.

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

E>>Ты разрабатываешь этот язык, ты отвечаешь за выбор и внедрение в него новых возможностей?

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

От скромности ты никогда не умирал.

VD>Ты давай, не уходи от ответа. Так все же. Как вяжется твоя теория о том, что "ученые" не могут сделать ничего жизнеспособного и тот факт, что куче программистов-практиков нравится то что у них получается?

Ты выдумал за меня какую-то теорию и пытаешься заставить меня ее доказывать. Увольте, сударь.

Модула, Эйфель, Оберон, Пролог и Ада не только нравится, но и используется кучей программистов-практиков. Которые, в отличии от тебя, деньги на собственном софте зарабатывают, а не редакторы для януса или плагины для VS пишут. Тем не менее, популярными они не стали. При том, что так же являются хорошими языками, с кучей достоинств. Так что о верности или неверности моего утвердения в отношении Nemerle можно будет судить только когда Nemerle станет заметным явлением не только в рамках RSDN.

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

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

VD>Так что макросы тут не пирчем. Разницы между бардачным проектированием классов/функций и бардачным проектирвоанием макросов — нет.

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

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

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

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

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

ЗЫ

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

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

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

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

Здравствуйте, 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>Так что вы здесь делаете? Вместо того, чтобы доказывать, что у Nemerle есть будущее взяли бы и сделали это будущее. Мне, например, хватает того, что есть в C++, Ruby, D, Java и Scala.

О, ты начал исползовать Скалу? Scala достойный конкурент Nemerle. Если ты начал его использовать то поздравляю тебя с хорошим выбором. Вот только не верится что-то.

E>Нафига еще один язык, лично мне не понятно. Может быть под .NET ничего более стоящего просто нет?

Просто истерика какя-то

. Ты бы так за свой велосипед переживл.

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

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

VK> Особенно отличился в этом Гапертон, высказавший мысль, что увлечение Nemerle это симптом некой болезни и что людей с любым упоминанием Nemerle в резюме не стоит брать на работу.Такие заявления по-моему это элементарное неуважение к участникам форума.

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

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

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

А если тебе не нужен язык? Если нужно сразу много языков, и ты не знаешь, каких именно? Как тут без макросов?

G> Инженеры из моего отдела придерживаются такого же мнения.

Они не в теме. Некомпетентны.

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

G>Чем это радикально лучше вот этого:
G>

G>bool my_fun( char x, char y ) { return x == y && y == ' '; }

G>...
G>unique(str.begin(),str.end(), my_fun );
G>...
G>

Слава Создателю, сотворившее всё ненужное трудным и всё трудное ненужным.

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

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

DG>>Думаю к тому, что Немерле не Лисп

L>И для этого нужно писать статью?

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

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

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

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

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

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

15.08.06 03:47: Ветка выделена из темы Почему у Nemerle нет будущего — IT

15.08.06 03:49: Перенесено модератором из 'Декларативное программирование' — IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G>А из каких соображений разрабатывался Немерле?

Будешь смеяться, но соображения безопасности в нем одно из главных. Ява просто дырявое корыто с граблями по сравнению с Немерле. Еще в C# было устранено не мало грабель Явы, а немерловцы пошли еще дальше.

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

Да, не, это вряд ли. Иначе ты бы давно бросил бы все и продвигал бы Немерле в массы

. Шучу.

Если серьезно, то задачи которые ставили немерловцы описаны и у них на сайте и наших статьях. Они хотели создать безопасный язык для платформы .NET органично поддерживающий императивную парадигму, функциональную парадигму и метапрограммирование. При этом они ставлии задачу создать язык с С-подобным синтаксисом и близкой к C# семантикой. Последнее естественно из соображений упрощения миграции с С-подобных языков и лучей совместимости с .NET.

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

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

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

Можно примеры, где бы Nemerle был безопаснее Java?

VD>И вообще, я не понимаю откуда такая забота о судьбе языка с которым ты лично и дргие критики явно даже не собираетесь познакомиться?

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

VD>Дайте судьбе определить будующее этого языка. И не надо нагнетать негатива.

А ты можешь перестать делать это по отношению к C++? Покажи пример.

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

VD>Я вряд ли могу назвать себя ученым. Но мне этот язык понравился. Как это вяжется с твоей теорией?

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

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

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

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

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

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

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

Здравствуйте, 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 из той же оперы).

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

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

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

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

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

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

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

При чем тут хаскель? С чем спорим-то?

Тебе кажется, я что-то очень сложное и хитрое тебе доказать хочу?

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

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

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

Дык, а почему нет

? Мне уже стало интересно.

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

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

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

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

Здравствуйте, граммофон, Вы писали:

Г>Интересные знакомые.
Г>Вы там скажите им, если время будет, что в Java есть и unchecked exceptions (extends RuntimeException).

ну я всегда был не очень высокого мнения о квалификации данных товарищей.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

Win2k wrote:
>> > А если тебе не нужен язык? Если нужно сразу много языков, и ты не
>> > знаешь, каких именно? Как тут без макросов?
> C>Пишешь компилятор — и вперед.
> Долго и дорого. А с макросами у нас уже есть на халяву хороший компилятор.
Не "на халяву". С помощью макросов просто можно сделать только
простенькие примеры. Чего-то нестандартное (типа создания логического
языка, например) будет уже того же порядка сложности, что и написание
отдельного компилятора.

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

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

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

Posted via RSDN NNTP Server 2.0

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

Хорошо пишеш.

Напиши еще чтонибудь...
Если можно — на заказ. Хочу прочитать про "Резкое падение популярности .NET. Кто виноват и что делать. Тематический обзор, интервью и аналитика с диаграммами и картинками." Обещаю поставить 3 раза по х3 там где пальцем покажеш.

[RSDN@Home][1.2.0][alpha][655]
[Hесчастлива страна, у которой нет героев. [Б. Брехт]]

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

E>Можно примеры, где бы Nemerle был безопаснее Java?

Еще пришло в голову...

3. В Яве как в С++ нет ключевого слова override и все методы являются вирутальными. Это приводит к тому, что можно нечайно переопределить метод базового класса или наоборт думать, что мы его переопределили, но в результате ошибки в имени метода или списке параметров создать новый метод.
4. Грабли с оператором == для ссылочных типов. Интутитивно думаешь, что == произведет сравнение значений объектов. Меж тем в Яве сравнение производится с помощью метода equals, а оператор == сравнивает ссылки. Причем из-за интернирования строук константные строки удается сравнить оператором ==, а вот получаенные в результате вычисления — нет. Еще те надо сказать грабли.
5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.
6. Потеря значения функции. Классическая ошибка:

str1.Rerlace("some", "other");

Этот пример не изменит строку и компилятор при этом не выдаст ни одного предупрежднеия. Эти грабли так же уснаследовал и C#. В немерле значение фукнции можно игнорировать только явно. Это можно сделать так:

_ = SomeFuncWithSideEffect();

или с помощью спецального макроса (который в прочем делает тоже самое).

ignore(SomeFuncWithSideEffect());

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VD>>Я не против критики, если она критика. Я против домыслов.

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

Хотите программ на Немерле — nemerle.org в раздел исходники компилятора

VD>>Ты давай, не уходи от ответа. Так все же. Как вяжется твоя теория о том, что "ученые" не могут сделать ничего жизнеспособного и тот факт, что куче программистов-практиков нравится то что у них получается?

E>Ты выдумал за меня какую-то теорию и пытаешься заставить меня ее доказывать. Увольте, сударь.

E>Модула, Эйфель, Оберон, Пролог и Ада не только нравится, но и используется кучей программистов-практиков. Которые, в отличии от тебя, деньги на собственном софте зарабатывают, а не редакторы для януса или плагины для VS пишут.

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

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

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

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

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

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

Ничего, я переживу.

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

IT>Это как раз без проблем

Сообщи, когда это знаменательное событие произойдет.

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

E>А что есть? Насколько помню, в Java операции приведения не возвращают null в случае неудачи.

Возможно я путаю. С явой много лет дел не имел. В C# такие грабли есть. Так как Немерле не прямой наследник Явы, то могли бы и эти грабли тоже подцепить, но не переняли. Именно потому, что заботились о безопасности языка.

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

VD>>2. Нет старой сишной проблемы возникающей в switch если забыть закрыть case break-ом. В C# такой проблемы тоже нет, но там это достигается обязательностью break в конце case.

E>Понятно.

Что понятно?

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

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

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

E>От скромности ты никогда не умирал.

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

E>Ты выдумал за меня какую-то теорию и пытаешься заставить меня ее доказывать. Увольте, сударь.

ОК, буду считать эту фразу заменой "беру свои слова про ученых обратно".

E>Модула, Эйфель, Оберон, Пролог и Ада не только нравится, но и используется кучей программистов-практиков.

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

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

Ты хочешь погворить о запрлате? Или о моей компетенции? Уверен, что для пенисометрии по обоим пуктом твоя пиписка явно требует серьезного удлинения

. Так что предлагаю не развивать эту тему.

Есть, что скзать по теме — милости просим. Нет, лучше жувать и зарабатвать зарплату.

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

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

Так что не надо развивать эту ситуационную логику.

Языки эти объективно атсайдеры. И виной тому их плохая выразительноть, отсуствие инфраструктуры, и наличие более интересных языков. А вот в случае Немерла дела обстоят с точностью наоборот. Это очень выразительный язык имеющий очень мало реальных конкурентов каждый из которых имеет ряд особенностей делющих Немерле в общем-то уникальным. По крайней мере второго столь перспективного языка со сттической типизацией для платформы .NET попросту нет.

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

Извините сэнсэй Предказамус. Был не прав, поддался эмоциям... Усомнился в вашем виликом предсказамусе.

Если серьезно, то твои предсказания имеют такой же авторитет, как у гадалки из подворотни. Да и являются они чистешим негативом. А негатива и так через край в этой жизни.

Я уже давно сказал, что время само расставит все на свои места. А подобным гаданиям грошь цена. Лично я вижу приемщества языка и желаю языку лучшей судьбы, но говорить что-то с уверенностью о его будущем не буду. Ибо глупо это. Количество факторов так велико, что даже гадание на подбрасвывании монетки и то будет более точно. К тому же все каждую минуту может измениться. Вдруг завтра появится Мерле или B++ и расклад сил изменится? В общем, пустое это.

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

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

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

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

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

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

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

VD>Рядовой разработчик не может менять язык. Он не может даже менять стандартную библиотеку. Все что он в силах сделать — это собственную библиотеку макросов.

Это вопрос терминологии. Для меня дополнение — это частный случай изменения синтаксиса, а макрос — это зачастую изменение синтаксиса.

VD>И нам с тобой как потебителям останется выбрать нужны нам его поделки или нет.

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

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

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

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

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

VD>>Скажи, ты читал эту статью? Крыша плавилась?

L>Какое отношение эта статья имеет к лиспу?

Думаю к тому, что Немерле не Лисп

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

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

DG>макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?

Это называется аналогия

DG>Так вот статья думаю (я не автор,к сожалению) для того, что бы показать что немерле это вовсе не сложно

Не-е-е, в топку, это не доказательство. Вот если бы кто-то сказал — "у нас было 100 программистов на С#. Из них 17 перешли на Nemerle и стали более продуктивны, 5 перешли и так же продуктивны, 29 перешли и менее продуктивны, а 49 вообще не смогли освоить язык", то это было бы уже кое-что. А то собралисть тут умнейшие люди и обсуждают какой Nemerle простой

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

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

L>Не хочется спорить. У тебя на этой ниве (споры) опыта будет на порядки поболее чем у меня. Время нас рассудит. Посмотрим что будет годика через 3.

+1

L> Ставлю на то, что большого распространиения Nemerle за этот период не получит.

Ставить, класть и даже забивать не буду. Но что-то мне подсказывает, что сдедующий движок этого сайта будет на Nemerle.

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

По крайней мере хотелось бы так думать.

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

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

E>>А что есть? Насколько помню, в Java операции приведения не возвращают null в случае неудачи.

VD>Возможно я путаю. С явой много лет дел не имел. В C# такие грабли есть. Так как Немерле не прямой наследник Явы, то могли бы и эти грабли тоже подцепить, но не переняли. Именно потому, что заботились о безопасности языка.

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

Поверить во что? В то, что операция приведения типа в Java не возвращает null?
Или в то, что Nemerle безопаснее Java?
Мне кажется, что это именно тебе нужно лучше узнать другие языки.

VD>>>2. Нет старой сишной проблемы возникающей в switch если забыть закрыть case break-ом. В C# такой проблемы тоже нет, но там это достигается обязательностью break в конце case.

E>>Понятно.

VD>Что понятно?

Понятно, что ты считаешь, что эта фича в Nemerle делает язык более безопасным, чем Java.

VD>Да, уж. Я лучше пожеву. Хотя я в общем-то не о себе. Тут и без меня людей хватает. Вон IT, например, и другие. Так же стоит поглядеть на голосование по поводу Немерле. Там четко было видно, что большинство из топ-а РСДН-а оценивает его как минимум как перспективный язык определяющих будующее ЯП.

Если ставить вопрос как "Перспективный ли язык Nemerle и будет ли он определять будущее ЯП?", то я так же с этим соглашусь.

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

E>>Ты выдумал за меня какую-то теорию и пытаешься заставить меня ее доказывать. Увольте, сударь.

VD>ОК, буду считать эту фразу заменой "беру свои слова про ученых обратно".

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

E>>Модула, Эйфель, Оберон, Пролог и Ада не только нравится, но и используется кучей программистов-практиков.

VD>Это настолько явная неправда, что объяснить ее можно только гиперизвращенным пониманием слова "кучей".

Уж во всяком случае гораздо больше, чем Nemerle. В особенности что касается языка Ада.

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

VD>Ты хочешь погворить о запрлате? Или о моей компетенции? Уверен, что для пенисометрии по обоим пуктом твоя пиписка явно требует серьезного удлинения

. Так что предлагаю не развивать эту тему.

Нет, я хочу сказать, что условия разработки OpenSource и Freeware для собственного удовольствия сильно отличаются от разработки софта под заказ или на деньги инвестора/кредита, а именно:
* в OpenSource у тебя нет жестких сроков;
* в OpenSource у тебя нет проблемы подбора персонала. Ты начинаешь в одиночку или в небольшом круге единомышленников, по ходу дела к тебе присоединяются энтузиасты желающие что-нибудь изучать и делать. Поэтому даже начинающий программист без большого опыта в программировании или платформе, но со светлой головой, могут оказывать очень серьезную помощь в проекте;
* в OpenSource ты можешь себе позволить выпускать alpha- и beta- версии продуктов без опасения потерять пользователей, очень надолго откладывать выпуск release-версии.

Не так уж сложно заметить, что когда нет увлеченной одной идеей (интересом к одному языку) команды, когда есть жесткие сроки и требуется обеспечить высокое качество сразу, то подход к выбору технологии и персонала меняется. Так вот Eiffel, Oberon и Ada используются (прочти внимательно, используются) в коммерческих проектах.

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

VD>Они у тебя стали резко хорошими исключительно на время пока ты пыташся тут доказать свои домыслы. Реально не составит труда понять,ч то Аду с Модулой ты вообще в глаза не видел, а Оберон с Прологом на этом сайте у Губанова и во время обученя в институте. Так же не составит труда найти твои споры с тем же Губановым.

Ну найди. И заодно обоснуй свои утверждения о моем незнании Ады и Модулы.
А что касается Eiffel, то это язык, изучая который задаешься одним простым вопросом -- нафига были придуманы Java и C#, если был Eiffel? Очень стройный и приятный язык, безнадежно загубленный маркетингом.

VD>Я уже давно сказал, что время само расставит все на свои места. А подобным гаданиям грошь цена. Лично я вижу приемщества языка и желаю языку лучшей судьбы, но говорить что-то с уверенностью о его будущем не буду. Ибо глупо это. Количество факторов так велико, что даже гадание на подбрасвывании монетки и то будет более точно. К тому же все каждую минуту может измениться. Вдруг завтра появится Мерле или B++ и расклад сил изменится? В общем, пустое это.

Выделенное является ключевым моментом в твоих высказываниях. Ты очень быстро соскочил с одной иглы на C#, затем так же быстро на Nemerle, затем так же быстро на новый B++ (может потому, что тебе не нужно заниматься сопровождением предыдущих проектов?). А вот тем, что начнет вкладывать деньги в разработку на Nemerle сделать это просто так не получится.

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

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

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

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

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

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

(c)Klapaucius

Здравствуйте, 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.

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

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

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

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

Здравствуйте, 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 враперов и текстовых редакторов понятия не имеют как писать софт для атомных электростанций. А когда они о чём-то не имеют понятия, то не лезут к другим со своими советами, суждениями и козявками.

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

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

Нда, аргументация супер. Спосибо за пять минут смеха.

И чем этот "стандарт" отличается от стандарта http://nemerle.org ?

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

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

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

Интересная тенденция — многие знакомые мне программисты на Яве любят давить исключения в зародыше, чтобы не париться с декларированием этого исключения по всему стеку функций до того места, где его можно разумно обработать. А для обработки ошибок используют..... коды возврата (здравствуй, каменный век!)
Вот так то. Эта фича только на первый взгляд кажется такой хорошей, на деле же всё совсем не так бело и пушисто.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

Количестве уровней абстракции должно быть адекватно поставленной задаче. Правило "чем меньше уровней абстракции, тем лучше" просто не работает.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

если конечно за это время не появится что-то еще более удобное

... << RSDN@Home 1.1.4 stable rev. 510>>

Win2k wrote:
> G> Мое мнение другое — *хорошему языку макросы не нужны,* там должно
> быть и без них комфортно. Если от макросов есть заметный плюс — что-то
> не так с самим языком.
> А если тебе не нужен язык? Если нужно сразу много языков, и ты не
> знаешь, каких именно? Как тут без макросов?
Пишешь компилятор — и вперед. А еще лучше — берется какой-нибудь
интерпретатор с гибким синтаксисом и прикручивается.

> G> Инженеры из моего отдела придерживаются такого же мнения.
> Они не в теме. Некомпетентны.
Ага, конечно. Вероятно хорошо развиты телепатические способности.

Posted via RSDN NNTP Server 2.0

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

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

NB>>>Тогда еще вопрос. Зачем нужны макросы.
NB>>>ИМХО, они позволяют
NB>>>1. избежать дублирования кода.
G>>Самые обычные функции с этим прекрасно справляются.

NB>ну вот из последнего
NB>

NB>#define MAKE_BINARY_OP(NAME,name,T1,OP,T2,RET) \
NB>  struct NAME : lambda::Lambda<NAME>           \
NB>  {                                            \
NB>...
NB>  } const name = NAME ();                      \
NB>                                               \
NB>  template< typename T1,typename T2 >          \
NB>  lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > operator OP ( T1 const & x, T2 const & y ) { \
NB>    return lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > ( name, lambda::make_tuple (x,y) ); \
NB>  }

NB>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>

NB>как сделать с помощью функций?

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

NB>>>Что из перечисленного мешает сопровождению кода.

G>>Примеры мои смотрел? Или я впустую пишу?

NB>ладно, давай рассмотрим.
NB>

NB>a = b + c + d
NB>

NB>что предлагается взамен?
Ты объясни по человечески, что ты от меня хочешь, ок? Пока я вижу, что ты вырываешь фразы из контекста (вне контекста они теряют смысл), и задаешь короткие вопросы, которые мне кажутся глупыми, их смысл мне не понятен. Дурацкие споры я уже год как вести устал, и спорить с тобой не буду.

NB>>>гибкость теха позволяет писать запутанный текст. но это не делает его плохим языком.
NB>>>сообщество выработало стиль, устраняющий эту проблему.
NB>>>что препятствут другим пойти этим путем?
G>>Ничего. Иди этим путем. В третий раз подряд объяснять разницу между тех-ом и языками программирования у меня нет сил, извини. Пиши с макросами, я не против.

NB>спасибо тебе, добрый человек.

NB>у меня без твоего разрешения работа стояла...

Так ты обращайся почаще с вопросами "что препятствует идти путем", я тебе завсегда отвечу.

Мне совершенно все равно, каким путем тебе идти — зачем мне об этом спорить?

NB>#define MAKE_BINARY_OP(NAME,name,T1,OP,T2,RET) \
NB>  struct NAME : lambda::Lambda<NAME>           \
NB>  {                                            \
NB>...
NB>  } const name = NAME ();                      \
NB>                                               \
NB>  template< typename T1,typename T2 >          \
NB>  lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > operator OP ( T1 const & x, T2 const & y ) { \
NB>    return lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > ( name, lambda::make_tuple (x,y) ); \
NB>  }

NB>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>

NB>как сделать с помощью функций?

Лямбда должна поддерживаться языком. И тогда этот ужас просто не нужен. Тем более, что нормальную лямбду ты все равно не сделаешь, хоть обложись макросами — все равно в мало-мальски сложном случае придется объявлять функтор. Пример твоего кода — это как раз такой код, которого в продакшне я видеть не хочу ни под каким видом. Тебя же я переубеждать не собираюсь — это твое дело, как писать. Спорить я с тобой тоже не буду, я уже объяснил, чем такой код с моей точки зрения плох, достаточно доходчиво, чтобы не отвечать в десятый раз на вопросы "почему" — кому надо тот поймет. Ты не обижайся, ничего личного. Это нормально, когда кто-то несогласен со мной или с тобой. Я тебя понимаю прекрасно, возможно и ты поймешь меня когда-нибудь.

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

C>Не "на халяву". С помощью макросов просто можно сделать только
C>простенькие примеры. Чего-то нестандартное (типа создания логического
C>языка, например) будет уже того же порядка сложности, что и написание
C>отдельного компилятора.

Фигуленьки. Показать, как написать по тупому эффективный компилятор Пролога на Схеме?

C>Даже наоборот, для отдельного компилятора я могу использовать AntLR для
C>которого есть замечательные визуальные построители грамматик. А вот
C>макросы мне придется руками самому делать.

От визуальных лабалок нигде толку нет — кроме как разве что для демонстрации видимости бурной деятельности.

C>Не макросы, просто интерпретатор. Это проще и быстрее.

C>Может для каких-то очень специфичных задач макросы и подходят, но я их
C>пока что-то не вижу.

Зря. А мне без них тяжко — любая задача без макр решается раз в десять сложнее.

Win2k wrote:
> C>Не "на халяву". С помощью макросов просто можно сделать только
> C>простенькие примеры. Чего-то нестандартное (типа создания логического
> C>языка, например) будет уже того же порядка сложности, что и написание
> C>отдельного компилятора.
> Фигуленьки. Показать, как написать по тупому эффективный компилятор
> Пролога на Схеме?
Эффективный? С поддержкой модулей и IO? А может еще с сильной типизацией?

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

> C>Даже наоборот, для отдельного компилятора я могу использовать AntLR для
> C>которого есть замечательные визуальные построители грамматик. А вот
> C>макросы мне придется руками самому делать.
> От визуальных лабалок нигде толку нет — кроме как разве что для
> демонстрации видимости бурной деятельности.
Не видел — не говори. Визуальный построитель грамматики для ANTLR
чрезвычайно удобен, так как умеет подсказывать какие правила применимы в
данный момент, смотреть дерево разбора и т.п.

http://antlreclipse.sourceforge.net/

> C>Может для каких-то очень специфичных задач макросы и подходят, но я их
> C>пока что-то не вижу.
> Зря. А мне без них тяжко — любая задача без макр решается раз в десять
> сложнее.
ROTFL. Советую прочитать про методику Усова и писать на Обероне — так
вообще производительно в 1000 раз возрастет.

Posted via RSDN NNTP Server 2.0

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

NB>>например, удаление дублирующихся пробелов:
NB>>

NB>>unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );
NB>>

G>Лямбда получилась хорошая, на самом деле. Не ожидал, что будет выглядеть настолько хорошо. Но все равно.

G>Чем это радикально лучше вот этого:
G>

G>bool my_fun( char x, char y ) { return x == y && y == ' '; }

G>...
G>unique(str.begin(),str.end(), my_fun );
G>...
G>

ну, например, в с++ нет вложеных функций.
саппорту придется, как ты верно заметил, возвращаться и искать, что-же такое my_fun.
можно через функтор, но это уже будет не одна строчка.

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

а в твоем мозгу произошел большой взрыв, чтобы понять написанное?

G>Учитывая это и общее незначительное количество употреблений лямбд в прикладном коде — какой смысл применять твою лямбду?

я никому ничего не навязываю (как и ты

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

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

NB>ну, например, в с++ нет вложеных функций.
NB>саппорту придется, как ты верно заметил, возвращаться и искать, что-же такое my_fun.
Верно. Это ровно одно лушнее телодвижение. При этом саппорт будет знать, что он ищет именно функцию.

NB>можно через функтор, но это уже будет не одна строчка.

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

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

NB>а в твоем мозгу произошел большой взрыв, чтобы понять написанное?

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

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

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

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

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

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

G>На самом деле расстояние не особо важно — все равно определение такой функции ищется поиском.

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

G>И это сделать существенно проще, чем разбираться с устройством лямбды или добавлять в лямбду свои операторы — тут даже и говорить не о чем. Код с функцией поймет с ходу любой человек, знакомый на С++ на среднем уровне. Что не скажешь про "лямбду".

Вот вот. Но проблема тут не в лямбде, а в том, что это никакая не лямбда на самом деле. И проблем будет больше даже не у того, кто первый раз увидит "лямбду", а у того, кто лямбду уже видел и будет думать что от такой "лямбды" можно ожидать того же, что от лямбды нормальной. Если такой человек что-то попытается сделать, руководствуясь этим убеждением, то немедленно ударится лбом о притолоку. Но это ситуация фантастическая, так как того, что лямбда в C++ будет работать как надо, наверное никто и не ждет. Первая же мысль будет о том, в чем же тут подвох? А потом придется копаться во внутренностях "лямбды".
Тоесть сама мысль о том, что расширение будет работать как надо — чистое безумие. И не потому, что расширение может быть глючным, а потому, что оно полноценным быть не может в принципе. И никем на практике не рассматривается как повышение уровня абстракции, но только как присыпаный листьями взведенный капкан, который оставлен вам в подарок добрыми людьми.
Понятно, что такие расширения не нужны. Правда, понятно не всем.

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

G>Вопрос — нафига нам макросы в нормальном языке? Почему они бывают популярны в ненормальном — понятно, люди пытаются править эти ненормальности. Да и то, нафиг-нафиг. Лучше уж ненормальный язык, но знакомый и предсказуемый, чем "исправленый" макросами.

Во-первых, я разделю макросы и синтаксические расширения. Синтаксические расширения — опасная штука, тут я с Вами полностью согласен, применять их повсеместно неразумно. Тем не менее даже и они в нормальном языке могут пригодиться. Для написания стандартных расширений. Всякие using-и, foreach-и и тем более yield-ы в С# генерируют код, вот только посмотреть тут же, на месте, какой код они сгенерируют нельзя. Разве только декомпилировать, но это не совсем то. А кодогенератор вообще никак не посмотреть. Это уже минус, хотя человек, который не знает, что может быть по другому, об этом жалеть не будет. Если же расширения реализованы на синтаксических макросах, то такая информация доступна.

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

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

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

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

Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка и слабости системы типов. Большое количество паттернов, которые надо знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь — исключительно для примера — эрланг, как видим, так и пишем, например так:

Облегчим себе жизнь в одну строку:
switch( { State, Data }, Transition ) -> State( Transition, Data ).

И поехали описывать автомат:

state1( { ivegotevent1, EventData }, StateData ) -> ... { stateN, NewData }
state1( { ivegotevent2, EventData }, StateData ) ->

и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

K>В чем принципиальная разница таких макросов и других параметрических типов? Тип может быть параметризован другим типом или веткой AST. Или любые параметрические типы — это одни проблемы?

Нет, почему же, параметрические типы это хорошо. Я пожалуй попрошу вас показать, чем он отличается от макроса, а то я не вполне понимаю, о чем речь. Ну, и что такое "тип, параметризованный веткой AST", тоже непонятно.

Gaperton wrote:
> Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка
> и слабости системы типов.
НЕТ! Паттерн — это конкретный прием программирования.

> Большое количество паттернов, которые надо
> знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по
> грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь —
> исключительно для примера — эрланг, как видим, так и пишем, например так:
И что? В Эрланге паттерн "конечный автомат" просто вмонтирован в
сам язык.

Точно так же, в С можно сделать паттерн "наследование", а в С++ он уже
вмонтирован.

> и так далее. Вопрос: куда девался навороченный паттерн с double
> dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь
> макросы?
Он просто реализуется по-другому.

Posted via RSDN NNTP Server 2.0

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

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

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

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

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

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

E>...

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

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

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

E>...

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

--
Mikl

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

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

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

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

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

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

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

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

Здравствуйте, 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>>

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

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

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

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

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

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

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

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

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

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

Дайте судьбе определить будующее этого языка. И не надо нагнетать негатива.

Все ваши слова это какие-то чисто субъективные мысли. Вот если бы вы привели какие-то факты, то было бы интересно их обсудить. А пока я вижу только море скеписа и домыслов.

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

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

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

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

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

Скажи, ты читал эту статью? Крыша плавилась?

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

Все вокруг идиоты и враги сами себе? Да даже если так. Ты решаешь свои задачи. И тебя никто не заставляет использовать чужой код. Макросы — это чужой код. Отключи его и не делай на него ссыки и ты получишь тот самый простой и понятный язык.

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

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

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

Рядовой разработчик не может менять язык. Он не может даже менять стандартную библиотеку. Все что он в силах сделать — это собственную библиотеку макросов. И нам с тобой как потебителям останется выбрать нужны нам его поделки или нет. Если это бдет, например, хорошая замена для Кибернэйта, то мы наверное возмем такую библиотеку когда будем обращаться к БД. А если это будет уродец, то мы просто пошлем его на три веселых. Точно так же дела обстоят с библиотеками в C#. Тебя смущают тонных кривых библиотек валюшихся в Интеренте? Меня, нет. Я вообще обхожусь в основном своими наработками и стандартной библиотекой.

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

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

E>Можно примеры, где бы Nemerle был безопаснее Java?

Можно. Только у меня под рукой готового списка нет. Но то что сразу приходит в голову:
1. Приведение типов. В немерле паттерн-матчинг кроме функции сопоставления с образцом за одно выполняет функцию блока защиты. Причем операторов приведения возвращающих null в случаее неудачи вобще нет. Таким образом исключены NullRefferenceException-ы (или как их там в Яве?) при приведении типов.
2. Нет старой сишной проблемы возникающей в switch если забыть закрыть case break-ом. В C# такой проблемы тоже нет, но там это достигается обязательностью break в конце case.

Сейчас не могу найти, но у нас на сайте как-то пробегала ссылка на грабли в Яве. Если не ошибаюсь, ни одних этих граблей в Немерле нет. Грабли Явы чистили еще в C#, а в Немерле почистили уже грабли и из C#.

VD>>И вообще, я не понимаю откуда такая забота о судьбе языка с которым ты лично и дргие критики явно даже не собираетесь познакомиться?

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

Если бы она тебе была безразлична, то ты не залез бы в форум в котором с роду не был.

А обсуждение, на мой взгляд, опять носит маргинальный характер. Ни одной ссылки, факта и т.п. Одни "IMHO" и все как один психоделические и основанные на том, что окружающие сплошь идиоты.

VD>>Дайте судьбе определить будующее этого языка. И не надо нагнетать негатива.

E>А ты можешь перестать делать это по отношению к C++? Покажи пример.

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

Я не против критики, если она критика. Я против домыслов.

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

VD>>Я вряд ли могу назвать себя ученым. Но мне этот язык понравился. Как это вяжется с твоей теорией?

E>Ты разрабатываешь этот язык, ты отвечаешь за выбор и внедрение в него новых возможностей?

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

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

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

Ты пыташся обосновать теорию которая рассыпается на глазах. Меж тем это все твои слова домыслы. Надо признать, что ребата сделали не так много нового. 95% того что они привнесли в Немерле является давно опробированными технологиями. Просто ты жил и продолжашь жить в другом мире. Твой мир незнает этих концепций и решений, от того они кажется тебе причудливыми. Но вот парадокс. Из тех кто серьезно использовал Немерле еще ни один человек не сказал что язык отстой. Да что там "отстой"? Небыло ни одной сдержанной реакции. Вон даже Гапертон до тех пор пока не встал в позу лесно отзывался о языке (хотя явно им реально не пользовался).

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

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

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

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

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

ОК. В моем понимании безопасность — это свойство языка уберегающая программистов от отдельных ошибок или их классов. Например, типобезопасность присутствующая в Ява, Немерле и C# и отсуствующая в C, D, C++ позволяет устранить огромный класс ошибок связанный с неверным использованием типов (неверной реинтерпретацией памяти, неверными действиями...).

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

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

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

E>>>>Нет, не инженера, а ученого. У них это в крови, собственно и работа у них такая.
VD>>>Я вряд ли могу назвать себя ученым. Но мне этот язык понравился. Как это вяжется с твоей теорией?
E>>Ты разрабатываешь этот язык, ты отвечаешь за выбор и внедрение в него новых возможностей?
VD>Практически, нет. Потому и спрашиваю, что же не так в этом мире если работа "ученых романтиков" нравится далего не самым отсталым программистам с этого сайта?

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

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

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

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

Нет. Это Влад сказал, что Nemerle безопаснее Java. Значит у него были критерии и примеры, которые я и хотел увидеть. Увидел. Но вот предлагать что-то самому у меня не было желания.

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

VD>3. В Яве как в С++ нет ключевого слова override и все методы являются вирутальными. Это приводит к тому, что можно нечайно переопределить метод базового класса или наоборт думать, что мы его переопределили, но в результате ошибки в имени метода или списке параметров создать новый метод.

+-
Есть final.
Если несколько методов с разными сигнатурами виртуальные, то кто гарантирует что мы из-за ошибки в названии метода или списке параметров не поставили override у совсем другого метода?

VD>4. Грабли с оператором == для ссылочных типов. Интутитивно думаешь, что == произведет сравнение значений объектов. Меж тем в Яве сравнение производится с помощью метода equals, а оператор == сравнивает ссылки. Причем из-за интернирования строук константные строки удается сравнить оператором ==, а вот получаенные в результате вычисления — нет. Еще те надо сказать грабли.

+

VD>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.

?
Не понял.

VD>6. Потеря значения функции. Классическая ошибка:
VD>

VD>str1.Rerlace("some", "other");
VD>

VD>Этот пример не изменит строку и компилятор при этом не выдаст ни одного предупрежднеия. Эти грабли так же уснаследовал и C#. В немерле значение фукнции можно игнорировать только явно. Это можно сделать так:
VD>

VD>_ = SomeFuncWithSideEffect();
VD>

VD>или с помощью спецального макроса (который в прочем делает тоже самое).
VD>

VD>ignore(SomeFuncWithSideEffect());
VD>

+-
Никто не подскажет программисту убрать однажды написанный ignore.

А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?

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

IT>Аргументы про учёных мне особенно нравятся. Если не ошибаюсь Страуструп тоже не на стройке гвозди заколачивал.

Страуструп работа (вроде) в исследователькой лаборатории AT&T или еще чего-то там.

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

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

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

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

VD>Скажи, ты читал эту статью? Крыша плавилась?

Какое отношение эта статья имеет к лиспу?

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

E>+-
E>Есть final.
E>Если несколько методов с разными сигнатурами виртуальные, то кто гарантирует что мы из-за ошибки в названии метода или списке параметров не поставили override у совсем другого метода?

final — это совсем из другой оперы. Это запрет на переопределение. Аналог в C#/Nemerle — sealed.

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

VD>>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.

E>?
E>Не понял.

Что там понимать:

while (variable = 1)
    ...

вместо

while (variable == 1)
    ...

и приплызд. Хотя конечно это могли быть проблемы компилятора который у меня тогда был.

E>Никто не подскажет программисту убрать однажды написанный ignore.

Я вообще не понял, что ты пытался сказать. Зачем что-то убирать? Или ты явно выражашь намерение проигнорировать результат, или ты используешь результат. В обратном случае получаешь сообщение компилятора. Таким образом ты физически не можешь проигнорировать значение функции по невнимательности.

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

E>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?

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

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

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

DG>Думаю к тому, что Немерле не Лисп

И для этого нужно писать статью?

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

L>Это вопрос терминологии. Для меня дополнение — это частный случай изменения синтаксиса, а макрос — это зачастую изменение синтаксиса.

Ага. Но по собственному желанию. Это не воля свыше.

VD>>И нам с тобой как потебителям останется выбрать нужны нам его поделки или нет.

L>Зачастую это не так. Это верно только для новых проектов. Для других проектов (а их большинство), возможностей выбора зачастую просто нет. Зато есть унаследованный код. И не факт, что твое представление об уродливости синтаксиса будет совпадать с представлениями тех программистов, которые писали код до тебя.

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

Так что макросы тут не пирчем. Разницы между бардачным проектированием классов/функций и бардачным проектирвоанием макросов — нет.

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

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

VD>>Скажи, ты читал эту статью? Крыша плавилась?

L>Какое отношение эта статья имеет к лиспу?

А какое отношение имеет Лисп к этой теме (к Немерле)? Ты ведь не маргнул глазом — провел аналогию с Лиспом и сделал на ее базе далеко идущие выводы. Меж тем аналогия не верна.

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

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

Вся сила Немерле в том, что позволяет писать используя его почти на C#-е. Это очень похоже на ситуацию с С++ в начале его развития, когда люди писали на С++ как на С и постепенно обучались новым возможностям (ООП, а потом и шаблонам).

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

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

L>И для этого нужно писать статью?

Как видишь. Иначе и это было бы еще одним поводом для домыслов

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

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

DG>макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?

Я бы сказал, не улавливаете, а вспоминате свой ход мыслей .

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

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

DG>>макросы это лисп, лисп это сложно, немерле это макросы, немерле это сложно. Улавливаете мысль?

A>Это называется аналогия

Это называется логическая ошибка. Коию ты и еще немало народа делают.

Лисп сложно потому что Лисп это сложно (причем это утверждение верно не для всех).
Макроы сложно создавать потому что для этого нужно подняться на одну ступень абстракции (измерение) выше.
Использовать же макросы сложно только если это плохо написанный или неотлаженный макрос. Тут они ничем не отличаются от библиотечной фунции. Например, использовать функцию с названием Open которая форматирует диск — сложно. И ничго в мире это не изменит. А использовать макрос while который реализует понятную идеому цикла с условием — просто даже не смотря, на то что многие могут не понять как реализован данный макрос:
Небольшой отчет о сделанной работе

...для макроса "while" (сначала приводится код использующий макрос)

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

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

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

A>>Это называется аналогия

VD>Это называется логическая ошибка. Коию ты и еще немало народа делают.

Не, ну я же не сказал, что это правильная аналогия

VD>Макроы сложно создавать потому что для этого нужно подняться на одну ступень абстракции (измерение) выше.

+1

VD>Использовать же макросы сложно только если это плохо написанный или неотлаженный макрос. Тут они ничем не отличаются от библиотечной фунции. Например, использовать функцию с названием Open которая форматирует диск — сложно. И ничго в мире это не изменит. А использовать макрос while который реализует понятную идеому цикла с условием — просто даже не смотря, на то что многие могут не понять как реализован данный макрос:

+1

Теперь вопрос — чтобы использовать Nemerle (потому что в шарпе я макросов не заметил) обезьянкам переучиваться надо? И если надо, то оно того стоит всегда-всегда?

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

L>>Какое отношение эта статья имеет к лиспу?

VD>А какое отношение имеет Лисп к этой теме (к Немерле)? Ты ведь не маргнул глазом — провел аналогию с Лиспом и сделал на ее базе далеко идущие выводы. Меж тем аналогия не верна.

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

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

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

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

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

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

A>Теперь вопрос — чтобы использовать Nemerle (потому что в шарпе я макросов не заметил) обезьянкам переучиваться надо? И если надо, то оно того стоит всегда-всегда?

Не надо. Ну, или почти не надо. Макросы они будут использовать думая, что это часть "улучшенного C#", а те макросы которые напишут опытные программисты будут приподнесены как библиотеки которые нужно использовать.

Хотя программирование обезьянками по-моему глупость. Можно конечно иметь ряд неквалифицированных кадров чтобы поручать им неквалифицированную, но объемную работу. Но при наличии макросов очень многие из задач будет выгоднее решить генерацией кода. Как минимум будет исключен человеческий фактор и разползание ошибок по проекту.

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

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

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

L>Влад, мой мессидж был не по поводу немерле, а по поповоду противопоставления простоты и сложности.
L>Как ни странно, эти два понятия в жизни вполне могут уживаться вместе, что я и попытался показать на примере лиспа. А раз они могут уживаться, то некорректно для доказательства не-сложности аппелировать к простоте.

ОК. Тогда объясни что ты вообще хотел сказать.

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

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

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

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

Не хочется спорить. У тебя на этой ниве (споры) опыта будет на порядки поболее чем у меня. Время нас рассудит. Посмотрим что будет годика через 3. Ставлю на то, что большого распространиения Nemerle за этот период не получит.

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

VD>final — это совсем из другой оперы. Это запрет на переопределение. Аналог в C#/Nemerle — sealed.

VD>Помешать ошибке в описанных мной случаях это не может.

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

VD>>>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.

E>>?
E>>Не понял.

VD>Что там понимать:
VD>

VD>while (variable = 1)
VD>    ...
VD>

VD>вместо
VD>

VD>while (variable == 1)
VD>    ...
VD>

VD>и приплызд. Хотя конечно это могли быть проблемы компилятора который у меня тогда был.

Очень вероятно:

class Test {
    public void test_assigment_in_condition() {
        int var = 0;
        if( var = 1 )
            System.out.println( "failure (var = 1)!" );
    }
}

результат:

Test.java:4: incompatible types
found   : int
required: boolean
                if( var = 1 )
                        ^
1 error

Так что мимо кассы. Подобная проблема будет существовать только, если var имеет тип boolean.

E>>Никто не подскажет программисту убрать однажды написанный ignore.

VD>Я вообще не понял, что ты пытался сказать. Зачем что-то убирать? Или ты явно выражашь намерение проигнорировать результат, или ты используешь результат. В обратном случае получаешь сообщение компилятора. Таким образом ты физически не можешь проигнорировать значение функции по невнимательности.

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

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

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

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

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

May be. Тем не менее к безопасности это вряд ли имеет отношение. Катострофических последствий это не вызовет, поскольку это логическая ошибка программиста. С таким же успехом программист может поставить ignore там, где ему нужно было сохранить значение. Запись:

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

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

E>>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?

VD>Это к граблям не приводит.

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

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

Здравствуйте, 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. Причина — та же, читайте первое предложение в ответе. Хотите, чтобы это однажды произошло с вашим кодом?

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

Т>

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

(c)Klapaucius

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

) читается легко

Если он, конечно, не левой задней пяткой написан

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

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

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

Потом интересно будет посмотреть на среднее время исправления дефекта годика через 3 непрерывного maintenance, когда у вас хотя бы 1 ключевой разработчик уйдет. А также на балланс вносимых/исправляемых ошибок. А пока можно что угодно говорить.

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

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

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

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

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

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

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

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

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

Здравствуйте, 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).

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

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

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

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

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

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

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

Кстати, Москалю похоже тоже дисер защитил.

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

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

VD>Что там понимать:
VD>

VD>while (variable = 1)
VD>    ...
VD>

VD>вместо
VD>

VD>while (variable == 1)
VD>    ...
VD>

VD>и приплызд. Хотя конечно это могли быть проблемы компилятора который у меня тогда был.
Современные компилеры вроде бы на такую конструкцию давно warning выдают.

E>>Никто не подскажет программисту убрать однажды написанный ignore.
VD>Я вообще не понял, что ты пытался сказать. Зачем что-то убирать? Или ты явно выражашь намерение проигнорировать результат, или ты используешь результат. В обратном случае получаешь сообщение компилятора. Таким образом ты физически не можешь проигнорировать значение функции по невнимательности.
VD>Ошибка — эта очень частая.
ИМХО если человек делает такие ошибки то ему следует озаботиться о повышении квалификации. Потому как ошибка крайне глупая, и свидетельствует либо о невнимательности/небрежности сделавшего ее, либо о том, что название функции не достаточно понятно отражает ее суть.

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

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

Д>Интересная тенденция — многие знакомые мне программисты на Яве любят давить исключения в зародыше, чтобы не париться с декларированием этого исключения по всему стеку функций до того места, где его можно разумно обработать. А для обработки ошибок используют..... коды возврата (здравствуй, каменный век!)
Д>Вот так то. Эта фича только на первый взгляд кажется такой хорошей, на деле же всё совсем не так бело и пушисто.

Интересные знакомые.
Вы там скажите им, если время будет, что в Java есть и unchecked exceptions (extends RuntimeException).

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

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

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

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

Не знаю, не знаю. Меня вот в Эрланге последнее время скобки с запятыми сильно напрягают. Лисповский стиль и стиль языков с каррингом (они близки по сути — каждый аргумент берется в скобки) существенно читабельнее на вложенных конструкциях, а их необычайно много в функциональном коде.

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

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

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

Д>Интересная тенденция — многие знакомые мне программисты на Яве любят давить исключения в зародыше, чтобы не париться с декларированием этого исключения по всему стеку функций до того места, где его можно разумно обработать. А для обработки ошибок используют..... коды возврата (здравствуй, каменный век!)
Д>Вот так то. Эта фича только на первый взгляд кажется такой хорошей, на деле же всё совсем не так бело и пушисто.

Да, согласен, у твоих знакомых каменный век. Но причем тут Жава?

Стандартный патерн, это декларировать свой собственный InternalException, который имеют все функции и кучу наследников от него.
Далее, весь стафф который кидается внутри функции другими фреймворками, например в EJB — CreationException, становится cause для InternalException.

Обрабатывай не хочу.

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

Влад, да хватит уже плакатом размахивать

[RSDN@Home][1.2.0][alpha][655]
[Во всякой стране молодое поколение — всегда иностранцы. [А. Сталь]]

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

D>Да, согласен, у твоих знакомых каменный век. Но причем тут Жава?
При том, что такой каменный век и стал одним из основных мотивов отказа от checked exceptions в дотнете. После анализа паттернов применения checked exceptions, девелоперы из Микрософт пришли к выводу, что они вынуждают девелоперов заниматься нехорошими практиками. В том числе перевыбрасыванием исключений (ведущем к потере инфррмации), и проглатыванием исключений (которое рушит всю идею на корню).

D>Стандартный патерн, это декларировать свой собственный InternalException, который имеют все функции и кучу наследников от него.
D>Далее, весь стафф который кидается внутри функции другими фреймворками, например в EJB — CreationException, становится cause для InternalException.

D>Обрабатывай не хочу.
Не хочу. Вот я в свое время с этим сильно ругался. Невозможно сделать, к примеру, независимый от СУБД код, который обрабатывает нарушение uniqueness constraint. Потому, что вся информация заворачивается в слишком обобщенный тип исключения, и определить настоящую причину программным способом невозможно. В дотнете хотя бы nesting exceptions вшит во фреймворк, стимулируя сохранение информации.

1.1.4 stable rev. 510

Здравствуйте, Andrei N.Sobchuck, Вы писали:

K>>Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста.
ANS>А вот некоторые предлагают со Схемы вообще начинать изучать программирование.

Ну так пусть предлагают. Может для самого начала это и нормально. В основном потому, что вся интеллектуальная продукция человеческой цивилизации будет для него, как схема-программиста, только источником вредных привычек. Так что с чистого листа — и в полной изоляции. Я даже представляю себе такого маугли, воспитанного схемой.
Просто существуют такие общепринятые языки, как математическая нотация и так далее. Для человека, который ничего о математике и не слыхивал (+ a b) может и не отличается ничем от a+b, но человек привыкший к инфиксным опрераторам наврятли не увидит между ними разницы.

Вот первый код на Haskell, который вероятнее всего увидит начинающий программист:

factorial 0 = 1
factorial n = n * factorial (n-1)

Лично у меня вообще никаких вопросов небыло. Это, фактически, декларативное определение факториала.
А вот первый код на Scheme:

 (define (factorial n)
   (if (= n 0)
     1
     (* n (factorial (- n 1)))))

Код мне понятен, но выглядит он, мягко говоря, по-марсиански.
Допустим, что через некоторое время можно привыкнуть, но зачем? Какие это даст преимущетсва?

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

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

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

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

Т>

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

(c)Klapaucius

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

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

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

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

Это заказ военных.
K>>В том то и дело, что в Ada в некоторых случаях нельзя, но если очень хочется, то можно. А потом Ариан 5 падает. Так что такое нельзя не считается.
G>Какое такое нельзя? Я что, неправильно назвал основную мотивацию при разработке Ады? Ничего, кроме этого я не сказал, и сказать, что характерно, не хотел. С чем спорим?

Основную — ,как мне кажется, неправильно. Это одна из многих мотиваций, только и всего.
Требования военных к Аде можно прочитать, кажется, здесь
Если я правильно понял, то основная мотивация для создания Ады — сокращение количества языков, используемых для разработки ПО для Мин.обороны. Ада это такой F-111 в программировании. Такие идеи в то время вообще были популярны в военной среде.
Причем, что характерно, Ада не является каким-то симплистичным языком. Скорее уж навороченным. Хотя maintainability и simplicity для него такие же необходимые требования как и другие прочие. Впрочем, хорошо видно, что требования противоречивы достаточно для того, чтобы все было принесено в жертву всему. Что и произошло.

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

Тебе кажется, я что-то очень сложное и хитрое тебе доказать хочу?

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

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

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

? Мне уже стало интересно.

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

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

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

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

.

И это правильно.

G>Таким образом, главная причина местный восторгов станет не относящейся к делу.

Мне не кажется, что это причина — главная.

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

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

K>Основную — ,как мне кажется, неправильно. Это одна из многих мотиваций, только и всего.
Хм, возможно.

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

Тебе кажется, я что-то очень сложное и хитрое тебе доказать хочу?

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

K>Просто как иллюстрация того, что убогость безопасности не добавляет, а мощность, как раз таки да.
Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

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

Это плюс.

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

Это — минус

G>>Таким образом, главная причина местный восторгов станет не относящейся к делу.

K>Мне не кажется, что это причина — главная.

Ну, я почитал ветку, и типовые вопросы. Из того, что я видел — чаще всего упоминаются именно макросредства, процентов на 99. Хотите опрос проведем, кстати?

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

E> Т.е. нужно учится, учится и еще раз учится.

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

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

Такие, что написанную на Nemerle функциональность вредоносные люди будут дёргать из кода, написанного ими на Visual Basic, языке, разработанном специально для таких, как они.

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

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

И такие, по твоему, и без инструмента обойдутся? Кто-то ведь должен делать НАСТОЯЩИЕ инструменты. Не всем же совковые лопаты лабать.

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

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

W> И такие, по твоему, и без инструмента обойдутся? Кто-то ведь должен делать НАСТОЯЩИЕ инструменты. Не всем же совковые лопаты лабать.

В ответ на это и на предыдущие ваши сообщения: я считаю, что должны быть сложные и мощные инструменты. Я знаю, что успешно, эффективно и без больших проблем такие инструменты будут использоваться небольшими высокопроффесиональными командами (в которых умные люди не могу поглупеть из-за стадного инстинкта). Что для некоторых проектов именно формула "идея + маленькая команда + мощный инструмент" является залогом успеха. Но, такой инструмент не может быть широко распространенным (популярным). По определению. И Nemerle похож на такой мощный но не простой инструмент. А если это действительно так (если, поскольку только время и жизнь расставит все на свои места), то и ему распростаненность и популярность не грозит (но это не есть "отсутствие будущего"). О чем я и сказал в теме, которая была посвящена проблемам будущего Nemerle.

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

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

G>Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

хотелось бы узнать ваше мнение. tex -- это плохой язык, или нет?

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

G>Это — минус

+1

G>Ну, я почитал ветку, и типовые вопросы. Из того, что я видел — чаще всего упоминаются именно макросредства, процентов на 99.

+1

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

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

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

W> А если тебе не нужен язык? Если нужно сразу много языков, и ты не знаешь, каких именно? Как тут без макросов?
Честно? Мое ИМХО — если не знаешь, каких именно, но при этом почему-то точно знаешь, что нужно много языков — я бы посоветовал бросить программирование, лучше заняться чем-нибудь другим.

G>> Инженеры из моего отдела придерживаются такого же мнения.
W> Они не в теме. Некомпетентны.

Гхм. Как мне повезло — не часто встретишь в форуме такого компетентного гуру, как Вы.

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

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

G>>Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

NB>хотелось бы узнать ваше мнение. tex -- это плохой язык, или нет?
Я не оперирую понятиями добра и зла, так что не могу однозначно сказать "плохой" tex язык или нет. Но, скажем, решать на нем численно диффуры я бы не стал, как и писать на нем веб-сервер. Т.е. тех — это не совсем тот язык, который стоило бы приводить в пример. Макроассемблер гораздо лучший пример — на нем много софта писали в 70-е.

Также, хочу заметить, что
1) ядро tex писалось одним человеком (Кнутом), и maintainability тут не особо играет. Ну и кроме того, кнут это кнут. Он, зараза, пишет почти без ошибок на чем угодно.
2) Пользователи теха обычно не определяют своих макросов — все расширения теха стандартизованы (Latex, например, или AMStex).
3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

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

G>>>Если бы "убогость" == "отсутствие макросов" — то я бы сказал, что это возражение. Я не выставлял убогость в качестве свойства, повышающего maintainability. Я выдвинул тезис, что макросы его ухудшат, потому что люди есть люди, они такие, какие есть (криворукие), и что хорошему языку макросы не нужны. Готов поспорить с возражениями к этим тезисам.

NB>>хотелось бы узнать ваше мнение. tex -- это плохой язык, или нет?
G>Я не оперирую понятиями добра и зла, так что не могу однозначно сказать "плохой" tex язык или нет.

Спрошу по-другому, tex -- это хороший язык (учитывая выделенное), или нет?

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

Спросил про тех, потому что догадываюсь о вашем отношении к ниму

Без макросов он был бы совсем другим.

G>Также, хочу заметить, что
G>1) ядро tex писалось одним человеком (Кнутом), и maintainability тут не особо играет. Ну и кроме того, кнут это кнут. Он, зараза, пишет почти без ошибок на чем угодно.

но используют его не только Кнут.

G>2) Пользователи теха обычно не определяют своих макросов — все расширения теха стандартизованы (Latex, например, или AMStex).

Да. Именно мощьная система макросов позволила создать Латех.
Почемы вы лишаете такой возможности другие языки.
Кстати, только не говорите что у вас нет своих макросов. Их делает каждый, кто прочел "Все про тех"

G>3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?

PS: мне не очень нравятся истерические вопли вокруг Nemerle, но сам то язык в этом не виноват. Думается, его проблемы не в макросистеме.

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

>> А если тебе не нужен язык? Если нужно сразу много языков, и ты не
>> знаешь, каких именно? Как тут без макросов?
C>Пишешь компилятор — и вперед.

Долго и дорого. А с макросами у нас уже есть на халяву хороший компилятор.

C> А еще лучше — берется какой-нибудь
C>интерпретатор с гибким синтаксисом и прикручивается.

То есть — таки макросы, да? Да и медленно это, не всегда интерпретатор выдюжит задачу.

>> G> Инженеры из моего отдела придерживаются такого же мнения.
>> Они не в теме. Некомпетентны.
C>Ага, конечно. Вероятно хорошо развиты телепатические способности.

Весьма хорошо развиты. Вы угодали. Возможно и у вас в своё время проявятся в полную силу.

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

E>Но, такой инструмент не может быть широко распространенным (популярным).

И хвала Аллаху за это.

E> По определению. И Nemerle похож на такой мощный но не простой инструмент.

Не похож. Он таковым просто является.

E> А если это действительно так (если, поскольку только время и жизнь расставит все на свои места), то и ему распростаненность и популярность не грозит (но это не есть "отсутствие будущего").

Не грозит. Если б грозила, я б его и смотреть не стал — зачем вскакивать на поезд, который потом неизбежно пойдёт под откос? Я рад, что с Питона соскочил довольно рано, до того ещё, как пошли разговоры про "на фиг lambda, на фиг reduce".

E>Так что я в большей степени согласен с вашими замечаниями, чем вам это может показаться.

Ok, fixed.

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

NB>Спрошу по-другому, tex -- это хороший язык (учитывая выделенное), или нет?

Да, но это не язык программирования в обычном смысле этого слова, сравнивать некорректно

.

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

NB>Спросил про тех, потому что догадываюсь о вашем отношении к ниму

NB>Без макросов он был бы совсем другим.

NB>Да. Именно мощьная система макросов позволила создать Латех.
NB>Почемы вы лишаете такой возможности другие языки.

Конечно. Макросы и [макро]замена — естественная вещь для обработки текста, к этому сводится сама суть его обработки. Слава богу, на семантику самого текста макросы теха не влияют, не так-ли (поэтому на его понимании не сказываются)? Этим они и отличаются от макросов в языках программирования.

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

G>>3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

NB>Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?
Ну вот это и есть ответ на ваши вопросы — почему я возражаю против аналогии с тех-ом, вроде вы с этим согласны. Конкретные примеры я привел в http://rsdn.ru/Forum/Message.aspx?mid=2050485&only=1

NB>PS: мне не очень нравятся истерические вопли вокруг Nemerle, но сам то язык в этом не виноват. Думается, его проблемы не в макросистеме.
Не знаю, в чем его проблемы, и это не особенно мне интересно. Я возражаю против конкретного пункта, вокруг которого истерика — макросы.

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

NB>>Да. Именно мощьная система макросов позволила создать Латех.
NB>>Почемы вы лишаете такой возможности другие языки.

G>Конечно. Макросы и [макро]замена — естественная вещь для обработки текста, к этому сводится сама суть его обработки.

Тогда еще вопрос. Зачем нужны макросы.
ИМХО, они позволяют
1. избежать дублирования кода.
2. описывать проблему в терминах этой самой проблемы.

Что из перечисленного мешает сопровождению кода.

G>Слава богу, на семантику самого текста макросы теха не влияют, не так-ли (поэтому на его понимании не сказываются)? Этим они и отличаются от макросов в языках программирования.

Тут не совсем ясно, что есть семантика теховского текста.
Например пакет listings меняет семантику, или нет?

G>>>3) Обработка и генерация текстов по сути своей состоит из [макро]замен и подстановок. Тех имеет больше общего со всякими XSLT, которые при большой фантазии тоже можно назвать "макросами". Когда тех интерпретирует исходный файл, он запускает макросы, преобразуя исходный текст в другой. Когда я пишу в корпоративную вики, я тоже люблю определять макросы, чтобы облегчиь разметку текста. Когда вы пишете статью — пользоваться макросами естественно. Только программная система — не статья.

NB>>Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?
G>Ну вот это и есть ответ на ваши вопросы — почему я возражаю против аналогии с тех-ом, вроде вы с этим согласны. Конкретные примеры я привел в http://rsdn.ru/Forum/Message.aspx?mid=2050485&only=1

я наверное тупой.

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

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

NB>Тогда еще вопрос. Зачем нужны макросы.
NB>ИМХО, они позволяют
NB>1. избежать дублирования кода.
Самые обычные функции с этим прекрасно справляются.

NB>2. описывать проблему в терминах этой самой проблемы.
Адекватный выбор идентификаторов прекрасно позволяет это сделать.

Попробуй привести конкретные прикладные примеры, показывающие, когда это работать не будет.

NB>Что из перечисленного мешает сопровождению кода.

Примеры мои смотрел? Или я впустую пишу?

NB>>>Здесь не спорю. Однако если один подход успешно работает в одной области, почему бы не применить его в другой?
G>>Ну вот это и есть ответ на ваши вопросы — почему я возражаю против аналогии с тех-ом, вроде вы с этим согласны. Конкретные примеры я привел в http://rsdn.ru/Forum/Message.aspx?mid=2050485&only=1

NB>я наверное тупой.

NB>не понимаю, что мешает перенести плюсы теха на другие языки.
Нет, это я, наверное, тупой. Либо ты не внимательно читал пример. И так уже все разжевал настолько, насколько это ИМХО возможно, больше не могу, извини.

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

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

NB>>Тогда еще вопрос. Зачем нужны макросы.
NB>>ИМХО, они позволяют
NB>>1. избежать дублирования кода.
G>Самые обычные функции с этим прекрасно справляются.

ну вот из последнего

#define MAKE_BINARY_OP(NAME,name,T1,OP,T2,RET) \
  struct NAME : lambda::Lambda<NAME>           \
  {                                            \
...
  } const name = NAME ();                      \
                                               \
  template< typename T1,typename T2 >          \
  lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > operator OP ( T1 const & x, T2 const & y ) { \
    return lambda::proxy< NAME, lambda::tuple<T1 const, T2 const> > ( name, lambda::make_tuple (x,y) ); \
  }

MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)

как сделать с помощью функций?

NB>>2. описывать проблему в терминах этой самой проблемы.
G>Адекватный выбор идентификаторов прекрасно позволяет это сделать.

G>Попробуй привести конкретные прикладные примеры, показывающие, когда это работать не будет.

NB>>Что из перечисленного мешает сопровождению кода.

G>Примеры мои смотрел? Или я впустую пишу?

ладно, давай рассмотрим.

a = b + c + d

что предлагается взамен?

NB>>гибкость теха позволяет писать запутанный текст. но это не делает его плохим языком.
NB>>сообщество выработало стиль, устраняющий эту проблему.
NB>>что препятствут другим пойти этим путем?
G>Ничего. Иди этим путем. В третий раз подряд объяснять разницу между тех-ом и языками программирования у меня нет сил, извини. Пиши с макросами, я не против.

спасибо тебе, добрый человек.

у меня без твоего разрешения работа стояла...

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

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

VD>Ява отнюдь не примитивный язык. Ява 1.5 вообще-то еще тот монстрик. Вложенные классы с замыканиями, безымянные классы, дженерики, сахар вроде foreach...

Вложенные классы и анонимные классы были в Java очень давно, чуть ли не с рождения.

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

забавная описка, однако.

VD>

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

понятность этого фрагмента лично у меня вызывает большие сомнения

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

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

Кто тебе сказал, что не трогает. Очень даже трогает. C++ и Ruby -- это языки для маленьких команд, на них удобно делать проекты в одиночку или с двумя-тремя коллегами. Но, как только в команду попадает слабый разработчик или кто-то помещает в проект отстойный (например, из-за нехватки времени) код, то все, приплыздец натупает.

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

Правда действительно тривиальна. К Nemerle я уже давно отношусь очень спокойно. Из-за своей .NET-овской привязки он просто-напросто лежит в стороне от моих интересов.

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

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

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

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

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

VD>Ну, вторую версию (ту что вошла в стандарт) С++ как раз разрабатывал комит.

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

VD>Да и Паскаль сыскал невероятную популярность в свое время. Так что ты лукавишь.

Тот паскаль, который стал популярным в виде Turbo Pascal/Borland Pascal/Dephi и Object Pascal на MacOS был очень сильно модернизированным вариантом исходного Виртовского паскаля. И эти модернезированные варианты отнюдь не коммитеты и не ученые делали.

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

Ты недоговариваешь одной важной вещи: кроме простоты в языке должны быть еще достаточные возможности.

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

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

Тогда объясни, что произошло с Ada. И с Eiffel.

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

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

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

NB>>>>Тогда еще вопрос. Зачем нужны макросы.
NB>>>>ИМХО, они позволяют
NB>>>>1. избежать дублирования кода.
G>>>Самые обычные функции с этим прекрасно справляются.

NB>>ну вот из последнего
NB>>

NB>>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>>

NB>>как сделать с помощью функций?

G>Лямбда должна поддерживаться языком. И тогда этот ужас просто не нужен. Тем более, что нормальную лямбду ты все равно не сделаешь, хоть обложись макросами — все равно в мало-мальски сложном случае придется объявлять функтор.

чтобы не было вырвано из контекста: http://aleksey.loginov.googlepages.com/index.html
стандартные функторы (plus,bind1st,equal,...) заменяет прекрасно.
при отсутствии нормальной лямбды, увеличивает читаемость в разы.
например, удаление дублирующихся пробелов:

unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );

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

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

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

NB>>>>>Тогда еще вопрос. Зачем нужны макросы.
NB>>>>>ИМХО, они позволяют
NB>>>>>1. избежать дублирования кода.
G>>>>Самые обычные функции с этим прекрасно справляются.

NB>>>ну вот из последнего
NB>>>

NB>>>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>>>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>>>

NB>>>как сделать с помощью функций?

G>>Лямбда должна поддерживаться языком. И тогда этот ужас просто не нужен. Тем более, что нормальную лямбду ты все равно не сделаешь, хоть обложись макросами — все равно в мало-мальски сложном случае придется объявлять функтор.

NB>чтобы не было вырвано из контекста: http://aleksey.loginov.googlepages.com/index.html
NB>стандартные функторы (plus,bind1st,equal,...) заменяет прекрасно.
NB>при отсутствии нормальной лямбды, увеличивает читаемость в разы.
NB>например, удаление дублирующихся пробелов:
NB>

NB>unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );
NB>

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

Чем это радикально лучше вот этого:

bool my_fun( char x, char y ) { return x == y && y == ' '; }

...
unique(str.begin(),str.end(), my_fun );
...

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

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

NB>>а в твоем мозгу произошел большой взрыв, чтобы понять написанное?

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

.

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

struct Pair : lambda::Lambda<Pair>
{
    template<typename First, typename Second>
    struct sig : std::binary_function < First, Second, std::pair<First,Second> > {};

    template<typename First, typename Second>
    typename sig<First,Second>::result_type operator () ( First & x, Second & y ) const {
        return std::make_pair (x,y);
    }

} const pair = Pair ();

согласен, новый человек без чтения документации такое врядли напишет

G>Скорее я предпочту написать одну функцию, как это сделано у меня — так гораздо проще и быстрее, чем тратить время на понимание устройства и ограничений лямбды по твоему коду.

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

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

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

NB>>

NB>>unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );
NB>>

G>Чем это радикально лучше вот этого:
G>

G>bool my_fun( char x, char y ) { return x == y && y == ' '; }

G>...
G>unique(str.begin(),str.end(), my_fun );
G>...
G>

Мне кажется, что чем больше расстояние между строкой

bool my_fun( char x, char y ) { return x == y && y == ' '; }

и строкой

unique(str.begin(),str.end(), my_fun );

тем хуже это будет читаться.

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

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

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

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

K>Мне кажется, что чем больше расстояние между строкой
K>

K>bool my_fun( char x, char y ) { return x == y && y == ' '; }
K>

K>и строкой
K>

K>unique(str.begin(),str.end(), my_fun );
K>

K>тем хуже это будет читаться.

Это так. На самом деле расстояние не особо важно — все равно определение такой функции ищется поиском. И это сделать существенно проще, чем разбираться с устройством лямбды или добавлять в лямбду свои операторы — тут даже и говорить не о чем. Код с функцией поймет с ходу любой человек, знакомый на С++ на среднем уровне. Что не скажешь про "лямбду".

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

K>Все-таки сложность несколько преувеличена.
Преувеличена?

Знаешь, когда на мне висит дефект или suggestion первого приоритета, мне типа делать больше нефиг, как разбираться с реализацией "простой" лямбды, из-за того, что кому-то было лень лишнюю строку кода добавить, или казалось, что "так некрасиво".

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

Да не будет она часто встречаться. Как только встанет необходимость внутри дурацкой "лямбды" сделать что-нибудь нетривиальное, кроме x==y, любой вменяемый разработчик выкинет ее к чертям собачьим и заменит функцией — и все сделает за 1 минуту.

K>Но с тем, что в нормальном языке такие вещи должны быть я полностью согласен.
О чем и речь. Вопрос — нафига нам макросы в нормальном языке? Почему они бывают популярны в ненормальном — понятно, люди пытаются править эти ненормальности. Да и то, нафиг-нафиг. Лучше уж ненормальный язык, но знакомый и предсказуемый, чем "исправленый" макросами.

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

C>Gaperton wrote:
>> Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка
>> и слабости системы типов.
C>НЕТ! Паттерн — это конкретный прием программирования.

Вопрос точки зрения. Я считаю что ДА. А дальше свой тезис иллюстрирую примером. А вы?

>> Большое количество паттернов, которые надо
>> знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по
>> грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь —
>> исключительно для примера — эрланг, как видим, так и пишем, например так:
C>И что? В Эрланге паттерн "конечный автомат" просто вмонтирован в
C>сам язык.

Да вы что

. А "квиксорт" туда нне "вмонирован" — ведь там квиксорт записывается в 4 строки

? Может, туда вмонтированы все алгоритмы на деревьях? И вообще — черт знает что туда вмонтировано, но

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

Я вот ничего кроме обыкновенных вызовов функций и паттерн-матчинга в своем примере ничего не вижу. Оба механизма, знаете-ли, немного более общи и фундаментальны, чем какой-то там паттерн "конечный автомат".

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

C>Точно так же, в С можно сделать паттерн "наследование", а в С++ он уже
C>вмонтирован.

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

>> и так далее. Вопрос: куда девался навороченный паттерн с double
>> dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь
>> макросы?
C>Он просто реализуется по-другому.
Вот именно.

По другому.

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

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

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

Д>Нет там ничего подобного. Мануал ты читал или по диагонали, или просто ничего в нем не понял.
Д>Может быть, тебе просто не хочется признаться даже самому себе, что ты потратил время и силы на Руби зря?

Я уже показывал (Re[5]: Питон наступает :)) что практически все примеры использования макросов с немерлевского сайта легко реализуются на питоне, думаю на руби это сделать не сложнее. Так что есть.

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

G>Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка и слабости системы типов. Большое количество паттернов, которые надо знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь — исключительно для примера — эрланг, как видим, так и пишем, например так:

G>Облегчим себе жизнь в одну строку:
G>switch( { State, Data }, Transition ) -> State( Transition, Data ).

G>И поехали описывать автомат:

G>state1( { ivegotevent1, EventData }, StateData ) -> ... { stateN, NewData }
G>state1( { ivegotevent2, EventData }, StateData ) ->

G>и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

Возможно не самый известный факт, но pattern matching в переписывающих языках вообще и в функциональных в частности реализуется обычно именно через конечный автомат. Не совсем обычный правда, а для т.н. Tree Languages, но тем не менее.
В этом вообще говоря очень много смысла — связь между автоматами и логикой (особенно переписывающей, включая лямбда-исчисление) — это очень важная часть современного CS.

То есть этот пример — скорее пример использования уже готового автомата

Что, впрочем, ни на секунду не уменьшает его полезности: автоматы — штуки, неисчерпаемые как электрон и жизнь облегчают постоянно и везде.
А вот программировать их на ОО-языках — это одно мучение, да. Я вот именно сейчас как раз занимаюсь тем, что пытаюсь сделать дизайн такого автомата на Java. На чистом Си было бы легче.

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

Умно говоришь.

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

G>и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

На немерле это пишется примерно также и без единого макроса.

variant State
{
    | State1 { i : int; }
    | State2 { s : string; }
}
variant Event
{
    | Event1 { f : float; }
    | Event2 { l : list[string]; }
}
def fsm(_ : State, _ : Event) : State
{
| (State1 as s, Event1 as e) => State.State2("ads");
| (State2 as s, Event1 as e) => State.State1(123);
...
}

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

Пришлось копипастить.

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

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

K>>Теперь, для чего нормальному языку макросы, которые не меняют синтаксис. Для решения тех задач, которые сейчас решают кодогенераторами, я полагаю. Чем кодогенератор, который может быть недоступен и куча нагенеренного им кода лучше, чем макросы в данном случае?
K>>Или чем лучше выделение паттерна проектирования в коде, а перед тем его реализация, чем простая декларация?
G>Давайте перейдем к конкретным примерам, и все станет ясно.

Вообще-то мы говорим не о какой-то конкретной ситуации, чтобы решить нужны для данного конкретного случая макросы или нет, а обсуждаем такое вот Ваше утверждение:

Вопрос — нафига нам макросы в нормальном языке? Почему они бывают популярны в ненормальном — понятно, люди пытаются править эти ненормальности. Да и то, нафиг-нафиг. Лучше уж ненормальный язык, но знакомый и предсказуемый, чем "исправленый" макросами.

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

Вот только какой язык считать нормальным?

G>Предлагайте пример, где помогают макросы, обсудим.

Пример привести легко. Генерация кода сериализации в compile time. Но, как я сказал выше, это к делу не относится.
Что характерно, привести примеры пагубного влияния изменения синтаксиса на maintainability для Вас большого труда не составило, однако с макросами, не меняющими синтаксис вышла заминка.

G>Кстати, знаете, что такое "паттерн"?

Возможно.

G>Это типовая обходка кривизны языка и слабости системы типов.

В некоторых случаях так и есть, но далеко не во всех.

G>Большое количество паттернов, которые надо знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь — исключительно для примера — эрланг, как видим, так и пишем, например так:
G>Облегчим себе жизнь в одну строку:

switch( { State, Data }, Transition ) -> State( Transition, Data ).

G>И поехали описывать автомат:

state1( { ivegotevent1, EventData }, StateData ) -> ... { stateN, NewData }
state1( { ivegotevent2, EventData }, StateData ) ->

G>и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

Пример, по-моему, не очень удачный. FSM как раз к разряду костылей не относится. Ответ: Паттерн никуда не девался. Просто он реализован не "по грамотному, по ООП-шному, в С++", а с помощью pattern matching (впрочем, я Erlang не знаю, могу и ошибаться) и, что вополне естественно, выглядит значительно элегантнее.

Возвращаясь к нормальному языку. Что Вы под словом "нормальный" подразумеваете можно вывести разве только из того самого утверждения.
Я вижу три варианта
1) Это язык в котором и так все есть. Поэтому макросы не нужны. Я даже не знаю, страшно это или смешно. Наверное и то и другое. Но, к счастью, это не возможно.
2) Это язык в котором есть все, что надо, а если чего-то нет, то вам этого и не надо. Подход знакомый, хорошо опробованный, но не без недостаков. В частности, всегда выясняется, что тот, кто принимал решения что нам всем нужно ошибался.
3) Это язык, в котором можно сделать (почти)все что нужно, но без всяких макросов. Мне не особо нравится. Макросы одним своим существованием хоть как-то выделяют "рискованное" подмножество возможностей, чего от таких "нормальных" языков ожидать не приходится.

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

K>>В чем принципиальная разница таких макросов и других параметрических типов? Тип может быть параметризован другим типом или веткой AST. Или любые параметрические типы — это одни проблемы?
G>Нет, почему же, параметрические типы это хорошо. Я пожалуй попрошу вас показать, чем он отличается от макроса, а то я не вполне понимаю, о чем речь. Ну, и что такое "тип, параметризованный веткой AST", тоже непонятно.

Ну пусть лучше будет — выражением. Это так, на правах бреда, близко к сердцу не принимайте.
В принципе, параметрических тип это что-то вроде

Type -> Type

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

Expr -> Expr

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

Expr*Type -> Type

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

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

От:	Gaperton	http://gaperton.livejournal.com
Дата:	11.08.06 10:47
Оценка:	6 (2) +6

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

От:	Gaperton	http://gaperton.livejournal.com
Дата:	17.08.06 21:16
Оценка:	+7 -1

От:	IT	linq2db.com
Дата:	14.08.06 17:24
Оценка:	44 (4) +2

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

	От:	Klapaucius
	Дата:	11.08.06 22:00
	Оценка:	36 (2) +2

	От:	Дарней
	Дата:	15.08.06 01:11
	Оценка:	+1 -2

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

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

	От:	Dr.Gigabit
	Дата:	13.08.06 07:51
	Оценка:	+2 -1

	От:	Трурль
	Дата:	22.08.06 16:04
	Оценка:	3 (1)

От:	adontz	http://adontz.wordpress.com/
Дата:	13.08.06 21:36
Оценка:	+1

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	14.08.06 13:00
Оценка:	+1

От:	Mamut	http://dmitriid.com
Дата:	14.08.06 14:34
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	17.08.06 06:34
Оценка:

	От:	Cyberax
	Дата:	21.08.06 08:19
	Оценка:	+2

	От:	Sheridan
	Дата:	24.08.06 10:19
	Оценка:	+1