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

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

Как ты мерял ? Сколько лет длился суппорт-майнтенанс и сколько команд сменилось ?

Хочешь угадаю ? Ты сам и суппортал ну может силами своей тимы. Опаньки !!!

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

Где взять еще одного IT ?

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

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

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

IT>Да и высокость порога тоже пойдёт на пользу. Мешьше всяких "индусов" будут лезть в это дело.

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

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

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

Лучше прикинь другое. Для сапорта и мейнтененса никто не нужен, потому что сапорт и мейнтененс настолько тривиальны, что занимают от нуля до половины процента времени. У меня вообще хобби такое создавать решения не требующие саппорта. А если я уйду, то минимум год с моим кодом будет всё в порядке. В нём легко разберуться и легко начнут сапортить, пока не понавносят туда изменений, которые напрочь уничтожат всю вложенную туда простоту мейнтейнабилити и саппортобилити. И пофиг будут там МП и DSL или их там не будет.

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

T>Вроде как объем рынка определятся объемом спроса, а у тебя, похоже, наоборот. Или ты хочешь бизнес запугать настолько, что бы они посворачивали проекты ? Тут спору нет, индусов станет радикально меньше. И по моему это единственный вариант когда "Мешьше всяких "индусов" будут лезть в это дело."

Бизнесу вообще-то пофиг и пороги вхождения и DSL и МП все вместе взятые.

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

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

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

IT>Что касается обоснований, то я могу привести простой пример с конкретными технологиями, использующимися для метапрограммирования. Речь идёт о run-time генерации кода. В .NET есть такая очень низкоуровневая штука — System.Reflection.Emit. Решения на SRE получаются сложными, малопонятными и хрупкими. Так вот за 10 лет существования библиотки BLToolkit практически никто кроме меня не трогал код, где используется SRE. С 3-м фреймворком мы получили другую технологию, которая может использоваться для тех же целей, что и SRE — System.Linq.Expressions. Это гораздо более высокоуровневая вещь. Если SRE оперирует примитивами соответствующими ассемблерному коду, то SLE использует уже что-то вроде языковых конструкций. В результате народ стал править мой код с SLE и писать свой налево и направо. SLE позволяет преодолеть некий барьер сложности, метапрограммировать становиться на порядок проще и народ потянулся.

Я немного ниже поясню, почему именно так.

IT>Другой пример — T4 шаблоны. В них используется тот же самый C#, т.е. язык, к которому мы все привыкли и хорошо знаем. Тем не менее, написание шаблонов задачка не для слабонервных. А причина в том, что для того C#, который в T4 практически нет никакой поддержки со стороны студии, нет рефакторингов, нет интелисенса, навигации, подсветки и даже отладки. Т.е. написание кода сравнимо с написанием кода в нотепаде. Язык тот же, а вот окружение отсутствует и всё, результат очень печален.

Причина не в этом. Писать код который пишет другой код на порядок сложнее. Хоть с инструментами, хоть без. Сначала нужно решить задачу А, потом написать код, который напишет код решения задачи А. То есть, решать нужно 2 задачи. Но это не все. Результат(код) ты увидишь только после генерации. При этом в обычном программировании ты этот результат(код) видишь практически все время перед глазами. Вот теперь становится ясно, почему квазицитирование достаточно легко поднимается людьми, хотя бы и в кастрированом виде, SLE, — результат(код) видет точно так же непосредтсвенно по мере написания его. Точно так же понятно, почему Т4 хорошо идет — результат не надо додумывать при правильном подходе. И это так же объясняет, почему дсл и макры идут туго — результат лежит где хрен знает где, а потому без тула вообще никуда, или же результат недоступен вовсе и нужно обладать хорошей прокачкой скилов что бы этот результат представить. Собтсвенно эти же недостатки есть и у SRE — результат очень сложно представить.

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

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

T>>Хороший аргумент. Только стл это обобщенное программирование, метапрограммирование, а не ООП. Ну ты понял
WH>В каком месте STL мета-программирование?

Да почти в любом.

WH>Ну, раз тебе не нравится STL, можно взять любую другую большую ОО библиотеку.
WH>Покажи мне новичка, который сможет создать WPF.

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

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

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

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

T>>Вроде как объем рынка определятся объемом спроса, а у тебя, похоже, наоборот. Или ты хочешь бизнес запугать настолько, что бы они посворачивали проекты ? Тут спору нет, индусов станет радикально меньше. И по моему это единственный вариант когда "Мешьше всяких "индусов" будут лезть в это дело."

