Здравствуйте, hi_octane, Вы писали:
_>Тут просто нехватка понятий. Обычно под ДСЛ понимают именно языковые конструкции, ключевые слова там новые и т.п.
Под ДСЛ, прежде всего, понимают его семантику.
Синтаксис штука приятная, но второстепенная.
_>В этом случае у нас от ДСЛ не так и много было — readlock, writelock, ещё что-то такое-же простое. А получилось что язык вообще стал отступать, под давлением всяких "неявных" реализаций. Это уже даже не DSL а Domain Specific Runtime что-ли.
Это вы просто начали менять семантику немерла так чтобы он начал подходить под ваши задачи.
Те это и есть настоящий ДСЛ.
Его конечно можно засыпать специализированным синтаксисом, но в вашем случае даст это не много.
Ибо синтаксис немерла вполне подходит к тому, что вы делаете.
Но это не всегда правда. Ибо, например, в случае с парсером синтаксис немерле не подходит и тут специализированный синтаксис уже рулит.
_>И чем дальше тем сильнее мы уходили от декларативного программирования, всё больше полагаясь на магию автогенерации, завязанную на совершенно нетрадиционные вещи — имена классов и namespace'ов, объявленные но не реализованные интерфейсы, тот же тип поля SyncRoot, значение константы Offset (там была магия с DateTime на разных системах).
Наоборот. Вы шли к декларативному программированию.
Ибо декларации задают логику.
_>Что было очень неожиданно, так как первое правило которое мы сами себе придумали — это что код не должен браться из ниоткуда. Типа там нам самим будет непонятно, если не будет аттрибута [AutoDispose] хотя-бы на классе, а лучше на мемберах. А оказалось наоборот, что аттрибуты тоже код, и если избавляться по-возможности и от них — то жить проще.
Именно.
Главное тут понять что происходит это за счет того что вы поменяли семантику немерла так что на него стало проще натягивать вашу предметную область.
Но все эти AutoDispose, ChangedBy итп это всё ещё фичи общего назначения.
Это хоть и существенные, но косметические фичи.
_>Да, и ещё интересный момент — связность кода за счёт иерархий наследования реализации стала сильно падать. Сейчас мне даже кажется что virtual и override это неправильный костыль, и можно выкатить язык на одних только интерфейсах и с макропрограммированием, и будет epic win. Но пока не потренируюсь на прототипе, выносить эту идею в philosophy/flame.comp не готов
Это опять рассуждения на уровне языка общего назначения.
Я не в курсе того что конкретно у вас делается но уверен что всю вашу логику можно переписать без всех этих readlock, writelock, AutoDispose итп.
Просто по тому, что это детали функционирования платформы и напрямую к бизнеслогике не относятся.
А значит если сделать чистый язык, который работает напрямую в терминах конкретной предметной области то можно все это сгенерировать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, fddima, Вы писали:
F> Да ну? Древние это как? Есть реалии. C++11 — по факту, никем ещё не поддерживается, ближе всех gcc и clang, как я понимаю. F> А вот написание — return Singleton<BuildInfo, LeakySingletonTraits<BuildInfo> >::get(); — суровая правда жизни.
А можно узнать, с чем мэтр C++ DarkEld3r — не согласен?
С тем, что >пробел> — это реальная правда жизни, и никуда от неё не дется в C++11?
С тем, что я так устарел, а у нас каждый компилятор поддерживает C++11 в полном объеме?
С чем конкретно? Расскажи уж. Просвяти всех. Я лично буду тока рад.
Здравствуйте, VladD2, Вы писали:
VD>Общая идея — макрос позволят добиться почти идеальной абстракции. Эта абстракция может выражать суть предметной области настолько точно насколько это только возможно, и при этом макрос позволяет сделать реализацию настолько конкретной и качественной насколько это нужно.
Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.
Здравствуйте, VladD2, Вы писали:
VD>Факт что лучшее. Но, конечно же не единственное.
Неужели у тебя и доказательство имеется этого "факта"?
Вопрос, конечно, риторический.
Re[12]: Недостатки Nemerle
От:
Аноним
Дата:
11.07.12 09:39
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VoidEx, Вы писали:
VE>>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.
VD>Факт что лучшее. Но, конечно же не единственное.
Не лучшее, метасвязки лучше, но я даже не слышал об их использовании за пределами теоритических работ. Макросы это упрощение метасвязок с отношением примерно таким же как макросы к функциям.
Здравствуйте, Аноним, Вы писали:
А>Не лучшее, метасвязки лучше, но я даже не слышал об их использовании за пределами теоритических работ. Макросы это упрощение метасвязок с отношением примерно таким же как макросы к функциям.
Здравствуйте, VoidEx, Вы писали:
VE>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее.
А что лучше макросов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VE>>Важно только понимать, что макросы — не единственное средство, и уж тем более не факт, что лучшее. WH>А что лучше макросов?
Аноним вот написал про какие-то метасвязки, интересно бы узнать, что это такое.
Я позволю себе сказать утрированно для краткости.
Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.
VE>Аноним вот написал про какие-то метасвязки, интересно бы узнать, что это такое. VE>Я позволю себе сказать утрированно для краткости. VE>Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.
+1. Метасвязки от Анонима — это, несомненно, будущее программирования.
Если бы он мог объяснить, то сказал примерно следующее:
компонентное программирование имеет очевидный недостаток — для скрепления компонентов нужно много рукописного, специфического кода.
если представить, что компоненты будут свойствами "автосвязи" и "авторасширения" с компонентами, которые находятся рядом, то мы можем
выйти на уровень роботов из жидкого металла, компоненты которых "знают" свое место и "знают" как реагировать со связными компонентами.
К стати, этим будущим мы ежедневно пользуемся. Понятия естественного языка — такие компоненты.
Здравствуйте, VoidEx, Вы писали:
VE>Лучше макросов всё, что может быть использовано вместо них. Так что вопрос стоило бы поставить иначе "что хуже макросов", потому что хуже ничего нет, но иногда без них не обойтись. И вот это "иногда" надо изолировать и делать наименее необходимым за счёт улучшения основного языка.
Макросы это и есть улучшение основного языка.
Причем вплоть до уровня, когда на языке можно решать задачу в терминах задачи.
Причем если у нас все есть макрос то "основной язык" у нас под ногами путаться перестает.
Что позволяет добиться максимальной выразительности, надежности и производительности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _Claus_, Вы писали:
_C_>+1. Метасвязки от Анонима — это, несомненно, будущее программирования.
Ты лучше ссылки на статьи дай.
Ибо своими словами ты еще ни кому, ни чего, ни разу не объяснил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, fddima, Вы писали:
F>> Да ну? Древние это как? Есть реалии. C++11 — по факту, никем ещё не поддерживается, ближе всех gcc и clang, как я понимаю. F>> А вот написание — return Singleton<BuildInfo, LeakySingletonTraits<BuildInfo> >::get(); — суровая правда жизни. F> А можно узнать, с чем мэтр C++ DarkEld3r — не согласен? F> С тем, что >пробел> — это реальная правда жизни, и никуда от неё не дется в C++11? F> С тем, что я так устарел, а у нас каждый компилятор поддерживает C++11 в полном объеме? F> С чем конкретно? Расскажи уж. Просвяти всех. Я лично буду тока рад.
Чуть меньше пафоса, пожалуйста.
Не согласен именно с такой "правдой жизни". Если подробнее, то с двумя вещами:
1. "ПОЛНАЯ поддержка" для такой мелочи не нужна. Её до сих пор ни у кого нет, вроде. Но частичная есть у многих. GCC поддерживает это с версии 4.3 которая вышла в марте 2008 года.
2. Есть "особенности компиляторов". Вижуал студия 2008 (это вообще 2007 год) нормально воспринимает такой код и без всякой поддержки новых стандартов. Может это некорректно, но работает и хоть это не лучший аргумент, но не всем нужна кросплатформенность.
Подробнее сразу отвечать не стал так как, во первых, в данной теме это офтопик. Во вторых, про это легко самому узнать при минимальных усилиях. Например, я вбил в гугл "gcc c++ right angle brackets" и перешел по первой же ссылке.
Из-за этого воспринял такие заявления как троллинг. Возможно, был не прав, хотя ответная реакция забавная.
Ок. Спасибо. Пафос — то я не со зла.
Ну да, видимо кроссплатформенность, и долгое время ориентации на MSVC2008 и есть причина "суровой", а то что это ещё с gcc 4.3 пофикшено — не знал.
Здравствуйте, VladD2, Вы писали:
VD>Ага. Всегда проще наклеить ярлычок вроде "евангилизм", чем в чем-то разобраться и попробовать на практике.
До свидания.
VD>Короче, уж извини, но с тобой не интересно дискутировать. Ты не оперируешь аргументами, а сыплешь ярлыками. Не ясно только одно, зачем интересоваться чем-то, если заранее для себя решил, что это тебе не нужно?
Я для себя решил, что если евангелист отвечает вопросом на вопрос или не может родить внятных примеров, объяснений, то это хреновый евангелист, его не надо слушать, у него ничего нет.
Re[15]: Недостатки Nemerle
От:
Аноним
Дата:
12.07.12 18:42
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, _Claus_, Вы писали:
_C_>>+1. Метасвязки от Анонима — это, несомненно, будущее программирования. WH>Ты лучше ссылки на статьи дай. WH>Ибо своими словами ты еще ни кому, ни чего, ни разу не объяснил.
Метасвязки не тьюринг подобное обобщение макросов. В общем случае скомпилировать программу написанную корректно в виде метасвязок за конечное время на машине тьюринга не возможно, так же как и исполнить.
Здравствуйте, <Аноним>, Вы писали:
А>Метасвязки не тьюринг подобное обобщение макросов. В общем случае скомпилировать программу написанную корректно в виде метасвязок за конечное время на машине тьюринга не возможно, так же как и исполнить.
В общем случае и на машине Тьюринга можно получить вечный цикл.
Конкретней про метасвязки можно?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>До свидания.
Лучше — прощай.
I>Я для себя решил, что если евангелист отвечает вопросом на вопрос или не может родить внятных примеров, объяснений, то это хреновый евангелист, его не надо слушать, у него ничего нет.
Ты что-то путаешь. Евангелисты — это в Майрософт и т.п. Им за это деньги платят. Я всего лишь говорю, то что знаю сам.
А отвечать и объяснять можно только тем кто стремится понять и узнать. Ты же ясно пришел не слушать или спрашивать, а с какими-то другими целями.
Так что если вдруг возникнет желание разобраться в чем-то для тебя новом, то заходи — мы с удовольствием ответим на все вопросы. А пока, пока.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Не лучшее, метасвязки лучше, но я даже не слышал об их использовании за пределами теоритических работ. Макросы это упрощение метасвязок с отношением примерно таким же как макросы к функциям.
Я не знаю что такое метасвязки. Возможно это очень круто. Приведи внятное описание, почитаем.
Я же говорил о доступных в реальной жизни методах абстракции. Фактически на сегодня общеприменимыми методами абстракции являются:
1. Функции/процедуры.
2. Типы (АТД).
3. Языки (ДСЛ/расширения ЯП).
Собственно ДСЛ-и потенциально дают наилучшее выражение задач. А генерация кода позволяет не меняя самих языковых абстракций как угодно менять реализацию.
Собственно говорить "лучшее" не очень правильно. Тут лучше подойдет слово "самая мощная", потому как языковые абстракции не бесплатны. Если задачи качественно решаются функциями или типами, то прибегать к ДСЛ-ям зачастую бессмысленны. Но если функции и типы пасуют, то ДСЛ-и, обычно являются отличной заменой.
Конечно, можно порассуждать о том, что и в языках без мета-подсистем можно создавать ДСЛ-и (флюент-интерфейс, реинтерпретация синтаксиса, и т.п.), но тут сразу встает проблема отсутствия возможности преобразовать код на ДСЛ в эффективный и корректный исполняемый код. Нормально это можно сделать только имея генерацию кода времени компиляции или динамической компиляцией/интерпретацией.
В общем, связка ДСЛ + метапрограммирование дает оптимальную абсракцию и гибкость.
Что же такое метасвязки и чем они лучше я не знаю, но с удовольствием послушаю объяснение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
