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

R>Другими словами как я это переварил, до тех пор пока серъезного продакшина нет, немерля может расти и развиватся. Как она станет кому-то хужна — детство окончено и начинаются трудовые будни. Как у си-плюс-плюса, си-шарпа и прочих взрослых.

Нет. И вот почему. В отличии от сегодняшних шарпов и плюсов немерлу не нужно меняться, чтобы меняться. Немерл 1.х был спроектирован как расширяемый язык. Любой может расширить его написав собственный макрос. Причем любой пользователь может отказаться от использования тех или иных расширений. Для этого ему нужно просто не открывать пространство имен в котором объявлено языковое расширение. Например, ты можешь воспользоваться ХМЛ-литералами, а можешь не делать это и пользоваться Х-линком напрямую.

Именно эту особенность мы и хотим развить в Н2.

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

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

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

Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?

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

Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов. В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.

Хуже с темплейтами, где полностю отсутствует типизация.

А макросы Си/Си++, вообще, ломают все рамки со скобками. Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора". Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".

Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков. Там после включения какой-нибудь eval-напичканой библиотечки нужно подрубать искуственный интелект, способный бороться с Проблемой Остановки. Микрософт, вроде бы, что-то недавно наклепали в Студии недавно на эту тему, чем очень гордились — с деталямия я не знаком, к сожалению.

Промолчу про саму Немерлю, которая хоть и упрощена до нельзя, но стадий компиляции — непочатый край.

Я веду к тому, что весь этот зоопарк не просто разные способы изобразить одно и то же. Может еще Си-шарп, VB.NET, и Жаву можно к общему знаменателю подогнать. Добавь чего-то "нестандартное" и сложность растет экспоненциально.

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

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

I>>А можно поподробней, как удаётся использовать N с C# проeктами.

M>Так я ничего выкрутасного не делаю! Классы-Документы лежат в C# проекте (DLL), он загружается немерлёй, рефлектится вдоль и поперёк и на выходе получаем другой C# проект, в котором построен UI для манипуляции доками. Вот эта генерация других сорсов делается элегантным способом $-строками — намного очевиднее сишарповых стрингбилдеров и форматтеров. Возможно, T4 тоже было бы решением, но его использование было бы угловатым — он больше подходит для задач 1 вход — 1 выход.

Интересная идея. К немерлю только присматриваюсь, думаю было бы и другим интересно посмотреть на тестовый проект как это делаете. Может сделаете маленький пример и зальёте его куда-то.

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

R>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин.
В майкрософт очень не правильно подходят к разработке.
Да и конечный продукт у них будет мягко говоря не о том.

R>Не кажется, что объем работы для Н2 на порядок больше?
Скорее, на порядок меньше.
Но сложнее. Ибо алгоритмы придумывать надо.

R>Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?
Н2 это не язык общего назначения.
Это язык для описания языков. И себя в том числе.
Часть Н2 уже есть. И он уже частично написан сам на себе.
Дальше будет больше.

R>Но, ИМХО, все языки имеют пересечения только с академической точки зрения. Да, концепции типов, переменных, наследования и т.п. довольно похожи друг на друга. Но имплементация компиляторов абсолютно другая.
Это по тому, что руками. А если реализацию компилятора генерировать, то там все будет очень похоже.

R>Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов. В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.
Тут всё намного проще, чем кажется.

R>Хуже с темплейтами, где полностю отсутствует типизация.
Тут ты не прав.
Она хоть и не полная, но она там есть.
То, что обычно разработчики компиляторов ее не осиливают, не значит что, её там нет по стандарту.

R>А макросы Си/Си++, вообще, ломают все рамки со скобками. Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора". Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".
Это должно обрабатываться на уровне препроцессора.
Вот только интелесенсу оно не мешает. Если правильно делать.

R>Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков.
Динамически типизированные языки не нужны.
Вообще.

Они не ловят ошибки. Они тормозят. Для них нельзя сделать нормальный интелисенс.

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

В Н2 будет только 3 стадии.
1)Парсинг.
2)Типизация.
3)Кодогенерация.

R>Я веду к тому, что весь этот зоопарк не просто разные способы изобразить одно и то же. Может еще Си-шарп, VB.NET, и Жаву можно к общему знаменателю подогнать. Добавь чего-то "нестандартное" и сложность растет экспоненциально.
Линейно. Я на эту тему очень много думал и изучал.

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

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

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

