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

F> Открой для себя WebIDL и обнаруж, что исключительно все интерфейсы — статические, и легко вписываются в систему типов .NET. JS — лиш биндинг к этим интерфейсам и их реализации в движках. В WebKit эти биндинги кстати генерируются автоматически по тем же WebIDL.
Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?

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

А>Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?
Тоже что и в случае с динамикой. Сделать интерфейс, который не будет полагаться на этот метод.
Разница в том, что в случае со статикой мне об этом сразу скажет компилятор, а в случае с динамикой код будет молча глючить.
И такое наблюдалось ни раз и ни сто.

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

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

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

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

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

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

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

F>> Открой для себя WebIDL и обнаруж, что исключительно все интерфейсы — статические, и легко вписываются в систему типов .NET. JS — лиш биндинг к этим интерфейсам и их реализации в движках. В WebKit эти биндинги кстати генерируются автоматически по тем же WebIDL.
А>Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?

var browser90 = browser as IBrowser90;
if (browser90 != null) browser90.blink();

?

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

J>

J>var browser90 = browser as IBrowser90;
J>if (browser90 != null) browser90.blink();
J>

А теперь, допустим версий не две, а десять и браузер не один, а неопределённое количество, которое периодически пополняется. И например есть браузер Y в котором метод тоже реализован, но в версии 15. Как синхронизировать все интерфейсы? и самое главное — чем больше таких кастов тем больше испаряются преимущества статики и проявляются преимущества динамики.

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

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

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

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

А>А теперь, допустим версий не две, а десять и браузер не один, а неопределённое количество, которое периодически пополняется. И например есть браузер Y в котором метод тоже реализован, но в версии 15. Как синхронизировать все интерфейсы? и самое главное — чем больше таких кастов тем больше испаряются преимущества статики и проявляются преимущества динамики.

дык достаточно не по версиям браузеров интерфейсы вводить, а то фичам:

var blinkable = browser as IBlinkable;
if (blinkable != null) blinkable.blink();

теперь неважно в какой версии какого браузера эта фича реализована.

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

А>Кто контролирует API при таком подходе?
Какое отношение API имеет к системе типов.
Правильно. Никакое.

А>кто из производителей браузеров согласится, чтобы ему диктовали API?
А что http://www.w3.org/ уже отменили?

А>Кто из разработчиков захочет пользоваться лишь усреднённым минимумом функциональности?
Все кто хочет, чтобы их сайт адекватно отображался в разных браузерх именно этим и занимаются.
Сам этим маленько занимался.
Проклял их всех.
Ибо во всех браузерах всё работает по-разному.
Полагаться можно только на фичи которым лет 10.

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

А>Система типов потенциально меняется,
Зачем системе типов меняться?

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

А>А теперь, допустим версий не две, а десять и браузер не один, а неопределённое количество, которое периодически пополняется. И например есть браузер Y в котором метод тоже реализован, но в версии 15. Как синхронизировать все интерфейсы? и самое главное — чем больше таких кастов тем больше испаряются преимущества статики и проявляются преимущества динамики.
может я далек от этой темы, но каким образом тип типизации (статическая/динамическая) связан с тем, что вы пишете? ну какие могут быть преимущества у динамики?

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

J>дык достаточно не по версиям браузеров интерфейсы вводить, а то фичам:
Просто мусье теоретик. И ни разу ни чего не верстал.
Ибо если бы верстал то не стал бы тут разводить треп про, то, что в разных браузерх всё работает.

Я когда в яндексе работал (слава байту не на вёрстке) у верстаков видел список браузеров, в которых сервисы яндкса должны работать. Их там было (включая разные версии) меньше десятка.
И это блин в яндексе. С его относительно бесконечными ресурсами.

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

BS>может я далек от этой темы, но каким образом тип типизации (статическая/динамическая) связан с тем, что вы пишете? ну какие могут быть преимущества у динамики?

Тем что в статике требуется полное описание интерфейса и полное описание интерфейса всех параметров всех методов. Если например меняется тип одного из параметров, меняется и интерфейс.

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

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

WH>Какое отношение API имеет к системе типов.
WH>Правильно. Никакое.
В статике тип должен быть полностью описан. В динамике нет. Т.е. если есть несколько реализаций с небольшими отличиями в интерфейсе в динамике это разруливается сравнительно просто. С точки зрения статики это будут просто разные типы, несмотря на то что они "почти" одинаковы.

WH>А что http://www.w3.org/ уже отменили?
А разве фичи в стандарте появляются не после того, как они реализованы практически всеми, но немного по разному?

