?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

О вреде макросов

Posted on 2009.07.25 at 00:41
Tags: , ,
Прикольный олдовый программерский пост в RSDN. Дискуссия о макросах и языках. Тогда на RSDN было модно восхищаться метапрограммированием, и языком Немерле в частности. Сейчас мне за него поставили оценку, и я его перечитал. Клевый пост. Идея в том, что высокий indirection level языковых конструкций отрицательно влияет на читабельность. Правильная идея, все так и есть. Очевидна тем, кто работал на поддержке, и совершенно непонятна "пионерам".


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

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

Comments:


ban_dana
ban_dana at 2009-07-24 22:31 (UTC) (Link)
Я бы добавил (и это видно из приведенного диалога): _неправильно использованный_ "высокий indirection level языковых конструкций отрицательно влияет на читабельность". Т.к. правильное его использование подразумевает _разумное_ скрытие ненужных подробностей (повышение уровня абстракции) и, таким образом, положительно влияет на читабельность, а не отрицательно. Да, использованные при этом средства лучше (а то и обязательно) знать, но если компания берет на поддержку проекта на С++ людей, которые не знают, что такое перекрытие операторов - у них проблемы с рекрутингом, независимо от того насколько разумно это перекрытие применялось в легаси-коде.
Gaperton
gaperton at 2009-07-24 23:39 (UTC) (Link)
Это так. Однако признаком _правильно_ использованных макросредств является _понижение_ требований к квалификации и мозговых усилий людей, которые работают с кодом. Не наоборот. Иначе нафига их использовать - смысла нет.

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

Если речь идет о промышленном использовании макросредств в болших группах. Это то, чего не понимала публика тогда, в данной дискуссии.
Макс Лапшин
levgem at 2009-07-25 05:38 (UTC) (Link)
меня не заставят верить в то, что лисп был причиной успеха. Язык, основанный на скобочках — эта жуть.
mindfactor at 2009-07-25 07:28 (UTC) (Link)
Йоу !

Как же хорошо, что я не программист и мне всей этой жути знать не обязательно !
ext_72902 at 2009-07-25 08:01 (UTC) (Link)
Не люблю макросы, но...

> Проблема здесь в том, что ты вынужден посмотреть определение класса CDoSomething, не доверяя ее названию (!), потому что автору может прийти в голову сделать там что угодно.

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

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

> a = b + c + d

a = f(b, f(c, d))

И мы тоже нифига не знаем. Разница-то?

> то ли присваивание имеет побочный эффект — черт его знает.

Вот поэтому и нужно контролировать побочные эффекты.

> Вопрос: сколько кода надо просмотреть, чтобы понять смысл этой конструкции на С++

Хотя Лисп и не относится к моим любимым языкам, но мне потребовалось расставить отступы и прочитать 9 строчек, чтобы понять этот самый смысл. Заметим, что документацию я не читал.

> и ход ее выполнения?

А зачем?

> Как показывает практика — и придают любой, вплоть до противоположных по смыслу названий.

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

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

Вот Берлиоз тоже думал, что нужно отойти подальше от трамвая, и будешь в безопасности.

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

Два утверждения:

1) Yahoo переписали движок Store с Лиспа на чего-то там.
2) Yahoo последнее время в заднице.

Не берусь утверждать, что эти события коррелированы.
tretiy3
tretiy3 at 2009-07-25 08:31 (UTC) (Link)
конечно же цель применения макросов - повышение читабельности.
достигается это соблюдением определенной культуры их написания.
как правило, хороший макрос - это железобетонная конструкция, которая никогда не изменяется. соответсвенно, не возникает необходимости поглядывать на его реализацию.
хороший пример: srfi в scheme.
lordmad2009 at 2009-07-25 18:23 (UTC) (Link)

О вреде молотков

Молотки очень вредны - дети могут ими пораниться... Поэтому детям не дают молотков, а родителей, которые дают своим детям молотки, лишают родительских прав.

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

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

Улыбнуло. Давайте сформулируем законы макросотехники:
1. Макрос не может причинить вред maintainability или своим бездействием допустить, чтобы человеку был причинён вред.
2. Макрос должен повиноваться всем приказам, которые дает maintainability, кроме тех случаев, когда эти приказы противоречат Первому Закону.
3. Макрос должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

Только не забудем про еще один закон:
0. Макрос не может причинить вреда maintainability, если только не будет доказано, что в конечном итоге это будет полезно для всего maintainability в общем.
Gaperton
gaperton at 2009-07-25 19:31 (UTC) (Link)

Re: О вреде молотков

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

