Собираюсь портировать код с C# и Java на Dart, похоже, придется написать конвертор, чтобы облегчить себе жизнь. Интересно, может ли Немерле/N мне в этом помочь?

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

Попроси Влада дать Н2.
Там это будет сделать относительно легко.
Возможно процентов 30 уже даже ими сделано.

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

A>Собираюсь портировать код с C# и Java на Dart, похоже, придется написать конвертор, чтобы облегчить себе жизнь. Интересно, может ли Немерле/N мне в этом помочь?

Можно, в качестве легкого офтопа, откуда родилась потребность?

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

A>Можно, в качестве легкого офтопа, откуда родилась потребность?

Хочу посмотреть, можно ли наконец-то использовать алгоритмы с интенсивными вычислениями и требованиями к памяти (statistical computations, regressions, machine learning, chemoinformatics, bionformatics algorithms) прямо в браузере. Джаваскрипт просто ужасен по многим причинам, а на Дарте я бы попробовал, приятный язык и я думаю, что него очень светлое будущее. Перевел вчера несколько тысяч строк кода на Дарт, набил себе руку в дартовском синтаксисе и в библиотеках, получил первые обнадеживающие результаты (особенно под Dartium) и теперь хочу хотя бы частичной автоматизации.

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

A>Собираюсь портировать код с C# и Java на Dart, похоже, придется написать конвертор, чтобы облегчить себе жизнь. Интересно, может ли Немерле/N мне в этом помочь?

Как тут правилно заметили, для трансляции языков больше подойдет Nitra. Обращайся на скайп (vc.rsdn.ru). Грамматика для C# есть. Для явы — нет, но создать ее довольно просто.

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

A>Перевел вчера несколько тысяч строк кода на Дарт, набил себе руку в дартовском синтаксисе и в библиотеках, получил первые обнадеживающие результаты (особенно под Dartium) и теперь хочу хотя бы частичной автоматизации.

Из Википедии:

В настоящее время предполагается два способа исполнения Dart-программ: с использованием виртуальной машины или с промежуточной трансляцией в javascript.

Как-то это не похоже на то что может дать хорошую производительность. Что за ВМ они для него сделали?

И не проще ли ту же Яву или Дотнет использовать? По любому код быстрее будет исполняться.

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

VD>И не проще ли ту же Яву или Дотнет использовать? По любому код быстрее будет исполняться.

1. Не факт что быстрее. Dart строго типизирован.
2. Dart работает в любой браузере без доработок, а для той же джавы или нет надо ставить плагины которые в большинстве случаев запрещены. Например у меня в браузере не будет работать ни шарп ни джава.

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

VD>Из Википедии:
VD>

VD>В настоящее время предполагается два способа исполнения Dart-программ: с использованием виртуальной машины или с промежуточной трансляцией в javascript.

VD>Как-то это не похоже на то что может дать хорошую производительность. Что за ВМ они для него сделали?

Их VM пока что работает только в Дартиуме, производительность, грубо говоря, как у джаваскрипта, ну где-то в два раза быстрее. Вот их графики — https://www.dartlang.org/performance/

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

VD>И не проще ли ту же Яву или Дотнет использовать? По любому код быстрее будет исполняться.

Дотнет (в основном C++ для тяжелых вычислений) мы сейчас как раз и используем, но сейчас мне хочется очень странного — чтобы единожды написанный код работал в Chrome на всех платформах, включая мобильные (с прицелом на 2-3 года) и Chromebooks. Отдельного упоминания по этому поводу заслуживает PNaCl, но это тема отдельного топика. Я и сам не уверен, что мне этим следует сейчас заниматься, т.к. от вида джаваскрипта меня подташнивает (Дарт намного лучше, но все равно одного поля ягоды). Тем не менее, исследование я решил продолжить, посмотрим, что получится... я могу ошибаться, но мне кажется, что вся экосистема Chrome (Dart/PNaCl/Chrome-packaged apps) созрела для качественного скачка, Гуглу осталось только объединить разрозненные части в единое целое.

