Доброго времени суток.

Есть коммерческий продукт на C# 3.0, 200+ KLOC, вторая версия. Как архитектор хочу использовать Nemerle для разработки третьей версии продукта, засунув в макросы Nemerle журналирование, валидацию входящих данных, проверку пред|пост условий, инвариантов, асинхронность и персистентность. Вижу дополнительный риск при разработке на Nemerle(помимо ненулевой вероятности ухода Nemerle в небытие, чего искренне надеюсь не случится) — масштабные изменения синтаксиса языка в Nemerlе 2.0, ломающие совместимость с предыдущей версией языка/компилятора.
Внимание, вопрос — наверняка изменения будут, но хотелось бы узнать от главных разработчиков и в частности от Влада:
1) Какие изменения в языке уже запланированы ?
2) Что не нравится Владу и другим главным разработчикам в текущей версии языка/компилятора, чтобы оценить возможные переделки под следующую версию языка/компилятора Nemerle ?
Понимаю, что ответы на эти вопросы возможно уже есть на форуме, но во первых, не факт что изложенное ранее будет актуальным, а во вторых — хотелось бы увидеть некую выжимку планов по развитию языка/компилятора Nemerlе. Это позволит мне оценить хотя бы примерно возможные сроки по адаптации будущего кода под новую версию языка/комплятора.

Заранее благодарю за ответы.

С уважением к разработчикам Nemerle.

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

А> Есть коммерческий продукт на C# 3.0, 200+ KLOC, вторая версия. Как архитектор хочу использовать Nemerle для разработки третьей версии продукта,

Безумству храбрых поем мы песню!

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

А>Здравствуйте, Аноним, Вы писали:

А>> Есть коммерческий продукт на C# 3.0, 200+ KLOC, вторая версия. Как архитектор хочу использовать Nemerle для разработки третьей версии продукта,

А>Безумству храбрых поем мы песню!

Для нишевых продуктов с большой инновационностью бенефиты от использования Nemerle перевешивают возможные риски.

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

А> Есть коммерческий продукт на C# 3.0, 200+ KLOC, вторая версия. Как архитектор хочу использовать Nemerle для разработки третьей версии продукта, засунув в макросы Nemerle журналирование, валидацию входящих данных, проверку пред|пост условий, инвариантов, асинхронность и персистентность.

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

А>Вижу дополнительный риск при разработке на Nemerle(помимо ненулевой вероятности ухода Nemerle в небытие, чего искренне надеюсь не случится) — масштабные изменения синтаксиса языка в Nemerlе 2.0, ломающие совместимость с предыдущей версией языка/компилятора.

Уход случится вряд ли. Основная роблема — это невозможность выделять на язык и его окружение достаточного времени (у нас у всех есть своя работа). Но думаю, что с расширением комьюнити и с улучшением качества кода компилятора (которое так же планируется на 2.0) будет все больше людей содействующих развитию проекта не на словах, а на деле. Плюс возрастающая декларативность и чистота реализации компилятора упростит его развитие и поддержку.

А>Внимание, вопрос — наверняка изменения будут, но хотелось бы узнать от главных разработчиков и в частности от Влада:
А>1) Какие изменения в языке уже запланированы ?

В языке особых изменений не планируется. Точно будут дополнения/расширения.
Постараемся сохранить все возможности что были в 1.0. К тому же 1.0 так же будет жить и поддерживаться.

Вот в API макросов изменения будут точно. Но опят же постараемся сделать так чтобы старые макры тоже работали.

Почти наверняка будут изменяться разные имена имеющие сегодня кривые названия. Но это всего лишь переименование по контексту. На первое время будем водить дубликаты и помечать их как "деприкетед".

А>2) Что не нравится Владу и другим главным разработчикам в текущей версии языка/компилятора, чтобы оценить возможные переделки под следующую версию языка/компилятора Nemerle ?

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

Основное изменение двушки будет замена текущего рукописного парсера на автоматически генерируемый парсер основанный на синтаксических макросах нового поколения. Фактически нового парсера не будет. Вместо этого мы создадим макросы которые смогут разобрать весь код и заменим парсер на макросы. В общем, вся грамматика (включая базовую) будет описываться декларативно. Это уменьшит количество ошибок, сделает код более декларативным. Позволит автоматически генерировать документацию на синтаксис.

