Здравствуйте, Ikemefula, Вы писали:
I>>>У меня был случай, когда я понаписывал макросов а товарищи по проекту отказались их использовать и долбили копи-пастом. I>>>Во второй раз я решил проблему радикально — отказался от макросов и изменил фреймворк так что мои фичи использовались безо всякого геморроя.
Y>>Макросов на чем? Отказались по какой причине?
I>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.
— Да дерьмо этот ваш Корузо.
— По чему это?
— Петька вчера напел.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Ну, что мы можем признать, что идеи макросов таки могут быть полезных хотя бы в каких-то областях?
AVK>А чего признавать то? Я обратного и не утверждал? Ты с кем споришь?
Фанаты ассоциируют себя с предметом фанатизма, а максималисты фразу "в МП Немерле мне нравится это" слышат как "МП в Немерле мне не нравится вообще, взять хотя бы это".
Вот мы и имеем, что имеем.
Надо было в дисклеймере ещё красными большими буквами написать, что кроме того, что не нравится, есть ещё и то, что нравится, хотя это и очевидно, но видимо не для всех.
Здравствуйте, AndrewVK, Вы писали:
AVK>Игорь, я этот аргумент уже мильен раз слышал, даже в этом топике. Мысль, которую я пытался раскрыть с самого начала — макросы работают на значительно более глубоком уровне и обладают значительно большими возможностями. Это конечно круто, но есть, увы, и обратная сторона. Чем больше мы подкручиваем средство разработки, будь то макросы или сложные фреймворки, тем дальше экосистема разработки уплывает от среднепотолочной. Надо искать золотую середину. Мне так кажется, что макросы в моих условиях уже за такой серединой.
В том-то и дело, что это не проблема макросов. Макросы всего лишь средство выражения твоих решений. Если твои решения сложны для использования в твоей команде, то неважно как эти решения будут реализованы. Как раз макросами наоборот можно выразить это проще и доступнее. Возьмём тот же $-макрос из Немерле и сравним со string.Format:
$"Output: $a"
string.Format("Output: {0}", a)
Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.
Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции. Это просто не имеет смысла. Если легче и понятнее использовать функцию, то используется функция. Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач, чем аналогичное решение без макросов. Те же сплайс-строки, приведённые выше не только проще в использовании и нагляднее, но они ещё и безопасней, менее подвержены ошибкам. И так практически всегда.
IT>> Ведь ни функции, ни макросы, ни ключевые слова сами по себе не вводят новых концепций, они их реализуют и являются всего лишь следствием, формой.
AVK>Я же уже вроде писал — ничего не имею против, если макросы используются для разработки языка в рамках, заданных well known стандартом. Ну так, чтобы я мог требовать знание этих концепций при приеме на работу, и иметь при этом шансы кого то нанять.
Ты не можешь требовать знания ваших внутренних концепций, которые реализованы в ваших внутренних проектах. Человеку придётся учится, а тебе придётся его учить. Это обычный процесс, который даже для опытных девелоперов занимает несколько месяцев, чтобы въехать во все детали проекта. А в большинстве случаев во все детали никто никогда не въезжает. Потому что нафиг не надо. Работает у соседа соседский код и хорошо.
IT>>В общем, сложность использования макросов надумана
AVK>Видишь ли, я про сложность использования макросов ничего не писал. Я про сложности, порождаемые их использованием. А использовать да, использовать их просто, не могу не согласиться.
Что-то ты меня совсем запутал. Использовать просто, но простота использования порождает сложность. Какую сложность? Я не понимаю.
IT>>Ничего особенного, гораздо проще, чем, например, эмитить код. Ну потратишь ты на это дело несколько часов, да даже несколько дней. В рамках проекта на несколько месяцев, если от твоего DSL будет серьёзный эффект, то потраченное время окупится с лихвой.
AVK>Я тоже так думал. А на практике оказалось, что этот DSL приходится поддерживать постоянно. Если DSL этот — ключевое момент системы, это еще ничего. А вот если вспомогательный — сложно все таки мыслить концепциями генераторов, сложнее, чем просто писать целевой код.
Любой общий компонент требуется поддерживать постоянно. Точнее не постоянно, а поначалу пока он утрясается и потом, когда нужно подстроиться под новые функциональные требования. Это касается любого компонента. Макросы и DSLи не исключение.
IT>>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. AVK>Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?
Я подумал ты о Custom Tools. А в данном случае если студия генерирует, то пусть себе генерирует.
IT>>Это опять лишь домыслы. Генерировать код на Немерле не сложнее, чем генерировать текст.
AVK>Опять же, ты неверно понял. Я нигде не писал, что генерировать код на Немерле сложнее, нежели генерировать текст. Я говорил о другом — нередко проще вообще ничего не генерировать. Это все я написал к тому, что была у меня задача создания довольно сложной модели и ее реализации в условиях цейтнота. Тогда я справился при помощи кодогенерации, и очень быстро получил результат. Но теперь, по проществии нескольких лет, приходится признать, что на поддержку генератора я затратил больше усилий, чем если бы я ничего не генерировал с самого начала и просто рефакторил бы готовый код.
У тебя скорее всего precompile-time генерация. Так с ней всегда так. Легко получить первоначальный результат, а потом начинаются пробуксовки до полной остановки. Проблема в негибкости и в ограниченности возможностей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>В том-то и дело, что это не проблема макросов.
Я считаю, что все таки макросов.
IT>Как раз макросами наоборот можно выразить это проще и доступнее.
Все таки мы говорим об разных вещах. Я не про то, что макросами нельзя выразить доступно.
IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.
Ты неверно ставишь вопрос. Мне не нужно опытному программисту объяснять ничего про C# и BCL, он обязан это знать, на эту тему есть мильен книг и статей.
IT>Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции.
Охотно верю.
IT> Это просто не имеет смысла. Если легче и понятнее использовать функцию, то используется функция. Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач
Да. Именно! Я как раз это и говорю — макрос мощнее и гибче обычного фреймворка.
IT>Что-то ты меня совсем запутал.
Ты сам себя запутал. Мои слова в исходном сообщении следует понимать буквально. Не стоит додумывать то, чего там нет.
IT> Использовать просто, но простота использования порождает сложность. Какую сложность?
Сложность вползания в сильно отличающуюся языковую среду, которая на долго живущем проекте обязательно будет эволюционировать в нечто уникальное. Эта проблема есть и сейчас, безусловно. Но, по крайней мере, сейчас это сдерживается рамками стандарта языка.
Если же урезать мощность макров с целью этого избежать, то, мне кажется, можно придумать какие то более простые решения, легче реализуемые, более дружелюбные к рефакторингу и IDE и т.д.
IT>Любой общий компонент требуется поддерживать постоянно.
Непонятно, опять же, с кем ты споришь. Конечно надо. Но генератор поддерживать тяжелее, чем код, который он генерит.
AVK>>Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?
IT>Я подумал ты о Custom Tools.
Я уже заметил. Вобще, в этом топике каждый думает о своем, вместо того, чтобы внимательно прочитать, что я пишу. Я не столько на вопросы отвечаю, сколько опровергаю утверждения о том, что я говори то то и то то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
VD>То есть, VladD2 не дебил, а это значит что он может написать мокросы которые нужны ему и другим. VD>Но это не значит, что только VladD2 не дебил. Таких людей много, а значит много кто сможет писать макры.
Теоритически это так.
VD>Скажем много кто пишет мета-код на основе шаблонов С++, но это ужасно сложно и неудобно. Но люди пишут. Писать мары на Немерле в сто раз проще. И значит их смогут писать куда большее число людей чем мета-код на С++ (например).
Откуда взялись твои оценки сложности ? Здесь то и зарыта собака.
Разумеется, если разработчик в состоянии осилить такую глубину и большую, то ему будет легче. Речь то не об этом.
Судя потому, что люди плохо понимают виртуальные методы, интефейсы, индексеры, итераторы и эвенты, любое новшество это уже чрезмерное усложнение.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Кроме того, если у разработчика возникнет понимание МП в Nemerle (а иначе как он придет к желанию покрыть макросами все его возможные потребности?), то он уже вполне может считаться "недебилом" и начать потихоньку писать их самостоятельно.
_>>Каждый свою success story имхо сам должен делать.
I>Ага, должен Это слово чаще всего встречается, когда речь идеть о хилых инструментах, всегда находятся отношения долженствования.
Не хочу превращать тему в флейм, обсуждением абсолютных характеристик (мощность, хилость и их производных) неких инструментов. Можно ли считать .NET языки в которых нет вообще МП, хилыми? Заодно и к теме топика вернёмся
I>При этом надо будет показать, что производительность труда на голову выше чем у конкурентов.
Опять флейм. Кого и в чём надо убедить — сильно зависит и от того где работаешь и от того какую должность там занимаешь.
IT> Возьмём тот же $-макрос из Немерле и сравним со string.Format:
IT>$"Output: $a" IT>string.Format("Output: {0}", a)
IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности. IT>Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции.
Я тебе открою глаза: ты сам две строчки выше написал пример макроса, который труднее использовать чем функцию.
7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.
I>>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.
VD>- Да дерьмо этот ваш Корузо. VD>- По чему это? VD>- Петька вчера напел.
Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.
M>>Генератор запускается когда студия решила, что файл изменился, или когда программист нажал правую кнопочку и попросил.
L>Не только. Например, когда в свойствах проекта меняешь default namespace, происходит запуск. Проверялось на t4.
И это правильно, как правило генерируемый код наследует default namespace.
IT>$"Output: $a" IT>string.Format("Output: {0}", a)
IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.
Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.
Первый опускает все подробности, а программисту в голове по любому нужно держать их в голове.
Для объяснения "делает всякое со строкой" разумеется проще первый.
А вот для нормального использования надо знать все, что спрятано за коротенькой строчкой.
Попробуй объяснить это человеку, который не в теме и сразу поймешь в чем дело.
Второй пример без объяснений понятен любому, кто хотя бы пару месяцев осваивал программирование.
IT>Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач, чем аналогичное решение без макросов.
В том то и дело. Это и поднимает порог для входа.
IT>Что-то ты меня совсем запутал. Использовать просто, но простота использования порождает сложность. Какую сложность? Я не понимаю.
Ну примерно так -бинарный код самый простой из языков программирования он же самый сложный
Простота использования очевидна — пиши себе единицы и нули сколько влезет и как попало.
Сложность тоже очевидна — никому не ясно, что же там делается то.
Здравствуйте, hi_octane, Вы писали:
I>>Ага, должен Это слово чаще всего встречается, когда речь идеть о хилых инструментах, всегда находятся отношения долженствования.
_>Не хочу превращать тему в флейм, обсуждением абсолютных характеристик (мощность, хилость и их производных) неких инструментов. Можно ли считать .NET языки в которых нет вообще МП, хилыми? Заодно и к теме топика вернёмся
Про хилый я говорю в контексте распространения технологии. Ну, шаблоны С++ куруть и мощь. Однако людей их умеющих, единицы, стало быть хилый подход.
I>>При этом надо будет показать, что производительность труда на голову выше чем у конкурентов.
_>Опять флейм. Кого и в чём надо убедить — сильно зависит и от того где работаешь и от того какую должность там занимаешь.
Это не флейм, это в тему про истории успеха. Как ты можешь убедить меня, например, работая в своей конторке — неясно.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Кроме того, если у разработчика возникнет понимание МП в Nemerle (а иначе как он придет к желанию покрыть макросами все его возможные потребности?), то он уже вполне может считаться "недебилом" и начать потихоньку писать их самостоятельно.
I>Ну, так, и что ?
А то, что если понимания не возникнет, то и потребности в макросах на все случаи жизни у него не будет, и будет он писать в C#-like стиле, постепенно вникая в технологию, необходимость и целесообразность применения МП. И учитывая
По этой причине людям стараются дать технологии, которые не отнимают времени на освоение.
я в упор не понимаю, почему это преподносится как аргумент против МП в Nemerle, когда он явно является аргументом "за"
Здравствуйте, mihailik, Вы писали:
I>>>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.
VD>>- Да дерьмо этот ваш Корузо. VD>>- По чему это? VD>>- Петька вчера напел.
M>Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.
А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.
Все рождены в равенстве и с равными возможностями!
Здравствуйте, kochetkov.vladimir, Вы писали:
M>>Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.
KV>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.
Желание и стартовая позиция. Лучше всего, когда профессию люди осваивают с глубокого детства, такие люди достигают максимальных успехов.
Технологии должны экономить время путем вовлечения в разработку безграмотных толп людей.
Если нечто этим свойством не обладает, то это не технология вовсе.
У них, безграмотных толп, гарантировано желания нет чего то осваивать и тем не менее это не становится преградой для распространения технологии.
А вот с плохими технологиями вечно возникают оправдания, что де люди суть тупое быдло, ничем не интересуются и тд и тд.
Вот например, у нас на проекте работают
1 Тестировщики
2 Девелоперы
3 Алгоритмисты(это девелоперы но завязаные на очень узкую часть — алгоритмы которые придумывают математики)
4 Математики
5 специалисты по предметной области
интересы девелопера в математике отсутствуют, как и во всех других областях, а вот математики точно так же не имеют интереса кроме как в математике.
Ровно так же со всеми остальными.
Т.е. здесь имеет место вовлечение безграмотных масс в разработку, ибо должную подготовку по разработке ПО имеет только п.2.
P.S.
Вобщем то данный топик крутится вокруг одного вопроса — оценка сложности конструкций.
Игра приобрела такой расклад — одна часть считает что $"Output :$a" сложно, а вторая наоборот, считает что легко.
Если нам не помогут, то мы тоже никого не пощадим.
