Я не понял зачем сравнивать определения типа и оператора? Во-первых, это не имеет отношения к использованию. Во-вторых, мой способ гибче, потому что я не принимаю Си за точку отсчёта и ничто не мешает написать
В-третьих, новые типы определяются настолько редко, что затратами на их определение, тем более конкретизацию шаблона, можно пренебречь.
VK>Мне понадобилось секунды три чтобы понять, что происходит в первом случае (да, я настолько тупой). И ~0.0 секунд чтобы разобраться во втором.
А зачем тебе определять что там происходит? Ну сантиметр, ну и ладно. А если очень интересно — Ctrl+Space и смотрим названия параметров шаблона. В принципе это ограничение Си++, что мне пришлось дроби записывать как числитель и знаменатель. Шаблоны не параметризируются не интегральными типами.
physical_value_t<1, 0, 0, double, 0.01, 1.0, 1.0>
конечно же лучше, но не бывает.
Зато в пределах одной системы счисления всё очень даже просто
typedef physical_value_t<1, 1, -2> phys_newton_t;
VK>Очень смешно. Во-первых не увидел одинаковой функциональности. У тебя предусмотрены только три вида базовых единиц — масса, длина и время.
Да хоть 100, просто добавятся однотипные строчки — делов-то. Для решения написанного за час вполне сойдёт. Там по уму ещё надо сделать нетипизированный коэффициент и степени считать не через pow, а шаблонами в момент компиляции. Вообще много чего можно доработать в любом решении, было бы желание.
VK>В решении на Nemerle практически нет хардкодинга и в этом его главное преимущество. Мне честно-говоря даже страшно представить во что превратится твое решение на C++ если скажем понадобится десятка два таких базовых единиц.
ОК, это всё правильно, но какое это имеет отношение к использованию решения? Даже если я добавлю поддержку ещё 10 единиц измерения (что на данном этапе займёт 15-30 минут) это не уменьшит и не увеличит проблем использования.
Здравствуйте, adontz, Вы писали:
A>В коде у тебя что-то не то, но понял ты правильно. A>А теперь внимание — я хочу тип производной скорости по расстоянию.
Si.Acceleration. Т.е. такой тип задан в моих алиасах. Если ты говоришь о вычислении типа производной, то конкретно этой фичи нет, но её можно добавить. Если ты говоришь об объявлении физической переменной произвольной размерности без её предварительного описания в DSL, то, во-первых, непонятно, на кой это надо, во-вторых, можно добавить её описание в DSL, и, в третьих, всё равно тут синтаксис Nemerle позволяет писать более красивые вещи, чем скалярные параметры шаблонов C++. Например, имхо
value_t<1, -2, 0> acc = value_t<1, -2, 0>(1);
Выглядит очень непонятно (попробуй удержи в голове, какой параметр какому орту соответствует) и хуже, чем такой вариант (вполне реализуемый для Nemerle):
def acc = phys-value[Time / (Length ^ 2)](1)
Это я к тому, что тут шаблоны C++ не спасают и на Nemerle присутствует лучшее решение — просто надо перестроить свои мозги, сломать себя и понять тот простой факт, что метапрограммирование на Nemerle лучше оного на C++.
. Кстати, я надеюсь, ты не будешь заявлять, что сделать такое на Nemerle невозможно — если это можно сделать в описании величин, то и в коде, очевидно, тоже.
Здравствуйте, adontz, Вы писали:
A>С таким уровнем аргументации далеко не уедешь.
С таким, как у тебя в сообщениях, тоже. Ты совершенно не осознаёшь возможности, предоставляемые языком, потому что, видимо, не пробовал на нём писать. Кроме того, ты приводишь какие-то глупые аргументы против моей библиотеки, которые говорят о том, что ты не понимаешь, как она работает.
Советую хоть немного изучить Nemerle и поиграться с моей библиотекой, прежде чем подвергать их необоснованной критике.
A>Nemrle не распространён, у него даже официальной документации нет.
У него есть документация — по ней я и учил язык. Или ты говоришь о стандарте? Стандарта, естественно, нет, но мне без него не холодно не жарко. Назови, например, хотя бы парочку компиляторов C++, которые на 100% соответствуют стандарту
Где же его большая гибкость, в таком случае?
A>В-третьих, новые типы определяются настолько редко, что затратами на их определение, тем более конкретизацию шаблона, можно пренебречь.
Отличная отмазка Особенно хорошо будет поддерживать такой код Кстати, сам автор исходной библиотеки на C++ признаёт, что такое решение коряво
.
VK>>Мне понадобилось секунды три чтобы понять, что происходит в первом случае (да, я настолько тупой). И ~0.0 секунд чтобы разобраться во втором.
A>Зато в пределах одной системы счисления всё очень даже просто
typedef physical_value_t<1, 1, -2> phys_newton_t;
Да уж, невероятно просто и легко... впрочем, об этом я уже писал. Видимо, у всех поклонников C++ overcomplication считается преимуществом...
VK>>В решении на Nemerle практически нет хардкодинга и в этом его главное преимущество. Мне честно-говоря даже страшно представить во что превратится твое решение на C++ если скажем понадобится десятка два таких базовых единиц.
A>ОК, это всё правильно, но какое это имеет отношение к использованию решения? Даже если я добавлю поддержку ещё 10 единиц измерения (что на данном этапе займёт 15-30 минут) это не уменьшит и не увеличит проблем использования.
Ой ли? В общем, я уже написал всё, что хотел — тебе осталось только внимательно прочитать, не упустив ничего из виду
Кстати, у меня возникает простой вопрос — неужели ты сам не мог додуматься до того, что я написал в сообщении? Или ты просто и вправду пытаешься "докопаться" до моего решения (я нахожу такое поведение глупым, поэтому и не могу поверить, что это так)?
Здравствуйте, adontz, Вы писали:
A>>>Нет value_t<1, 1, -2> это величина с разверностью A>>>м*кг A>>>----- A>>>с^2
VD>>Это домыслы. A>Нажимаем Ctrl+Space.
Пять баллов! Я просто в восторге, на самом деле. Ctrl + Space — вот решение всех наших проблем
Здравствуйте, adontz, Вы писали:
O>>Кстати, ты всерьёз считаешь, что value_t<1, 1, -2> удобнее хоть в каком-то случае?
A>Конечно нет. Конечно же для всех базовых величин надо сделать typedef. НО! Если я захочу производную размерность, причём не важно какую, она у меня есть. Причём именно в том виде в котором я её записываю — единицы измерения со степенями, ибо названия нет.
. И на всякий случай словами: тем не менее, решение на шаблонах неинтуитивно — в сообщении предложено более (на мой взгляд) красивое решение. И безо всяких Ctrl + Space
VD>это тоже в общем-то ДСЛ, но язык менее выразительный и все проблемы недоДСЛей вылезают очень сильно. Сравни декларацию типов, да и оцени использование физических литералов.
Да уж... Притопала банда Nemerle-поклонников (практически в полном составе, только IT не был пока замечен) и ввалила бедолаге по первое число. А заодно превратила тему ЯОП в очередную пропаганду Nemerle.
Мужики, ну чесслово, забабахало. Может хватит поминать Nemerle на каждом шагу? И уж тем более сравнивать его с C++, в котором не было штатных механизмов метапрограммирования (разве что макросов). А все, что было найдено -- это следствие нестандартного использования совершенно не предназначенных для метапрограммирования вещей. Хотите раскрутить Nemerle -- сравнивайте его с C# или с Java, или со Scala. А можно со Smalltalk, Lisp или Ruby. Но, блин, не в теме же про языково-ориентированное программирование.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да уж... Притопала банда Nemerle-поклонников (практически в полном составе, только IT не был пока замечен) и ввалила бедолаге по первое число.
Nemerle — это наглядный пример статически типизированного языка, позволяющего писать свои DSL-и.
E>А заодно превратила тему ЯОП в очередную пропаганду Nemerle.
Тебе тут мерещатся ведьмы?
E>Мужики, ну чесслово, забабахало. Может хватит поминать Nemerle на каждом шагу? И уж тем более сравнивать его с C++, в котором не было штатных механизмов метапрограммирования (разве что макросов). А все, что было найдено -- это следствие нестандартного использования совершенно не предназначенных для метапрограммирования вещей.
Так мы и не начали сравнивать. К сожалению, выходит наоборот — оппоненты постоянно говорят про ущербность Nemerle и про то, что многие подобные задачи на C++ решаются лучше. Я, например, не могу в таком случае промолчать. Вот и выходит, что приходится делать такие сравнения.
А насчёт метапрограммирования и C++ ты совершенно прав — я с тобой полностью согласен тут.
E>Хотите раскрутить Nemerle -- сравнивайте его с C# или с Java,
Так тоже сравниваем с C#, просто не все это замечают. Скоро даже статья выйдет — там в основном с C# и идёт сравнение.
E>или со Scala.
Scala я не знаю, так что тут скромно промолчу
E>А можно со Smalltalk, Lisp или Ruby.
По-моему, с Lisp уже сравнивали. Сошлись на том, что наличие синтаксиса, гигиена в макросах (которую, впрочем, можно явно нарушить) и квази-цитирование есть хорошо.
Про Ruby и его подход к метапрограммированию (основанный на интерпретации и динамической типизации) по-моему тоже был разговор, и как раз с тобой
Smalltalk, опять же, не знаю...
E>Но, блин, не в теме же про языково-ориентированное программирование.
В этой теме зашёл разговор про неприменимость DSL. Nemerle был приведён как пример языка, на котором DSL-и пишутся легко, да ещё и с контролем на этапе компиляции. Почему нет?
PS: И не надо искать фанатизма в наших постах — его там нет Зато у них есть аргументация и вполне определённая цель, которой я в этом сообщении не вижу (если, конечно, целью не является зафукать Nemerle в очередной раз ). Никто не мешает тебе, например, смотреть на DSL через призму Ruby — почему же нам нельзя смотреть на них через стёклышко Nemerle?
Здравствуйте, Oyster, Вы писали:
E>>А заодно превратила тему ЯОП в очередную пропаганду Nemerle.
O> Тебе тут мерещатся ведьмы?
При чем здесь ведьмы?
Просто оскомину набило очередное обсасывание применимости Nemerle для метапрограммирования.
Имхо, в этой теме было бы более полезно и интересно обсуждать такие моменты, как:
— определениее ситуации, в которой DSL был бы более выгоден, чем API, кодогенерация или разделение приложения на несколько слоев/процессов;
— оценка качества DSL (т.е., насколько он будет удобен в использовании, сопровождении, расширении, совместном использовании с другими DSL);
— вопросы о совместимости различных DSL в одном приложении/модуле;
— что-нибудь еще.
Ну и не нужно забывать, что речь перешла на обсуждение internal DSL, т.е. создание собственного расширения существующего языка. В этом подходе DSL действительно не сильно отличается от еще одного API (а в Ruby таковым и является, т.к. все эти Ruby-новые фишки являются всего лишь вызовами методов объектов без разширения/изменения синтаксиса языка).
Однако, существует еще понятие external DSL. Про которые (точнее про инструмент для создания которых) шла речь в обсуждаемой здесь статье. И уж к этой разновидности DSL ваше очередное красноречивое доказывание достоинств Nemerle просто не в тему. Уж извини, но если кто-то сомневается в возможностях Nemerle -- пригласите его в соответствующую тему или создайте отдельную. А в очередной раз читать про макросы Nemerle в теме, которая не имеет к этому непосредственного отношения, лично мне скучно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
VD>>это тоже в общем-то ДСЛ, но язык менее выразительный и все проблемы недоДСЛей вылезают очень сильно. Сравни декларацию типов, да и оцени использование физических литералов. E>Да уж... Притопала банда Nemerle-поклонников (практически в полном составе, только IT не был пока замечен) и ввалила бедолаге по первое число.
На самом деле, это ещё совсем не понятно — кто кому за что и сколько. Но до боли напоминает дискуссии с AVK, IT и VladD2 3-х летней, кажется, давности. Что примечательно, тогда тоже был C++ vs., правда, C#.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, adontz, Вы писали:
A>Это конечно очень замечательно брать существующие DSL'и придумывать новые и проч. ит проч., но чрезмерное использование DSL порождает больше проблем чем, пользы. В том числе A> A> Надёжность A> Языки A> Диалекты A> Совместимость A> Взаимозаменяемость, обучение A> Поддержка A>
A>В целом к введению в проект новых языков надо относиться очень осторожно. Не надо уподобляться ООН, где большая часть сотрудников это армия переводчиков, которая что-то постоянно синхронно и асинхронно переводит, а большая часть бюджета — их зарплаты.
A>Должны быть очень серьёзные причины чтобы заставлять людей учить новый язык (я думаю изучение языка программирования по сложности сопоставимо с человеческим языком)...
Все это так и все эти вопросы действительно актуальны. Но, нужно понимать, что DSL-ям не один день от роду. И что эти вопросы уже кем-то когда-то поднимались.
Therefore, it will often be the case that your only defense against designing a bad minilanguage is knowing how to design a good one. This need not be a huge step or involve knowing a lot of formal language theory; with modern tools, learning a few relatively simple techniques and bearing good examples in mind as you design should be sufficient.
Кстати, может быть интересно, что C++ и Eiffel могут рассматриваться всего лишь как DSL
Ведь до сих пор на некоторых платформах C++ реализован через cfront и из C++кода генерируется C-код.
А из трех существующих трансляторов Eiffel два (EiffelStudio и SmartEiffel) не генерируют нативного кода, а транслируют Eiffel в C-код (так же возможна трансляция либо в MSIL (EiffelStudio), либо в Java byte code (SmartEiffel)).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Просто оскомину набило очередное обсасывание применимости Nemerle для метапрограммирования.
Это всё понятно. Но раз уж тему Nemerle подняли, то мне ничего не оставалось, как отвечать
Да и те, другие, вопросы, тоже обсуждаются. Разговор ведь пошёл о Nemerle потому, что появилась идея, что всё это нагромождение из тулзов, предложенное товарищем из JetBrains, возможно, не нужно, а достаточно языка, который позволяет посать обработчики любых DSL на себе.
E>Ну и не нужно забывать, что речь перешла на обсуждение internal DSL, т.е. создание собственного расширения существующего языка.
...
E>Однако, существует еще понятие external DSL. Про которые (точнее про инструмент для создания которых) шла речь в обсуждаемой здесь статье.
Да, Nemerle гибок, но недостаточно для создания любого внешнего (в терминах Фаулера) DSL. Да и возможностей рефакторинга у него ноль на данный момент... Но это не означает, что в этой теме Nemerle лишний на 100%.
А за разворачивание чересчур уж бурной дискуссии я ответственности не несу — я всего лишь защищался
Здравствуйте, Oyster, Вы писали:
O>Если ты говоришь об объявлении физической переменной произвольной размерности без её предварительного описания в DSL
Да, именно об этом я и говорю
O>то, во-первых, непонятно, на кой это надо,
Ну как же Величины бывают разными
O>во-вторых, можно добавить её описание в DSL
Это не способ
O>в третьих, всё равно тут синтаксис Nemerle позволяет писать более красивые вещи, чем скалярные параметры шаблонов C++. Например, имхо
O>
Здравствуйте, Oyster, Вы писали:
O>Да и те, другие, вопросы, тоже обсуждаются. Разговор ведь пошёл о Nemerle потому, что появилась идея, что всё это нагромождение из тулзов, предложенное товарищем из JetBrains, возможно, не нужно, а достаточно языка, который позволяет посать обработчики любых DSL на себе.
Так вот интересно выслушать соображения о том, в каких случаях выгодно писать internal DSL (здесь уже как раз можно затронуть вопросы предпочтения одного языка другому в конкретных условиях), а в каких таки лучше предпочесть external DSL. Соответственно, узнать, что за цену придется платить в этом случае.
O>А за разворачивание чересчур уж бурной дискуссии я ответственности не несу — я всего лишь защищался
Оправдания -- признак признания вины
Nemerle как раз в тему (я сам первым его название здесь упомянул ), но не в качестве противопоставления Nemerle rulez forever!, а C++ must die!
Было бы интересно как раз примеры DSL на Nemerle видеть. Скажем о примере с размерностями. Для меня в нем самым интересным является как раз небольшой фрагмент с описанием одних величин через другие. Вот это выглядит интересно. Имхо, это то, что действительно можно считать удачным декларативным DSL. Как результат работы подобного DSL будет использоваться затем в программе -- это уже другой вопрос. Можно в виде 10 kg, как предлагалось. А можно и в виде результата кодогенерации. Например, для C++ можно было бы из подобного DSL сгенерировать набор не шаблонных классов (Mass, Length, Time, ...) определить для них набор перегруженных операторов (например, Length / Time дает Velocity) и вспомогательные функции. Чтобы запись выглядела как:
Mass m1 = Cgs::mass(10);
Mass m2 = Si::mass(m1);
...
Length l1 = Cgs::length(100);
Length l2 = Si::length(l1);
...
Time t1 = Cgs::time(1);
Time t2 = Si::time(t1);
...
Velocity v1 = l2 / t1;
Не так лаконично, как в Nemerle, но и без шаблонных наворотов. Примечательно, что аналогичным образом можно было бы генерировать код не только для C++, но и для других языков, например, C# или Java (однако со специальными костылями для отсутствия перегрузки операторов, чтобы можно было Length на Time делить ).
Однако важно другое, что описание преобразования физических величин можно не хардкодить в виде ручного описания классов и их методов, а реализовать для этого описания DSL. Для языков с продвинутой поддержкой метапрограммирования (Nemerle, Lisp, Ruby) такой DSL можно построить в виде internal DSL (здесь мы получаем некоторые преимущества). В случее более ущемленных в этом плане языков (C#, Java, C++) придется использовать external DSL.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Макрос custom-unit сгенерирует тип юнита с нужной размерностью на лету (я уже генерю такие типы в своих макро-операторах, поэтому технических проблем тут никаких). Имхо из такой записи сразу понятно, какой тип у юнита (в отличие от записи на шаблонах C++).
— если это можно сделать в описании величин, то и в коде, очевидно, тоже.
Тебе тут мерещатся ведьмы?