А>>И самое главное, как это поможет коду использовать по максимуму новые возможности и работать в старых браузерах?
WH>Эти сказки ты рассказывай тому, кто ни разу не пытался сверстать страничку, которая одинаково отображается в разных браузерах.
WH>Я пытался.
Есть такое, я и не отрицаю.

А>>Система типов потенциально меняется,
WH>Зачем системе типов меняться?
Прогресс. Появляются же новые элементы типа video, соответственно и api будет развиваться. как же без этого.

WH>Вот из-за таких может все браузеры, и работают по-разному.
Тут подумалось, что аналогом в статическом мире в какой-то степени может быть компиляция под nix-ы, где хитрые скрпиты пытаются определить окружение и определить правильно макросы/поправить код так чтобы компиляция прошла. В браузерах примерно тоже самое, но разброда ещё больше, проверка окружения перенесена на клиента (ибо больше некуда) ну и обычно требуется работоспособность даже если часть функционала недоступна.

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

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

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

А>Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?
Слушай, ты не задумывался о динамическом связывании? А?
Когда ты зовёшь Win32 CreateFile, — тебя как-то не парит Windows 95 это или Windows 7. Тоже самое происходит в .NET и в любых других _нормальных_ средах. Если произошло ОЙ, то тогда ОЙ. Я ещё раз повторяю, что динамические языки и статические — абослютно равны перед тем вопросом, что ты поставил. При том статические как раз вводят гораздо больше контроля над происходящим, в аккурат на этапе компиляции, а не у клиента в продакшине.
Возвращаясь к

Речь не о нём, а о том что DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

то DocumentImpl работает исключительно CellRangeImpl, ему нет нужны работать с какими-то обобщенными интерфейсами, и возвращать ему их тоже не нужно. Твои ICellRange1/2/3/4/5/10 — есть адаптеры к одной имплементации. Адаптеры вполне в большинстве своём можно генерировать.

Не веришь?

Почитай W3C DOM Level 3/4 specification. Имплементаций DOM — может быть много, а вот выполнить node1.appendChild(node2) возможно только в случае если node2 из той же имплементации (более того, из того же документа), не смотря на то, что обе ноды реализуют один и тот же интерфейс. Интерфейс — это контракт. Интерфейс в стиле современных языков программирования — не описывает его семантику никак, да и врядли сможет. Увы, но да, как раз семантика описывается документом рядом.

Так что то о чём ты говоришь — реально встречающаяся проблема, но ты её явно преувеличиваешь, заодно сюда мешая динамические языки, которые проблему эту не только не решают, а ещё делают хуже. Решение таких проблем — исключительно индивидуально, способ описанный мною — выдуман мною, но вполне жизнеспособен. С другой стороны, если бы я делал свой JS фреймворк (а я делал) — так вот — мне никто не мешает в новой версии переименовать свойство name в displayName — а далее два варианта: а) name — теперь нечто другое б) его вообще не существует. Если будут существовать два интерфейса вроде IItem1/IItem2 — тогда вопросов в статике не будет, а вот в динамике в JS — будут и плачевные.

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

А>Да я совсем не про то что работает, а про то, что при таком разброде невозможно свести всё к статической системе типов. И если даже взять все браузеры и свести сейчас, то через год она опять развалится, потому что каждый вендор наклепает своё.
Невозможно заставить только IE реализовать стандарты — FF и WebKit и о боже Opera! — их реализует в основном без астрономичных нареканий. Вещи которые, извините, всё ещё в working draft — естественно идут с префиксом движка. Ну так это вам не XAML, которых теперь 5 штук, и все разные, причём наглупили в элементарных вещах. А что другого взять с индусятины-теоретиков?

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

А>Кто контролирует API при таком подходе? кто из производителей браузеров согласится чтобы ему диктовали API?

Все. А вот пример диктатора.

А>Кто из разработчиков захочет пользоваться лишь усреднённым минимумом функциональности? И самое главное, как это поможет коду использовать по максимуму новые возможности и работать в старых браузерах?

Единственный способ придуманный для борьбы с разрозненными API — это создание оберток. И совершенно по фиг на чем делать обертки, на динамике или на статике. Какой-нить jquery без проблем мог бы оперировать DOM-ом через 5 разных типизированных API. Главное чтобы можно было добиться требуемой функциональности.

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

А>В статике тип должен быть полностью описан. В динамике нет. Т.е. если есть несколько реализаций с небольшими отличиями в интерфейсе в динамике это разруливается сравнительно просто. С точки зрения статики это будут просто разные типы, несмотря на то что они "почти" одинаковы.