Новые макросы практически полностью снимут ограничения на расширение синтаксиса.

Фактически PegGrammar это прототип новой макро-системы.

Старые же макры будем эмулировать.

А>Понимаю, что ответы на эти вопросы возможно уже есть на форуме, но во первых, не факт что изложенное ранее будет актуальным, а во вторых — хотелось бы увидеть некую выжимку планов по развитию языка/компилятора Nemerlе. Это позволит мне оценить хотя бы примерно возможные сроки по адаптации будущего кода под новую версию языка/комплятора.

Вот здесь

Автор: VladD2
Дата: 17.06.10

есть примерное описание того что планируется на 2.0.

Что до адаптации, то все что пишется на немреле адаптируется к появляющимся изменениям. Если просто следить за проектом, то с адаптацией проблем не будет. Если что мы поможем.

Здравствуйте, <Аноним>, Вы писали:

А>засунув в макросы Nemerle
Это все лучше обсудить на форуме.

А>журналирование, валидацию входящих данных, проверку пред|пост условий, инвариантов, асинхронность и персистентность.
Ибо часть из названного уже есть либо тут есть люди которые могут это сделать/помочь сделать.
Например IT грозится уделать вообще всех

Автор: IT
Дата: 03.11.10

. А к словам автора самой быстрой ОРМ в мире стоит прислушиваться.

А>Вижу дополнительный риск при разработке на Nemerle(помимо ненулевой вероятности ухода Nemerle в небытие, чего искренне надеюсь не случится) —
Не думаю.
К тому же в некоторой степени это компенсируется тем что проект с исходным кодом и под очень либеральной лицензией.

А>масштабные изменения синтаксиса языка в Nemerlе 2.0, ломающие совместимость с предыдущей версией языка/компилятора.
Синтаксис останется тем же.
Обратная совместимость обычного кода будет по максимуму сохранена. Хотя гарантировать точное воспроизведение всех багов нельзя. Даже у мелкософт это не всегда получается.
Будет полностью переделано API компилятора. Как следствие будут сломаны все существующие макросы.
До какой степени сломаны сейчас сказать сложно. Но скорей всего большинство из них можно будет довольно просто починить.

А>1) Какие изменения в языке уже запланированы ?
Очень трудно сказать.
Сейчас идет множество исследовательской работы по результатам которой будут приниматься решения.

А>2) Что не нравится Владу и другим главным разработчикам в текущей версии языка/компилятора,
Студентокод. Из-за этого очень трудно что-то сделать.
Ручной парсер. Очень трудно поддерживать и расширять. Писать макры сильно меняющие синтакс очень сложно.
Медленный и слабый вывод типов. Да я знаю что круче нет но можно.
Кодогенерация через System.Reflection.Emit из-за этого куча проблем включая баги которые мы не можем устранить.

В принципе мне много чего еще не нравится но оно может быть устранено только написанием своей виртуальной машины. Ибо мелкософты сделали .НЕТ очень кривым. Конечно лучше чем жаба но всеравно кривь страшная.

А>чтобы оценить возможные переделки под следующую версию языка/компилятора Nemerle ?
Обычный код должен перенестись без проблем.
Макры придется переделывать. Насколько сильно зависит от макры.

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

VD>В языке особых изменений не планируется. Точно будут дополнения/расширения.
VD>Постараемся сохранить все возможности что были в 1.0. К тому же 1.0 так же будет жить и поддерживаться.

Для меня на самом деле не настолько критично полное сохранение имеющихся недоработок в языке/компиляторе Nemerle 1.0. Важнее — прогнозируемость затрат на изменение кода при переходе на Nemerle 2.0. Или проще говоря — если что-то перестанет работать при переходе на Nemerle 2.0 при уже написанном коде продукта — не критично. Критичнее — прогнозируемость затрат. Также для меня важно стремление коммьюнити Nemerle к чистоте и стройности самого языка, помноженное на реализацию корректного поведения компилятора Nemerle. Т.е. пока коммьюнити Nemerle компактное, а используют сам Nemerle самый смелые и отважные — то от имеющихся костылей в языке/компиляторе имеет смысл избавиться как можно быстрее.
Вот такая вот моя точка зрения.