R>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?


Roslyn это Nemerle без поддержки удобным языком. То есть получается компилятор, который позволяет встраиваться в разные стадии компиляции, но не имеет языковых средств, типа макросов для удобного применения. Так же отсутствует паттерн матчинг, что делает работу с AST совершенно зубодробительным процессом. Про синтаксические расширения я промолчу, до них майкрософту еще далеко.

Шарп, как он имплементирован сейчас, будет совсем не сложно сделать (то есть транслятор в Nemerle и потом компиляция по его правилам). Другое дело, что спецификация шарпа есть, а немерла нет. И повторить спецификацию шарпа будет не то, что бы сложно, просто очень объемно. JB имеет такие ресурсы, вопрос только в целесообразности.

R>Но, ИМХО, все языки имеют пересечения только с академической точки зрения. Да, концепции типов, переменных, наследования и т.п. довольно похожи друг на друга. Но имплементация компиляторов абсолютно другая.

R>Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов. В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.

У вас очень поверхностное представление о компиляторах.

R>Хуже с темплейтами, где полностю отсутствует типизация.

R>А макросы Си/Си++, вообще, ломают все рамки со скобками. Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора". Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".

Препроцессор естественно нужен (не в темплейтах конечно), а скорость это вопросы оптимизации. Никто не говорил, что супер сложные задачи превратятся в элементарные, они станут просто сложными. Нормальный сенс в С++ получить очень непросто и эту сложность никуда не денешь.

R>Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков. Там после включения какой-нибудь eval-напичканой библиотечки нужно подрубать искуственный интелект, способный бороться с Проблемой Остановки. Микрософт, вроде бы, что-то недавно наклепали в Студии недавно на эту тему, чем очень гордились — с деталямия я не знаком, к сожалению.

Не понял про JS, какие проблемы распарсить eval'ы?

R>Промолчу про саму Немерлю, которая хоть и упрощена до нельзя, но стадий компиляции — непочатый край.

Скажу по секрету, эти стадии в похожем виде есть во всех компиляторах. Просто в Nemerle открыто API для них.

R>Я веду к тому, что весь этот зоопарк не просто разные способы изобразить одно и то же. Может еще Си-шарп, VB.NET, и Жаву можно к общему знаменателю подогнать. Добавь чего-то "нестандартное" и сложность растет экспоненциально.

Это просто инструмент. Применить его к одним языкам будет просто, к другим сложнее. Для одних будет достаточно декларативно задать грамматику, для других придется добавлять препроцессор, для третьих переписывать механизм типизации с нуля, для многих придется писать отдельные бэкенды. Но это все может стать стандартом, как в свое время стали lex&yacc, только еще и для IDE.

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

Z>Roslyn это Nemerle без поддержки удобным языком. То есть получается компилятор, который позволяет встраиваться в разные стадии компиляции, но не имеет языковых средств, типа макросов для удобного применения. Так же отсутствует паттерн матчинг, что делает работу с AST совершенно зубодробительным процессом. Про синтаксические расширения я промолчу, до них майкрософту еще далеко.
Рослин это вообще не о том.
Росли это IDE и компилятор для двух конкретных языков.
Метапрограммирование там сайдэффект. Его никто специально не делал. Ну и получилось то что получилось.

Z>Не понял про JS, какие проблемы распарсить eval'ы?
Такие что я любую IDE для динамически типизированного языка несколькими строками кода могу запутать.

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

R>>Не кажется, что объем работы для Н2 на порядок больше?
WH>Скорее, на порядок меньше.
WH>Но сложнее. Ибо алгоритмы придумывать надо.
Работы намного меньше так какое надо разделять стадии искусствено

WH>Динамически типизированные языки не нужны.
WH>Вообще.

WH>Они не ловят ошибки. Они тормозят. Для них нельзя сделать нормальный интелисенс.
Часто простора написания перевешивает все эти плюсы.

WH>Хотя есть проблемы с тем, чтобы под это дело писать макросы. Эти стадии мне весь мозг уже съели.