Спасибо за приглашение в скайп, завтра постучусь!

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

А>1. Не факт что быстрее. Dart строго типизирован.

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

Я не разбирался в деталях, но эмпирический опыт меня обычно не подводит.

А>2. Dart работает в любой браузере без доработок,

Как же он работает если он требует VM? Или речь идет о коде преобразованном в JS? Ну, так это будет заведомый тормоз. А ты воде как хочешь быстрый код.

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

Бесплатный сыр бывает только в мышиловке. Поставить яву или дотнет не является проблемой для людей. Сам использую банковскую систему написанную на Яве.

С точки зрения скорости в броузере, на сегодня, это единственное рабочее решение. Ну, и с точки зрения скорости и надежности разработки.

Попробуй просто использовать Немерл или Котлин/Скалу (для Явы). Может это решит твои проблемы. По прозводительности это будет куда лучше Дарта преобразованного в ЖС. И, скорее всего, лучше его ВМ. В будуем, расклад может и изменится. Но пока ты сэкономишь массу времени. А озвученные языки куда мощнее.

Кстати, для генерации ЖС у немерла есть http://www.nemerleweb.com. Очень перспективная штука.

PS

В общем, нам очень даже выгодно, если ты будешь исползовать Nitra/Nemerle для конвретации Шарпа и Явы в Дарт. Постараюсь помочь тебе насколько позволяет время. Так что можешь стучаться мне на скайп (vc.rsdn.ru), я дам тебе текущую версию и консультации. Но сама идея использования Дарта мне кажется стремной. Но настаивать не буду.

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

A>Дотнет (в основном C++ для тяжелых вычислений) мы сейчас как раз и используем, но сейчас мне хочется очень странного — чтобы единожды написанный код работал в Chrome на всех платформах, включая мобильные (с прицелом на 2-3 года) и Chromebooks.

Может тогода было бы разумнее написать генератор для того же http://www.nemerleweb.com? Он и ЖС-версию выдаст (уже умеет) и Драт (если транслятор сделаешь). Там это будет куда проще, чем писать с нуля парсер и конвертер.

A>Отдельного упоминания по этому поводу заслуживает PNaCl, но это тема отдельного топика.

Да, ничего ничего. Для общего развития подобные сведения очень полезны. Так что излагай. Не стесняйся.

A>Я и сам не уверен, что мне этим следует сейчас заниматься, т.к. от вида джаваскрипта меня подташнивает (Дарт намного лучше, но все равно одного поля ягоды). Тем не менее, исследование я решил продолжить, посмотрим, что получится... я могу ошибаться, но мне кажется, что вся экосистема Chrome (Dart/PNaCl/Chrome-packaged apps) созрела для качественного скачка, Гуглу осталось только объединить разрозненные части в единое целое.

Ну, у МС есть Тайпскрипт. Как язык пребразуемый в ЖС он выгдяит очень перспективно. ДжетБрэйнс ему поддержку делает. Так что работать будет удобно.

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

VD>Попробуй просто использовать Немерл или Котлин/Скалу (для Явы). Может это решит твои проблемы. По прозводительности это будет куда лучше Дарта преобразованного в ЖС. И, скорее всего, лучше его ВМ. В будуем, расклад может и изменится. Но пока ты сэкономишь массу времени. А озвученные языки куда мощнее.

Я не аноним, которому ты отвечал, но Немерл и Скала (которую я немного использовал) не помогут — мои проблемы и так решены с помощью C++ и C#, а сейчас вот хочется именно странного. Немерл, кстати, я собирался использовать для построения силверлайт приложений в том же контексте, где я сейчас пробую Дарт, но компиляция в силверлайт так и не появилась, а сейчас уже и сам силверлайт списан в утиль.

