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

G>>Могу сказать про себя — я в таких случаях делал свой парсер и свою виртуальную машину. Благо что ФОРТ-машина, как и парсеры, делается элементарно, быстро и на автомате — не успеешь сказать "немерле". DSL-и были очень специфические, это были языки описания торговых систем и преобразований временных рядов, и для них не было ну совершенно никакого известного инструмента.

L>Ну! О чем и речь.
L>Если задаче нужен DSL, а известного нет, то его приходится писать. А макросы в этом деле неплохо помогают. Я, честно говоря, даже не представляю, зачем мне писать на лиспе, у которого нет макросов.

L>В общем то это моя вина. Из-за категоричности твоих постов я решил, что ты противник макросов.
Чтобы расставить точки над "i" — я сторонник чрезвычайно осторожного обращения с макросами, т.е. я действительно противник их [широкого] применения. Подробности здесь http://rsdn.ru/Forum/Message.aspx?mid=2048270&only=1

Автор: Gaperton
Дата: 08.08.06

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

В этом и состоит мое отличие от точки зрения большинства здесь — я совсем не в восторге от лекости метапрограммирования в Немерле, считая это в реальности очень небольшим плюсом. То, что он .NET-based, для меня еще более снижает его ценность как средства создания DSL — его не так просто встроить в другой процесс, как, например, LISP, Python, LUA, etc.

И это нормально. У меня свои задачи и своя точка зрения, у других может быть другая. Форум нужен, чтобы делиться точками зрения, не так ли?

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

L>>В общем то это моя вина. Из-за категоричности твоих постов я решил, что ты противник макросов.
G>Чтобы расставить точки над "i" — я сторонник чрезвычайно осторожного обращения с макросами, т.е. я действительно противник их [широкого] применения. Подробности здесь http://rsdn.ru/Forum/Message.aspx?mid=2048270&only=1

Автор: Gaperton
Дата: 08.08.06

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

В общем, я скатываюсь в банальщину.

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

Конечно. Только я считаю, что совсем не учитывать этот фактор тоже не очень правильно.

G>В этом и состоит мое отличие от точки зрения большинства здесь — я совсем не в восторге от лекости метапрограммирования в Немерле, считая это в реальности очень небольшим плюсом. То, что он .NET-based, для меня еще более снижает его ценность как средства создания DSL — его не так просто встроить в другой процесс, как, например, LISP, Python, LUA, etc.

Я тоже не в восторге от макросов в Немерле :-) Но причина у меня другая и очень субъективная — в Лиспе я создаю свой язык, а в Немерле надстраиваю имеющийся. Ну и еще в Лиспе не надо что то добавлять к синтаксису, чтобы добавить макры. В Немерле это как отдельный инструмент. Ну, т.е. я его так воспринимаю.

G>И это нормально. У меня свои задачи и своя точка зрения, у других может быть другая. Форум нужен, чтобы делиться точками зрения, не так ли?

Да. Создание своей шкалы ценностей — дело опыта. У тебя макры и DSL-и находятся пониже на этой шкале, у меня повыше.

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

[большую часть удалил]
G>Так что у нас в конторе Немерле не будет. Мы жить хотим. Вдруг в ком-нибудь неожиданно проснется талант Брайана Белла?

перечитайте пож. ваш NDA.

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

G>Да вот посмотрите, что тут один дядька пишет на эту тему...

G>

G>I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."

G>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

G>The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

G>Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99.

G>Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ

Что-то я про макросы не разглядел, в какой именно строчке это выражено?

G>сделают их сложнее для понимания другим человеком, даже если он мега-гуру.

Макросы сами по себе и усложнение понимабельности кода никак между собой не связаны. Вообще! С тем же успехом можно запретить команду copy/paste в среде разработки. Вот уж действительно вещь, которая нанесла и ещё не раз нанесёт непоправимый урон простоте кода. А вот с макросами можно писать наоборот, очень простой, понятный и отжатый от всего лишнего бизнес код.

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

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