По сути, подобным мусором, провоцирущим флейм, форумы и блоги заполнены чуть менее чем полностью, ибо чтобы так комментировать, не обязательно ни читать что написано, ни включать мозг. Как я от этого устал, все-таки.
lordmad2009 at 2009-07-25 22:32 (UTC) (Link)

Re: О вреде молотков

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

Вы считаете, что макросы (по крайней мере, в рассматриваемых проявлениях - вроде основы для DSL) отрицательно влияют на читабельность, так? Тогда давайте сразу разделим два случая: когда макросы применяются аккуратно (им даются адекватные и "говорящие" имена, а их применение хорошо и достаточно документируется), и, соответственно, неаккуратно (вроде примеров из Вашего поста, когда Вы не можете даже доверять их именам). Тогда в первом случае проблема может возникнуть практически, только если имеет место баг (баги случаются везде, в том числе и при написании макросов), но этот случай ничем качественно не отличается от любого другого бага, если выполняются два условия:
1. К макросам предъявляются повышенные требования в плане отсутствия ошибок (об этом чуть ниже).
2. Есть возможность анализа кода, получающегося после работы препроцессора (что есть везде).
Второй случай представлял бы собой проблему, если бы в каждой книжке по языку программирования, который поддерживает макросы, не писали бы про то, как осторожно нужно использовать макросы. А если что-то пишут уж в каждой книжке, значит только ребенку это не известно. Конечно, еще есть люди, которые считают, что хоть это и не тривиально, но они то крутые - им можно, они то не "пионеры" (прошу не обижаться на цитату). Поэтому придумали такие интересные вещи как тестирование, code review, оценивание квалификации, а менеджерам дали право распределять работу между сотрудниками (и даже самые тупые из менеджеров при распределении работ догадываются посоветоваться с ведущими разработчиками в команде на эту тему, раз сами не могут). Поэтому, если видите, что в руках у ребенка молоток, не говорите, что молотки вредны - идите и добивайтесь, чтобы у менеджера отняли "родительские права".
Да, к написанию макросов - особые требования. Именно из этих особых требований выливается мотивация к их неприменению не к месту (когда есть другое решение и оно лучше). К слову, зачастую использовать внешний DSL, вместо построенного на макросах оказывается значительно хуже по многим причинам, включая maintainability, не говоря уж о том, что часто дороже.

Приводя примеры кода, вы призываете исходить из предпосылки "все лгут". Хороший принцип. Применительно к разработке ПО, на эту тему очень хорошо уже написал Бертран Мейер (задолго до первого сезона сами знаете какого сериала).
Жуткая ведь штука может случиться, если кто-то в проекте на C/C++ создаст макрос assert, который будет делать не то, что подразумевается. Что предлагается - прописывать вместо assert вызов функции с __FILE__ и __LINE__ в качестве фактических параметров? Вы думаете, что
BEGIN_TESTCASE(foo)
TEST(NaN)
{
// ...
}
END_TESTCASE
станет более читабельным, если сюда добавятся "кишки", ответственные за регистрацию теста NaN в этом testcase?
В любом случае, если Вы хотите бегло понять в чем смысл фрагмента кода - Вы будете вынуждены в чем-то положиться на адекватность автора этого кода (потому что альтернатива в чем? как писал, если не ошибаюсь, Александр Степанов: хорошо бы чтобы компилятор C++ не давал менять семантику операторов, но пока не понятно как это сделать), а если захотите понять с нюансами - отсутствие таких штук как макросы не поможет - придется "приложить руки". Есть определенные правила (гласные и негласные) - они должны соблюдаться, за их несоблюдение нужно давать по рукам - с этим никто и не спорит. В зависимости он конкретных условий к правилам можно относиться жестче (вплоть до "закона 0" из моего предыдущего поста) или мягче. А говорить, что макросы - вредны, это, извините, экстремизм.
Gaperton
gaperton at 2009-07-25 23:03 (UTC) (Link)

Re: О вреде молотков

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

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

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

Вот и все. Большинство участников той дискуссии на RSDN этого не осознавало. Надо смотреть контекст дискуссии, прежде чем отвечать, а не реагировать на название темы.

И последнее. Не надо воображать себе в голове дебилизм, и приписывать его собеседнику, чтобы с ним потом поспорить. Характеризует это в первую очередь вас, а не собеседника. Создается четкое впечатление, что вы хотите самоутвердится за чужой счет. Что является отличительной чертой пионеров.
lordmad2009 at 2009-07-26 00:29 (UTC) (Link)

Re: О вреде молотков

В каком месте я с Вами разговаривал как с умственно отсталым, извините?

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

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

>макросредства в разработке большим коллективом должны быть запрещены в обычных коммитах, должны быть изолированы, и должны тщательно контроллироваться

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

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