VD>Кстати, для генерации ЖС у немерла есть http://www.nemerleweb.com. Очень перспективная штука.

Да, довольно-таки интересная вещь.

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

A>>Я и сам не уверен, что мне этим следует сейчас заниматься, т.к. от вида джаваскрипта меня подташнивает (Дарт намного лучше, но все равно одного поля ягоды). Тем не менее, исследование я решил продолжить, посмотрим, что получится... я могу ошибаться, но мне кажется, что вся экосистема Chrome (Dart/PNaCl/Chrome-packaged apps) созрела для качественного скачка, Гуглу осталось только объединить разрозненные части в единое целое.

VD>Ну, у МС есть Тайпскрипт. Как язык пребразуемый в ЖС он выгдяит очень перспективно. ДжетБрэйнс ему поддержку делает. Так что работать будет удобно.

По сравнению с Дартом, Тайпскрипт у меня не вызывает никакого энтузиазма по следующим причинам:
— ТС — это, грубо говоря, всего лишь типизированный джаваскрипт, что облегчает порог вхождения, но не делает язык хорошим. Как язык, Дарт мне нравится намного больше.
— Потенциал по производительности у Dart VM намного больше, чем у джаваскрипта c его V8, SpiderMonkey и Nitro. Более того, видно, что разработчикам это действительно важно — например, поддержка SIMD появилась уже давно — https://www.dartlang.org/articles/simd/ — да, это камень в сторону .нет.
— ДжетБрейновский WebStorm поддерживает дарт.
— Последняя и, наверное главная причина — гугл кровно заинтересован в разработке инструментвов и экосистем, позволяющих разрабатывать сложные приложения, которые работают на всех системах, и уже имеет платформу для распространения приложений — хром, который работает везде, и PNaCl, которые позволяет запускать нативный код на всех платформах. Смысла же майкрософту развивать тайпскрипт я не вижу никакого, ведь если на нем начнут писать приложения, заменяющие офис и т.д., то это отрицательно отразится на продажах — все перейдут на 200-долларовые хромбуки. Да и, если честно, они исчерпали мой кредит доверия после убийства силверлайта.

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

A>Хочу посмотреть, можно ли наконец-то использовать алгоритмы с интенсивными вычислениями и требованиями к памяти (statistical computations, regressions, machine learning, chemoinformatics, bionformatics algorithms) прямо в браузере.

Native Client не интересовались?

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

A>Немерл, кстати, я собирался использовать для построения силверлайт приложений в том же контексте, где я сейчас пробую Дарт, но компиляция в силверлайт так и не появилась, а сейчас уже и сам силверлайт списан в утиль.

Компиляция в другие рантаймы не появилась, но МС кое-что подкрутил

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

и теперь можно использовать под другими ратнаймами сборки сделанные на десктопе.

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

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

A>>Хочу посмотреть, можно ли наконец-то использовать алгоритмы с интенсивными вычислениями и требованиями к памяти (statistical computations, regressions, machine learning, chemoinformatics, bionformatics algorithms) прямо в браузере.

N>Native Client не интересовались?

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

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

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

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

A>- Потенциал по производительности у Dart VM намного больше, чем у джаваскрипта c его V8, SpiderMonkey и Nitro. Более того, видно, что разработчикам это действительно важно — например, поддержка SIMD появилась уже давно — https://www.dartlang.org/articles/simd/ — да, это камень в сторону .нет.

Потенциал у них одинаков. Если кто-то сделает нативный компилятор ЖС, то он может быть по эффективности аналогичен Яве и Шарпу. Даже, возможно, потенциально побыстрее будет, за счет того, что параметры типов в нем ближе к С++-м шаблонам, нежели к недодженирикам явы. А интерфейсы там вовсе очень грамотно сделаны.