IT>Бизнесу вообще-то пофиг и пороги вхождения и DSL и МП все вместе взятые.

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

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

WH>1)Порог вхождения в ООП намного больше. Я серьёзно. Ибо сделать хороший ОО дизайн намного сложнее, чем хороший ДСЛ. Более того хороший ДСЛ возможен для любой предметной области которую вообще возможно формализовать. Для ООП, ФП, ЛП,... и любого другого программирования, которое навязывает вычислительную модель это не верно.

Где можно ознакомиться с методикой сравнения сложности ?

M>>Интересно, что про это тут говорят абсолютно все, кроме, скажем, вульфхаунда, который постоянно верещит про «нада пользавацца правильными инструментами!!одинодин»

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

Как-то неохота

IT>>>В макросах List нет доступа к информации о типах. В результате применение таких макросов сильно ограничено и ценность их примерно на уровне текстуальных подстановок макросов C.
M>>Это не ответ. Откуда возьмется информация о типах в DSL тоже никому неизвестно. Инструменты-то для разработки отсутсвуют

IT>Не понял этой реплики. Я говорю, что макросы Lisp не имеют информации о типах. А любой более менее полезный макрос для того же C# будет нуждаться в такой информации. Команда Немерле это прекрасно понимает и то решение, над которым они работают, будет это всё учитывать. Существующие макросы Немерла и сегодня предоставляют информацию о типах, но всё это сделано через такую задницу, что подобное решение нельзя назвать даже приемлемым.

С тобой не согласится Вульфхаунд

Автор: WolfHound
Дата: 16.03.13

А в целом я к тому, что не факт, что будет написан очередной Лисп на тех же макросах Немерле, без информации о типах. Да даже с информацией о типах, следующее остается верным:

все зависит от качества ДСЛ-я и качества его реализации. Но тогда мы приходим к тому, что код на ДСЛ и обычный код имеют сходные свойства и вытекающие из него проблемы....

... Там еще сам язык играет большую роль. Лисп есть лисп. Его не каждый читать может. Но это отдельная история.

Это как раз то, о чем неапологеты DSLей говорим уже который год подряд

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

WH>>В каком месте STL мета-программирование?
T>Да почти в любом.
Похоже под МП ты понимаешь что-то своё.

T>В стл все алгоритмы и структуры данных тривиальные, их изучают максимум на втором-третьем курсе. Все сложность там в АПИ и композиции. А вот ВПФ это вещь действительно очень сложная, рядом с стл и не лежала.
Ну, так покажи мне студента который WPF сделает.
Ведь ООП это так просто...
Да ты даже не студента искать задолбаешься.

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

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

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

Почему ты напираешь на отсутствие типов в макросах (хотя они есть) при этом считаешь, что динамически типизированные языки это нормально?

Короче у тебя есть только куча двойных стандартов и передергиваний.

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

I>Чудеса то какие. Это самое ООП которое такое сложное проникло практически везде, и настолько просто что с него начинают обучение студентов, дают азы практически на первой-второй лекции. А вот ваша вся нетленка пока еще никуда не проникла, ну разве что в журнал и три проекта.
И при этом сделать нормальный ОО дизайн почти никто не может...
Наверное, по тому что ООП это просто.

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

В каком месте управление инвертируется?
https://github.com/rampelstinskin/ParserGenerator/blob/master/N2/N2.Grammar/GrammarParser2.n2
Ты вообще понимаешь, о чем говоришь?

I>P.S. Картина маслом — первый семестр, первый курс, первое занятие по программированию : "...а сейчас мы построим ДСЛ..."
На первом нужно научится готовыми языкам пользоваться. На втором курсе уже можно и свои делать.

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

WH>>1)Порог вхождения в ООП намного больше. Я серьёзно. Ибо сделать хороший ОО дизайн намного сложнее, чем хороший ДСЛ. Более того хороший ДСЛ возможен для любой предметной области которую вообще возможно формализовать. Для ООП, ФП, ЛП,... и любого другого программирования, которое навязывает вычислительную модель это не верно.

T>Где можно ознакомиться с методикой сравнения сложности ?

Она вся в цитате, на которую ты отвечаешь.

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

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