"Рядовой программист" - это, по-Вашему, дебил, который не понимает опасностей, к которым может привести бездумное использование макросов? У нас такой не попадет даже в junior'ы.

>Большинство участников той дискуссии на RSDN этого не осознавало. Надо смотреть контекст дискуссии, прежде чем отвечать, а не реагировать на название темы.

Вы будете удивлены, но я посмотрел перед первым своим постом еще.
Думаю, они не будут возражать если я процитирую:
Quintanar: "Понятное дело, что использование макросов для DSL надо контролировать"
Klapaucius: "С другой стороны контролируемые эксперименты над синтаксисом вполне могут улучшить свойства "литературности"."
Причем этот контекст быз задан до приведенного здесь Вашего поста.
А вот чего я там не вижу - так это причин считать, что "Большинство участников той дискуссии на RSDN этого не осознавало". Это как раз к вопросу о "Не надо воображать себе в голове дебилизм, и приписывать его собеседнику, чтобы с ним потом поспорить."
Gaperton
gaperton at 2009-07-26 02:24 (UTC) (Link)

Re: О вреде молотков

> Проблема в том, что макросы применяются бесконтрольно? Бросьте, нет такой проблемы, если уж не совсем случайные люди в команде.

Не брошу, есть такая проблема. Если мы закроем глаза, всем вокруг не станет тмено. Достаточно посмотреть на практику применения некоторых конструкций С++ и boost, при условии отсутствия регламента их применения. Я насмотрелся. И "случайность" людей в команде здесь не причем, здесь проблема в отсутствии дисциплины. А она НЕОБХОДИМА, как только команда будет не 5-6 человек, а 20 или больше.

> Не уверен, что правильно понимаю, что Вы подразумеваете под "обычными коммитами" - это бесконтрольные коммиты что ли?

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

>С тем, что макросы должны быть изолированы и тщательно контроловаться никто и не спорит - ни сейчас, ни тогда на RSDN.

Сейчас я вообще не знаю, с чем вы спорите. Тогда на RSDN того, о чем я говорю, не понимала значительная часть аудитории, и спор был. Что подтверждается оценками. Посмотрите оценки, полюбопытствуйте.

> Рядовой программист" - это, по-Вашему, дебил, который не понимает опасностей, к которым может привести бездумное использование макросов? У нас такой не попадет даже в junior'ы.

Рядовой программист - это тот, кто занимается прикладухой, пользуюясь фреймворком и DSEL. Это никак не связано с его умом и квалификацией- это связано со специализацией. Он в 98% случаев не будет определять своих макросов. В случае, если разработка основана нормально, и в техническом руководстве сидят не дебилы, и они понимают, чем чреват свой DSEL, и зачем он им нужен. А нужен он как раз затем, чтобы в 90% случаев макросы были не нужны.

А кто к вам попадает или не попадает в junior-ы - совершенно не относится к теме разговора.

> А вот чего я там не вижу - так это причин считать, что "Большинство участников той дискуссии на RSDN этого не осознавало"

Причины на это есть. Дискуссия состоит не только из двух постов, на которые вы ссылаетесь. И я, когда отвечаю, никого не считаю дебилом. И я всегда развернуто показываю свою точку зрения. Вместо дебильных шуточек, которые позволяли себе вы здесь вместо разговора по существу, в своем первом комменте. Это, опять же, к слову.
Gaperton
gaperton at 2009-07-26 02:30 (UTC) (Link)

Re: О вреде молотков

> В каком месте я с Вами разговаривал как с умственно отсталым, извините?

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

Я просто попрошу вас сменить интонацию и наменение. При несогласии это сделать - возможность для вас оставлять комменты будет прекращена. Ибо в своем ЖЖ мне флуд разводить тупо влом. Для этого есть RSDN - там ради бога.

Но вроде как, вы это уже сделали, так что вопрос исчерпан, не так ли? Что тут еще говорить. Исчерпан, и все.
Gaperton
gaperton at 2009-07-25 19:35 (UTC) (Link)

Re: О вреде молотков

И не пытайтесь флудить дальше. Смысла нет, все равно ничего не получится, ибо забаню при первой же попытке без разговоров. А флуд удалю. Есть что по сути сказать - говорите. Нет проходите мимо.
ryukzak at 2009-07-31 19:51 (UTC) (Link)

Re: О вреде молотков

Не могли бы вы помочь либо ссылкой, либо кратким ликбезом о том, что такое DSEL, так как найти ничего ни в гугле, ни в вики по этому вопросу не удалось.
Gaperton
gaperton at 2009-08-01 04:16 (UTC) (Link)

Re: О вреде молотков