Legacy code всегда был проблемой. И эта проблема, в первую очередь, усугубляется объёмом этого самого кода. Во вторую — его запутанностью. Чаще всего объёмность и запутанность ходят вместе. Но вот кто и когда успел поставить знак равенства между макросами и объёмностью и запутанностью, мне не понятно Код с макросами, краткий, но непонятный на первый взгляд (хотя опять же почему непонятный?) в любом случае будет гораздо проще сопровождать чем накопипейсченный или того хуже изуродованный бредовым дизайном какого-нибудь Брайана Белла.

В общем, связь между макросами и ухудшением maintainability пока плохо улавливается.

G>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.

А что насчёт неадекватного применения design patterns, кнопки копи/пейст, генераторов кода, которые потом теряются или меняются, а нагенерированные ими десятки тысяч строк остаются? Что делать с ленью девелоперов, тупостью архитекторов и близорукостью менеджеров? Это всё тоже очень сильно сказывается на обеспечении maintainability. Или запрет макросов одним махом решит все эти проблемы? Я сомневаюсь. Макросы — штука мощная, но однозначно разрушительной она может стать только у тех, у кого и без макросов проблем выше крыши.

G>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...

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

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

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

Как интересно. А что же он тогда позволил писать макросы в ТеХ?

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

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

G>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.

Понятное дело, что использование макросов для DSL надо контролировать. Но макросы не виноваты, что ими пользовался кто-то криворукий. Более того, скажу, что в одной из крупнейших российских компаний своими глазами наблюдал ужасающий DSL на основе XML реализованный на C++ с использованием COM. Более гнусной вещи еще не встречал. И при этом руководство прекрасно знало о его недостатках, но не вмешалось и не заставила его переделать.

G>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...

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

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

O>[большую часть удалил]
G>>Так что у нас в конторе Немерле не будет. Мы жить хотим. Вдруг в ком-нибудь неожиданно проснется талант Брайана Белла?

O>перечитайте пож. ваш NDA.

И? Думаете я раскрыл нечто, что даст конкурентам CQG решающее преимущество? Теперь, после моего поста, и упоминания волшебных слов FLO и GOC вам стало ясно, как делать программные комплексы класса CQG, состоящие из десятка типов серверов, нескольких десятков клиентских подсистем, и содержащие миллионы строк кода? Флаг вам в руки.

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

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

Моя вина в нечеткой формулировке. Беда, конечно же, не в изобилии эмоциональных суждений, а в отсутствии каких либо иных суждений кроме эмоциональных.
Что касается характера немерлистов — то мне нет до него никакого дела, как нет дела и до замечаний, которые делаются мне из-за действий, которые совершали какие-то другие люди. Я конечно заметил, что на rsdn существует, скажем так, институт коллективной ответственности, но мне такая практика категорически не нравится.

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

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

G>Автор, очевидно, имеет в виду идеи, стоящие за literate programming, противопоставляя их пионерскому подходу "настоящих программистов", которые пишут "настоящий код не для всех". Знакомый типаж?

Более чем. Я не собираюсь оспаривать идеи, стоящие за literate programming, а то, что программы пишутся для людей — считаю самоочевидным. Я просто не согласен с тем, что автор приписывает авторам Nemerle "пионерский подход". Лично я не заметил в дизайне Nemerle каких-то особенностей, принуждающих писать криптокод. Как раз наоборот — массу возможностей писать очень понятный и легко читаемый код. Что же касается возможностей писать криптокод, то их более чем достаточно в любом известном мне языке.
Проблема криптокода, по-моему, вообще не в том, что программистов так уж сложно убедить в необходимости писать понятный код, а скорее в том, что взгляды на понятность кода у программистов зачастую кардинально расходятся.

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

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

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

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

G>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++.

Да, это так.

G>Ну и разумеется, макросы, как средство, наиболее опасное для maintainability,

Это спорное утверждение. Однако опасность существует — это факт.

G>должно находится под строгим контролем,

+1

G>и применяться очень ограничено.

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

G>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...

