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

IT>Это — не плохой аргумент. Это — жизнь. В середине проекта, в котором участвует только девелоперов с полсотни, менять VCS из-за проблем с кодогенерацией в одной из шести команд — это безумие. Никто на это не пойдёт.

У нас начальник тоже так думал. Долго думал. Но когда на войну с VSS стало уходить по полчаса-часу в день даже он сдался. Сейчас не жалеет совершенно, наоборот сам затеял перетаскивание на SVN бизнес-кодеров, бо он у нас еще еженощными билдами занимается и прочей служебной мракобесией, а там с VSS тоже все весьма неприятно.

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

AVK>С чего бы это?

Ну смотри. Вот переопределяем мы поведение класса с помощью Reflection.Emit. Сделать это мы можем только сгенерировав класс-наследник и переопределив поведение в нём. И этот класс появится только во время выполнения, т.е. на этапе написания кода мы не можем создать его экземпляр. Поэтому нам приходится заводить фабричный метод, который по типу базового класса создаёт нам экземпляр прокси-типа, сгенерированного в рантайме, т.к. если мы будет использовать обычный new, то получим экземпляр базового класса без функциональности, добавленной с помощью Reflection.Emit. Например, при использовании моей библиотеки пользователям приходится писать такой код:

// Тут неявно создаётся экземпляр наследника, созданного в рантайме
BizEntity ent = BizFactory.Instance.Create<BizEntity>();

// Если мы напишем так, то переопределение функциональности BizEntity,
// выполненное с помощью runtime code generation, потеряется
BizEntity ent = new BizEntity();

Надеюсь, объяснил доходчиво...

AVK>Неужели ты не видишь разницы между библиотеками и синтаксисом языка?

Не вижу. Библиотеки макросов — это библиотеки макросов, которые мы вольны не использовать.

AVK>LINQ не позволяет менять синтаксис.

Да, согласен — LINQ вообще не добавляет ничего нового, кроме кучки синтаксического сахара, подслащённого усердными промоутерами. Ещё раз замечу, что Nemerle лишь даёт возможность добавлять новые синтаксические конструкции, а программисты могут как использовать, так и не использовать эти возможности.

Вообще я тебя не понимаю. Добавляют MS по щепотке новых ключевых слов раз в несколько лет — рулез, даёт Nemerle эту же возможность всем желающим — сакс... Да, сейчас кто-нибудь может мне ответить, что в MS изучают тенденции, прощупывают индустрию, добавляют только самое нужное, самое правильное... Это всё не так. Настоящая правда заключается в том, что в MS разленились и тормозят.

Да, ещё кто-то может добавить, что опасно давать мощь макросов Nemerle в руке челяди (типа поломают всё, нехорошие люди, и нас по миру пустят), но я на такие слова решительно возражу, что эволюцию ещё никто не отменял. Кривые библиотеки сдохнут и Nemerle никогда не станет вторым Пёрлом (если выживет) просто потому, что всем будет легче использовать библиотеки, не навязывающие какой-то свой синтаксис. Но вот в некоторых случаях это таки чертовски удобно (LINQ, "XML без кавычек") и поэтому так здорово то, что с Nemerle (или другим языком, предоставляющим столь же изящную технологию метапрограммирования под .NET) мы можем не ждять, пока добрые дяди из Редмонда напишут LINQ 2.0, а экономить собственное время прямо сейчас.

PS: Пусть немного патетично, зато оптимистично

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

AVK>Да да. Одни мы тут такие неимоверно талантливые. Извини, но я в повальные недостатки не верю, не бывает так чтобы все кругом в дерьме, один я в белом фраке.

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

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

AVK>Здравствуйте, Дарней, Вы писали:

Д>>Если в программе нет никаких неизвестных терминов,

AVK>А если есть?

А если сначала прочитать сообщение не "по диагонали", а целиком?

AVK>Вот вот — чтобы разобраться в исходниках нужно изучать рефлектором код макросов.

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

А сейчас, чтобы понять работу неизвестной программы, приходится восстанавливать ход мыслей автора по обрывкам документации. Это по твоему лучше?

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

VD>>Ты вот это http://nemerle.org/Open_projects читал?

AVK>Читал. Ни слова про плагин.

раньше у них были проблемы с лицензией беты, которая не разрешала распространение любых использующих VS SDK исходников. С релизом проблема порешалась, но проект некоторое время был заброшен. Поэтому проект выложили в открытый доступ совсем недавно. Любая контрибуция приветствуется
(Похоже, квалификация его разработчика оставляет желать лучшего. Вот эта инструкция:

3. unzip this file into "C:\Program Files\Visual Studio 2005
SDK\2005.12\VisualStudioIntegration\Samples\NemerleIntegration"

наводит на такие мысли )

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

IT>Я вот одного не пойму. О каких именно проблемах ты говоришь? Ты можешь их хотя бы сформулировать или это всё игра на публику?

Есть у меня такой проект, SObjectizer

Автор: Евгений Охотников
Дата: 30.12.05