T>Причина не в этом. Писать код который пишет другой код на порядок сложнее. Хоть с инструментами, хоть без. Сначала нужно решить задачу А, потом написать код, который напишет код решения задачи А. То есть, решать нужно 2 задачи. Но это не все. Результат(код) ты увидишь только после генерации. При этом в обычном программировании ты этот результат(код) видишь практически все время перед глазами. Вот теперь становится ясно, почему квазицитирование достаточно легко поднимается людьми, хотя бы и в кастрированом виде, SLE, — результат(код) видет точно так же непосредтсвенно по мере написания его. Точно так же понятно, почему Т4 хорошо идет — результат не надо додумывать при правильном подходе. И это так же объясняет, почему дсл и макры идут туго — результат лежит где хрен знает где, а потому без тула вообще никуда, или же результат недоступен вовсе и нужно обладать хорошей прокачкой скилов что бы этот результат представить. Собтсвенно эти же недостатки есть и у SRE — результат очень сложно представить.
И ты ничего не угадал. Ибо не видел, как IT с SRE работает.
Как видишь практически квазицитаты MSIL'а.

        public void Test()
        {
            EmitHelper emit = new AssemblyBuilderHelper("HelloWorld.dll")
                .DefineType  ("Hello", typeof(object), typeof(IHello))
                .DefineMethod(typeof(IHello).GetMethod("SayHello"))
                .Emitter;

            emit
                // string.Format("Hello, {0}!", toWhom)
                //
                .ldstr   ("Hello, {0}!")
                .ldarg_1
                .call    (typeof(string), "Format", typeof(string), typeof(object))

                // Console.WriteLine("Hello, World!");
                //
                .call    (typeof(Console), "WriteLine", typeof(string))
                .ret()
                ;

            Type type = emit.Method.Type.Create();

            IHello hello = (IHello)TypeAccessor.CreateInstance(type);

            hello.SayHello("World");
        }
    }

Вот только очень уж MSIL низкоуровневый. Работать с ним неудобно.

M>>Это как раз то, о чем неапологеты DSLей говорим уже который год подряд
WH>Ох. Вот только всё это относится и к обычным языкам с обычными библиотеками.
WH>Но ты почему-то это всегда игнорируешь?
WH>Почему?

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

WH>Почему ты напираешь на отсутствие типов в макросах (хотя они есть)при этом считаешь, что динамически типизированные языки это нормально?

Угу. Ага. Я напираю на отсутсвие типов в макросах, ога. Ты бы это, перечитал, кто на что напирает.

WH>Короче у тебя есть только куча двойных стандартов и передергиваний.

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

Здравствуйте, WolfHound, Вы писали:
WH>Другими словами МП проще всего остального просто по тому, что всё остальное навязывает модель вычислений, а МП нет. Из-за этого при решении задачи другими средствами тебе приходится не только решать задачу, но еще и бороться с инструментом.
Разве само МП не является "моделью вычислений"(с которой надо будет бороться)?

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

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

M>Угу. Ага. Я напираю на отсутсвие типов в макросах, ога. Ты бы это, перечитал, кто на что напирает.
После того как ты научишься читать то что ты сам пишешь.

Здравствуйте, C.A.B, Вы писали:

WH>>Другими словами МП проще всего остального просто по тому, что всё остальное навязывает модель вычислений, а МП нет. Из-за этого при решении задачи другими средствами тебе приходится не только решать задачу, но еще и бороться с инструментом.
CAB>Разве само МП не является "моделью вычислений"(с которой надо будет бороться)?
Нет.

WH>>>Другими словами МП проще всего остального просто по тому, что всё остальное навязывает модель вычислений, а МП нет. Из-за этого при решении задачи другими средствами тебе приходится не только решать задачу, но еще и бороться с инструментом.
CAB>>Разве само МП не является "моделью вычислений"(с которой надо будет бороться)?
WH>Нет.
Почему?

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

I>>Чудеса то какие. Это самое ООП которое такое сложное проникло практически везде, и настолько просто что с него начинают обучение студентов, дают азы практически на первой-второй лекции. А вот ваша вся нетленка пока еще никуда не проникла, ну разве что в журнал и три проекта.
WH>И при этом сделать нормальный ОО дизайн почти никто не может...
WH>Наверное, по тому что ООП это просто.

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

WH>В каком месте управление инвертируется?
WH>https://github.com/rampelstinskin/ParserGenerator/blob/master/N2/N2.Grammar/GrammarParser2.n2
WH>Ты вообще понимаешь, о чем говоришь?

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

I>>P.S. Картина маслом — первый семестр, первый курс, первое занятие по программированию : "...а сейчас мы построим ДСЛ..."
WH>На первом нужно научится готовыми языкам пользоваться. На втором курсе уже можно и свои делать.

Ну так возьми в команду студента 2-3го курса и покажи как все круто. У меня в команде такие были, ООП им ничем не мешало.