Это больше говорит о lisp и применении малораспространенных языков в мэйнстриме вообще, чем о злобной сущности макросов. Зло вообще в голове, а не в вещах. Просто смысл в программировании на lisp без использования макросов от меня ускользает.
С другой стороны видно, что макросы это оружие обоюдоострое. Но это о любом средстве можно сказать, за исключением тех средств от которых вообще ничего кроме вреда не бывает. Макросы дали Грэхемовскому стартапу конкурентное преимущество, а для yahoo и тех lisp-стартапов, которые планируют yahoo продаться (если такие вообще существуют) создали проблемы.
Я не спорю с тем, что то, что Грэхему хорошо — то yahoo смерть. Я не понимаю, как сама возможность писать макросы может погубить Nemerle при том, что макрописателей там всегда можно ограничить.

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

G>>>талант Брайана Белла?

O>>перечитайте пож. ваш NDA.

G>И? Думаете я раскрыл нечто, что даст конкурентам CQG решающее преимущество? Теперь, после моего поста, и упоминания волшебных слов FLO и GOC вам стало ясно, как делать программные комплексы класса CQG, состоящие из десятка типов серверов, нескольких десятков клиентских подсистем, и содержащие миллионы строк кода? Флаг вам в руки.

Раскрыл раскрыл. Теперь конкуренты наймут Браяна Белла, который поможет всё это написать и CQG разорится.

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

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

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

Q>Как интересно. А что же он тогда позволил писать макросы в ТеХ?

"Автор" — в данном случае не Кнут, а ласточкин. Он выразил это мнение, а не кнут.

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

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

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

Q>Не мог бы ты привести аргументы (а не домыслы) в пользу того, что код на макросах поддерживать труднее. Пока что я видел только ужасающий код без макросов.
Код макрос ужасающий быть может очень. Грамматика правило ввести новое я удобное мне, и хочешь понимай как. И еще человек сделают двадцать так. (определение измененной "грамматики" искать в файлах /megasystem/coolhacker_code. Файл правлен тремя людьми, с промежутком в год, а еще двое посмотрели на него, не вкурили и назвали отстоем, и написали пару своих "грамматик".).

Давай поставим вопрос так. Ты вообще на саппорте больших систем когда-нибудь работал? Систем, которым более 5 лет, которые писало человек 20, и в которых кода от миллиона строк? Если нет, то тебе сначала придется долго объяснять, в чем вообще суть понятия maintainability. А уже только потом перейти к макросам, и с переходом на яблоки, обяснить тебе разницу между определением нового термина (без макросов) и расширением синтаксиса и семантики языка (с макросами). Разница в том, что в первом случае ты, читая незнакомый код, знаешь правила его понимания, но не знаком со значением некоторых терминов, а во втором ты даже прочитать его толком не сможешь. Давай ты не будешь давать подстрочных комментариев, а дочитаешь до конца, и постараешься понять, о чем я — ты просил объяснить, я объсняю. Все таки, мы слишком давно знакомы по форуму, чтобы считать друг бруга идиотами, не так ли, Quintanar?

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

CDoSomething somethg( a, b, c );

somethg( d, e );
somethg( x, y );
somethg( w, r );
somethg( f, i );

Подсказка — этот код на самом деле оказался эквивалентен следующему:

something( a, b, c, d, e );
something( a, b, c, x, y );
something( a, b, c, w, r );
something( a, b, c, f, i );

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

Ок, здесь мы хотя бы знаем, что CDoSomething — это класс, что у него могут быть перекрыты скобки, и что там может быть что угодно. Однако, этот код уже вынуждает читателя знать о C++ много, например, что скобки можно перекрывать. А у новичка взорвет мозг. Лады, это была ерунда. Усугубляем проблему, приближаясь по силе воздействия к макросам. Вот такой код, :

a = b + c + d

где a, b, c, d — члены класса.

Что делает? А мы не знаем — то ли там перекрыт плюс, то ли присваивание имеет побочный эффект — черт его знает. Для того, чтобы понять что это, мы должны:
1) Посмотреть определение класса выяснить типы аргументов.
2) Посмотреть определение типов, проверить на предмет перекрытого =, оператора +, и (!!) операторов приведения типов, которые в свою очередь, могут указывать на другой "сложный" тип.
3) Вернуться обратно, и постараться восстановить ход мысли — ведь мы тут на самом деле проездом, и совсем по другому делу.

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