, в котором требуется делать довольно много метаописаний. В C++ эти метаописания реализуются макросами, но из-за ограниченности плюсовых макросов сделать можно далеко не все. В частности, я могу указать, какой тип сообщений обрабатывает событие, но не могу сразу же сделать автоподписку события. Хотя часто заранее известно, какие сообщения агент будет обрабатывать. Есть и еще более сложные случаи. В C++ я думаю упростить их за счет внешнего (или даже встраиваемого в C++ комментарии) DSL на Ruby с генерацией кода.

Если заниматься портированием SObjectizer на .NET или в Java, то с метаописаниями так же придется что-то курить. Либо использовать аннотации, либо опять внешний DSL. Но тут поднимается кипишь вокруг Nemerle. По первому впечатлению язык забавный и интересный. Но главное -- это возможность изменения синтаксиса под себя. Т.е. появляется перспектива портирования SObjectizer в .NET с действительно удобным встроенным DSL (за счет расширения синтаксиса Nemerle собственными синтаксическими конструкциями). Но чем больше я обдумывал это дело, тем больше начинал сомневаться в том, что расширение синтаксиса в библиотеке является хорошей идеей. И главная причина сомнений в том, что не контролируемые расширения синтаксиса конфликтуют. И возможность разруливания конфликтов только одна -- нужно давать синтаксическим конструкциям уникальные имена, которые с большой степенью вероятности не будут пересекаться с другими именами. Как это может выглядеть, я показал вот здесь

Автор: eao197
Дата: 18.02.06

.

В итоге я пока решил, что DSL с изменением синтаксиса Nemerle может доставить потенциальные проблемы мне, как разработчику библиотеки, так и потенциальным клиентам библиотеки.

Вот такой у меня, можно сказать шкурный, интерес был в фичах Nemerle.

Здравствуйте, AndrewVK, Вы писали:
AVK>А как надо? Ты считаешь что каждый программист способен сделать грамотное изменение синтаксиса языка? ИМХО для этого нужна квалификация и объем работ, на голову больший, нежели разработка API.
Кстати, хорошим, ИМХО, примером может служить Borland C++ Builder. Вроде тоже пацаны не самые тупые делали — я так полагаю, написать компилятор плюсов это не для средних умов задача. И что же мы видим? Банальные свойства приклеить они так и не сумели. Стоило объявить свойство ссылочного типа, как у компилятора начинало нехорошо рвать крышу. А если сделать свойство типа, у которого перегружен оператор []... У меня был как раз такой проект — я был молодой и учился программировать. Больше всего мне понравилось то, что компилятор одинаковый код компилировал как бог на душу положит. В одной строчке += означало вызов сеттера (чего, собственно, и хотелось), а в другой — вызывался геттер, а затем выполнялась inplace-модификация временного объекта. Красота. Я бы понял, если бы компайлер счел такую ambiguity ошибкой. Так ведь нет...
После этого я понял, что придумать язык типа С++ еще тяжелее, чем реализовать. Потому что нужно учесть очень много вот таких побочных эффектов. Шаг вправо/шаг влево, и твой компилятор начинает принимать совершенно неожиданные решения.

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

E>В итоге я пока решил, что DSL с изменением синтаксиса Nemerle может доставить потенциальные проблемы мне, как разработчику библиотеки, так и потенциальным клиентам библиотеки.

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

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

VG>Очень понравился мне комментарий одного товарища из ЖЖ на мою публикацию о Nemerle, так понравился, что рука к нагану потянулась:

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

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

AVK>>Неужели ты не видишь разницы между библиотеками и синтаксисом языка?

O>Не вижу. Библиотеки макросов — это библиотеки макросов, которые мы вольны не использовать.

+1. Я бы даже сказал так библиотеки != "библиотеки макросов", это разные понятия. И вовсе необязательно, что они будут менять синтаксис. И без измения синтаксиса можно очень многое сделать.

O>Да, сейчас кто-нибудь может мне ответить, что в MS изучают тенденции, прощупывают индустрию, добавляют только самое нужное, самое правильное... Это всё не так. Настоящая правда заключается в том, что в MS разленились и тормозят.

Не совсем согласен. Загляни на досуге на сайт Microsoft Research. У них "под колпаком" например уже давно трудится один из основных имплементаторов и дизайнеров Haskell, Simon Peyton-Jones. Под эгидой MSR разрабатывается целая куча разных исследовательских языков и других проектов. Тому же Nemerle выделили финансирование в рамках Rotor Funding Project 2, хотя он и не разрабатывается в рамках MSR. Для всех проектов, профинансированных таким образом устроили в сентябре прошлого года workshop(нечто вроде конференции).

Так что Microsoft ни в коем случае не упускает возможность изучить современные тенденции и недостатка в "исследовательском материале", который можно использовать по назначению у них явно нет. Да и вообще то, что будет представлять из себя C# 3.0 это уже большой прорыв вперед для mainstream языков. Я думаю в Microsoft даже слегка опасаются, что C# 3.0 не поймут и далеко не все новвоведения одобрят.

