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

Итак, сабж.
1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.
При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.
Итого — внесение изменений в компилятор для улучшения языка лично для меня с точки зрения промышленного программирования малополезно (при этом побаловаться для проектов, рассчитаных на одну-две хари фо фан я как бы и не против).
2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.
Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.
3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.
4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.
5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.

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

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

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

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

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

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

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

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

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.

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

AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.

Насколько мне известно, аббревиатура DSL в DSL Tools появилась по недоразумению. С DSL эти Tools имеет мало обощего.

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

Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.

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

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.

Не знаю зачем ты добавил сюда этот пункт, но МП тут вообще ни при чём. Если у тебя задача не может использовать МП, или ООП, или ФП, то странно в этом обвинять МП, ООП, или ФП.

В общем, как-то всё не очень убедительно. Фактически я увидел две претенции:

1. Сложноть использования макросов.
2. Сложность написания макросов.

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

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

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

IT>Инженер, который не знает инструмента, с которым он работает, не может эффективно выполнять свои функции в принципе.

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

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

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

IT>Главная проблема при изучении нового не в запоминании названия функций и конструкций языка. Главная проблема в освоении новых концепций.

Ну да. Я здесь же вчера писал ровно то же самое.

IT> А разобравшись будет уже не важно как это реализуется, функцией, макросом или языковой конструкцией.

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

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

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

IT>В общем, сложность использования макросов надумана

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

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

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

AVK>>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.

IT>Насколько мне известно, аббревиатура DSL в DSL Tools появилась по недоразумению.

Это спор о терминах. Лично я считаю, что все там по разумению. Вполне нормальное средство разработки графических domain specific языков.

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

IT>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код.

Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?

IT>Это опять лишь домыслы. Генерировать код на Немерле не сложнее, чем генерировать текст.

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

IT>Не знаю зачем ты добавил сюда этот пункт, но МП тут вообще ни при чём.

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

IT>1. Сложноть использования макросов.

Нет такой притензии.

R>но где здесь 5 спецсимволов и где здесь клиника?

1) $
2) "
3) :
4) $
5) "

Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.

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

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

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

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

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

С начало не плох было бы продемонстрировать демагогию в моих словах.
Демагогия, а точнее софистика как раз сплошь и рядом в словах АВК.

VD>>Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.
IB>Не снимает. Проблема не в том, что можно так не делать, проблема в том, что так делать в принципе можно, об этом говорилось уже ни раз.

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

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

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

VD>>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.
IB>Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

Андрей просто неверно трактует термины встроенный DSL и мета-программирование. Об этом я и говорил.

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

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

IB>И не составит никаких проблем описать бухгалтерию точки общественного питания в терминах системы управления АЭС?

Ты сейчас намеренно сказал глупость. Зачем?
Конечно описывать бухгалтерию в терминах АСУТП АЭС глупо. Скажу даже больше невозможно.
Но встроить в один язык два подъязыка-ДСЛ-я один из которых позволит описать предметную область бухгалтерии, а другой АСУТП АЭС можно. Вряд ли это потребуется в одном проекте, но это ведь не проблема?

VD>>Так вот поддержка ДСЛ-ей заключается не в наложении ограничений или расширений к основному языку, а в том, что язык позволяет описать совершенно новую семантику, а иногда и синтаксис.
IB>С набором ограниченных возможностей.

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

Неужели это плохо?

VD>>Но ты почему-то проигнорировал наши просьбы дать расскзать о проблемах МП в Немерле. Вместо этого ты почему-то рассказал нам о своих предубеждениях (ни на чем не основанных).
IB>Во-первых, никто не обещал рассказывать про проблемы МП в немерле, обещали рассказать чем не устраивает немерле именно AVK, и именно это и рассказали.

Вообще-то обещал. Но в другой теме.

IB>А во-вторых, рассказали на чем именно основаны "предубеждения".

Да не очень то. А вот, то что это предубеждения ясно любому кто знаком с Немерле не по наслышке. Заметь не нашлось никого, кто хоть немного знал бы этот язык и при этом согласился бы с АВК.

VD>>Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль.
IB>А ты не хами и жалеть не придется.

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

VD>>Ведь только в честных спорах рождается истина.
IB>Возможно. Но только честно спорить ты не умеешь.

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

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

VD>Дык если бы каждый чих этого требования, то проблему бы давно решили написав набор стандартных функций или введя синтаксис аналогичны сринг-формату. На на практике потребность фоматировать даблы столь редка, что о ней и говорить не приходится. К тому, же всегда можно настроить все через культуру. Это зачастую снимает много проблем.
Это от того, что единственное, что вы пишете — это компилятор. У вас там наверное во всём проекте ни одного дабла, кроме как в тесткейзах, нет.
А в жизни ни даты, ни даблы никто никогда не выводит в "дефолтном" формате. Слишком велик разброс вариантов. Задавать же, к примеру, количество знаков после запятой, через культуру — еще менее удобно, чем подставлять ad-hoc функцию. В культуре есть понятие стандартного вывода денежных значений. Но никакого типа currency нет, а сплайс-строки не предоставляют возможности использовать эту настройку. В String.Format я пишу {0:C} и всё — будет выводиться корректный префикс и количество цифр после точки.

VD>Все эти F2 и FX действительно затрудняют понимание и никакими курсами тут не поможешь. Я вроде уже боец не молодой, но запомнить эту ересь я не могу. А функция затрудняет понимание нее больше чем знаки форматирования. Скажу больше, функция может содержать описание которое будет видно из подсказки (хинта) в IDE. Это решает проблему чтения, в отличии от срок форматирования.

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

Ну, я, собственно, уговаривать тебя не собираюсь. Я не пользуюсь Nemerle, и задачи продвинуть его в top100 языков программирования у меня нету.
Но то, что вы позиционируете как killer feature штуку, которая сильно отстаёт по возможностям от "родного" аналога, удручает.
Так ты слона не продашь (с).

Понимаешь, идея не в том, чтобы сказать всем "вы косные тупые уроды, бросьте всё и пишите как мы, пусть это будет длиннее по строчкам кода", а в том, чтобы сказать "смотрите, привычные вам вещи умеют больше".

VD>Кстати, одно из соображений почему мы не сделали формат аналогичный стринг-форматному как раз и была полная непонятность этого формата. А ведь еще в 6-ом Васике вроде как были весьма интуитивно понятные средства форматирования.
Не вижу ничего непонятного. По сравнению с синтаксисом RegEx форматные строки — детский лепет. Реально, Влад, это еще один DSL, существующий в рамках .Net. Вот взяли бы его и замутили на Nemerle. Так, чтобы все там пряники типа компайл-тайм проверки, code completion, и так далее.
А то, что вы сейчас позиционируете как killer feature, извини, не намного лучше прямого вызова String.Concat.

VD>Это не правда. Ты просто плохо смотрел. Вот, например.
Да, правда, плохо смотрел.

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

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

Типа PHP? Ребята, это не серьёзно. Если бизнес модель твоей компании базируется на эксплуатации дешовых кодеров-пэтэушников, которые в состоянии использовать только примитивные технологии, то МП однозначно не для тебя. Не заморачивайся. Купи одну книжку ПХП за три дня на всю контору и этого будет более чем достаточно. Вкладывайте деньги не в обучение, не в качество, а в количество. Возможно такая модель более прибыльна. Хотя, судя по тому как сейчас трещит по швам индусский аутсорсинг, это не совсем так в определённой перспективе.

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

I>Да, это хороший подход. Работает исключительно в коммандах из топ-разработчиков.

Это работает всегда. От проблемных людей надо избавляться. Команда из 5-7 человек с проблемным мембером работает гораздо эффективнее без него. Уж поверь мне на слово, как ведущему сабокоеду, съевшему не одну собаку на корпоративной грызне пока я работал в IBM. Убираешь такого человека из команды и работа начинает в буквальном смысле спориться. Исключений не бывает.

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

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

I>Это тебе кажется, что не сложнее. А реально — много сложнее. Примерно на порядок.

Чушь. Из какого пальца "порядок" высасывал?

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

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

I>Во второй раз я решил проблему радикально — отказался от макросов и изменил фреймворк так что мои фичи использовались безо всякого геморроя.

Т.е. геморрой был изначально и скорее всего аккуратно был перенесён в макрос

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

I>На этом срубается примерно 90% разработчиков, а остальные 10% рассматривать как целевую аудиторию для новых технологий как минимум несерьезно.

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

1. Желание объясняющего объяснять.
2. Необходимый базовый уровень знаний обучаемого.

В частности, человеку с C++ бэкграундом, знающему что такое указатель на функцию, вся функциональщина объясняется на раз. Как её применять он уже потом сам научится, но что это такое и как это всё работает объяснить не составляет проблем.

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

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

I>Сложности нет. Сложность в людях.

Сложность в неверии в людей и в костности мышления.

IT>>А про правку сгенерированного кода и железной линейкой по пальцам тут уже сказали. И я с этим полностью согласен, т.к. встречался с таким баранизмом на практике.

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

Сто процентов не тот. Precompile генерация кода — не тот инструмент по определению.

IT>>По первому пункту я уже всё сказал. Это не сложнее, чем использование классов, методов и атрибутов. Сложность не в макросах, сложность в концепциях, которые они реализуют. Но это в равной степени относится и к тем же классам, методам и атрибутам.

I>Это справедливо только для разработчиков топ-уровня.

Это не справедливо только для джуниоров — 0-3 года опыта. И то не для всех.

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

VD> достоин попадания в аналы истории.

Супер!!!

AVK>что будет больше, выигрышь от улучшения языка или проигрышь в поиске программистов
AVK>И это, конечно, не бестолковые индусы, это просто люди

Позволю себе исправить орфографию.

Правильно писать не "бестолковые индусы", а "безграмотное московское жлобьё".

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

M>1) $
M>2) "
M>3) :
M>4) $
M>5) "

M>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.

$"Output: $a"
string.Format("Output: {0}", a)