VD>Вот в API макросов изменения будут точно. Но опят же постараемся сделать так чтобы старые макры тоже работали.

VD>Почти наверняка будут изменяться разные имена имеющие сегодня кривые названия. Но это всего лишь переименование по контексту. На первое время будем водить дубликаты и помечать их как "деприкетед".

Понял. Цена поддержки подобных изменений в использующих Nemerle проектах прогнозируемая и маленькая.

VD>Главным образом сложность разработки нетривиальных макросов и их недостаточная гибкость. На это и будет направлен следующий рализ. Так же не нарвится некоторые непоследовательности в АПИ макросов.

VD>Основное изменение двушки будет замена текущего рукописного парсера на автоматически генерируемый парсер основанный на синтаксических макросах нового поколения. Фактически нового парсера не будет. Вместо этого мы создадим макросы которые смогут разобрать весь код и заменим парсер на макросы. В общем, вся грамматика (включая базовую) будет описываться декларативно. Это уменьшит количество ошибок, сделает код более декларативным. Позволит автоматически генерировать документацию на синтаксис.
VD>Новые макросы практически полностью снимут ограничения на расширение синтаксиса.

Каковы пессимистичные сроки реализации ?

VD>Фактически PegGrammar это прототип новой макро-системы.

VD>Старые же макры будем эмулировать.

Т.е. по факту в рамках одного инсталлятора будет два разных компилятора — старый и новый ? И разработчики на Nemerle смогут выбирать — каким пользоваться ?
В дальнейшем будет развиваться только новый компилятор, чтобы не распылять силы коммьюнити ? Последнее я понимаю и поддерживаю. Подчеркну — прогнозируемость изменений важнее.
С нашей стороны, например, после выхода третьей версии продукта, мы сможем перевести имеющийся код на новый компилятор, потеряв прогнозируемое количество времени(не более 10% времени жизненного цикла разработки новой версии). Такие цифры меня устраивают.


VD>Вот здесь

Автор: VladD2
Дата: 17.06.10

есть примерное описание того что планируется на 2.0.

VD>Что до адаптации, то все что пишется на немреле адаптируется к появляющимся изменениям. Если просто следить за проектом, то с адаптацией проблем не будет. Если что мы поможем.

Большое спасибо за ответ и за предложение помощи.

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

WH>Здравствуйте, <Аноним>, Вы писали:

А>>засунув в макросы Nemerle
WH>Это все лучше обсудить на форуме.

Если будут вопросы — конечно буду задавать

А>>журналирование, валидацию входящих данных, проверку пред|пост условий, инвариантов, асинхронность и персистентность.
WH>Ибо часть из названного уже есть либо тут есть люди которые могут это сделать/помочь сделать.
WH>Например IT грозится уделать вообще всех

Автор: IT
Дата: 03.11.10

. А к словам автора самой быстрой ОРМ в мире стоит прислушиваться.

Спасибо за предложение помощи. К слову — перечисленные мною фичи Nemerle, корректно реализованные, расширяемые под нужды разработчиков на Nemerle и хорошо задокументированные — готовый код на включение в стандартную библиотеку Nemerle.

А>>Вижу дополнительный риск при разработке на Nemerle(помимо ненулевой вероятности ухода Nemerle в небытие, чего искренне надеюсь не случится) —
WH>Не думаю.
WH>К тому же в некоторой степени это компенсируется тем что проект с исходным кодом и под очень либеральной лицензией.

А>>масштабные изменения синтаксиса языка в Nemerlе 2.0, ломающие совместимость с предыдущей версией языка/компилятора.
WH>Синтаксис останется тем же.
WH>Обратная совместимость обычного кода будет по максимуму сохранена. Хотя гарантировать точное воспроизведение всех багов нельзя. Даже у мелкософт это не всегда получается.

Я Владу уже ответил, но повторюсь — сейчас важнее как можно быстрее избавиться от костылей в языке/компиляторе. С прогнозированными затратами использующих Nemerle при переходе на новую версию.

WH>В принципе мне много чего еще не нравится но оно может быть устранено только написанием своей виртуальной машины. Ибо мелкософты сделали .НЕТ очень кривым. Конечно лучше чем жаба но всеравно кривь страшная.

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