(L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
  (L|COND, 
    (L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
    (L|(L|ATOM, TREE2), NIL),
    (L|T, (L|AND,
      (L|ISOMORPHIC, (L|CAR, TREE1), 
                     (L|CAR, TREE2)),
      (L|ISOMORPHIC, (L|CDR, TREE1), 
                     (L|CDR, TREE2))
))))

Вопрос: сколько кода надо просмотреть, чтобы понять смысл этой конструкции на С++, и ход ее выполнения? При этом, не обольщяйся, вообрази, что вот такого описания http://www.intelib.org/intro.html у тебя нет, а это обычный умеренно документированный код в составе системы. Поэтому, тебы не должно смущать внешнее сходство с Лиспом — автор мог придатьэтой конструкции любой смысл. Как показывает практика — и придают любой, вплоть до противоположных по смыслу названий. Последнее, причем, обычно результат групповой работы.

G>>Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.

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

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

Q>Более того, скажу, что в одной из крупнейших российских компаний своими глазами наблюдал ужасающий DSL на основе XML реализованный на C++ с использованием COM. Более гнусной вещи еще не встречал. И при этом руководство прекрасно знало о его недостатках, но не вмешалось и не заставила его переделать.

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

G>>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...

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

Я и говорю о проблемах Яхо, а не Грэхема, если ты не заметил.

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

G>>И? Думаете я раскрыл нечто, что даст конкурентам CQG решающее преимущество? Теперь, после моего поста, и упоминания волшебных слов FLO и GOC вам стало ясно, как делать программные комплексы класса CQG, состоящие из десятка типов серверов, нескольких десятков клиентских подсистем, и содержащие миллионы строк кода? Флаг вам в руки.

ANS>Раскрыл раскрыл. Теперь конкуренты наймут Браяна Белла, который поможет всё это написать и CQG разорится.

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

Кстати, насчет Брайана в Trading Station — это идея. А то чой-то они больно шустро новые продукты выпускают, надо им мощный гандикап подложить. Обучить Брайана Nemerle — и заслать на работу в Trading Station .

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

K>Что касается характера немерлистов — то мне нет до него никакого дела, как нет дела и до замечаний, которые делаются мне из-за действий, которые совершали какие-то другие люди. Я конечно заметил, что на rsdn существует, скажем так, институт коллективной ответственности, но мне такая практика категорически не нравится.

Респект . Характер выдержанный, нордический — без дураков.

хъ

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

В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.

Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?

G>>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...

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

Ты все правильно пишешь. Только один нюанс, смотри предложение сверху и снизу.
K>Я не спорю с тем, что то, что Грэхему хорошо — то yahoo смерть. Я не понимаю, как сама возможность писать макросы может погубить Nemerle при том, что макрописателей там всегда можно ограничить.
Т.е. на лиспе писать без макросов смысла нет, он от тебя ускользает. Что характерно, я с тобой в этом согласен. Теперь объясни мне, согласному с тобой, какой смысл писать на Немерле, если макрописателей придется (от греха) ограничивать.

ЗЫ: Погубить эта возможность Немерле ИМХО не может. Он еще не дошел до того состояния, чтобы его что-то вообще могло "погубить".

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

G>Код макрос ужасающий быть может очень. Грамматика правило ввести новое я удобное мне, и хочешь понимай как. И еще человек сделают двадцать так. (определение измененной "грамматики" искать в файлах /megasystem/coolhacker_code. Файл правлен тремя людьми, с промежутком в год, а еще двое посмотрели на него, не вкурили и назвали отстоем, и написали пару своих "грамматик".).

G>Давай поставим вопрос так. Ты вообще на саппорте больших систем когда-нибудь работал? Систем, которым более 5 лет, которые писало человек 20, и в которых кода от миллиона строк? Если нет, то тебе сначала придется долго объяснять, в чем вообще суть понятия maintainability. А уже только потом перейти к макросам, и с переходом на яблоки, обяснить тебе разницу между определением нового термина (без макросов) и расширением синтаксиса и семантики языка (с макросами). Разница в том, что в первом случае ты, читая незнакомый код, знаешь правила его понимания, но не знаком со значением некоторых терминов, а во втором ты даже прочитать его толком не сможешь. Давай ты не будешь давать подстрочных комментариев, а дочитаешь до конца, и постараешься понять, о чем я — ты просил объяснить, я объсняю. Все таки, мы слишком давно знакомы по форуму, чтобы считать друг бруга идиотами, не так ли, Quintanar?

G>Вопрос: сколько кода надо просмотреть, чтобы понять смысл этой конструкции на С++, и ход ее выполнения? При этом, не обольщяйся, вообрази, что вот такого описания http://www.intelib.org/intro.html у тебя нет, а это обычный умеренно документированный код в составе системы. Поэтому, тебы не должно смущать внешнее сходство с Лиспом — автор мог придатьэтой конструкции любой смысл. Как показывает практика — и придают любой, вплоть до противоположных по смыслу названий. Последнее, причем, обычно результат групповой работы.

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

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

Меня Немерль не интересует. Мне обидно за макросы.

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

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

G>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.

G>Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?

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

Дело в видимо в "фильтрах" большенства читателей:
1) желавших поспорить о возможностях языка (которых я вообще не касался);
2) требовавших конкретных доказательств (хотя посыл был именно в том, что человеческая природа иррациональна и слабо подвержена логике);
3) эмоционально восклицавших "не все программисты дебилы!" и "сам такой!" на банальнейшие слова об ограниченности человеческого разума.