A>- Последняя и, наверное главная причина — гугл кровно заинтересован в разработке инструментвов и экосистем, позволяющих разрабатывать сложные приложения, которые работают на всех системах, и уже имеет платформу для распространения приложений — хром, который работает везде, и PNaCl, которые позволяет запускать нативный код на всех платформах. Смысла же майкрософту развивать тайпскрипт я не вижу никакого, ведь если на нем начнут писать приложения, заменяющие офис и т.д., то это отрицательно отразится на продажах — все перейдут на 200-долларовые хромбуки. Да и, если честно, они исчерпали мой кредит доверия после убийства силверлайта.

Все тоже самое есть у МС. Разве что нет планов создания компиляторов для ТС. Но кто-нить это точно сделает. Глупо не получать выгоду из наличия типов в компайлтайме.

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

VD>Все тоже самое есть у МС. Разве что нет планов создания компиляторов для ТС. Но кто-нить это точно сделает. Глупо не получать выгоду из наличия типов в компайлтайме.

У МС нет
— хрома, которые работает везде
— PNaCl
— самое главное: амбиций и смысла развивать технологии, которые работают на платформах, отличных от Windows.

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

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

Ага, сейчас увидел. Честно говоря я не хочу новый язык с специально под него разработанной VM.
Меня бы больше устроил правильно встроенный и возможно улучшенный JVM (Dalvik?) в котором было бы возможно использовать существующие наработки в Java-based библиотеках и языках (Scala, Clojure, Jython, etc).

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

A>- самое главное: амбиций и смысла развивать технологии, которые работают на платформах, отличных от Windows.

Кстати, пока мы тут вели дискуссии, Гугл, похоже, завершил разработку Oilpan — нового GC для Blink, который в числе прочих вкусностей позволит интегрировать Dart VM в Chrome.
https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6JJroM8aRP49Yf0QWznZ9jrk/mobilepresent#slide=id.p

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

A>Кстати, пока мы тут вели дискуссии, Гугл, похоже, завершил разработку Oilpan — нового GC для Blink, который в числе прочих вкусностей позволит интегрировать Dart VM в Chrome.
A>https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6JJroM8aRP49Yf0QWznZ9jrk/mobilepresent#slide=id.p

Похоже на то, что Гугл открыл для себя не точный GC.

Интересно сколько времени им понадобиться чтобы открыть для себя точный GC и понял, что С++ и GC плохо совместимы?

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

A>По сравнению с Дартом, Тайпскрипт у меня не вызывает никакого энтузиазма по следующим причинам:
...
A>- ДжетБрейновский WebStorm поддерживает дарт.

Он также поддерживает TS.

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

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

Точный GC у них есть внутри V8. Но внутри С++ кода самого браузера точный GC сделать или нельзя, или он будет сильно тормозить.

VD>и понял, что С++ и GC плохо совместимы?

C++ без GC они уже пробовали, получилось плохо. Что предлагаешь, GC без С++? Насколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.

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

DM>Насколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.

А что, есть какие-то принципиальные проблемы сделать браузер на managed? по-моему это просто никому не надо вот и все.

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

V>А что, есть какие-то принципиальные проблемы сделать браузер на managed? по-моему это просто никому не надо вот и все.
Скорость.

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

А>Скорость.
42?

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

V>А что, есть какие-то принципиальные проблемы сделать браузер на managed?

Никаких. Когда-то давно Сан чуть ли не с Явой такой поставлял.

V>по-моему это просто никому не надо вот и все.

Маразм сией ситуации в том, что единственным сдерживающим фактором при применении Явы и Дотнета (упрвляемых сред) являются накладные расходы связанные с GC. И вот Google на очередном витке эволюции переизобретает старое новое.

После перехода на точный GC смысла использовать С++ уже не будет никакого. Накладные расходы будут такими же как в случае Дотнета.

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

V>>А что, есть какие-то принципиальные проблемы сделать браузер на managed? по-моему это просто никому не надо вот и все.
А>Скорость.

Вот точный GC эту скорость и сожрет. Результат будет точно таким же как если бы код был написан на Яве или Дотнете.

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