Ну ':' ты зря посчитал, это элемент строки, а не спец. символ. Итого будет 4 спец. символа. Давай по аналогии посчитаем количество спец. символов в шарпе:
1. '.'
2. '('
3. '"'
4. "{"
5. "0"
6. "}"
7. """
8. ","
9. ")"

Итого 9 против 4-х, Шарп то, поклиничнее будет

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

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

VE>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.

VE>Все рождены в равенстве и с равными возможностями!

Я же вроде уточнил, что говорю о данном случае?

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

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

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

Эта техника отличалась от всех остальных, ранее нами изученных, в т.ч. и следующим:

1. Позволяла крайне быстро получить работы необычайной красоты и выразительности
2. Основной базис для рисунка со всеми его богатыми фактурами и переходами выполнялся не художником, а другим, более огрубленным рисунком, нанесенным заранее на стекло.
3. Овладение пером и навыками уточнения контуров хоть и потребовало некоторое время, но результат того стоил однозначно
4. Концентрация творческой составляющей, преимущественно на последней стадии позволила целиком и полностью посвятить себя на ней передаче своих эмоций, а не размазывать этот процесс по всем этапам, как в других техниках.

Вот и с чего это я про нее сейчас вспомнил?

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

A>1. Нужен road map. Если он есть — можно ссылку?

Можно даже без ссылок, а прямо inline-ом.
Роад-мап очень простой. В ближайшее время будет выпущена версия 1.0. Произойдет это после того как я доведу работы по поддержке LINQ до финала и после того как мы вычистим основные ошибки в компиляторе и интеграции.
Я надеюсь, что эта работа будет завершена в Январе. В крайнем случае в первой половине 2009-года.
Новых фич при этом добавляться не будут. Только если библиотеки разработанные сторонними авторами. Так возможно мы увидим библиотеку поддержки XML а-ля LINQ to XML и (опять же возможно) реализацию макры аналогичной фиче dynamic из C# 4.0.

A>2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт. Огонь и движение
A>

A>Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет.

A>Пример — необходимость реализации поддержки Linq в Nemerle.
A>На очереди dynamic, ...

Что-то в этом эссе есть. Но Джоиль человек не традиционной ориентации в прямо и переносном смысле этого слова.
Я не разделяю его вглядов. По крайней мере не все или не на 100%.

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

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

Посему считаю, что Linq должны поддерживать все уважающие себя гибридные языки реализующиеся на платформе дотнет (да и не только).
К тому же поддержка Линк не так сложна. Скорее сложно было довести систему разрешения перегрузок Немерле (действующую в очень жестких условиях отложенной типизации), чтобы быть совместимыми с библиотекой входящей в .NET Framework 3.5, нежели с самим Query Pattern. Само же преобразование кода в деревья выражений вообще было реализовано на базе макросов. Так что МС напряг не очень сильно своим Линком. Но он заставил довести систему разрешения перегрузки до очень высокого уровня.

A>Я так понял тут уж ничего не поделаешь.

Ну, почему же не поделаешь?
Вот погляди на ситуация которая складывается сегодня...
Все новые фичи C# 4.0 (до выхода которого еще 1.5 года) уже поддерживаются Nemerle. Разве что dynamic реализован не в полной мере и не через DLR, а через рефлексию. Но ведь, черт побери, реализован! И это было сделано 2 года назад! То есть мы опередили огромный Майкрософт ах на 4 года! Это ли не успех?
И так почти по всем новым фичам МС. Даже Линк — это проявление ФП которое было в Немрле с рождения.
Ко-/контр-вариантность интерфейсов и делегатов уже давно поддерживается в Немерле.
В общем, Немерле уже поддерживает все то что будет не только C# 4.0, но и в C# 5.0 (ведь компилятор изначально доступен как компонент, МП не просто реализовано, а реализовано как базовая фича языка).

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

Кроме того нужно:
1. Более качественное IDE. Желательно безупречная. Но это большая работа, особенно в условиях когда сама IDE основана на COM.
2. Вести работы над упрощением API компилятора используемого для целей мета-программирования.
3. Написать множество стандартных макросов которые можно будет использовать как строительные блоки.
4. Ускорить работу генерируемого им исполняемого кода. А это значит, что нам нужно научить его инлайнить хотя бы базовые ФП-функции вроде Map, Fold, Zip и Filter. А так же локальные функции и лямбды передаваемые в них. В идеале же нужно использовать технику супер-компиляции которая бы позволила максимально устранить, что называется, performance penalty от использования ФП.
5. Ускорить работу компилятора. Отчасти это сделает пункт 4, но кроме того компилятор нужно сделать многопточным. Чтобы он мог масштабироваться за счет увеличения процессоры ядер.
6. Возможно нужно снять ограничения на то где может применяться макрос и из каких лексем он может состоять. Тогда даже разбор самого описания макроса можно реализовать по средствам макроса, а ДСЛ-и можно будет объявлять на уровне типов.

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

A>3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если
код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.

Гарантия отсуствия ломающих изменений, по крайней мере серьезных — это бутсртипинг компилятора, т.е. то что компилятор компилирует сам себя. Это приводит к эволюционному его развитию. Без ломающих изменений вряд ли получится улучшить язык. Но я уверен, что они не будут очень болезненными. Скажем переименование АПИ — это ломающее изменение. Но без него не обойтись. К тому же можно постараться сохранить и старые названия пометив их как obsolete.

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

A>4. Больше информировать комьюнити что происходит в Команде Nemerle.

Постараемся.

A>ЗЫ. Я так понял что не получилось у грандов выбить гранты — так разместите "Donate" на сайт и к вам потянутся люди.

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

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

Итак, автор темы, как я предполагал, нашел в первом же моем вопросе "А автор темы вообще знает, что макросы в Nemerle не обязаны изменять синтаксис языка?" фатальный недостаток.

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

Автор: AndrewVK
Дата: 26.12.08

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

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования.

Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.
Обратимся за разъяснениями к Википедии.
http://ru.wikipedia.org/wiki/Предметно-ориентированный язык программирования
Предметно-ориентированный язык программирования (англ. domain-specific programming language, domain-specific language, DSL) — язык программирования, специально разработанный для решения определённого круга задач, в отличие от языков программирования общего назначения, например C, или языков моделирования общего назначения наподобие UML. Например языки Postscript, SQL и др.

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

AVK>И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.

Продолжим разбираться в терминах. Итак DSL-и делятся на внешние и встроенные.
Пример внешнего ДСЛЯ-я файлы спецификации YACC и LEX. Это независимые DSL-и описывающие грамматику и синтаксис некоторого (конкретного) языка программирования которые превращаются в код (на языке общего назначения) парсера и лексере с помощью отдельной (внешней) мета-программ. Внешним он является, так как не встроен в другой язык, а живет своей отдельной жизнью.
Внутренний DSL (EDSL или DSLE) живет внутри другого языка. Примером внутреннего DSL могут являться: регулярные выражения, LINQ-запросы, $-строки (Nemerle, PHP или Руби), всевозможные спецификации (например, спецификации O/R-отображения на основе пользовательских атрибутов) и многое другое.
Удобстово встроенных ДСЛ-ей заключается в том, что они могут тесно взаимодействовать с языком общего назначения (ЯОН) в который они встроены. Кроме того ЯОН поддерживающие разработку встроены ДСЛ-ей (такие как Немерле) мгоут значительно облегчать создание встроенных ДСЛ-ей.

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

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

AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.

Короче не всегда быстрее и уж точно не всегда правильнее.
MPS, DSL Tools, Oslo — это как минимум не конкуренты Немерле хотя бы потому, что это средства создания внешних ДСЛ-ей.

Несомненно каждый подход имеет право на существование. Но только в области своего применения.
Скажем DSL Tools — это по сути средство создания визуальных моделлеров таких как UML, ER или диаграмм классов из VS.
Интересно, что Немерле может весьма эффективно применяться совместно с ним для генерации кода по модели. Обратное не имеет смысла. В общем, это разные инструменты которые можно использовать вместе.
MPS — это отдельная песня. Это RAD-средство создания внешних ДСЛ-ей. По возможностям от оно более ограничено нежели немерловые макросы хоят бы потому, что не может использовать мета-информацию о типах языка для которого производится генерация и тем, что MPS создает только внешние ДСЛ-и.
Но надо признать, что во многом MPS — это конкурент Немерле. Причем в отличии от других данный конкурент предлагает весьма интересные средства и подходы.
Осло — это вообще мутант предлагающий писать внешние ДСЛ-и на основе ХМЛ и весьма странных средств трансформации.

Короче, все перечисленные средства как-минимум не умеют делать то, что умеет делать Немрле. А по жизни являются узко специализированными решениями.

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

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

Да, несомненно. В визардах используется генерация код. И несомненно она там обычно очень примитивная. Но на визардах свет не закачивается.
Есть куча задач требующих генерации кода. И, кстати — эти задачи называются мета-программированием, как бы автор темы в это не верил.
Более того, зачастую нужда в визардах исчезает если мы имеем в своем арсенале мощные средства мета-программирования.
Так же пропадает и нужда в кодогенераторах.
Например, в проектах C# и VB.NET ресурсные файлы генерируются визуальным интерфейсом встроенным в VS. Он формирует ХМЛ-файл с описанием ресурсов. Но ХМЛ-файл нельзя использовать их программы. В программе нужно иметь код который прочел бы ресурсы из исполняемого модуля и представил бы их в удобном для программы виде. Для этого в VS придумали весьма кривое решение — Custom Tool. Это кодогенератор создаваемый на дотнет-языке и ассоциируемый (в реестре) с расширением файла. Когда Студия производит запись файла, она вызывает ассоциированный с ним компонент и тот генерирует код на нужном языке. Кривость данного решения очевидно. Ведь без студии мы не можем запустить данный генератор. К тому же создание такого генератора весьма не тривиальная задача.
Немерле позволяет создать макрос читающих описание ресурсов в ХМЛ и генерирующий классы-обертки которые становятся доступными даже в во время разработки. Данный макрос одинаково работает как при компиляции, так и в дизайн-тайме. При этом сложность создания такого макроса на порядок ниже нежели генератора на обычном языке, так как при этом используется вся мощь мета-подсистемы Немерле. Описанный макрос создал человек не являющийся гуру в Немерле. При этом ему понадобилось всего пара советов.

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.

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

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

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле.

Не "неверно", а 100%. Только причем тут АОП? BLToolkit — это типичный пример встроенного DSL предназначенного для описания и организации DAL (уровня абстрагирования доступа к данным) реализованного на основе техники мета-программирования. Только IT использовал не продвинутые средства мета-программирования Немерле, а дико низкоуровневый Sustem.Reflectin.Emit (т.е. генерацию IL-а). Это дико усложнило задачу. Так, что надо отдать должное мастерству и упорству IT который сумел создать такую мощьную библиотеку столь неудобными для этого и низкоуровневыми средствами.
Кстати, BLToolkit отличный пример DSL-я не реализвемого средствами перечисленных автором темы, идеологически более правильных (по его словам) MPS, DSL Tools и Oslo. Все дело в том, что BLToolkit нуждается в информации о типах конкретных структур данных, а это невозможно без специального API данные для которого генерируются компилятором. Для BLToolkit такими данными являются данные рефлексии генерируемые компилятором и доступные в рантайме. В Немерле все те же данные можно получить во время компиялции, что с одной стороны увеличит быстродействие, так как не надо будет компилировать код в рантайме анализируя структуры данных, а с другой стороны его было бы проще реализовать так как генерировать код по средством квази-цитирования в сто раз проще.

AVK> Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню:

Да не стоит. Собственно я знаю, что в задачи автора темы входила генерация типов по описанию хранимому в ХМЛ-файлах которое производилось во время развертывания приложения на сервере.
Это интересный подход, но его тоже можно осуществить на макросах если просто запускать компиляцию прикладных сборок во время развертывания. Точно так же делал и автор. Только он сначала генерировал код с помощью XSLT, а потом компилировал его стандартным компилятором C#.

AVK>инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.

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

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

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

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

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

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

E>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого.

E>Пи<censored>... Трындеж.

Ну, я ожидал, что это не будетт для данного форума чем-то из ряда вон выходящим

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

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.

+1, в этом есть смысл
Всё остальное — просто ни о чем. Резонёрство сплошное.

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

L>Целиком и полностью поддерживаю по всем пунктам!

"А я еще больше люблю господина ПЖ!" (С)

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

A>>В чем демагогия то?
IB>В том, что он передергивает практически каждое предложение и отвечает не на то что было написано, а на то что ему удобно.

Не надо грязи. Иронизирую — да, но нельзя не иронизировать над набором заблуждений и неверных трактовок терминов.
А демагогии в моих словах нет вообще. Ух где она есть, так это в словах АВК.

IT> Возьмём тот же $-макрос из Немерле и сравним со string.Format:

IT>$"Output: $a"
IT>string.Format("Output: {0}", a)

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

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

7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.

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

AF>>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle".

AVK>Перечитай название темы.

И что? Надо перечитывать, пока не перестану там видеть "МП" и "Немерле"?

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

I>До объективности тут как до небес — нет ни одной оценки сложности от тебя или от Влада.

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

Здравствуйте, VoidEx, Вы писали:
VE>Пока что я не вижу массового въезжания программистов в идеи МП (хоть с трудом, хоть без), а про деньги МС и Блабов уже наслышан, но верится с трудом, нерелигиозен.
Странно. Лично у меня опыт на 100% обратный — т.е. я не припомню программиста, который не пробовал баловаться с метапрограммированием. Это прямо с 12 лет.
Я помню, что еще тогда удивлялся тому, что есть программисты, которые пишут программы, заточенные на совершенно конкретную структуру таблички в базе данных.
Ведь вместо этого можно сделать универсальную программу, которая будет читать метаданные и работать с любой таблицей!

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

Поэтому у "въезжания в идеи" с массовостью, имхо, всё ок. Помилуйте, да если 90% программистов эти идеи изобретают, то уж наверное остальным 10% их удастся хотя бы объяснить?

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

I>Еще одна банальность. Невозможно всем дать московские ЗП, проще перевести разработку в Москву и набирать людей там.

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

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

К сожалению, в этом рассказе, я не увидел две вещи которые вроде бы должны были присутствовать в данной теме.
А именно:
1. Я не увидел последовательный анализа проблемы.
2. Я не увидел ни одного конкретного слова про Nemerle (хотя вроде как ему и посвящена тема).
Посему не ясно с чем дискутировать.
Все что я могу — это разобрать разрозненные (на мой взгляд) высказывания и дополнить их или дать свои комментарии.

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

В двух словах этот пункт говорит — "Я против синтаксических расширений потому как людей надо учить".
Сразу возникают два вопроса:
1. А автор темы вообще знает, что макросы в Nemerle не обязаны изменять синтаксис языка? Есть:
* Макросы уровня выражений. Их можно использовать как обычную функцию, но при этом они могут делать значительно больше чем просто фунции, так как выполняются во время компиляции и могут получать доступ как компилируемому коду (и проекту), так и к любым ресурсом в системе. Например, $-строка в Немерле — это макрос который не изменяет синтаксис. Или пример макроса который позволяет в мгновение локализовать локализовать всю программу не возясь при этом с АПИ ресурсов.
* Макро-атрибуты. Это такие же атрибуты как и те что автор темы привык использовать в C#. Только во время компиляции можно вместо них выполнить некоторые действия с проектом или его отдельной частью (например, функцией). Например, макросы из файла DesignPatterns.n: ProxyPublicMembers, AbstractFactory и Aggregate позволяют автоматизировать использование соответствующих паттернов проектирования. Это позволяет не заниматься копипэстом, а декларативно описывать желаемый паттерн и получать его реализацию автоматически. Более подробно об этих макросах можно прочесть здесь. Другими примерами могут служить макро-атрибуты Memoize (позволяющий автоматически кэшировать результаты вычисления для заднных аргументов методов), http://nemerle.org/Record_macroздесь]Record (который позволяет не писать конструкторы вручную).
Создается впечатление, что автор или не знает об этом, или пытается намеренно скрыть такую возможность, так как эта информация вырывается из стройного ряда его изложения.
2. Рассказы о том, что люди плохо учат новый синтаксис — это страшилки для не посвященных. Реально макросы вводящие новый синтаксис упрощают реализацию тех или иных участков программы. Например, такие макросы могут заменять использование громоздкого паттерна на компактный и интуитивно понятный код. Тут даже за примерами ходить не нужно. Конструкции "foreach, using, lock" которые в C# являются встроенными в Немерле являются макросами. Все кто использовал эти конструкции могут представить как было бы неприятно жить без подобных фенечек. Но в языке есть далеко не все, что хочется иметь. Скажем конструкция аналогичная using очень часто нужна когда нужно что-то на время активизировать, а потом, при раскрутке стека отключить. Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.
Где здесь та самая кривая обучения о которой ведет рассуждения автор? Я ее не вижу. Конструкция очевидна, интуитивно понятна и не требует дополнительного описания. А не понятные можно просто не использовать. Это ни чем не отличается от классов и методов с непнятными названиями или от методов с тучей непонятных параметров. Просто там где сейчас уродливый код мы можем написать чистый и понятный код.
Скажу больше. Позиция автора — это чистой воды обман. Не знаю уж осознанный или нет, но обман. Кривая обучения не снизится если в проекте не будут использоваться новые синтаксические конструкции. Она повысится! Почему? Да потому, что обучается человек прикладной логике используемой в программе. А ее тем проще понять чем она проще. И если что-то можно выразить специальным синтаксисом значительно проще чем без него будет проще и понять.

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

Причем тут какой-то конкретный язык я так и не понял.

Времени нет. Так что продолжу разбор полетов позже.

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

KV>А то, что если понимания не возникнет, то и потребности в макросах на все случаи жизни у него не будет, и будет он писать в C#-like стиле, постепенно вникая в технологию, необходимость и целесообразность применения МП. И учитывая

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

KV>

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

KV>я в упор не понимаю, почему это преподносится как аргумент против МП в Nemerle, когда он явно является аргументом "за"

Это ты решил, что Немерле не отнимает времени на освоение.

Нигде не заметил каких то соображений на счет простоты МП и Немерле.

Я же считаю, что дело обстоит совершенно иначе — МП можно давать после того, как у человека образуется хорошая база в .Net, а уже потом, когда появится хорошая база в МП только тогда можно давать Немерле.

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

Т.е. единства внутри сообщества Немерле просто не будет, будет внутривидовая борьба.

Что то похожее есть в Перле, идеология Перла поощряет волюнтаризм, и тоже самое с Немерле.

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

Другие стараются пользовать наоборот, явные конструкции.

В итоге сообщество состоит минима из двух видов перлистов.

Выливается это в невозможность должным образом сопровождать перловые проекты.

В Немерле это будет в гораздо большем масштабе.

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

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

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

G>Не знаю правильно ли понял.. Например, если взять веб-сервисы и кодогенерацию по WSDL — удобнее сгенерировать код и потом править, чем использовать макрос Nemerle, который генерит классы во время компиляции и поменять что-то под собственные нужды довольно сложно. Я правильно описал проблему? Тогда +1.

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

Так что этот пример — большой минус, а не плюс.

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

VD>1. А автор темы вообще знает

VD>Позиция автора — это чистой воды обман.

Ясно. В лес.

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

VD>> Ну, ты просто гений! Я бы так не смог.

AVK>Да, ненадолго тебя хватило.

Ну, вот... и похвалить нельзя.
Сразу ищут в этом подвох. А я искренне восхищаюсь тобой. Вот IT сам справиться не мог. И я не смог. И никто не смог. А ты смог! Причем смог не просто разобраться, но и сделать верные выводы. Это дорогого стоит и позволяет рассуждать о предмете глубоко и интересно.

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

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

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

A>В чем демагогия то?
В том, что он передергивает практически каждое предложение и отвечает не на то что было написано, а на то что ему удобно.

A>Если вы знаете о задачах автора, то можно более подробно. Все повествование завязано на них, но упоминание о них крайне туманно.
Там упоминание очень конкретно. Он по пунктам расписал как именно он видит использование МП на своих задачах и почему немерле тут не подходит.

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

A>И как это понимать?
А что тут не понятного? В способы ведения честного спора "ирония" не входит.

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

R>Я как бы просмотрел последние сообщения IT, пример упомянутого макроса не нашел, или же имелся ввиду вот этот

R>

R>$"Output: $a"
R>string.Format("Output: {0}", a)
R>

R>но где здесь 5 спецсимволов и где здесь клиника?

Где там 5 спецсимволов, неясно.

Но вот код такой просто клиника.

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

Прозрачности в первой строке около нуля, как объяснить например студенту первого курса подобное — неясно. Вот она, сложность.

Далеко ходить не надо.

Есть два цикла, for и foreach

Первый суть алгоритмическая структура для итераций, а второй это очень, очень, очень сложная штукенция.

использовать если бездумно, то проще foreach

А если хоть немного думать при использовании, то только этот цикл требует разъяснения чуть не всего что есть в .Net вообще.

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

M>>1) $
M>>2) "
M>>3) :
M>>4) $
M>>5) "

M>>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.

R>Скажите мне, что это стеб А то невольно вспоминается разговор про синтаксический оверхед господина Губанова

Стеб или нет, но язык действительно птичий Write Only.

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

M>7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.

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

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

R>>>Да ну А обоснования будут?

I>>А надо ? Не мог бы ты еще больше текста скипать ?

R>А как же. Не рассматривать же в качестве объяснения "клиники" размышления про разницу между for и foreach

Я честно скажу — с трудом догоняю эти $. Я хорошо понимаю только то что легко проговаривать.

R>А почему не наоборот Причем, что первую что вторую тоже вполне может понадобиться разъяснять через printf, если человеку так легче.

Потому что это будет обман будет.

I>>VladD2 сам объясняет через C# код и удивляется где же сложность.

R>Статья больше была расчитана на людей с C# бекграундом, будь она расчитана на другую аудиторию — были бы и соответствующие примеры

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

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

I>Как же он поймет если ты не хочешь прояснять и пояснять свою позицию ?

Извини, но я не знаю как объяснять такие вещи. Название темы абсолютно не допускает ни какого толкования. Там прямым и понятным русским языком сказано.

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

M>$"Output: $a"

IT>>Первый вариант довольно тупо реализуется в runtime через string.Concat.

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

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

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

IT>>Бывает, бывает. Есть генерилки, которые вообще не заточены на автоматическую генерацию вроде Custom Tools. С ними нужно повозиться, указать все необходимые параметры и потом раз и сгенерировать. После этого сгенерированный код используется как обычный рукописный. Народ этим широко пользуется.

VD>Есть, пользуются... не спорю. Только это уродство.

Что-то из тебя какой-то неадекват попёр.

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

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

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

VD>Согласен. Скажу больше. У формат-стринга есть еще одно приемущество (в некоторых случаях) — она позволяет менять формат в рантайме.

VD>Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:
VD>

VD>$"Rum-Coke: $(F2(10 / 3))"
VD>

А знак доллара выведется? Или он должен быть частью функции форматирования?

VD>Или тупо воспользоваться форматом.
Хм. А ты можешь пояснить, почему строки сделаны именно так? Как аналог перла?
Потому что мне, к примеру, кажется, что для внедрения на рынок дотнета выгоднее было бы починить проблемы String.Format.
Самый хомячковый вариант — заменить номера аргументов на сами выражения.
Тогда бы работало, скажем, вот так:

Console.WriteLine($"Rum-Coke: {price:2}");

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

VD>В этом споре замечательно продемонстрировано как самые прогрессивные идеи могут разбиваться о косность и упрямство недолеких людей заучивших однажды что-то и считающих дальше что это true way.
А без намёка на мою недалекость можно было обойтись?

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

KV>Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого.

Пи<censored>... Трындеж.

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

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

I>>>>>Архитектура и меняется рефакторингом, а у же потом вносится новый функционал. Но часто отделить рефакторинг от написания нового функционала просто невозможно.
G>>>>Значит вы неправильно делаете рефакторинг.

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

I>Покажи пример неправильного рефакторнга.
Неправльный рефакторинг — тот который нарушает наблюдаемое поведение системы.

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

Визарды, custom tools и даже не упомянутые паттерны проектирования и пост-билд утилиты вроде FxCop — расцвели только из-за полного отсутствия каких-бы то ни было средств МП в C#/VB.NET. Не уверен только насчёт DSL.

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

По пунктам:

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

Log.Write($"Обновление $(line.Group.Name) завершено.");

Выглядит как вызов статического метода. Программист который это использует может никогда не узнать что статический метод не вызывается вовсе, а вместо этого создаётся код, который через service locator'ы собирает все доступные из метода сервисы логгирования и каждому вызывает уже экземплярный метод Write.

2) Если насущная необходимость ограничить по максимуму — то можно создать класс или несколько с методами, которые разрешено использовать конечному разработчику. То что все вызовы во внешнюю систему делаются только через методы этого класса отследить средствами МП легко. Более того можно свой синтаксис довесить, который только разрешённые методы будет использовать. Можно даже нацепить аттрибут уровня класса вроде [Skill(Level=Junior)] и такой аттрибут может проверить что в коде не используется методов относящихся к более высокому уровню сложности.
Одна лишь разработка качественного DSL парсера может встать в задачку сложнее чем разработка целой кучи макросов, классов и т.п. А может и нет. Зависит от DSL.

3) С внутренним устройством например студийных визардов не знаком. Работал только с кодогенераторами вроде CodeSmith, LLBLGen, MyGeneration — так им какие шаблоны целевого кода скормишь, такие файлы и сгенерируют. Многие шаблоны генерации были бы просто не нужны, имей компиляторы .NET средства МП как в Nemerle.

4) Как и в 2) — всё зависит от DSL.

5) Задача интересная, но очень специфическая и все ограничения из столь краткого описания не ясны. Интересно, если бы прикладной код был написан на Nemerle (или на языке с МП как в Nemerle) и теми же макросами в методы были вставлены вызовы пустых методов из внешней сборки, а в момент деплоймента с сервера забиралась бы уже реальная/обновлённая сборка, выполняющая инструментирование, это не решило бы проблему?

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

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

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

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

IT>В том-то и дело, что это не проблема макросов. Макросы всего лишь средство выражения твоих решений. Если твои решения сложны для использования в твоей команде, то неважно как эти решения будут реализованы. Как раз макросами наоборот можно выразить это проще и доступнее. Возьмём тот же $-макрос из Немерле и сравним со string.Format:

IT>$"Output: $a"
IT>string.Format("Output: {0}", a)

Кстати, а как предполагается локализовывать подобного рода строки?

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

U>>1) Добавление в язык птичьей конструкции "$", которая не вызывает никаких ассоциаций, соответственно плохо запоминается.
VD>Я даже не знаю что можно сказать на такое. Кроме как домыслами это назвать больше никак нельзя (ну, если оставаться в рамках приличия).
VD>Ты без проблем сам запомнил все что нужно и процитировал прямо. Что тут еще запоминать?

В чем достоинство именования вроде string.Format? В том, что если я завтра захочу написать аналогичную функцию мне понятно как ее назвать (<тип объекта>.<действие>), оставаясь в рамках концепции предложенной разработчиками шарпа. Если же я завтра захочу написать свой макрос аналогичный $ как мне его назвать? $my, $$, L, $my_macros, my, my_macros? Как назвать правильно непонятно, потому что за названием $ нет концепции. А это очень плохо, т.к. приводит к тому, что разработчики будут называть свои макросы как бог на душу положит, соответственно с интуитивной понятностью чужого кода придется попрощаться. Отсутствие концепции это и есть птичий язык, который можно только запомнить, а не интуитивно вывести.

U>>2) Ошибок форматирования, пожалуй, станет меньше, но они не исчезнут, такое ни компилятор, ни рантайм не отловят: $"Некая константа: obj1, $obj2" // забыли спецсимвол перед obj1.
VD>Другими словами мы нашли недостаток в том, что ошибок станет меньше, а не ноль?

Вот при такой записи допустить ошибку необнаруживаемую компилятором практически невозможно:

"Некая константа: " + _.s(obj1) + ", " + _.s(obj2);

В отличие от сплайс-строк, т.е. идеала сплайс-строки не достигли, это минус.

ps
Вообще, если бы сплайс-строка выглядела примерно так:

string.Inline("Некая константа: {obj1:F2}, {obj2}");

То решение бы мне наверное даже понравилось, т.к. оставалось бы в рамках концепции шарпа.

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

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

I>>>Ага, на рынок труда берем так и влияем.
4>>Получается, что влияете, т.к. открываете вакансии для "минимально справляющихся".
I>Кто тебе такое сказал ? Не только к нам дубы идут на собеседование, представь.
Беря на работу "минимально справляющихся" вы увеличиваете спрос (вернее величину спроса) для низкокачественной рабочей силы, тем самым увеличиваете предложение низкокачественной рабочей силы. А учитывая что количество программистов со временем растет медленно, то вы в среднесрочной перспективе еще и снижаете предложение более квалифицированной рабочей силы.

Кроме того из ваши постов видно что вы находитесь не в Москве\Питере\Другом_крупном_центре_разработки_ПО, при этом штат у вас порядка 100 человек, что достаточно много (я, например в Ростове-на-Дону обитаю, у нас софтверных контор от 100 человек нету). начит вы играте значительную роль на рынке программистской рабочей силы в вашем городе.

4>>Это банально дешевле + высокая гарантия положительного результата.
I>Это так. Но только в краткоскрочной перспективе.
Как раз набор высококачественных спецов выгоден в долгосрочной перспективе. Любая ставка на качество в разработке ПО выгодна именно в долгосрочной перспективе. Можете даже не спорить, это статистика.



4>>когда получалось, что 5% вытягивают остальные 95%.

I>Это и ежу ясно. Только надо учесть всего несколько моментов
I>1. специалистов надо набрать
I>2. специалистов надо удержать
I>Набор всегда и везде делается из тех, что на рынке труда, а не абстрактных.
I>Удержание задача очень сложная, больше всего проблем составляют не конкуренты в городе, а города/страны с большим уровнем ЗП.
А платить деньги людям не пробовали?
А создавать условия работы?
А давать потенциал для развития?

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

I>Результат весьма плачевный — убыток из за отсутствия специалиста очень часто гораздо больше привлечения студентов.
Это только в краткосрочной перспективе. Кроме того можете создать условия, к торых вчерашние студенты будут учиться у опытных спецов. При этом поддерживать разумное соотношение между "спецами" и "студентами".

I>А вот крупные проекты это уже совсем другое дело. Удержать 5 и более лет специалистов уровня сеньора задача очень сложная, особенно когда в соседней стране такой может в короткий срок заработать на квартиру, вернуться обратно и даже открыть фирму.
Хм... повторюсь... А денег платить не пробовали?

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

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

Кстати вы сами писали что работали на проекте на котором за год пару раз сменился состав разработчиков.
Каким образом вы удерживаете людей когда набираете студентов, а текучка в год составляет чуть ли не 200%?

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

AVK>Итак, сабж.
AVK>...

Целиком и полностью поддерживаю по всем пунктам!

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

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

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

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

КЛ>то-же самое качается фреймворков

Конечно. Разница только в одном — в рамках. У немерлевых макросов они сильно шире, нежели чем у фреймворков. Поэтому и эффект намного сильнее.

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

A>Про

A>1. Design_by_contract прикручивается на раз. И иже с ним...
A>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
A>3. "MPS, DSL Tools, Oslo" — еще один нужный (модный) ЯП, а может лучше "швейцарский нож"? Майкрософт всунула SQL в C#, так почему нельзя всунуть Oslo в Nemerle?
A>4. По поводу кодогенерации. Я считаю что МП в Nemerle не конкурирует с ней, а дополняет.
A>5. Если смотреть на МП в Nemerle как слишком БОЛЬШУЮ вещь, которую программерам лучше не давать — имеет слабую аргументацию. Уже вроде давно как доказан вред goto, но он есть в большинстве языков, в том числе и в недавно родившихся...

На все эти вопросы мой ответ содержится в корневом сообщении.

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

VD>Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова.
Это если не удалось хорошо распилить код при помощи partial классов.

VD>А ведь это может произойти тогда когда детали будут забыты, что приведет к серьезнешим проблемам и тормозам в развитии проекта.
VD>Макрос же — это настраиваемая программа генерации кода написанная на высокоуровневом расширении очень высокоуровневого языка. Научить его генерировать код так как надо тебе не сложно. Править при этом ничего не придется. Если появляется задача изменить генерируемый код, то достаточно будет чуть-чуть поменять логику (например, добавить нужный параметр макросу).
Вот тут (см. выделенное) есть некоторые сомнения. В том смысле, что если у тебя возникает т.н. one-off ситуация, то есть что-то там нужно подшаманить ровно в одном месте, то это проще всего подшаманить ровно в этом одном месте. Подшаманивание генератора рискует дать труднопредсказуемые эффекты в других местах, где поведение уже отлажено.

Я не могу сходу придумать реалистичный пример, но нутром чую, что за ними дело таки не станет — только начни реальное применение. И AVK ровно об этом говорит. Генерировать код — нетривиальная задача.
Вот есть, допустим, автоматический генератор SQL запросов по некоторой модели.

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

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

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

То есть ты реально пробовал всё это делать сам лично, причем с помошью Немерле?
Вах, я потрясен твоим опытом.

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

AF>>>"А я еще больше люблю господина ПЖ!" (С)
AF>>>

L>>Кто это?
S>http://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B4%D0%B8%D1%84%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D1%88%D1%82%D0%B0%D0%BD%D0%BE%D0%B2

Не, гипотеза не верна. т.к. из нее с необходимостью следовало бы, что и перед Top 0 rsdn-а я тоже должен был делать "Ку", а это, мягко говоря не совсем так.

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

VD> Ну, ты просто гений! Я бы так не смог.

Да, ненадолго тебя хватило.

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

VD>Процитируй, плиз, кусок своего сообщения который давал бы ответ хотя бы на этот вопрос:
A>>>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
Есть даже два.
Почему это не нужно конкретно AVK:

Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.

Почему этого не стал делать MS, и почему это в принципе может быть не очень здорово:

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

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

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

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

M>Например, многие мои знакомые англичане достаточно бегло говорят на английском языке и даже не спотыкаются на таких конструкциях как "will have been". Как ты думаешь, сложность использования времён в английском языке тоже надумана?

К чему эта демагогия? Давай обойдёмся здесь без времён и англиских знакомых. Ты считаешь использование макросов сложным делом? Приведи пример, если сможешь, который демонстрирует эту сложность. Я со своей стороны попытаюсь приложить все усилия, чтобы понять в чём эта сложность состоит. АВК, кстати, привёл такой пример — yield return. Трудно видишь ли некоторым это понять. Согласен, трудно. А ленивость в Linq не трудно? Проблема ведь та же, но ни одного ключевого слова там нет. Одни сплошные функции. Так в конструкциях языка дело ли? Тоже самое и с макросами. Макросы — это форма, такая же как и классы, методы, языковые конструкции. Настоящая сложность не в них, а в концепциях, которые они реализуют. Если в твоих проектах используются библиотеки общих компонент, то сложность их использования и сложность использования макросов будет абсолютно одинаковой. Никакой разницы.

IT>>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.

M>Понятное дело. Более того, если через полтора года что-то где в этом отлаженом механизме чем-то накроется -- нужно всего лишь найти того программиста, который это написал, кинуться ему в ноги, заплатить хороших денег -- и проблема решена. Куда проще чем попросить первого попавшегося и сунуть ему в зубы раздел MSDN по Custom Tools.

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

IT>>можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать.

M>Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.

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

M>Знаешь, в одной конторе провели чемпионат по Солитёру и всех трёх финалистов назавтра выперли. Так вот Солитёр не единственный непроизводственный "скил".

Что-то тебя сегодня на демагогию прорвало. Солитёры, чемпионаты Думаешь это делает твои умозаключения (кстати, какие?) более убедительными?

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

Ясно, значит, какой реальный опыт. Но я отвлекся.
Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle". Выяснилось, что он не в состоянии вложить мозги в головы дураков и грамотно сделать проектирование вместо программиста. Действительно, фатальный недостаток системы МП

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

AF>Например, возможность запретить использовать треды для низкоквалифицированных программистов. Или ограничение на unsafe-конструкции, как в C#. Или запрет обращаться к файловой системе и реестру напрямую в слое бизнес-логики. И т.д., и т.п.

Это не DSL. Это больше смахивает на FxCop.

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

VD>Ну, вот... и похвалить нельзя.
VD>Сразу ищут в этом подвох. А я искренне восхищаюсь тобой. Вот IT сам справиться не мог. И я не смог. И никто не смог. А ты смог! Причем смог не просто разобраться, но и сделать верные выводы. Это дорогого стоит и позволяет рассуждать о предмете глубоко и интересно.

Остапа понесло. Молодец, ты прекрасно продемонстрировал причину, по которой я не отвечал на твои вопросы.

VD>Да и как по другому?

Действительно. Не нахамишь — день зря прожит.

I>>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.

VD>- Да дерьмо этот ваш Корузо.
VD>- По чему это?
VD>- Петька вчера напел.

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

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


IT>$"Output: $a"
IT>string.Format("Output: {0}", a)

IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.

Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.

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

Для объяснения "делает всякое со строкой" разумеется проще первый.

А вот для нормального использования надо знать все, что спрятано за коротенькой строчкой.

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

Второй пример без объяснений понятен любому, кто хотя бы пару месяцев осваивал программирование.

IT>Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач, чем аналогичное решение без макросов.

В том то и дело. Это и поднимает порог для входа.

IT>Что-то ты меня совсем запутал. Использовать просто, но простота использования порождает сложность. Какую сложность? Я не понимаю.

Ну примерно так -бинарный код самый простой из языков программирования он же самый сложный

Простота использования очевидна — пиши себе единицы и нули сколько влезет и как попало.

Сложность тоже очевидна — никому не ясно, что же там делается то.

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

M>7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.

Я как бы просмотрел последние сообщения IT, пример упомянутого макроса не нашел, или же имелся ввиду вот этот

$"Output: $a"
string.Format("Output: {0}", a)

но где здесь 5 спецсимволов и где здесь клиника?

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

I>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Кроме того, если у разработчика возникнет понимание МП в Nemerle (а иначе как он придет к желанию покрыть макросами все его возможные потребности?), то он уже вполне может считаться "недебилом" и начать потихоньку писать их самостоятельно.

I>Ну, так, и что ?

А то, что если понимания не возникнет, то и потребности в макросах на все случаи жизни у него не будет, и будет он писать в C#-like стиле, постепенно вникая в технологию, необходимость и целесообразность применения МП. И учитывая

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

я в упор не понимаю, почему это преподносится как аргумент против МП в Nemerle, когда он явно является аргументом "за"

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

M>>Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.

KV>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.

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

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

Если нечто этим свойством не обладает, то это не технология вовсе.

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

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

Вот например, у нас на проекте работают

1 Тестировщики
2 Девелоперы
3 Алгоритмисты(это девелоперы но завязаные на очень узкую часть — алгоритмы которые придумывают математики)
4 Математики
5 специалисты по предметной области

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

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

P.S.

Вобщем то данный топик крутится вокруг одного вопроса — оценка сложности конструкций.

Игра приобрела такой расклад — одна часть считает что $"Output :$a" сложно, а вторая наоборот, считает что легко.

Как разрешить этот вопрос со сложностью — неясно.

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

A>Это проблема думать на Блабе

Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.

Кстати, парадокс Блаба — сладкая самообманка для "элиты", потому-то её так и любят пользователи крутых (по всем параметрам крутых!), но непризнанных (возможно пока, хотя насчёт ЛИСПа уже почти и сомнений нет, у Немерле ещё всё впереди) языков, автоматически записывая остальных в Блабы, даже если понимают, что это не так.
И уж это чья угодно проблема, но никак не программистов, которые выбирают язык.

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

I>А между тем, см. выше, без малого, 100% софта пишут безграмотные специалисты.

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

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

Это я к чему. 100% софта безграмотные специалисты пишут там, где это является стратегией компании. Примеров я могу привести мильён как из собственной практики, так и из практики друзей. Всё не так плохо. И не надо изо всех сил убеждать других в обратном.

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

IT>>$"Output: $a"
IT>>string.Format("Output: {0}", a)

IT>>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.

I>Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.

Это обманчивое впечатление, которое базируется на знании и привычности второго варианта. Мне, например, в своё время казалось, что круче "Output: %s" вообще ничего быть не может. Оказалось может. А потом оказалось, что может быть даже круче того, что может быть круче первого. В общем, не надо путать свои привычки, предпочтения и желанием поспорить с объективностью. Сплай-строки реально круче, а при соответствующей подстветке в студии ещё и гораздо нагляднее.

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

VE>>Кстати, парадокс Блаба — сладкая самообманка для "элиты", потому-то её так и любят пользователи крутых (по всем параметрам крутых!), но непризнанных (возможно пока, хотя насчёт ЛИСПа уже почти и сомнений нет, у Немерле ещё всё впереди) языков, автоматически записывая остальных в Блабы, даже если понимают, что это не так.

Y>А это видимо сладкая самообманка для "мейнстримщиков", которые по каким-либо причинам не могут использовать действительно крутые языки

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

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

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

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

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

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

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

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

AF>И что? Надо перечитывать, пока не перестану там видеть "МП" и "Немерле"?

Нет, надо перечитывать, пока не поймешь смысл написанного.

IT>В общем, не надо путать свои привычки, предпочтения и желанием поспорить с объективностью. Сплай-строки реально круче

Вышел и чётко сказал: реально круче. Это тебе не какие-то предпочтения.

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

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

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

И правда, пора бы.

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

I>>Придется объяснять это так. А вот первую строку придется объяснять через вторую, как ни крути.

IT>Первый вариант довольно тупо реализуется в runtime через string.Concat. Алгоритм второго сложен и запутан. Что проще объяснить?

Ну вот, раз первый реализуется через string.Concat, то string.Concat проще для понимания.

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

IT>>Первый вариант довольно тупо реализуется в runtime через string.Concat. Алгоритм второго сложен и запутан. Что проще объяснить?

I>Ну вот, раз первый реализуется через string.Concat, то string.Concat проще для понимания.

Офигительный вывод

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

ЗЫ. ИМХО, этот топик пора уже в Коллеги улыбнитесь переносить, а то читать уже без улыбки невозможно

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

M>Как я тебя понимаю!

M>Но по-моему это не стёб, они всерьёз этот птичий клёкот $"output:"$" считают понятнее string.Format.

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

А раз общения не будет, то и распространяться будет медленно.

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

IT>>$"Output: $a"
IT>>string.Format("Output: {0}", a)

L>Кстати, а как предполагается локализовывать подобного рода строки?

Зачем?

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

VD>Писать мета-код на С++ очень сложно. Понять его тоже весьма сложно. От того писать его могут единицы. Факт? Факт!

Твоими бы да устами... А то ведь пишут, читают Александреску и пишут...

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

VE>>Нет нет. "Наоборот" — это уже будет не доказательство. За что люблю детские вопросы типа "зачем", "почему", потому что они раскрывают, что тот, кто говорит, сам ничего не понимает, если до сути докопаться.

VD>Детям практически нельзя ничего объяснить серьезно. Как правильно заметил IT детям говорят, что "солнышко пошло спать", а когда они подрастут и поумнеют, им объясняют, что земля крутится вокруг солнца. За-то у детей есть доверие к взрослым. И если ребенку сказали что-то, то он это принимает это на веру.
Дети умнее, чем ты думаешь. Да и люди умнее, чем ты думаешь.
VD>Тут же получается глупая ситуация. Есть люди которые не в состоянии что-то воспринять по причине отсутствия базы и опыта, но на слово они не верят и требуют каких-то доказательств.
Нет, есть люди, которые сами не знают ответа, поэтому на вопрос детям "есть ли Бог" начинают мямлить всякую фигню типа "подрастёшь поймёшь", а взрослым — что у них нет базы.

VD>Ребята. Вам ничего доказать нельзя по причине отсутсвия базы. Идите наберите эту базу, а потом приходите и вам не придется ничего доказывать. Достаточно будет просто объяснить.
Ну-ка ну-ка. Какой базы? Религиозной? Веры в истинность некоторых спорных утверждений? Или что-то конкретное? Какой у нас базы нет? ФП, МП? Я гляжу, конкретики никакой, зато громких фраз много о том, что лучше, и ни слова о том, почему.
(И да, ты тут всех под одну гребёнку не равняй, я понимаю, что проще кучу человек в качестве некоего образа врага рассматривать, но я тут к сплайс-строкам например претензий не имею и меня интересовал только тот вопрос, который я задал)

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

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

VD>При этом свои абсурдные утверждения наши оппоненты обосновывать не считают нужным.
Это тебя оправдывает

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

S>Очевидно, тебе достаточно заменить все аргументы AddMessage одним вхождением сплайс-строки.

Хорошо, давайте теперь разберемся с плюсами и минусами такого решения:

Плюсы:
1) Некоторые ошибки форматирования станут невозможными, например, string.Format("Некая константа: {0}, {2}", obj1, obj2).
2) Более очевидный порядок переменных в строке.

Минусы:
1) Добавление в язык птичьей конструкции "$", которая не вызывает никаких ассоциаций, соответственно плохо запоминается.
2) Ошибок форматирования, пожалуй, станет меньше, но они не исчезнут, такое ни компилятор, ни рантайм не отловят: $"Некая константа: obj1, $obj2" // забыли спецсимвол перед obj1.
3) Сложный вывод форматированных значений.

Также еще несколько вопросов:
1) Что будет если переданное макросу сплайс-строки значение равно null?
2) Как записать такую форматную строку: string.Format("{0}добавление")? Т.е. как макрос понимает, что имя переменной закончилось и началась строковая константа?
3) Как работает приведенное Владом: $"Rum-Coke: $(F2(10 / 3))"? В какой код эту запись развернет компилятор?

В принципе если сравнивать приведенные плюсы и минусы, то возможно плюсы и перевесят, хотя и несильно. Но проблема в том, что записи: TraceHlp2.AddMessage("Некая константа: {0}, {1}", obj1, obj2) и TraceHlp2.AddMessage($"Некая константа: $obj1, $obj2") неэквивалентны. Например, завтра мне понадобится лог локализовать. Что мне делать если я использую строку форматирования понятно — исходная строка форматирования становится ключом, по которому находится строка форматирования для нужного языка. А что я должен делать, если использовал сплайс-строки?

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

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

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

M>>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.

IT> Считовод, блин. А почему пробел не посчитал?

Считовод ты сам, блин. У тебя не спросил.

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

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

I>>>А если у тебя МегаАрхитектура и требования не должны её ломать — извини, ты просто не умеешь делать рефакторинг.
VGn>>Я-то умею делать рефакторинг, а тот, у кого одна заплатка рвёт другую, скорее всего и не умеет.
I>При чем здесь заплатки, объясни ?

I>Вот придет заказчик и скажет, что в новой версии хочет видеть функционал который в предыдущих вообще не предусматривался.
I>Что ты ему ответишь ?
I>Это как раз тот случай, когда решение одной проблемы влияет на решение другой.
Нормальный product manager посовещается с разработчиками и скажет сколько такое будет стоит и в какой срок примерно будет готово.

I>А рефакторинг это как раз и есть способ разрешения подобных ситуаций.
Разберитесь в терминах. Рефакторинг — изменение кода с целью его улучшения без изменения внешнего поведения.
Ключевое выделено.

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

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

S>Я не готов делить шкуру ненаписанного кода. Возможно, ты и прав, но у меня нет никакой уверенности в том, что можно прямо вот так сесть и написать с первого подхода архитектурно красивый макрос.
S>Вот простое упражнение: берем существующий немерлёвый макрос sprintf и добавляем к нему умение читать не только тип данных, но и (опциональное) количество цифр после запятой.
S>Сколько это займет времени?

S>Теперь давай представим себе, что нас (прикладных разработчиков) везде устраивает тот вид sprintf, который был. И ровно в одном месте нам надо ограничиться одним знаком после запятой. Сколько времени заняло бы исправление сгенерированного кода?

Мда, меня всегда забавляли гипотетико-теоретики

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

I>>>Потому что для команды топов нужен топ-менеджер
G>>Так наймите такого менеджера. Он любых денег стоит в любом регионе.
I>Проще переехать в Москву, это не ко мне, это к руководству Там будет выбор и девелоперов и менеджеров.
Да вам уже десять раз сказали что не проще по многим причинам.

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

I>>>Есть определенная специфика отрасли, в основном наукоемкие десктоп-приложения, проектам в среднем лет по 5. Они не заканчиваются, разрабатываются версия за версией пока есть спрос.
G>>Такой тип проектов я называю "болото". Самый непревлекательный тип проектов для опытных разработчиков.

I>Опытные разработчики они разные, я бы не равнял всех по интересам.
I>Болото это когда технологии хорошо если девяностых годов — таких кстати говоря довольно много.
Ну а C++ каких годов? И какой интерес может быть в "болоте"? Разве что расширение своих занний в проедметной области, но такого интереса как раз на год хватает.

I>Въехать в проект я нызваю возможность более менее-полноценной замены одного из старых разработчиков.
I>А если разобрался с архитектурой, дизайном пары тройки подсистем — это до въезжания далеко.
Так это вообще другая величина. Такое "везжание" требует получения знаний на уровне автора проекта, что может быть не достигнуто и за 10 лет.
Обычно под "въезажинием" понимают когда человек способен писать production-код в разрабатываемом приложении. При этом необязателньо он должен заниматься архитектурой и высокоцровневым дизайном.


G>>Хм... Зашел в статистику по ЗП, С++ средняя зп 1100$, вы платите выше на 30%-50%, те 1400$-1600$ грубо говоря. И это для не самых крутых разработчиков.
I>1100 на этом сайте довольно сильно завышена, правильно будет около 1000, в динамике можно глянуть, непонятно с чего в середине осени рост взялся.
I>Студенты обычно получают от 500. Год-два после универа — это 1000. Топы получают 2000 обычно.
I>Все что выше это уже стартапы и практически всегда серая ЗП.
Так всетаки мало платите, и ваши слова о 30%-50% ЗП выше среднерыночной — фикция.

G>>Топу вполне можно платить в 2 раза больше, потому что он реально будет работать за двоих, то есть 2800$-3200$. Получаются очень даже московские ЗП для топов.
I>Топы, которые в Минске получают до 3000 обычно в Москве или Ньюйорке берут куда большие деньги. Здесь ничего не меняется.
I>Топы в Москве не получают 2800-3200
Но не каждый получающий 3000$ в Минске или в любой_другой_не_мскве захочет поехать в москву.

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

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

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

G>>>Так это вообще другая величина. Такое "везжание" требует получения знаний на уровне автора проекта, что может быть не достигнуто и за 10 лет.
I>>О чем и речь. То въезжание, о котором ты говоришь, и за въезжание не считается.
G>Это ты так думаешь. Я работал с десятками людей, которые успешно писали production код без полного въезжания в архитектуру системы в целом.

Есть версия, что, если для написания кода продакшн качества надо знать всю архитектуру системы в целом, то архитектура тогда не слишком модульно построена и в ней слишком много coupling (сцепления?)

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

A>>>Что подразумевается под словами "в моих задачах"?

AVK>>Хм, по моему это вполне по русски. Подразумевается, что речь идет о тех задачах, с которыми сталкивался и сталкиваюсь именно я, и на глобальные обобщения на всю софтописательную индустрию и тенденции ее развития я не претендую. Что именно непонятно?

A>>>Я правильно понял?

AVK>>Странный вопрос. Не знаю я, как ты понял.

A>И вот как дальше обсуждать? Иду лесом...

Так как я не телепат , то буду рассматривать "в моих задачах" как "к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков"

Про

1. Design_by_contract прикручивается на раз. И иже с ним...
2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
3. "MPS, DSL Tools, Oslo" — еще один нужный (модный) ЯП, а может лучше "швейцарский нож"? Майкрософт всунула SQL в C#, так почему нельзя всунуть Oslo в Nemerle?
4. По поводу кодогенерации. Я считаю что МП в Nemerle не конкурирует с ней, а дополняет.
5. Если смотреть на МП в Nemerle как слишком БОЛЬШУЮ вещь, которую программерам лучше не давать — имеет слабую аргументацию. Уже вроде давно как доказан вред goto, но он есть в большинстве языков, в том числе и в недавно родившихся...

Контра

Если коротко — это отсутствие ECMA стандарта. Если есть желание обсудить — распишу более подробно и по пунктам.

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

[]

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

AVK>Между индусами и мегапрофессионалами есть непрерывных спектр промежуточных вариантов.

есть, и этому спектру предлагают асиливать замыкания, правила overload resolution, контр/ковариантность. А вот атрибут навесить, который по сути макра, это сложно.

КЛ>> Вот, к примеру, RhinoMock. Нетривиально там все внутри? Так зачем мне знать, что там внутри? С макросами так-же.

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

Ок, давай отбросим макры уровня выражений. Отбросим даже те, которые синтаксис не меняют. Имеем синтаксис атрибутов. Этож почти как наследование. Добавил атрибут, есть в базе IXmlSerializable. Вроде ниче сложного. Писать будут сильные ребята из спектра, спектр тока атрибуты вешать

[]

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

А в немереле генерация кода за счет использования квазицитирования и декларативности должна писаться еще проще. CodeDom по сравнению с ней — мамонт

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

Каждый свою success story имхо сам должен делать. Неважно в целом по жизни или в применении каких-то фич каких-то языков в какой-то предметной области. У кого-то вон milliondollarhomepage выстрелил — и success story офигительная и бизнес модель явно проще чем самое короткое описание пути конвертации yield return в деньги

M>Короче, вся эта крутизна пока не подтверждена убедительной success story.

Я Nemerle success story

Автор: hi_octane
Дата: 14.02.08

почти год назад выкладывал, и даже на вопросы отвечал. Проект тот и сейчас развивается.

M>А без success story как ты промотивируешь команду сесть и вложить неделю времени в академические одиссеи?

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

Как переходила на Nemerle наша небольшая команда

Автор: hi_octane
Дата: 18.02.08

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

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

L>А префикс сплайса в L-строках все так же продолжит работать как и в $-строках?

Да. Но надо понимать, что это макрос, так что можно сделать так как тебе нравится.

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

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

VD>Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.
Не снимает. Проблема не в том, что можно так не делать, проблема в том, что так делать в принципе можно, об этом говорилось уже ни раз.

VD>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.
Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

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

VD>Так вот поддержка ДСЛ-ей заключается не в наложении ограничений или расширений к основному языку, а в том, что язык позволяет описать совершенно новую семантику, а иногда и синтаксис.
С набором ограниченных возможностей.

[PR метапрограммирования поскипан...]

VD>Но ты почему-то проигнорировал наши просьбы дать расскзать о проблемах МП в Немерле. Вместо этого ты почему-то рассказал нам о своих предубеждениях (ни на чем не основанных).
Во-первых, никто не обещал рассказывать про проблемы МП в немерле, обещали рассказать чем не устраивает немерле именно AVK, и именно это и рассказали.
А во-вторых, рассказали на чем именно основаны "предубеждения".

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

VD>Ведь только в честных спорах рождается истина.
Возможно. Но только честно спорить ты не умеешь.

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

VD>Кого я задрал?
Меня.

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

VD>Это не аргумент.
Для меня — аргумент.

VD> Запрети в своей конторе их использовать или дай разрешение на их введение только определенным лицам (т.е. себе любимому) и проблема исчезнет как класс.


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

VD>Андрей просто неверно трактует термины встроенный DSL и мета-программирование. Об этом я и говорил.
Даже если это и так, то речь идет не о терминах. Все прекрасно поняли что именно он делает и почему для этого не годится Nemerle.
Если ты не согласен — у тебя есть два варианта:
1. Объяснить AVK, что на самом деле Nemerle для этого годится.
2. Объяснить AVK, для чего еще мог бы пригодится Nemerle в его задачах, тем более, что ты о них знаешь.
Вместо этого ты домотался до терминологии, что совершенно не существенно в данном контексте, это и называется — прикладная демагогия.

VD>Да, и это нужно четко понимать если уж ты взял на вооружение ДСЛ-подход.
VD>Ты не сужаешь и не расширяшь базовый язык.
Отлично. Ну, а AVK надо именно сузить, а нерасширить => Nemerle здесь не подходит, о чем он и написал.
Таким образом, мы выяснили, что AVK, знал о чем писал и правильно оценил возможности Nemerle. Как следствие, твои наезды совершенно беспочвенны, хотя возможно используемая терминология ввела тебя в заблуждение.

VD>Неужели это плохо?
Возможно хорошо, просто AVK это не нужно или не устраивает из-за побочных эффектов.

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

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

I>Да, представляешь, берем на работу студентов 3-4го курса. Наиболее перспективные кандидаты. Был случай, когда ст. 2го курса работал.

Т.е. кандидаты наиболее перспективные, но учиться уже не хотят? Как-то это не стыкуется.

I>В каком городе ты работаешь ?

В НуЁрке.

I>Ага, у вас все кандидаты наук, в какую область ни ткни, хучь медицина, хучь сопромат, так ?

Кандидатов в нашей команде нет. Нет такой необходимости.

I>И все при этом на ура знают любую часть девелопмента ?

Практически любую. Есть один индус, который занимается только SQL и Перлом. А так .NET, Web, UI, серверная бузинес логика, SQL. Каждый знает всё. И в этом есть один очень большой плюс. Узкая специализация, разделение работы горизонтально на UI, BL, DB требует постоянного взаимодействия между UI, BL и DB девелоперами. А это задержки и конфликты интересов, в худшем варианте перетягивание одеяла. В IBM я на это насмотрелся выше крыши. Специализация в софте плохо работает. Если в промышленности сталевар варит сталь, а фрезеровщик фрезерует фрезой, то их работа связана довольно чётким технологическим процессом, который в частности исключает взаимодействие этих парней между собой. В софтостроении исключить взаимодействие разных специализаций крайне сложно. В результате мы имеем постоянные нестыковки, бесконечные митинги, конфликты интересов, чем больше бумаги, тем чище жадница и прочую малоэффективную активность.

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

Новые технологии, библиотеки изучаются по мере их появления и начинают применяться после их доступности в конторе на живых проектах, анализируется положительный/отрицательный опыт и принимается решение быть или не быть. Например, мы всё ещё в процессе поиска наилучшего решения для Web. AJAX от Microsoft, который UpdatePanel, был забракован после использования на одном проекте. Сейчас другой девелопер на другом проекте использует другой подход. Будет положительный результат, другие проекты тоже пойдут на этом фреймворке. Параллельно изучаются десктопно/браузерные альтернативы типа XBAP, WPF, Silverlight. И т.п.

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

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

Знаешь, когда мы были молодыми, то была такая ситуация, что и учиться было не у кого, не было ни интернетов, ни даже msdn'ов. И мы учились сами у себя. Буквально вчерашние студенты. Атмосфера была создана такая, что тяга к знаниям была у всех в команде. Постоянные обсуждения кто чего нового узнал, вау, круто, а если так и т.п. Все, буквально все тогдашние молодые специалисты из нашей команды стали хорошими инженерами с глубокими знаниями тех инструментов, с которыми они работают. И сегодня, кроме, конечно, тех, кто ушел в управление, любому за пол часа можно объяснить что угодно, если можешь объяснять, а он хочет слушать. Попробуйте у себя создать такую атмосферу, чтобы если даже ваши студенты шли пить пиво, то обсуждали между собой только новые технологии. И процесс обучения так пойдёт, что его трудно будет остановить. Они ещё тебя будут учить

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

A>>Что подразумевается под словами "в моих задачах"?

AVK>Хм, по моему это вполне по русски. Подразумевается, что речь идет о тех задачах, с которыми сталкивался и сталкиваюсь именно я, и на глобальные обобщения на всю софтописательную индустрию и тенденции ее развития я не претендую. Что именно непонятно?

A>>Я правильно понял?

AVK>Странный вопрос. Не знаю я, как ты понял.

И вот как дальше обсуждать? Иду лесом...

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

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

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

AVK>>Не очень понятно, если честно. При чем тут вольности? Выглядит как какая то эмпирика, а не истинная причина.

КЛ>Вольности, это клепать фреймворки и dsl-и на каждый чих

А, ну да, где то так.

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

КЛ>при чем тут мп от немерле?

Не знаю. Это ты про прогресс спросил. Я просто ответил на заданный вопрос.

КЛ>при том, что они дают возможность отойти от стандартов.

Да нет, все гораздо печальнее — они подразумевают отсутствие зафиксированного стандарта вовсе. Разве что можно сформировать что то навроде СLOS. Но если есть возможность стандарт нарушать, то да, получаем то, о чем я писал.

AVK>>Ммм, а где в вышеприведенных технологиях интероп?

КЛ>ок, гарантированное отсутствие интеропа. этими тулами dsl не заканчиваются, правда?

Все равно мне непонятно, каким боком тут интероп.

AVK>>В случае C# есть partial types и partial methods. Визарды не предназначены для повторных вызовов, если такое требуется, то это уже п.1.

КЛ>какие у partial types есть инструменты для анализа окружения?

Никаких. Он не для этого нужен.

КЛ> В немерле для этого есть почти все.

Не в Немерле, а в его инструментарии, доступном в рамках IDE. Но это, согласись, совсем другой вопрос с совсем другим ответом.

КЛ>а тему все-таки надо было назвать "что меня не устраивает в МП в Nemerle для пром. разработки"

Слишкам многа букаф

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

КЛ> боюсь, что фича вроде итераторов, не то, о чем можно говорить в контексте денежных/временных затрат.

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

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

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

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

A>Если коротко — это отсутствие ECMA стандарта. Если есть желание обсудить — распишу более подробно и по пунктам.

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

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

AVK>На все эти вопросы мой ответ содержится в корневом сообщении.

Серьезно?

Процитируй, плиз, кусок своего сообщения который давал бы ответ хотя бы на этот вопрос:
A>>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.

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


AF>>То есть ты реально пробовал всё это делать сам лично, причем с помошью Немерле?
AVK>Большую часть да, в том числе и с помощью Немерле.

И не разу ни к кому не обратился с вопросом? Ну, ты просто гений! Я бы так не смог.

AF>>Вах, я потрясен твоим опытом.

AVK>Ничего потрясающего в нем нет, чтобы просто побаловаться много времени не нужно. Когда то, несколько лет назад, еще до того как Влад тут всем начал МП пиарить, мне эта тема была интересна. Потом я интерес потерял.

Казалось бы причем тут Немерле?

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

VD> Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.

Например в языках с развитой системой типов это делается обычной функцией. Зачем нужен макрос тут?

AVK>Дисклеймер:

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

Круто, что foreach можно разъять на детали. Круто -- pattern matching. Круто полностью от начала до конца понимать, что такое монады (не гони пацан, это уже из "Что меня не устраивает в хаскелле").

Короче, вся эта крутизна пока не подтверждена убедительной success story. А без success story как ты промотивируешь команду сесть и вложить неделю времени в академические одиссеи?

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

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

Например, многие мои знакомые англичане достаточно бегло говорят на английском языке и даже не спотыкаются на таких конструкциях как "will have been". Как ты думаешь, сложность использования времён в английском языке тоже надумана?


IT>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.

Понятное дело. Более того, если через полтора года что-то где в этом отлаженом механизме чем-то накроется -- нужно всего лишь найти того программиста, который это написал, кинуться ему в ноги, заплатить хороших денег -- и проблема решена. Куда проще чем попросить первого попавшегося и сунуть ему в зубы раздел MSDN по Custom Tools.



IT>можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать.

Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.

Знаешь, в одной конторе провели чемпионат по Солитёру и всех трёх финалистов назавтра выперли. Так вот Солитёр не единственный непроизводственный "скил".

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

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

A>>1. Нужен road map. Если он есть — можно ссылку?

Большое спасибо Но я думаю что на Nemerle.org это бы прочитало значительно больше людей.

A>>2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт.

Я не считаю что это Майкрософт делает со зла. Но Nemerle Team все равно придется дублировать все фичи МС. Спасибо что убедил меня в том что это не большая проблема для Nemerle Team.

VD>Кроме того нужно:

Вот это все нужно в road map

A>>3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если
VD>код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.

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

Представь момент когда Nemerle стал мейнстримом. И что тебе скажут менеджеры проектов, когда после закачки обновлений прогибается код, написанный до этого? И плюс еще на сайте висит гордая надпись. "Переходите на 2.0, потому что мы через месяц прекращаем поддержку 1.0?" В общем я ничего не имею против ломающих изменений в бета, CTP, RC. Но мажорные версии должны полностью поддерживать возможности минорных. Иначе просто никто не рискнет использовать Nemerle в промышленных проектах.

PS. АПИ — это API? Я правильно понял?
PPS. Писали мы как-то один проект на .Net 2.0 бета. Говорю товарищу — а не опасно? Он — зато будем впереди планеты всей. Пришло время релиза .Net 2.0. Качнули, поставили. Прога запустилась. Ура! А тут сразу как полетели эксепшины. И что делать будем? Перекомплили исходники. И все заработало.

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

IT>>Это не DSL. Это больше смахивает на FxCop.

AF>В рамках языка такая фича полезнее. Например, когда я работал на ABBYY, то познакомился с целым талмудом страниц на 100 — "как писать нельзя".

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

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

AF>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle". Выяснилось, что он не в состоянии вложить мозги в головы дураков и грамотно сделать проектирование вместо программиста. Действительно, фатальный недостаток системы МП

Популярность Лиспа, Dylan'а и Форта показывают что недостаток может и не фатальный, но очень существенный.

IT> Трудно видишь ли некоторым это понять. Согласен, трудно.

Ты хотел пример, ты сам нашёл пример -- и сам видишь, что существование единичного примера ничего не доказывает.


IT> А ленивость в Linq не трудно? Проблема ведь та же, но ни одного ключевого слова там нет. Одни сплошные функции. Так в конструкциях языка дело ли? Тоже самое и с макросами. Макросы — это форма, такая же как и классы, методы, языковые конструкции. Настоящая сложность не в них, а в концепциях, которые они реализуют. Если в твоих проектах используются библиотеки общих компонент, то сложность их использования и сложность использования макросов будет абсолютно одинаковой. Никакой разницы.

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

НЕКОТОРЫЕ библиотеки сложны. Сложность использования НЕКОТОРЫХ библиотек сравнима с макросами немерле.


IT>Не вижу логической связи между этими двумя утверждениями. Получается, что если макросы, то кругом одни тупые кодеры, а если MSDN, первый попавшийся у нас гений, способный одной левой разобраться с таким редкосным гауном как Custom Tools.

Студент с улицы самостоятельно разберётся с Custom Tools в течении 3 дней (в среднем), какие бы ни были там омерзительные названия методов и ключей реестра.

60% студентов с улицы не осилят макросы немерле без посторонней помощи. Какие бы там ни были красоты внутреннего $.


M>>Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.

IT>Директору может и всё равно, а начальнику IT департмента не всё равно. А если всё равно, то долго он начальником не будет.

Производственные проблемы уборщицы не должны тормозить работу фирмы. Если фирме нужны литры-километры в срок, то всё остальное должно следовать строго в фарватере.

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

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

Ирония — да, оскорбление — нет. В чем демагогия то?

VD>>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.
IB>Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

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

Автор: AndrewVK
Дата: 26.12.08

.

VD>>Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль.
IB>А ты не хами и жалеть не придется.

А можно хамскую цитату?

VD>>Ведь только в честных спорах рождается истина.
IB>Возможно. Но только честно спорить ты не умеешь.

И как это понимать?

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

КЛ>можно разобью на 2?

КЛ>1. новые фичи осваиваются неохотно
КЛ>2. для пром. девелопмента лучше следовать стандартам, вольности неоправданы

КЛ>соглашусь частично только со 2м, тк если отталкиваться от п.1, то прогресс нафиг не нужен. макросы действительно хорошая штука, чтобы превратить код в кошмар. но я видел, как это делали используя обычные языки через жопу.

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

Дело в том что комманды разработчиков меняются со временем и использование хлама вроде Неммерле существенно завышает входную планку.

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

AF>Ясно, значит, какой реальный опыт.

Перечитай дисклеймер.

AF>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle".

Перечитай название темы.

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

M>Студент с улицы самостоятельно разберётся с Custom Tools в течении 3 дней (в среднем), какие бы ни были там омерзительные названия методов и ключей реестра.

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

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

M>Нет, не так. Я сказал что макросы без посторонней помощи не осилить, а вы сказали, что красоты внутреннего $ это и есть макросы, и их можно за пару часов осилить.

Написание макросов — да, их использование — нет.

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

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

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

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

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

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

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

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

Да, это хороший подход. Работает исключительно в коммандах из топ-разработчиков.

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

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

Это тебе кажется, что не сложнее. А реально — много сложнее. Примерно на порядок.

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

Во второй раз я решил проблему радикально — отказался от макросов и изменил фреймворк так что мои фичи использовались безо всякого геморроя.

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

На этом срубается примерно 90% разработчиков, а остальные 10% рассматривать как целевую аудиторию для новых технологий как минимум несерьезно.

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

Сложности нет. Сложность в людях.

IT>А про правку сгенерированного кода и железной линейкой по пальцам тут уже сказали. И я с этим полностью согласен, т.к. встречался с таким баранизмом на практике.

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

IT>По первому пункту я уже всё сказал. Это не сложнее, чем использование классов, методов и атрибутов. Сложность не в макросах, сложность в концепциях, которые они реализуют. Но это в равной степени относится и к тем же классам, методам и атрибутам.

Это справедливо только для разработчиков топ-уровня.

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

L>>А как быть в том случае, если использовали макросы немерле? Исходника-то как такового нет.

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

Могут или генерируют?
Есть ли средства, позволяющие отследить, каким именно макросом был сгенерирована та или иная строчка?
Какой код генерируют? Если даже элементарные конструкции for/foreach/etc. — суть макросы, то будет ли этот конечный код читаемым?

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

I>С новым инструментом надо решать вопрос — почему им смогут пользоваться дебилы.

"Дебилы" не смогут писать макросы, но они могут их использовать. В чем сложность использования макроса $ или foreach?
Не знаешь как писать? Пиши как на C# — hi_octane здесь

Автор: hi_octane
Дата: 27.12.08

доступно все описал.

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


I>Т.е. VladD2 понаписывает макросов на все случаи жизни ?

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

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

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

Y>>Макросов на чем? Отказались по какой причине?

I>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.

— Да дерьмо этот ваш Корузо.
— По чему это?
— Петька вчера напел.

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

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

AVK>А чего признавать то? Я обратного и не утверждал? Ты с кем споришь?

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

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

IT>В том-то и дело, что это не проблема макросов.

Я считаю, что все таки макросов.

IT>Как раз макросами наоборот можно выразить это проще и доступнее.

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

IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.

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

IT>Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции.

Охотно верю.

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

Да. Именно! Я как раз это и говорю — макрос мощнее и гибче обычного фреймворка.

IT>Что-то ты меня совсем запутал.

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

IT> Использовать просто, но простота использования порождает сложность. Какую сложность?

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

IT>Любой общий компонент требуется поддерживать постоянно.

Непонятно, опять же, с кем ты споришь. Конечно надо. Но генератор поддерживать тяжелее, чем код, который он генерит.

AVK>>Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?

IT>Я подумал ты о Custom Tools.

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

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

VD>То есть, VladD2 не дебил, а это значит что он может написать мокросы которые нужны ему и другим.
VD>Но это не значит, что только VladD2 не дебил. Таких людей много, а значит много кто сможет писать макры.

Теоритически это так.

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

Откуда взялись твои оценки сложности ? Здесь то и зарыта собака.

Разумеется, если разработчик в состоянии осилить такую глубину и большую, то ему будет легче. Речь то не об этом.

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

M>>Какая разница?

AVK>Есть разница.

Есть?


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

AVK>Главное, чтобы он запускался тогда, когда хочу я.

Легко -- правой кнопочкой и Run Custom Tool.

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

Уже конкретный оффтопик попёр. Если продублируешь вопрос в той теме на которую я давал линку — отвечу.