Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Приведённый кусок кода из реального проекта паука который облазил P2P сеть в сотни тысяч узлов, протокол общения между узлами как раз на базе структур-сообщений, которые сериализуются этим самым кодом — пример аналогичный твоему. Но ты конечно можешь и дальше болтать про "одни проблемы".
Это банальное очковтирательство. Ты привел не весь код. Основной код у тебя в библиотеках. И там его овер-дофига. Ты умолчал о куче разных деталей. Я же привел полную реализацию без библиотек и костылей вроде определения классов с помощью черт знает каких макросов.
Когда потребуется сделать, что-то не заложенное авторами этого FUSION-а, придется писать на этом чудо-средстве языке шаблонов самому. А писать на этом мягко говоря не просто.
Вот возникли у меня какие-то проблемы в реализации, я поставил точку остановки и в отладчике разобрался, что не так. А что делать с шаблонами? Там же даже отладочной печати не поставишь.
Ну, и скорость работы опять же не сравнима. Шаблоны — это интерпретация. Да еще и не полноценного ЯП, а эмулируемого на побочных эффектах шаблонов. Макры же — это компелированный код на том же самом языке, что используется для написание гражданского кода.
У меня в проекте 3 вида сериализации. Одна очень компактная и быстрая для сериализации событий. Она использует ряд умолчаний вроде того, что сериализация и десериализация должны производиться одной версией библиотеки. Другая поддерживает версионность для загрузки измененных структур данных из предыдущих форматов и поддерживает загрузку из внешних библиотек автоматом разрешая ссылки и строя граф объектов.
Моя стерилизация знает, что такое наследование и полиморфизм.
Она сериализует некоторые типы из стандартной библиотеки дотнета и нюгетов (которые скомпилированы до моих макросах и на другом языке).
И эти 10 строк меня могут только насмешить, так как в них и десятой доли всех эти нюансов не описать. Я вижу только какой-то шаблон генерящий вызов функций.
EP>Штука крутая, несомненно. Мой поинт в том что твой пример вообще не раскрывает силы макросов в Nemerle, ибо подобная автоматическая сериализация много где реализуема, и поэтому никакого вау-эффекта не производит.
Я же написал, что он писался не в расчете на гуру метапрограммирования на шаблонах С++. Это простой пример понятный дотнетчику.
Я конечно могу расказать про реализацию языка зависимых свойств, например, но боюсь придется сначала прочитать курс лекций по самим зависимым свойствам. А тут все ясно и привычно.
EP>Пример с пользовательским условным оператором а-ля if, или например реализация интерполированных строк, были бы куда более показательны и эффектны.
Они был бы непонятны тому кому я писал. К тому же это расширения языка, которые многие воспринимают в штыки (просто потому, что не пробовали и это страшно).
Примеров, вообще, можно привести много. Но задача же привести пример того как макры могут помочь в своей узкой задаче, а не улучшая язык. Про сам язык я тоже сказал. Но и через 10 лет после появления опережает Шарп. И многие его фичи реализованы, действительно, на макросах. Но вряд ли я сегодя удивлю шарпщика интеполированными (в оригинале сплайсед) строками или оператором безопасного доступа к членам "?.", так как они уже захардкожены в C#, а то что в Немерле еще в Шарп не войте просто будет непонятно шарпщику.
А вот примеры автоматизации и генерации кода они понятны всем и каждому. И что что кое что можно сделать на шаблонном МП в плюсах мало помогает этим шарпщикам.
EP>А получается так что именно прикладные вещи на C++ и пишутся, а всякие клей-прокладки между БД и UI на C#/Java — собственно скафолдинг и прочий LightSwitch тут не зря был упомянут, ибо подобные прокладки часто типовые.
Я не хочу на эту тему спорить. Делаешь, и далешь. На мой взгляд (и взгляд большинства прикладников) это оверкил.
EP>Так ты не понял о чём речь, и как обычно продемонстрировал чудеса адекватности. Речь о том что фичи о которых ты сказал есть ДАЖЕ в НЕ-IDE для обхаиваемого тобой C++. Скорей всего у Решарпера действительно есть какие-то крутые фичи для навигации, но ты почему-то вместо них упомянул какой-то примитив.
Да что-то в твоем видео ничего подобного тому о чем я говорил нет. Где там навигация по переопределениям виртуальных методов? Где поиск символов по всему солюшену в реальном времени? О переходе между гуем и кодом (о котором говорил автор темы) и говорить не приходится, так как этого самого гуя. На шарпе гуй — это какой-нибудь XAML. В нем море слабо типизированного или вообще не типизированного (динамического) кода на птичьих языка. Решарпер делает разные спекуляции и пытается типизироват это длое в IDE. В результате люди получают куда более удобную навигацию по коду и прочие фичи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, licedey, Вы писали:
L>>Из бенефитов я извлек только, что конструктор структуры генерится сам.
VD>Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки.
Я не буду что либо высказывать про Немерле, потому что не имею о нем должного представления. Но вы постоянно повторяете про макросы, я в тему не вникал, но догадываюсь что это из области мета-программирования. Если я скажу, что это типа #define в С, или шаблонов в С++, или упомянутый T4. Ну, скажем так, на практике надо приучится к такому подходу, чтобы сначала выявить обобщенный вариант, а затем заделать для него мета решение. Часто ли такое нужно в реальной жизни — незнаю. Мне например нет. Хотя у меня обычно по новому проекту в месяц, и часто используется одно и то же. Пока копипаста — мой друг.
Кстати, с WPF Nemerle дружит? А с ASP.NET MVC? Вот там шаблонных решений хоть отбавляй. Я про UI и всякие авторизации, конфигурации итд. Эти проклятые формы каждый раз с нуля верстать — "одно удовольствие". Если бы можно было как-то шаблонизировать этот процесс...у меня у самого есть несколько идей своего велосипеда, могу поделится
Но возвращаясь к вопросу о комьюнити, то мое мнение такое. Если вы считаете основной фишкой языка те же макросы например, то найдите целевую аудиторию и покажите ей что ваше решение мощное и экономит время.
Я не понимаю, почему те же Python, PHP взлетели, а вы забили на развитие комьюнити. Ок, другой пример. Буквально за 2 года Xamarin превратился из ничего в стандартный тулз для церкви свидетелей Гейтса. Дядя который занимался развитием этой штуковины, даже взымал нехилую мзду за использование. Почему? Ну вы знаете почему, потому что это нужно было людям. Чем учить пресловутый Objective-C и все тонкости iOS, получи пожалуйста все в своем любимом шарпе.
SO=StackOverflow если что
Здравствуйте, licedey, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, licedey, Вы писали:
L>>>Из бенефитов я извлек только, что конструктор структуры генерится сам.
VD>>Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки.
Вижу вы привели примеры, ну это громоздко как-то для getting started, человека который первый раз видит язык и понятия не имеет что из чего получится.
Здравствуйте, VladD2, Вы писали: EP>>Приведённый кусок кода из реального проекта паука который облазил P2P сеть в сотни тысяч узлов, протокол общения между узлами как раз на базе структур-сообщений, которые сериализуются этим самым кодом — пример аналогичный твоему. Но ты конечно можешь и дальше болтать про "одни проблемы". VD>Это банальное очковтирательство. Ты привел не весь код. Основной код у тебя в библиотеках. И там его овер-дофига.
Да какая разница если библиотека уже готова и с этим справляется? VD>Когда потребуется сделать, что-то не заложенное авторами этого FUSION-а, придется писать на этом чудо-средстве языке шаблонов самому. А писать на этом мягко говоря не просто.
Так я не агитирую против макросов, и даже не говорю что шаблоны их полностью заменяют. Я указываю на то что у тебя пример не мотивирующий совсем. VD>Вот возникли у меня какие-то проблемы в реализации, я поставил точку остановки и в отладчике разобрался, что не так. А что делать с шаблонами? Там же даже отладочной печати не поставишь.
Есть и отладочная печать, и REPL, и трассировщик, и даже подобие отладчика с визуализатором. Но мой поинт был совсем не про C++ и шаблоны. VD>Ну, и скорость работы опять же не сравнима. Шаблоны — это интерпретация. Да еще и не полноценного ЯП, а эмулируемого на побочных эффектах шаблонов. VD>Макры же — это компелированный код на том же самом языке, что используется для написание гражданского кода.
Есть constexpr и другие нововведения — приличная часть того что писалось на шаблонах теперь пишется на "гражданском" языке. В частности на основе этих фич и появилась Hana на замену Fusion. VD>У меня в проекте 3 вида сериализации. Одна очень компактная и быстрая для сериализации событий. Она использует ряд умолчаний вроде того, что сериализация и десериализация должны производиться одной версией библиотеки. Другая поддерживает версионность для загрузки измененных структур данных из предыдущих форматов и поддерживает загрузку из внешних библиотек автоматом разрешая ссылки и строя граф объектов. VD>Моя стерилизация знает, что такое наследование и полиморфизм.
Это уже относится непосредственно к сериализации, собственно как только есть рекурсивный обход структур — к нему можно прикрутить любую из готовых библиотек сериализации. EP>>Пример с пользовательским условным оператором а-ля if, или например реализация интерполированных строк, были бы куда более показательны и эффектны. VD>Они был бы непонятны тому кому я писал. К тому же это расширения языка, которые многие воспринимают в штыки (просто потому, что не пробовали и это страшно).
Так фишка-то как раз в расширении языка. Если язык не расширять, а делать только "внешние" макросы которые где-то в сторонке от основного кода будут что-то генерировать, то это не сильно отличается от обычной внешней генерации (хотя и местами получается действительно очень удобно). Собственно те же C#-программисты вполне себе умеют использовать T4.
На примере той же сериализации: даже если в языке нет абсолютно никакой рефлексии, и есть естественное желание не делать лишние повторения (сначала описать поля в структуре, потом вручную сериализовать каждое её поле) — то без проблем создаётся схема на каком-нибудь XML/JSON плюс небольшой кодогенератор на каком-нибудь Python. Из этой же схемы без проблем генерируется документация, графы, код для других языков и т.д. и т.п., и даже не-программисты справляются с такими схемами. В этом свете преимуществ у макро-сериализации не много — и именно поэтому пример с сериализацией не айс.
А вот какие-то недостающие фичи "внутри" языка (а-ля интерполированные строки) — такой внешней кодогенерацией разруливать трудно — ибо там нужно не только генерировать, но анализировать и "модифицировать" исходный код.
Вот такие примеры и нужно показывать — ибо это главная сильная сторона, ИМХО. VD>Примеров, вообще, можно привести много. Но задача же привести пример того как макры могут помочь в своей узкой задаче, а не улучшая язык.
Желательно чтобы пример этой узкой задачи не имел лёгкого решения другими средствами. VD>Про сам язык я тоже сказал. Но и через 10 лет после появления опережает Шарп. И многие его фичи реализованы, действительно, на макросах. Но вряд ли я сегодя удивлю шарпщика интеполированными (в оригинале сплайсед) строками или оператором безопасного доступа к членам "?.", так как они уже захардкожены в C#, а то что в Немерле еще в Шарп не войте просто будет непонятно шарпщику.
Так эти интерполированные строки в C# только-только появились, теперь они их распробуют и не будут лепить blub-отмазки а-ля "да это и не надо" — и пока они тёпленькие на контрасте как раз показать что они вполне реализуются/реализовались средствами Nemerle, не дожидаясь снисхождения ихнего всего. EP>>Так ты не понял о чём речь, и как обычно продемонстрировал чудеса адекватности. Речь о том что фичи о которых ты сказал есть ДАЖЕ в НЕ-IDE для обхаиваемого тобой C++. Скорей всего у Решарпера действительно есть какие-то крутые фичи для навигации, но ты почему-то вместо них упомянул какой-то примитив. VD>Да что-то в твоем видео ничего подобного тому о чем я говорил нет. Где там навигация по переопределениям виртуальных методов?
Это вообще старая фича — интерактивный fuzzy search (по кусочкам имени) в списках а-ля все пути/файлы в проекте, recent list, открытые файлы, все символы, символы в текущем файле, итерактивный live grep и т.п.
интерактивный поиск файла в проекте
интерактивный поиск символов
интерактивный live-grep
VD>О переходе между гуем и кодом (о котором говорил автор темы) и говорить не приходится, так как этого самого гуя.
GUI на C++ разный бывает — нужно смотреть конкретную среду. В частности переход из дизайнера форм в код обработчика типа OnClick был ещё с незапамятных времён C++ Builder. Как там сейчас дела с навигацией по динамически типизированным штукам типа QML — без понятия, ибо с GUI работаю очень редко.
И я не автору темы про GUI отвечал, а тебе на твои примеры очень удобной навигации РеШарпера.
Здравствуйте, licedey, Вы писали:
L>>>Из бенефитов я извлек только, что конструктор структуры генерится сам. VD>>Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки. L>Я не буду что либо высказывать про Немерле, потому что не имею о нем должного представления. Но вы постоянно повторяете про макросы, я в тему не вникал, но догадываюсь что это из области мета-программирования. Если я скажу, что это типа #define в С, или шаблонов в С++, или упомянутый T4.
Это ближе к макросам Lisp'а.
Если брать аналогию с T4 — то макросы Nermele это такой T4 который на порядок теснее интегрирован в язык, имеет больше доступа к информации о конструкциях языка, более типобезопасен, гигиеничен, дает ранее обнаружение ошибок и т.п.
Плюс фича по расширению синтаксиса — можно вводить новые конструкции, операторы и т.п. непосредственно в язык. В частности привычные конструкции типа условных операторов реализованы в библиотечном виде. Плюс интеграция в IDE — подсветка этого расширенного макросами синтаксиса.
Здравствуйте, licedey, Вы писали:
L>Эти проклятые формы каждый раз с нуля верстать — "одно удовольствие". Если бы можно было как-то шаблонизировать этот процесс...у меня у самого есть несколько идей своего велосипеда, могу поделится
Для шаблонизации "процессов" частенько достаточно простого кодоненератора на каком-нибудь Python, или близкого C#-истам T4.
L>Если вы считаете основной фишкой языка те же макросы например, то найдите целевую аудиторию и покажите ей что ваше решение мощное и экономит время.
Думаю изначально целевая аудитория/платформа выбрана не та, ИМХО.
Во-первых метапрограммирование даёт быстродействие по сравнению с более динамичными решениями. Например та же сериализация на макросах против сериализации на runtime-reflection — возможности примерно одинаковые, но отличается скорость. Для аудитории которая как молитву произносит всёвбазуупирается это в общем-то не интересно. А тем кому всё же иногда требуются — умеют расчехлять T4 при необходимости, и в ус не дуют.
Во-вторых даёт большую типобезопасность по сравнению с теми же динамическими аналогами. Но ради этого преимущества, да и то которое есть только в некоторых местах, вылазить из уютного, знакомого и популярного C#/Java/whatever мало кто будет. Многие вообще используют целиком динамические языки — а уж C# с динамизмом в некоторых местах вообще без проблем переживут.
В-третьих это расширения языка, но по заверениям самого VladD2 "многие воспринимают в штыки (просто потому, что не пробовали и это страшно)" — а уж программисты корпоративных опердней тем более будут воспринимать в штыки.
Коварный .NET — с одной стороны дал Nemerle огромную экосистему, обеспечил кое-какой старт и кое-какую применимость, а с другой обрёк на перманентный маргинальный статус.
А вот если бы был прицел на аудиторию C++, на соответствующую платформу, то это был бы отличный кандидат на пост убийцы C++. Ибо там есть огромный спрос на всякие zero-cost абстракции, метапрограммирование в почёте (даже всякая шаблонная "магия" а-ля enable_if легитимизируется переползая в стандарт), распространены встроенные доменно-специфичные языки и это несмотря на все языковые трудности и перегревы компиляторов.
Здравствуйте, Философ, Вы писали:
Ф>>>Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д. S>>Вот я бы не стал рекомендовать ничего подобного, т.к в большинстве случаев подобные хитрые схемы вырождаются в слепой карго-культ в стиле трёх сигм или ещё какой мутотени.
Ф>К сожалению твоя общая рекомендация "есть слона по кусочкам" часто приводит к тому, что каждый кусочек слона связан с миллиардом других кусочков слона, и даже просто добраться до кусочка 1ACE8 составляет проблему, не говоря уже о том, чтобы его поправить так, чтобы весь слон при этом не рассыпался. Моя основная мысль заключалась в том, что нужно оперировать разумным кол-вом кусочков за раз. А этого можно добиться только иерархическим проектированием этого самого слона.
Для этого, прежде чем кодить, нужно разбить слона на отдельные части и определить взаимосвязи между ними, при этом стремиться к тому, что бы интерфейс взаимодействия частей содержал как можно меньше функций.
Например — некоторые части слона:
Несущая конструкция, выполняющая так-же транспортные функции (скелет и мышцы)
Система управления, состоящая из ЦПУ, шины данных и датчиков (нервная система, состоящая из головного мозга, нервов и органов чувств)
Продуктопровод с насосной станцией (кровеносная система и сердце)
Система питания (пищеварительная система)
Система вывода отходов
Крупные части сообщаются между собой посредством шины данных и продуктопровода. На низком уровне каждая крупная часть состоит из объектов разных типов, унаследованных от класса Клетка.
Т.е. — имеем составные объекты, у каждого из которых своя функция и сообщающегося с другими по понятному интерфейсу. Каждый составной объект состоит из объектов более низкого уровня. В результате имеем систему с понятной иерархией объектов и конструкцией. Но при этом — в целом это сложнейшая система.
AN>Крупные части сообщаются между собой посредством шины данных и продуктопровода. На низком уровне каждая крупная часть состоит из объектов разных типов, унаследованных от класса Клетка.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, AleksandrN, Вы писали:
AN>>Крупные части сообщаются между собой посредством шины данных и продуктопровода. На низком уровне каждая крупная часть состоит из объектов разных типов, унаследованных от класса Клетка.
S>Не совсем удачная идея
S>Тут лучше не увлекаться аналогиями и разбирать конкретные примеры на конкретных сценариях. Иначе фигня получается.
Согласен, что аналогия не очень удачная получилась. А для примера хорошо бы посмотреть архитектуру какого-нибудь проекта топик-стартера и обсудить удачные и неудачные идеи в архитектуре.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, licedey, Вы писали:
L>>Эти проклятые формы каждый раз с нуля верстать — "одно удовольствие". Если бы можно было как-то шаблонизировать этот процесс...у меня у самого есть несколько идей своего велосипеда, могу поделится
EP>Для шаблонизации "процессов" частенько достаточно простого кодоненератора на каком-нибудь Python, или близкого C#-истам T4.
Python, T4 — ок. Но громоздко и сложно, особенно для UI. Я считаю должно быть решение "для домохозяйки", уменьшающее риск ошибки и универсальное как Калашников.
А в случае упомянутых тулс, каждый раз — по сути, пиши новый велосипед.
L>>Если вы считаете основной фишкой языка те же макросы например, то найдите целевую аудиторию и покажите ей что ваше решение мощное и экономит время.
EP>Думаю изначально целевая аудитория/платформа выбрана не та, ИМХО. EP>Во-первых метапрограммирование даёт быстродействие по сравнению с более динамичными решениями. Например та же сериализация на макросах против сериализации на runtime-
Основная аудитория, я так понимаю, сидит тут. Это энтузиасты которые могут позволить себе поковыряться в чем-то новом. У остальных, как вы правильно заметили, дедлайны и тупо нет времени на изучение. Я одним взглядом смотрю на синтаксис и мне страшновато, хотя бы оттого что он не С-подобный. Признаться мне и от Objective-C и Ruby, примерно такие же ощущения-недоумения. А есть еще такие дикие языки как Perl, Haskell и F#. Вот меня точно Высшая Сила накажет, если отправит на проект где они используются.
Ответ прост — я хочу есть и мне нужен молоток.
Я вижу только одну причину развития любого языка — это новая платформа. С++ стал нужен для UI, Java для кросс-платформ и веб, PHP для веба, Objective-C для iPhone. C# тупо, потому что существующие инструменты под Win устарели. Пусть грубо — но я вижу причину только в этом.
Почему бы не адаптировать Nemerle скажем для IoT. Или возьмем более узко — скраперы сайтов. Или тестирование. Да даже если он под мобайл будет заточен лучше Xamarin, я тут же брошусь учить.
Вот лично мне из Nemerle понадобился Peg, 4 года назад, когда не было еще Roslyn, и выбор пал больше потому, что я сидел на этом форуме и слышал про Nemerle.
Необходимость+Огласка там где зависаешь=Популярность языка.
