Здравствуйте, 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 был основой успеха. То что у Яхо не нашлось компетентных людей для поддержки кода — проблемы Яхо.

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