O>PS: Пусть немного патетично, зато оптимистично

Ты наверное хотел сказать пафосно. "Патетичный" означает жалкий, трогательный.

Здравствуйте, AndrewVK, Вы писали:
Андрей, пользуясь случаем: я в свое время имел дело с кастом тулом для XSLT процессинга. Мощная штука, но меня бесило одно место: хотелось иметь нормальную диагностику ошибок.
Так вот я так и не нашел способа генерить нормальные директивы #line, т.к. в XSLT процессоре нету доступа к номеру строки входного XML. Ты не знаешь, эта задача имеет решение?

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

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

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

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

Д>Если бы я не знал, что такое Немерле, я бы тоже какую-нибудь гадость написал

Можно ли узнать, много ли ты реализовал и внедрил проектов на Немерле?

Или хотя бы много ли проектов ты собираешься делать и внедрять на Немерле в ближайшее время?

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

VK>Ты наверное хотел сказать пафосно. "Патетичный" означает жалкий, трогательный.

Ну вообще-то и "трогательно" тоже, т.к. всё-таки не факт, что в итоге из Nemerle таки получится что-то но мне хочется в это верить.

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

E>Если тебе это кажется маразмом, то что ты скажешь на то, что передвижение по тексту осуществляется клавишами h, j, k и l? Ты думаещь -- это дико?
E>На самом деле дико удобно. И это сразу ощущается после небольшой практики.

Кстати, этими клавишами я пользовался только из-под телнета в Win95. Во всех других терминалах прекрасно работают стрелки.

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

E>Можно ли узнать, много ли ты реализовал и внедрил проектов на Немерле?

Я так полагаю, это риторический вопрос?

E>Или хотя бы много ли проектов ты собираешься делать и внедрять на Немерле в ближайшее время?

собираюсь перевести на него части своего любимого домашнего проекта. Как только у меня появится достаточно свободного времени
Правда, предварительно нужно будет добить до мало-мальски пригодного состояния плагин для VS. Про всякие автокомплиты и рефакторинги мечтать пока рано, но хотя бы обеспечить возможность редактировать/компилировать/запускать/отлаживать в студии — это обязательно.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Кстати, этими клавишами я пользовался только из-под телнета в Win95. Во всех других терминалах прекрасно работают стрелки.

Работают, но, что удивительно, этими клавишами все равно удобнее, чем стрелками. Т.к. при наборе не нужно руку перемещать на другой край клавиатуры.

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

E>>Можно ли узнать, много ли ты реализовал и внедрил проектов на Немерле?

Д>Я так полагаю, это риторический вопрос?

Это чтобы оценить достоверность фразы:

Если бы я не знал, что такое Немерле

Имхо, знание языка без большого опыта его использования очень поверхносно.

E>>Или хотя бы много ли проектов ты собираешься делать и внедрять на Немерле в ближайшее время?

Д>собираюсь перевести на него части своего любимого домашнего проекта. Как только у меня появится достаточно свободного времени

Это всегда так, к сожалению
Все равно, желаю удачи

Д>Правда, предварительно нужно будет добить до мало-мальски пригодного состояния плагин для VS. Про всякие автокомплиты и рефакторинги мечтать пока рано, но хотя бы обеспечить возможность редактировать/компилировать/запускать/отлаживать в студии — это обязательно.

Все таки как-то грусно смотреть на такие вещи... Такая сильная привязанность к VS...

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

AVK>Я не понимаю чем тут восторгаться. Ты Форт выдел? Там то же самое, даже еще круче. И это его и убило.

Нет, в Форте не то же самое. Форт — язык интерпретируемый, без строгой типизации. И без синтаксиса — там просто есть слова, работающие с двумя стеками — и всё. А определение нового слова — всего лишь добавление строки в словарик.

В Nemerle совсем не так всё сделано — тут тебе и строгая типизация, и проверка корректности макросов на этапе компиляции, и вменяемые диагностические сообщения... И никакой чехарды со стеком.

Имхо один из ключевых недостатков Форта — необходимость постоянно держать стек в мозгу при кодировании (на Форте почти всегда приходится писать состояние стека после операции в комментах к операции, чтобы не запутаться). Кстати, у Лиспа подобный недостаток, только в голове приходится держать AST (снова имхо).

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

...

E>В итоге я пока решил, что DSL с изменением синтаксиса Nemerle может доставить потенциальные проблемы мне, как разработчику библиотеки, так и потенциальным клиентам библиотеки.

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

Кстати, насколько я понял, в Nemerle макросы включаются в пространство имён, т.е. ты можешь писать:

using MyCompany.MacroLibrary;

myMegaMacro;

А можешь и:

MyCompany.MacroLibrary.myMegaMacro;

Как видишь, в таком случае проблем не больше, чем с обычными классами/методами, т.к. это не макросы Си и они не распологаются все в глобальном пространстве имён.

PS: Я тут не уверен насчёт своих рассуждений — пусть гуру меня поправят, если что.