А>>чтобы оценить возможные переделки под следующую версию языка/компилятора Nemerle ?
WH>Обычный код должен перенестись без проблем.
WH>Макры придется переделывать. Насколько сильно зависит от макры.

Понял. Спасибо.

Здравствуйте, <Аноним>, Вы писали:

А>Доброго времени суток.

А> Есть коммерческий продукт на C# 3.0, 200+ KLOC, вторая версия.

Оффтопик:

Если не секрет... Можно немножко больше обощенной информации о продукте? Без конкретики: просто предметная область, целевая аудитория (ентерпрайз/десктоп/веб/и т.п), количество пользователей?

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

KV>Здравствуйте, <Аноним>, Вы писали:

А>>Доброго времени суток.

А>> Есть коммерческий продукт на C# 3.0, 200+ KLOC, вторая версия.

KV>Оффтопик:

KV>Если не секрет... Можно немножко больше обощенной информации о продукте? Без конкретики: просто предметная область, целевая аудитория (ентерпрайз/десктоп/веб/и т.п), количество пользователей?

KV>

Финансы. Ентерпрайз/Десктоп. С ходу и не скажу. Надо считать

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

А>Для меня на самом деле не настолько критично полное сохранение имеющихся недоработок в языке/компиляторе Nemerle 1.0. Важнее — прогнозируемость затрат на изменение кода при переходе на Nemerle 2.0. Или проще говоря — если что-то перестанет работать при переходе на Nemerle 2.0 при уже написанном коде продукта — не критично. Критичнее — прогнозируемость затрат. Также для меня важно стремление коммьюнити Nemerle к чистоте и стройности самого языка, помноженное на реализацию корректного поведения компилятора Nemerle. Т.е. пока коммьюнити Nemerle компактное, а используют сам Nemerle самый смелые и отважные — то от имеющихся костылей в языке/компиляторе имеет смысл избавиться как можно быстрее.
А>Вот такая вот моя точка зрения.

Я примерно так же мыслю.

VD>>Основное изменение двушки будет замена текущего рукописного парсера на автоматически генерируемый парсер основанный на синтаксических макросах нового поколения. Фактически нового парсера не будет. Вместо этого мы создадим макросы которые смогут разобрать весь код и заменим парсер на макросы. В общем, вся грамматика (включая базовую) будет описываться декларативно. Это уменьшит количество ошибок, сделает код более декларативным. Позволит автоматически генерировать документацию на синтаксис.
VD>>Новые макросы практически полностью снимут ограничения на расширение синтаксиса.

А>Каковы пессимистичные сроки реализации ?

Загадывать тяжедло. Все зависит от многих фаткоров. Сейчас над PEG-ом (базовой вещью для новой версии) работает один Вольфхауд. Причем делает это в режиме маяка (то потухнет, то погаснет) . Когда он добьет этот макрос мы получим ответы на основные вопросы и сможем оценить время более детально.

Я оцениваю работу в год. Возможно получится значительно быстрее.