Ты путаешь статику и виды систем типов. В структурной типизации все тоже самое что ты подразумеваешь под динамикой, хотя типизация статическая и строгая.

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

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

Розлин — это закат солнца вручную ручная реализация менеджед-компиляторов C# и VB, а так же движок для IDE написанные на тех самых C# и VB.

Н2 — это мета-средство для создания того же самого для (потенциально) любого языка. Задача сложная, но дающая ряд преимуществ. Создав однажды мета-средство мы резко упрощаем дальнейшую работу. Ну, и пишем мы это все на не C# и VB, а на Немереле и на самом Н2, что резко поднимает производительность. Хотя не скрою, объем работы огромный и нам будет не просто сделать все в срок. Но мы постараемся.

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

Мы не собираемся создавать универсальный движок для всех языков. Мы создаем язык для упрощения реализации других языков. Это не отменяет работу по каждому из языков. Это упрощает эту работу за счет понятия уровня разработки.

R>Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов.

Это не верное утверждение. Парсинг тел методов, конечно же, проходит одновременно с парсингом типов. Вот типизация — другое дело.

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

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

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

На счет "полностью" не согашусь, но таки да — до подстановки параметров типов шаблоны полностью типизировать невозможно. Это беда С++ из-за которой (в том числе) для С++ так и не создано полноценного интеллисенса. Все что есть рано или поздно лажает.

R>А макросы Си/Си++, вообще, ломают все рамки со скобками.

Не знаю причем тут скобки, но таки да, препроцессор С++ — это серьезная проблема. Особенно include и define там очень мешают созданию полноценной поддержки IDE. Но у нас есть кое какие идеи. Так что может и тут удастся создать качественное решение. Хотя С++ для нас пока не приоритет.

R>Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора".

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

R>Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".

Препроцессор и даизайн С++, несомненно, препятствуют созданию качественного интелсенса. Но это общая проблема, а не только наша. Будем ее обходить.

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

С встраиваением одних языков в другие особых проблем нет. Более того Н2 как раз позволит встраивать их без "костылей", т.е. не в виде строк, а как полноценные подязыки. Но и строковые включения можно поддерживать на хорошем уровне (как это сейчас делают IDEA и ReHarper). Ну, а с эвалами ничего не поделать. Если мы не можем вычислить метаданных или предсказать их, то ничего поделать будет нельзя. Но не только нам, но и всем.

R>Там после включения какой-нибудь eval-напичканой библиотечки нужно подрубать искуственный интелект,

ИИ мы разрабатывать пока не будем

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

R>>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?
VD>Розлин — это закат солнца вручную ручная реализация менеджед-компиляторов C# и VB, а так же движок для IDE написанные на тех самых C# и VB.
К розлину уже давно появились средства типа генерации C#-кода который генерирует (? извиняюсь давно видел — могу чуть-чуть сбрехать) AST того же шарпа. Выхлоп этой тулзы превышает раза в 3-4 размер исходного кода. Даже в N1 эта проблема решена квазицитатами и, положа руку на сердце — я бы до квазицитат низашобывжизнисамбынидогадалсябы, но это реально очень красивое решение. Тем не менее у них (МС), насколько я понимаю, всё это остаётся на том самом уровне, где их фреймворк работает, но жизни нихрена не облегчает. Сгенерировать аспекты/классы? Да проще было и без Roslyn взять Mono.Cecil и переписать (rewrite) сборку, нежели трахаться с ихним избортением. Самое главное что это и сейчас остаётся правдой. Когда не было средств типа Cecil/Cci/IKVM — может это и было проблемой, но сейчас — как раз отнюдь никак не проблема.
А N1 уже предлагает совершенно иной подход. Проблемы есть? Есть конечно, но кто ищет — их находит, даже если взглянуть по этому форуму, хотя этот форум скорее для гиков, которые пытаются доработать компилятор. Зато трэды — очень интересные. Год читал форум, N не юзал — в итоге прочитал статьи по N — и понял что они мне уже не шибко полезны. Ну у каждого свой (иногда дурацкий) путь. В любом случае — у N есть открытый жизненный цикл продукта. МС этого никогда и никому не дадут. Те выперхи что они сделали в последнее время — в основном от того, что комьюнити стало больше МС. (ASP.NET WebStack и т.п., да, кстате — почему git? — неужели их расфуфыристая TFS — так плохо подходит?)).
А с Roslyn, скорее всего многие получат фишки кторые ждали, но ещё больше обломаются, когда не найдёт того, чего ждали.