VD>Маразм сией ситуации в том, что единственным сдерживающим фактором при применении Явы и Дотнета (упрвляемых сред) являются накладные расходы связанные с GC. И вот Google на очередном витке эволюции переизобретает старое новое.
VD>После перехода на точный GC смысла использовать С++ уже не будет никакого. Накладные расходы будут такими же как в случае Дотнета.

Не все так однозначно. Есть еще разница в качестве кодогенераторов. Плюс, С++ дает больше контроля над размещением в памяти, там есть почти бесплатная (де)аллокация на стеке и в аренах. С другой стороны, сейчас там у них использовались смартпоинтеры — по сути медленный и глючный reference counting GC. Сложно предсказать, какой из трех подходов в целом эффективней в их случае:
1) Как было: хороший кодогенератор + медленный и глючный RefCounting GC.
2) Как будет с Oilpan: хороший кодогенератор + пошустрее и не такой глючный tracing GC.
3) Java/Net: слабый кодогенератор и write barriers + эффективный generational tracing GC.

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

VD>Вот точный GC эту скорость и сожрет. Результат будет точно таким же как если бы код был написан на Яве или Дотнете.

Производительность они уже померяли и сошлись на том, что она приемлема (чуть быстрее в одних сценариях, на 10% медленнее в других). Уж насколько я люблю дот-нет, но хром я на нем представить не могу никак, даже оставив в стороне то, что его практически не существует на платформах, отличных от винды. Нафиг-нафиг.

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

DM> асколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.
Разве раст менеджед?

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

DM>C++ без GC они уже пробовали, получилось плохо. Что предлагаешь, GC без С++? Насколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.
Rust — это не managed-язык. Точнее, он managed, но совсем не в стиле Java/.NET

Из всех претендентов у Rust шансы сделать что-то реальное самые высокие. Уже есть прототип engine'а: https://github.com/mozilla/servo

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

По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать
1. Полноценный GC
2. Подсчет ссылок и удаление объектов с нулевыми ссылками. (циклические не удаляются до окончания работы)
3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)

Но Го медленнее С++ примерно в 2 раза, даже без учета проблем с GC. Может потом поправят. Правда с параллельностью там супер.
Вообще один из самых быстрых языков программирования это фортран. Сейчас он даже в парсинге рвет С. Но прогеть на нем... сами понимаете как приятно.

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

DE>Разве раст менеджед?

Не в смысле .Net, но кое-какой GC там имеется.

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

А>По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать
А>1. Полноценный GC
А>2. Подсчет ссылок и удаление объектов с нулевыми ссылками. (циклические не удаляются до окончания работы)
А>3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)

Хм, а где об этом можно почитать? В документации на golang.org ничего подобного я не увидел.
Последнее, что я видел на эту тему в Go, — там был частично консервативный stop-the-world mark-and-sweep GC.

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

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

А>>По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать
А>>1. Полноценный GC
А>>2. Подсчет ссылок и удаление объектов с нулевыми ссылками. (циклические не удаляются до окончания работы)
А>>3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)

DM>Хм, а где об этом можно почитать? В документации на golang.org ничего подобного я не увидел.
DM>Последнее, что я видел на эту тему в Go, — там был частично консервативный stop-the-world mark-and-sweep GC.

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

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

А>По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать
Это неверно. В Go все объекты лежат в общей куче.

А>3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)
Это невозможно, так как горутина может мутировать глобально доступные объекты, добавляя в них ссылки на объекты, созданные в горутине.

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

DE>>Разве раст менеджед?
DM>Не в смысле .Net, но кое-какой GC там имеется.
Он там становится совсем опциональным, хотя на практике ПОЛНОСТЬЮ избежать его использования очень сложно.

Хотя это особо и не надо, так как GC нужен сильно меньше за счёт механизма заимствования указателей и изоляции зелёных потоков.