Т.о. лишни раз подтверждается тезис: "Нельзя оценить систему, находясь в системе".

Спасибо. Надеюсь, всем понравилось

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

Q>Меня Немерль не интересует. Мне обидно за макросы.

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

Если тебе обидно за camlp4 — то зря. Мы с мужиками обсудили и давно решили, что это для нас tool of choice для прототипирования компиляторов и создания своих DSL. Причина — возможность оформления кусков грамматики в виде синтаксических расширений, упрощающих эксперименты при создании своего собственного языка программирования (этого известные генераторы парсеров не дают), + ML позволит раза в 2 снизить затраты разработки на собственно компилятор, удобно на нем компиляторы писать. Заметь, о том, что camlp4 — макропроцессором называется, мы как-то не подумали.

Кстати, макросы — это старая новость. В 70-х годах были очень мощные и развитые макросистемы. Не прижились как-то. Применяли их и в промышленных масштабах — макроассемблер ЕС ЭВМ, например, можно назвать — очень популярное средство было тогда. Для PL/I была макросистема какая-то, которая могла все, или почти все. Так что опыт эксплуатации и написания программных систем с макросами у человечества был. И восторгов оно от этого особых не испытывало.

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

G>Респект . Характер выдержанный, нордический — без дураков.

В юности я был черезвычайно вспыльчив, но после лоботомии все как рукой сняло.

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

G>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.

G>Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?

Я и не отрицал, что в сообщении ласточкина есть рациональное зерно, но полную ахинею написать вообще гораздо труднее, чем кажется.
Лично для меня утверждение о том, что "Literate Programming — это хорошо" — абсолютнейший трюизм. Я вообще не припоминаю чтобы кто-то утверждал что это плохо. Зато я и не припоминаю двух людей, чье представление о "Literate" хорошо согласовывалось.
Другое дело, что мне не интересно говорить об этом в терминах "общения с компьютером". Нормально, когда про "общение с компьютером" говорит тетя Клава, которая откуда-то (из фильма "Терминатор 2" или, может быть, из газеты "Вечерний желток") подчерпнула сведения о том, что компьютеры живые и собираются поработить человечество. Но для форума "декларативное программирование" это, мягко говоря, не то что нужно. Собственно, раз меня не устроила форма, то и возражение по этому пункту касается именно формы, а не содержания. В чем проблема-то?

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

K>>Это больше говорит о lisp и применении малораспространенных языков в мэйнстриме вообще, чем о злобной сущности макросов. Зло вообще в голове, а не в вещах. Просто смысл в программировании на lisp без использования макросов от меня ускользает.
G>Ты все правильно пишешь. Только один нюанс, смотри предложение сверху и снизу.
K>>Я не спорю с тем, что то, что Грэхему хорошо — то yahoo смерть. Я не понимаю, как сама возможность писать макросы может погубить Nemerle при том, что макрописателей там всегда можно ограничить.
G>Т.е. на лиспе писать без макросов смысла нет, он от тебя ускользает. Что характерно, я с тобой в этом согласен. Теперь объясни мне, согласному с тобой, какой смысл писать на Немерле, если макрописателей придется (от греха) ограничивать.

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