VD>Н2 — это мета-средство для создания того же самого для (потенциально) любого языка. Задача сложная, но дающая ряд преимуществ. Создав однажды мета-средство мы резко упрощаем дальнейшую работу. Ну, и пишем мы это все на не C# и VB, а на Немереле и на самом Н2, что резко поднимает производительность. Хотя не скрою, объем работы огромный и нам будет не просто сделать все в срок. Но мы постараемся.


Еще хочется, пожелать, в зависимости от позиционирования языка — перестать быть зависимым от ненужного. Например использование лямбд на аргументе Predicate<T> — тянет за собой !!!ненужную!!! за собой Nemerle.dll. Если язык хочет быть под .NET — то он его должен утилизировать по полной. А именно, то, что я случайно увидел, навроде открытия нэйспэйсов по умолчанию и типа Some — это ересь, за которую рубить рубить рубить надо нафиг, с какого вообще что-то открывать по дефолту, а если я как раз нехочу этого? А вообще — я хотел сделать проект .NET 2.0 only. Конечно, никто не мешает, не использовать лишнее и референс не попадёт — но — это дурость несусветная, а если удалить референс — у интеграции крыша едет. Незачем на каждую лямбду вместо метода городить отдельный класс, с телом лямбды. Удобно для компиляции? Пусть так. Удобно для пользователей? Отнюдь — этот Function<XXXX> там вообще нафиг не впал, и я не думаю, что кто-нибуль адекватно сможет его объяснить. Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.
В общем — N — хороший язык, действительно решает кучу задач. Но и детских болезней у него капец как много. От глупого IL кода, с теми же def — каждый следующий def что-то не собирается переиспользовать слот вообще — так и в целом встречались. Но, имхо — будет N2 — будут видны планы — будет видно куда двигаться.
Хотите больше пользователей — никаких нахрен зависимостей от Nemerle.dll, по максимуму.
Хотите больше пользователей — дайте контроль, Reference Assemblies пока ещё никто не отменил. :
Хотите больше пользователей — дайте наконец его юзать по полной, а не с теми "стандартными огрызками", которые, мне например, нафиг не впились, и которые вызывают проблемы. Не открывайте нэймспйэсы сами по себе!!! НАФИГ-НАФИГ!!!! ААААААААААААААААААААА!
Стандартная библиотека должна быть подключена только тогда когда это попросит пользователь. Никакого неявного using System C# не делает. А немерле делает. Ф ТОПКУ!!!
[Record] — нафиг. Это дрэг. А особенно с variant-ом.
Код сгенерированный в итоге — не должен содержать ниаких левых аттрибутов. Не нужно аттрибутов, позволяющих восстановить средства его генерации (это кстати о вариантах — варианты — классы — да одно фигня это всё). Короче хрень получается щас, которая иногда друг с другом конфликтует.

С другой стороы — щас опять кодю на шарпе. Не хватает match. Очень и очень. Ну и многого ещё. Но вот стандартной библиотеки Nemerle — как раз очень хорошо, что нет. У меня хватает своих нароботок вообще. Some — это вообще бред в N. option — не бред. А вот реализации — бред. Тут уже обсуждали не раз.

Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.

Знаю, что пахнет негативом, это не со зла, наоборот, хочется большего и лучшего. Кому-то мои замечания покажутся глупыми — кому-то нет. Мне в общем-то всё равно, реальность от этого прямо щас никак не изменится. Просто это реально наболевшие вопросы. И я знаю, что команда RSDN в этом смысле, ни к одной моей претензии не приложила палец, всё конечно же дело в поляках, ну или я буду в это верить.



В любом случае ждём обещанных анонса/отчётов с полей боя о том что нас ждёт в будующем и какую роль в этом всём будет играть N2.
Без этого рассуждения на счет N1 — имхо — безсмысленны.

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

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

F> В любом случае ждём обещанных анонса/отчётов с полей боя о том что нас ждёт в будующем и какую роль в этом всём будет играть N2.
F> Без этого рассуждения на счет N1 — имхо — безсмысленны.
Тут нужно понять что Н2 это не язык общего назначения.
Это язык для создания языков.
Те у тебя будет полный контроль над парсером, типизацией и кодогенерацией.
Не нужен nemerle.dll? Не используй.
Не нужен .НЕТ? Хочешь натив или жабу? Не проблема.
Хочешь компиляцию под несколько платформ? Нивапросваще.

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