WH>В Н2 будет только 3 стадии.
WH>1)Парсинг.
WH>2)Типизация.
WH>3)Кодогенерация.
Зачем их строго разделять?
WH>Линейно. Я на эту тему очень много думал и изучал.
Вряд ли линейно, Просто если у экспоненты маленький коэффициент то такая зависимость станет видна только на неимоверно больших программах.

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

А>Работы намного меньше так какое надо разделять стадии искусствено
Не смог распарсить предложение.

WH>>Они не ловят ошибки. Они тормозят. Для них нельзя сделать нормальный интелисенс.
А>Часто простора написания перевешивает все эти плюсы.
Это, мягко говоря сказки.
Я уже много лет прошу пример, где бы код на динамически типизированном языке был проще.
Неважно насколько любители динамики хотели показать круть динамики, за все эти годы не было ни одного примера, который бы не сводится к "мне так хочется".

WH>>В Н2 будет только 3 стадии.
WH>>1)Парсинг.
WH>>2)Типизация.
WH>>3)Кодогенерация.
А>Зачем их строго разделять?
Ну, попробуй не разделить

А>Вряд ли линейно, Просто если у экспоненты маленький коэффициент то такая зависимость станет видна только на неимоверно больших программах.
Не надо выдумывать экспоненту там, где её нет.

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

WH>Я уже много лет прошу пример, где бы код на динамически типизированном языке был проще.
WH>Неважно насколько любители динамики хотели показать круть динамики, за все эти годы не было ни одного примера, который бы не сводится к "мне так хочется".
Не надо объявлять переменные.

WH>>>В Н2 будет только 3 стадии.
WH>>>1)Парсинг.
WH>>>2)Типизация.
WH>>>3)Кодогенерация.
А>>Зачем их строго разделять?
WH>Ну, попробуй не разделить
Разборка текста зависит от типа объекта. Фактически я не представляю как их можно в рамках Н2 разделить.

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

WH>>Неважно насколько любители динамики хотели показать круть динамики, за все эти годы не было ни одного примера, который бы не сводится к "мне так хочется".
А>Не надо объявлять переменные.
Мегафейспалм.

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

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

WH>Я уже много лет прошу пример, где бы код на динамически типизированном языке был проще.

Возьмём например продукт типа Excel, который предоставляет интерфейс IDocument, который содержит экзмепляры ISpreadsheet, которые содержат ICell и т.д. И вот появляется версия 2.0 в которой добавилась новая функциональность в компоненты и появлись расширенные интерфейсы — IDocument2, ISpreadsheet2 и прочие. В строго типизировнном мире сразу возникают проблемы — IDocument.GetSpreadsheet возвращает ISpreadsheet, IDocument2.GetSpreadsheet — ISpreadsheet2 — теперь дублировать кучу методов в реализации? а когда появится версия 3? Какой-нибудь ISpreadsheet.MergeCells будет хотеть не ICellRange,а ICellRange2 — писать перегрузки под все типы?

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

Вовсе не обязательно плодить новые интерфейсы, если они только лишь расширяются, по крайней мере в мире .NET.
Кроме того, если уж и случаются breaking changes — можно и перекомпилировать клиентский код.
Это будет всяко лучше, чем внезапно глюкающий код, который знать ничего не знает о изменениях, но упорно продолжает делать вид, что работает.
В любом раскладе проблема сама по себе никуда не исчезнет, оттянется только время её обнаружения.

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

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

F>Вовсе не обязательно плодить новые интерфейсы, если они только лишь расширяются, по крайней мере в мире .NET.
Можно соорудить сборку 2.0, но интерфейсы версии 1.0 должны работать, и интерфейс из сборки 2.0 как бы не равен интерфейсу из сборки 1.0 даже если у них и сохранено название.

F>Кроме того, если уж и случаются breaking changes — можно и перекомпилировать клиентский код.
Про breaking changes речь не идёт. Просто о проблемах статической системы типов при появлении новых версий, если требуется обеспечить работу старых.

Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам), статическим он, мне кажется, не мог бы быть принципиально.

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

А>Про breaking changes речь не идёт. Просто о проблемах статической системы типов при появлении новых версий, если требуется обеспечить работу старых.
Нет таких проблем. Ты их придумал.
Ибо сколько я видел IDocument2 и компанию они все наследовались от IDocument.
А если говорить не про кривущий СОМ, а про несколько более прямой .НЕТ то там даже наследников создавать не нужно.
Просто добавляем методы и вперед.
Если клиент не использует новые методы, то он и не заметит что что-то поменялось.