Пока что задача зарелизить 1.0. Тут нас сдерживает ряд подпроектов (в основном новая стандартная библиотека и парсер C#).

VD>>Фактически PegGrammar это прототип новой макро-системы.
VD>>Старые же макры будем эмулировать.

А>Т.е. по факту в рамках одного инсталлятора будет два разных компилятора — старый и новый ? И разработчики на Nemerle смогут выбирать — каким пользоваться ?

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

1.0 и 2.0 можно будет ставить параллельно.

А>В дальнейшем будет развиваться только новый компилятор, чтобы не распылять силы коммьюнити ?

Лично мной — да. Но проект открытый. Если кто-то захочет развивать 1.х, то никто против не будт. Плюс будут промежуточные релизы (поддержка .NET 4.0 и VS 2010, например). Они так же (скорее всего) будут иметь версию 1.х.

А>С нашей стороны, например, после выхода третьей версии продукта, мы сможем перевести имеющийся код на новый компилятор, потеряв прогнозируемое количество времени(не более 10% времени жизненного цикла разработки новой версии). Такие цифры меня устраивают.

Думаю, что это более чем реально. 10% — это даже перебор. Думаю 1-2% — более реалистичная оценка. Все же это не с одного языка на другой проект переводить.

Только нужно соблюдать некоторые правила и стараться не лезть в дебри АПИ без нужны. Если стараться использовать квази-цитирование в макросах (вместо прямой работы с АСТ), то их перевод не должен стать очень сложным.

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

А>Мастерство инженера оценивается по умению находить компромисс среди множества противоречивых требований к разрабатываемому изделию в условиях несовершенных инструментов и ограниченности собственных способностей

+100 и без всякой иронии! Намечтать можно черта лысого, а реализовать в разумные сроки и при этом не испортить остальное, вот это реально сложная задача.

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

WH>В принципе мне много чего еще не нравится но оно может быть устранено только написанием своей виртуальной машины. Ибо мелкософты сделали .НЕТ очень кривым. Конечно лучше чем жаба но всеравно кривь страшная.

Извини за офтопик, но ты постоянно пишешь о кривости .NET. Можешь посоветовать что-то прочитать, чтобы я тоже смог увидеть насколько он кривой, или до этого обязательно самому доходить?

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

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

WH>>В принципе мне много чего еще не нравится но оно может быть устранено только написанием своей виртуальной машины. Ибо мелкософты сделали .НЕТ очень кривым. Конечно лучше чем жаба но всеравно кривь страшная.

DR>Извини за офтопик, но ты постоянно пишешь о кривости .NET. Можешь посоветовать что-то прочитать, чтобы я тоже смог увидеть насколько он кривой, или до этого обязательно самому доходить?

Для затравки:
1) тип System.Void просто для виду существует.
2) функциональные типы очень странные — с имененм
3) хвостовую рекурсию разруливает медленно
4) в генриках ограничения неудобные
...

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

VD>Только нужно соблюдать некоторые правила и стараться не лезть в дебри АПИ без нужны. Если стараться использовать квази-цитирование в макросах (вместо прямой работы с АСТ), то их перевод не должен стать очень сложным.

А можно эти правила озвучить ? Или речь идет как раз об использовании в коде макросов только квазицитирования(там где можно обойтись только им) ?

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

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

VD>>Только нужно соблюдать некоторые правила и стараться не лезть в дебри АПИ без нужны. Если стараться использовать квази-цитирование в макросах (вместо прямой работы с АСТ), то их перевод не должен стать очень сложным.

А>А можно эти правила озвучить ? Или речь идет как раз об использовании в коде макросов только квазицитирования(там где можно обойтись только им) ?

Да, речь идет о квазицитировании — пользоваться по возможности стоит только им, чтобы избежать слишком сильной привязки к АПИ компилятора.

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

А>А можно эти правила озвучить ? Или речь идет как раз об использовании в коде макросов только квазицитирования(там где можно обойтись только им) ?

Основное — это соблюдать принцип KISS. Предпочтение квази-цитирования прямому манипулированию структурами данных как раз отвечает этому принципу. Другой пример — не стоит увлекаться сложными решениями, если можно сделать все на базе простой трансформации АСТ и оставить на совести компилятора проверку типов.

Здравствуйте, <Аноним>, Вы писали:

А>Мастерство инженера оценивается по умению находить компромисс среди множества противоречивых требований к разрабатываемому изделию в условиях несовершенных инструментов и ограниченности собственных способностей
Я в курсе.

А>Это я хотел сказать — что своя виртуальная машина, это слишком сурово. Наверняка можно эмулировать нужную функциональность поверх .NET.
Тут возникает куча проблем которые могут быть решены только сильной потерей производительности.
А некоторые вообще не могут быть решены.
Но это уже страшный оффтопик.

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

H>Для затравки:
H>1) тип System.Void просто для виду существует.
H>2) функциональные типы очень странные — с имененм
H>3) хвостовую рекурсию разруливает медленно
H>4) в генриках ограничения неудобные
H>...

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

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

H>>Для затравки:
H>>1) тип System.Void просто для виду существует.
H>>2) функциональные типы очень странные — с имененм
H>>3) хвостовую рекурсию разруливает медленно
H>>4) в генриках ограничения неудобные
H>>...

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

Согласен со всем кроме дженериков.

Я бы выделил еще то, что ВМ ориентирована на ООП. Лучше бы она была чуть менее ООП, но подерживала бы такие фишки как замыкания и функциональные объекты (вместо действительно кривых делегатов).