Здравствуйте, VoidEx, Вы писали:
VE>>>Не понял. Тому, кому надоел каменный топор как орудие труда, нужно, чтобы другие какие-то программисты (тысячи их) переходили на следующий уровень мышления? Ну допустим. А зачем им это нужно? И много ли таких?
VD>>На подобный вопрос отвечали уже сто раз. Ответить сто первый? Или сам ответ поищешь? VE>Отвечай.
Это последний раз. Надоело.
Можно оставить орды кодманки которые будут пользоваться написанными нормальными программистами библиотеками и макросами. Это позволит решать задачи привычным вам способом шапкозакидательства...
... Но лучше формировать команду из людей способных развиваться. Тогда их можно будет легко, постепенно втянуть в новую среду. Опять же не все будут создавать макры. Но по крайней мере не придется объяснять что за непонятный код написан вот там, указывая на применение метода Map или Fold.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Проблема только в том, что пока он знает только Блаб и думает на Блабе, для него нет стимулов изучить что-то еще. Но он может просто поверить тем кто ему рассказал историю про Блаб или просто изучить новое из любопытства. Вот в рассчете на таких людей я и виду здесь дисскуссии.
Вот. А оппозиция утверждает, что таких людей недостаточно, чтобы набрать массу, вот и всё. Или я их мысль тоже упустил. Хотя шансов больше, чем у ЛИСПа, на порядок.
VD>Блабы могут называть этих людей (и меня, естествнно) фанатами. Но это не так. Фанаты — это те кто тупо лабает на Блабе и с пеной у рта доказывает, что их Блаб — это верх совершенства.
А разве Немерле не верх совершенства по совокупности факторов?
Здравствуйте, VladD2, Вы писали:
VD>Можно оставить орды кодманки которые будут пользоваться написанными нормальными программистами библиотеками и макросами. Это позволит решать задачи привычным вам способом шапкозакидательства...
VD>... Но лучше формировать команду из людей способных развиваться. Тогда их можно будет легко, постепенно втянуть в новую среду. Опять же не все будут создавать макры. Но по крайней мере не придется объяснять что за непонятный код написан вот там, указывая на применение метода Map или Fold.
Здравствуйте, VoidEx, Вы писали:
VD>>Блабы могут называть этих людей (и меня, естествнно) фанатами. Но это не так. Фанаты — это те кто тупо лабает на Блабе и с пеной у рта доказывает, что их Блаб — это верх совершенства. VE>А разве Немерле не верх совершенства по совокупности факторов?
Он по совокупности фактов отлично подходит на замену Явы и/или C#/VB.
Совершенством он не может быть по двум причинам.
1. В языках программирования многое определяется выбором из имеющихся вариантов. Скажем выбор между статической типизацией и динамической. Или выбор между ленивостью по умолчанию и не ленивостью. Вот хаскелисты, например, считают, что только ленивые языки могут являться совершенством.
2. В Немерле и вокруг него слишком много проблем. Решить их можно только имея много времени или много бабок. Вот F#-пу повезло. На него дали бабки. Но популярным этот язык вряд ли станет, так как предпочтения его авторов очень далеки от тех, что глубоко засели в головах мэйнстрим-программистов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VD>>... Но лучше формировать команду из людей способных развиваться. Тогда их можно будет легко, постепенно втянуть в новую среду. Опять же не все будут создавать макры. Но по крайней мере не придется объяснять что за непонятный код написан вот там, указывая на применение метода Map или Fold.
VE>Чем лучше?
Мне уже надоело тебе отвечать.
Лучше поупражняйся сам и опиши чем лучше делать наоборот. Все что ты выкинишь из своих доказательств и будет ответом на твои слова.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>IT написал первую макру только спустя год после знакомства с Немерле. По началу даже то, что стоило бы макрой сделать, делал вручную.
Вообще-то два года
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Лучше поупражняйся сам и опиши чем лучше делать наоборот. Все что ты выкинишь из своих доказательств и будет ответом на твои слова.
Нет нет. "Наоборот" — это уже будет не доказательство. За что люблю детские вопросы типа "зачем", "почему", потому что они раскрывают, что тот, кто говорит, сам ничего не понимает, если до сути докопаться.
Вот ты уверен, что лучше. Абсолютно уверен. Но не знаешь, почему. Для такого казалось бы очевидного утверждения нужно доказать, что хорошие спецы с новой технологией в целом обойдутся дешевле тысячи блабов. А в жизни куча примеров и первого, и второго.
Здравствуйте, VladD2, Вы писали:
IT>>Бывает, бывает. Есть генерилки, которые вообще не заточены на автоматическую генерацию вроде Custom Tools. С ними нужно повозиться, указать все необходимые параметры и потом раз и сгенерировать. После этого сгенерированный код используется как обычный рукописный. Народ этим широко пользуется.
VD>Есть, пользуются... не спорю. Только это уродство.
Что-то из тебя какой-то неадекват попёр.
VD>>>Изменение модели. IT>>Какой модели? VD>Любая генерация кода подразумевает, что есть модель описывающая базовые данные по которой генерируются частности.
Генератор — это прежде всего инструмент. В качестве инструмента, я могу, например, взять редактор кода и одним глазом подглядывая в SQL на структуру таблицы перенабить эту таблицу себе в код. Дале я буду поддерживать полученный класс в ручную. Как я понимаю — это правильный путь. Но если я вместо ручной начальной набивки напущу на эту таблицу генератор, то это уже уродство. Так что ли? Но ведь ты не найдёшь ни одного различия между этими классами. Так какая разница?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
L>>>Кстати, а как предполагается локализовывать подобного рода строки?
IT>>Зачем?
L>Супер! 5 баллов. Действительно совершено незачем.
Мне не надо Думаю, было бы довольно тупо не использовать сплайс-строки из-за локализации, если она мне абсолютно не нужна. Или ты с этим не согласен?
Если нам не помогут, то мы тоже никого не пощадим.
Визарды, custom tools и даже не упомянутые паттерны проектирования и пост-билд утилиты вроде FxCop — расцвели только из-за полного отсутствия каких-бы то ни было средств МП в C#/VB.NET. Не уверен только насчёт DSL.
После нескольких месяцев программирования на Nemerle изменяются подходы, так что сравнивать кодогенерацию с МП как в Nemerle можно имея лишь приличный опыт именно с МП Nemerle.
По пунктам:
1) Разработчики использующие МП должны стараться писать так, что-бы программисты использующие их библиотеки про МП вообще ничего не знали. Тогда даже ленивому программисту будет легко их код использовать. Пример из нашего проекта:
Выглядит как вызов статического метода. Программист который это использует может никогда не узнать что статический метод не вызывается вовсе, а вместо этого создаётся код, который через service locator'ы собирает все доступные из метода сервисы логгирования и каждому вызывает уже экземплярный метод Write.
2) Если насущная необходимость ограничить по максимуму — то можно создать класс или несколько с методами, которые разрешено использовать конечному разработчику. То что все вызовы во внешнюю систему делаются только через методы этого класса отследить средствами МП легко. Более того можно свой синтаксис довесить, который только разрешённые методы будет использовать. Можно даже нацепить аттрибут уровня класса вроде [Skill(Level=Junior)] и такой аттрибут может проверить что в коде не используется методов относящихся к более высокому уровню сложности.
Одна лишь разработка качественного DSL парсера может встать в задачку сложнее чем разработка целой кучи макросов, классов и т.п. А может и нет. Зависит от DSL.
3) С внутренним устройством например студийных визардов не знаком. Работал только с кодогенераторами вроде CodeSmith, LLBLGen, MyGeneration — так им какие шаблоны целевого кода скормишь, такие файлы и сгенерируют. Многие шаблоны генерации были бы просто не нужны, имей компиляторы .NET средства МП как в Nemerle.
4) Как и в 2) — всё зависит от DSL.
5) Задача интересная, но очень специфическая и все ограничения из столь краткого описания не ясны. Интересно, если бы прикладной код был написан на Nemerle (или на языке с МП как в Nemerle) и теми же макросами в методы были вставлены вызовы пустых методов из внешней сборки, а в момент деплоймента с сервера забиралась бы уже реальная/обновлённая сборка, выполняющая инструментирование, это не решило бы проблему?
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, VladD2, Вы писали:
VD>>Писать мета-код на С++ очень сложно. Понять его тоже весьма сложно. От того писать его могут единицы. Факт? Факт!
Y>Твоими бы да устами... А то ведь пишут, читают Александреску и пишут...
Ну не лукавь, мало пишут. Дай бог процентов 5 разбирается, а из них только процентов 20 пишут.
Здравствуйте, VladD2, Вы писали:
VD>Кроме того типы переменных сплайс-строки контролируются во время компиляции. А в стринг-формате спокойно можно ошибиться. Например, задать не те количество параметров.
Т.е. ради несколько более оптимального решения небольшой задачи (вывода форматированной строки) в язык вводится принципиально новая конструкция.
VD>В прочем, одно преимущество у стрин-формата есть — они позволяет менять строку формата в рантайме. Сплайс-строка контролируется во время компиляции.
При этом новый способ решения задачи более узкий, чем старый, часть задач, которые можно было решать с помощью string.Format, с помощью сплайс-строк решить не удастся. Соответственно string.Format все равно придется учить и о нем помнить.
В мэйнстримовском языке не должно быть 25 способ решения задачи, позволяющих каждый случай решить оптимальным образом. Мэйнстримовский язык должен содержать минимальное количество способов решения задач, позволяющих решить 99,9% задач качественным (но не обязательно оптимальным) способом. Новые способы решения задач, несколько более оптимальные, но имеющие какие-то недостатки и/или неспособные полностью вытеснить старые способы решения тех же задач должны добавляться в мэйнстримовский язык с большой осторожностью. К сожалению похоже даже разработчики шарпа перестали это понимать.
Здравствуйте, VladD2, Вы писали:
VD>В этом споре замечательно продемонстрировано как самые прогрессивные идеи могут разбиваться о косность и упрямство недолеких людей заучивших однажды что-то и считающих дальше что это true way.
Можно вопрос? В своих приложениях string.Format("Некая константа: {0}", obj) я пишу по большим праздникам, зато очень часто пишу TraceHlp2.AddMessage("Некая константа: {0}", obj). Можно объяснить как сплайс-строка позволит мне записать TraceHlp2.AddMessage лучшим образом?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Все новое в программировании вводит новые абстракции, а все что существует — конкретная реализация абстракций. Если вы пытаетесь объяснить новые абстракции через существующие реализации, то ничего у вас не выйдет. Для примера попробуйте объяснить замыкания тому кто на среднем уровне знает C\C++ и только его.
IT>Легко, если человек понимает что такое указатель на функцию.
И что это ему даст на таком примере:
int foo(int a, int b)
{
int bar(int c)
{
return a*c + b;
}
return bar(10);
}
Здравствуйте, Ikemefula, Вы писали:
I>>>Потому что это будет обман будет.
R>>В чем обман? Ну не знаком человек с шарпом, зато знает си, ну показал ты ему что
R>>
string.Format("Output: {0}", a) = sprintf("Output: %s", a)
I>Это и есть обман. Слишком много деталей упускается из рассмотрения.
Так и будешь ходить вокруг да около или покажешь, в чем обман?
Здравствуйте, IT, Вы писали:
IT>>>Зачем?
L>>Супер! 5 баллов. Действительно совершено незачем.
IT>Мне не надо Думаю, было бы довольно тупо не использовать сплайс-строки из-за локализации, если она мне абсолютно не нужна. Или ты с этим не согласен?
А ты поднимись повыше и посмотри вопрос. Если лень, то вопрос был о том, как сделать, а не делать или нет.
Здравствуйте, VladD2, Вы писали:
VD>>>Никак. Они для этого не предназначены.
L>>То есть для одного типа форматирования используем $-нотацию, а когда нужна локализация — откатываемся до строк в стиле "{0}"?
VD>А ты вернись на сообщение выше и прочти то, что успешно удалил перед тем как задать свой вопрос. Там все сказано.
Про "макры которые не просто локализуют строки"?
Тогда переформулирую вопрос. Если нам понадобилось локализовать строку в $ нотации, нужно ли ее переделывать в "локализуемые" строки?
А локализуемые строки будут поддерживать $-нотацию? А если надо заменить часть этой строки, предусмотрен ли механизм, аналогичный "{0}"?
Здравствуйте, VladD2, Вы писали:
VD>Я о большинстве. VD>Массы делают свой выбор бездумно. Находясь в плохих условиях они с огромной веорятностью выбирают зло. Пример — Германия в двадцатых годах прошлого века.
Что-то тебя совсем не в ту сторону понесло.
Если нам не помогут, то мы тоже никого не пощадим.
Думаю, было бы довольно тупо не использовать сплайс-строки из-за локализации, если она мне абсолютно не нужна. Или ты с этим не согласен?
Мы уже победили, просто это еще не так заметно...