Domain Specific Embedded Language. Почти DSL, разница в том, что DSEL является расширением существующего языка, а не отдельным языком. В свою очередь, что такое DSL: http://en.wikipedia.org/wiki/Domain-specific_language

Разница между DSL и DSEL в реализации довольно существенна. Если для DSL можно сделать (и часто делают) отдельную грамматику и отдельный парсер с интерпретатором/компилятором, то DSEL - расширение основного языка. Он, в том или ином виде, должен делаться макросом, или же расширением компилятора, или макрогенератором, который дает на выход тот же целевой язык.

DSEL - он Domain Specific. Его цель - устранить семантическую пропасть между требованиями (формулировкой проблемы) и решением. Однако, часто DSEL-ом называют просто любое расширение языка, даже если оно не Domain Specific.

DSEL может добавлять в язык новые синтаксические конструкции. DSEL может изменять смысл некоторых существующих конструкций. Примеры языков, которые поощряют мышление в терминах DSEL - это метаязыки, такие как LISP, Scheme, FORTH.

Есть две более общих концепции, которые опираются на эту возможность, и эксплуатируют ее. Речь в данном случае не только о DSEL, но и о DSL.
http://en.wikipedia.org/wiki/Language_oriented_programming
http://en.wikipedia.org/wiki/Model_driven_development

В целом, разница между DSL и DSEL проста - она в том, кто пользуется языком. Обычно, DSL-ем пользуется пользователь, а DSEL-ом - разработчик. Но это обычно. Это не отличительное свойство, а часто наблюдаемое.
ryukzak at 2009-08-01 10:06 (UTC) (Link)

Re: О вреде молотков

Благодарю.
weissefly at 2009-07-28 10:57 (UTC) (Link)
Согласен с gaperton в том что макруха зло, но, мне кажется, вы упустили главное. Самое страшное, не то, что надо заглядывать в определение, и не то, что это DSL, который надо учить, а в том, что макрос рвёт фклочья контекст, в котором разворачивается. Пример- BEGIN_MESSAGE_MAP, заканчивающийся скобкой. Образуемый DSL - самый плохой в мире язык с точки зрения дизайна. Он не подконтролен ни компилятору, ни программисту. Фактически мы берём нормальный ЯП и строим сверху говноязык на свою голову, подавляя все благие намерения компилятора.
Исходный пост на rsdn ниасилил.
Gaperton
gaperton at 2009-07-28 16:37 (UTC) (Link)
Вроде как, эта проблема решается "гигиеническими" макросами. Которые в Немерле есть. Да и в Схеме - есть. Если я правильно понял проблему. :)

Исходная дискуссия на RSDN крайне нудна. Там по большому счету учавствует три стороны:
1) Фанаты языка Немерле. Они напоминали тогда воинствующую секту. Главарь секты - VladD2. :)
2) Пионеры, которым прикольно, что можно вытворять ТАКОЕ, причем - очень легко, с низким порогом вхождения, по сравнению например с плюсовыми шаблонами. Они тащились. Это, в целом, та же категория программеров, кто приходит в восторг от фокусов Александреску с С++.
3) Небольшая группа людей, которая пыталась немного уравновесить весь этот бардак, сохраняя балланс. Я среди них. В целом, я балланс-кипер в подобных дискуссиях. Если бы Немерле мешали с дерьмом, я бы, пожалуй, начал его защищать. :)

Вообще же РСДНовские флеймы ужасно унылы. Это по своей сути долгий и нудный командный замер пиписьками. Такому поведению способствует модель рейтинга, испольщуемая РСДН.

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

Пример с лиспом на С++ по моему сам по себе веселый и удивительный. Это реальная библиотека, изображающая на чистом С++ с его метасредствами LISP. Ее можно скачать, и использовать. Однако, я очень живо представляю себе, как вытянется лицо у инженера поддерджки, когда он встретит в коде такое, не имея на это никакого мануала :). Ох, какие матюги будут в адрес авторов :). Не оценят их изобретательность коллеги :).
weissefly at 2009-07-28 17:58 (UTC) (Link)
Ушёл курить гигиенические макросы scheme со вкусом ментола. Вернусь походу не скоро.
the_realistic at 2009-08-24 21:55 (UTC) (Link)
+100.

Удивительно верно и в точку.

Я именно за это не люблю Си++. За operator T с побочными эффектами (он зовется неявно, в отличие от скобок и плюса).

За передачу параметров по ссылке, после чего f(x) у нас изменяет х.

За exception handling, который для полноценного использования требует оборачивать _вообще все ресурсы_ в auto-release классы, а, если это не сделано, то приносит вместо пользы вред.

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

Такие вещи на одном уровне гадостности с очень суровым спагетти.
Previous Entry  Next Entry