G>ЗЫ: Погубить эта возможность Немерле ИМХО не может. Он еще не дошел до того состояния, чтобы его что-то вообще могло "погубить".

Ну почему же? Умереть вполне можно еще до рождения.

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

L>Все мои утверждения были совершенно тривиальны.

Ласточкин, Вы меня просто поражаете. Если Вы сами считаете, что Ваши утверждения тривиальны — то зачем же вы их пишете. Не кажется ли Вам, что гораздо ценнее и интереснее нечто нетривиальное?
Я вот тоже могу сказать что Волга впадает в Каспийское море, а потом предаваться рассуждениям о будущем морей и рек, но будет ли от этого кому-нибудь счастье?

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

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

L>Дело в видимо в "фильтрах" большенства читателей:
L>1) желавших поспорить о возможностях языка (которых я вообще не касался);
L>2) требовавших конкретных доказательств (хотя посыл был именно в том, что человеческая природа иррациональна и слабо подвержена логике);

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

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

L>3) эмоционально восклицавших "не все программисты дебилы!" и "сам такой!" на банальнейшие слова об ограниченности человеческого разума.

L>Спасибо. Надеюсь, всем понравилось

Dum spiro, spero. Ну ну.

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

G>>Ну, если по существу мысль ласточкина тебе понятна, и тривиальна, как выясняется, то что ж ты ему ответил-то так?

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

K>Лично для меня утверждение о том, что "Literate Programming — это хорошо" — абсолютнейший трюизм. Я вообще не припоминаю чтобы кто-то утверждал что это плохо. Зато я и не припоминаю двух людей, чье представление о "Literate" хорошо согласовывалось.

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

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

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

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

Ай-ай. В форуме масса постов, которые мне, Gaperton-у, ничего не дают. Я их не читаю, и на них не отвечаю, потому, что никто не может заставить меня тратить время на то, что я делать не хочу. Уверен, так же поступаете и вы. У меня даже есть список авторов — ignore list.

С чего это вы, друг Клапауций, выбрали этот несчастный пост, и стали его клеймить по столь банальной, трюальной (извините, не знаю, что это слово значит, но красиво звучит, мне понравилось. "Трюизм", говорите?), и всем надоевшей причине?

Короче, по моему скромнейшему мнению, то, что вы перечислили — совсем не повод отвечать так, как это делаете как вы.

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

Ну да. То что вы оценили письмо ласточкина в киллограм/амперах — я заметил

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

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

L>Я не отвечал на вопрос "где примеры последовательности". Мои слова всего лишь повод задуматься:

Думать о домыслах? Нет уж. Увольте.

L> во-первых, есть люди, которым не нравится синтаксис Немерле именно своей нечеткостью,

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

L> во-вторых, это люди определенного круга, в-третьих,

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

L>на официальном сайте не дается ни опровержения, ни согласия с этим замечанием, подчеркивая, мол "есть мнение".

Совершенно естественно, что на официальном сайте не обсуждаются домыслы. Сформулируй вопрос, получишь ответ.

L>Т.е. примеры ничего не скажут — кому то они покажут, что синтаксис нечеткий (непоследовательность — немного не то слово), кому то нет.

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

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

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

G>>Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...

IT>Но сначала они получили неслабое конкуретное преимущество, не так ли? А потом не смогли, не захотели, не договорились. И как это обычно водится в больших компаниях, нашёлся какой-нибудь ушлый манагер, который на затаптывании старого кода и его переписывании сделал себе карьеру.

Кстати, популярность Яху была на пике именно в его времена, а как Грэхем ушел, так начала падать. Хотя все это домыслы.

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

VD>Кстати, популярность Яху была на пике именно в его времена, а как Грэхем ушел, так начала падать. Хотя все это домыслы.

А, может, и как только популярность начала падать, так Грэхем и ушел. Кто ж его знает...