А>Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам),
Хуже примера ты придумать не мог.
Ибо в результате любой код на нем нужно тестировать во ВСЕХ браузерах.
Либо делать компилятор нормального языка в жабаскрипт чтобы он все проблемы всех браузеров обходил.

А>статическим он, мне кажется, не мог бы быть принципиально.
Мог.
Жаба работает. .НЕТ тоже.
И проблем бы было намного меньше.

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

WH>>Я уже много лет прошу пример, где бы код на динамически типизированном языке был проще.
WH>>Неважно насколько любители динамики хотели показать круть динамики, за все эти годы не было ни одного примера, который бы не сводится к "мне так хочется".
А>Не надо объявлять переменные.

Реально у динамики есть только два преимущества:
1. Легкость в реализации полиморфизма (он сам собой получается).
2. Интерактивность разработки.

Оба пункта достижимы и в статике, но их значительно сложнее реализовать.

WH>>>>В Н2 будет только 3 стадии.
WH>>>>1)Парсинг.
WH>>>>2)Типизация.
WH>>>>3)Кодогенерация.
А>>>Зачем их строго разделять?
WH>>Ну, попробуй не разделить
А>Разборка текста зависит от типа объекта. Фактически я не представляю как их можно в рамках Н2 разделить.

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

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

WH>Ибо сколько я видел IDocument2 и компанию они все наследовались от IDocument.
Наследовались, но изменение нарпример ICellRange на ICellRange2 требует изменения всех испольюзующих его контрактов, при этом старые контракты должны оставаться актуальными.

WH>Если клиент не использует новые методы, то он и не заметит что что-то поменялось.
У него старая интерфейсная сборка. Вам же не понравится еслм ваше приложение осуществляющее экспорт в эксель 2000 не будет работать с экселем 2001.

А>>Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам),
WH>Хуже примера ты придумать не мог.
WH>Ибо в результате любой код на нем нужно тестировать во ВСЕХ браузерах.
нужно. Я же прекрасно понимаю в чём минусы динамики, но стараюсь назло тебе найти плюсы

WH>Либо делать компилятор нормального языка в жабаскрипт чтобы он все проблемы всех браузеров обходил.
И какая система типов была бы у этого языка? Сейчас конечно стандартизацию вроде как ускорят, но в любом случае реализация каждой новой фичи будет варьироваться во всех браузерах. т.е. именно в динамической развивающейся среде у статики, имхо, начинаются серьёзные проблемы.

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

F>>Вовсе не обязательно плодить новые интерфейсы, если они только лишь расширяются, по крайней мере в мире .NET.
А>Можно соорудить сборку 2.0, но интерфейсы версии 1.0 должны работать, и интерфейс из сборки 2.0 как бы не равен интерфейсу из сборки 1.0 даже если у них и сохранено название.
Это ты придумал, нет такой проблемы.

А>Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам), статическим он, мне кажется, не мог бы быть принципиально.
Открой для себя WebIDL и обнаруж, что исключительно все интерфейсы — статические, и легко вписываются в систему типов .NET. JS — лиш биндинг к этим интерфейсам и их реализации в движках. В WebKit эти биндинги кстати генерируются автоматически по тем же WebIDL.

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

WH>>Ибо сколько я видел IDocument2 и компанию они все наследовались от IDocument.
А>Наследовались, но изменение нарпример ICellRange на ICellRange2 требует изменения всех испольюзующих его контрактов, при этом старые контракты должны оставаться актуальными.
CellRangeImpl имплементит и то и другое. Методам которые работают с CellRangeImpl — глубоко пофиг через какой интерфейс их позвали. Интерфейсы все эти — лиш адаптеры к реальным объектнам. Так, что тут ты преувеличиваешь. Разумеется эти адаптеры в большинстве случаев можно генерировать. Да, это само по себе не даётся, — но и в динамике это тоже само по себе не даётся.

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

F> CellRangeImpl имплементит и то и другое. Методам которые работают с CellRangeImpl — глубоко пофиг через какой интерфейс их позвали.
Речь не о нём, а о том что DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.