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

V>>>Они выигрывали раньше, потому что для компиллируемых не было поддержки IDE.
V>>>В отсутствии поддержки IDE рулил подход REPL, ОК.
V>>>В присутствии же нормальной IDE такой подход становится нелеп, архаичен, подлежит списанию в утиль.
S>> Угу. При этом питоном бользуется большая часть сишников.

V>Для малюсеньких утилитных задач, вместо еще более ограниченного bash или виндового cmd.
V>Легкость "написал-запустил" должна жить ровно там, где ей и положено — в несложной автоматизации рутинных операций.
V>Но тут же речь идёт о том, чтобы писать на скрипте большие системы.
V>А это уже очевиднейшая инженерная ошибка.

Так и здесь нужно небольшой код использовать. Никио не собирается веь код на динамиках.

V>Причем, на 1C хотя бы из нейтива идёт ОЧЕНЬ много прикладного проблемно-ориентированного функционала, а на JS — аж нихрена, только базовые библиотеки. Весь проблемно-ориентированный код предлагается писать ручками.
V>А вот это уже ой.

Если мы говорим про TS и Angular 2. Там куча библиотек.
А динамика нужна там, где с типизацией нужно кучу оберток делать.
Как правило это небольшой объем кода.



V>Да, периодически "конфигурации" 1C выдают ошибки именно у клиента.
V>Тоже мне новость.

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

V>>>Я уже отвечал тебе, что до тех пор, пока такая аннотация опциональна, это всё равно, что её нет.
S>> То есть TS не нужен, Ты расписываешь про типизацию, но если она опциональна, то есть она и не нужна!!

V>Верно. Опциональная типизация не нужна.
V>Для сравнения в строго-типизированных языках "опциональная типизация" означает использование автовывода типов без вот этой "дыры" в смысле fallback до any. В TS содержится дыра.

Ну дык и C# с динамиками тоже опциональна. Да и Object тоже.
По твоей логике C# и Java не нужны.

S>> При этом большая часть ошибок ловится на стадии даже не компиляции в отличие от С++, а на стадии проектирования. Ускоряется безошибочный ввод кода.

V>Опять бла-бла-бла.
V>Ты с кем тут споришь? Сам с собой? Оставить тебя наедине? ))
Ну ты же говоришь, что TS не нужен ибо типизация опциональна.




V>Ладно бы взять TS для продолжения уже имеющегося проекта, тут вопрос "одно лучше другого" при сохранении обратной совместимости прокатывает, ОК.
V>Но когда кто-то говорит о НОВЫХ больших проектах на TS — сорри, это уже клиника.

А на чем предлагаешь делать?
То есть куча Web программистов использующих Angular 2 это больные люди?

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

I>>>Судя по твоим предыдущим "тестам", от тебя ожидать можно всего угодно. Как то так.
_>>Вообще то как раз именно этот тест подробно разбирался на форуме, в том числе и вместе с одним из лучших экспертов по C#. И ни единой претензии к нему не было. Так что это ты в очередной раз соврал со вполне понятной целью — если даже ложки и найдутся, то осадок останется. ) Короче сливаться ты стал совсем банально.
I>В твоем тексте никаких подробностей нет, кроме таблички. После твоих 'тестов' баз данных я тебе просто не верю.

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

I>>>Я в курсе, что ты тащишь С++ во все темы.
_>>Так а почему бы его не притащить в тему про "замену js", если C++
I>До свидания.

Если сливаешься, то лучше делай это молча. )

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

_>>Ну так если превращается в абсолютного новичка, то это же как раз означает, что никак навыков из C++ ему в Java перетащить не удастся. Что напрямую противоречит твоему изначальному утверждению. )))
I>Наоборот. Это в джаве он новичок. Соответственно, будет пытаться ехать на старом опыте. Например, я уже говорил, память он продолжает использовать как сиплюсник — пытается всё руками контролировать, но при этом не знает ничего про неявно создаваемые объекты и тд.

Ну так и как он будет контроливать память в Java? Ты покажи конкретный пример кода... Вот для обратной ситуации я вполне могу привести примеры (типичный Java код легко остаётся валидным и на C++, только при этом является не эффективным). А для твоего варианта пока ни одного примера не видел.

I>Типичный сиплюсник например вместо внятного ORM выберет какой нибудь jdbc просто потому, что опыта работы с ORM нет (чего ты сам продемонстрировал). С точки зрения С++ разработчика ОРМ это дико тормозная и абсолютно не нужная вещь.

О, т.е. один из навыков работы на C++ — это не использование ORM. Какие у нас тут очаровательные факты то открываются...

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

I>>В твоем тексте никаких подробностей нет, кроме таблички. После твоих 'тестов' баз данных я тебе просто не верю.

_>Угу, никаких подробностей, не считая только прямо самого работающего теста на JS. Похоже что тебя надо учить пользоваться функцией просмотра исходников в браузере...

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

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

_>>>Так а почему бы его не притащить в тему про "замену js", если C++
I>>До свидания.

_>Если сливаешься, то лучше делай это молча. )

Я напомню, что была речь про 'Питон тормоз по сравнению с JS'. Смотри, чего ты пишешь

> Не тормоз, а всего на десятки процетов
> Не тормоз, потому что C# vs Java тоже десятки процентов
> Не тормоз, потому что С++ vs `остальные языки` огого

Ты всерьез это аргументами считаешь ?

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

I>>Наоборот. Это в джаве он новичок. Соответственно, будет пытаться ехать на старом опыте. Например, я уже говорил, память он продолжает использовать как сиплюсник — пытается всё руками контролировать, но при этом не знает ничего про неявно создаваемые объекты и тд.

_>Ну так и как он будет контроливать память в Java? Ты покажи конкретный пример кода...

Зачем ?

I>>Типичный сиплюсник например вместо внятного ORM выберет какой нибудь jdbc просто потому, что опыта работы с ORM нет (чего ты сам продемонстрировал). С точки зрения С++ разработчика ОРМ это дико тормозная и абсолютно не нужная вещь.

_>О, т.е. один из навыков работы на C++ — это не использование ORM. Какие у нас тут очаровательные факты то открываются...

Это одна из особенностей. Ты, например, демонстрировал это в течении нескольких месяцев, после чего люди объясняли тебе же как работает твой недо-ОРМ и какие с ним проблемы.

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

_>>Угу, никаких подробностей, не считая только прямо самого работающего теста на JS. Похоже что тебя надо учить пользоваться функцией просмотра исходников в браузере...
I> Думаешь, одного результата хватит, что бы убедиться в достоверности остальных результатов ? Какие подробности должны намекнуть, что с таблицей все в порядке ?

Проверь сам, если сомневаешься)))

_>>Если сливаешься, то лучше делай это молча. )
I>Я напомню, что была речь про 'Питон тормоз по сравнению с JS'. Смотри, чего ты пишешь
I>

>> Не тормоз, а всего на десятки процетов
>> Не тормоз, потому что C# vs Java тоже десятки процентов
>> Не тормоз, потому что С++ vs `остальные языки` огого

I>Ты всерьез это аргументами считаешь ?

Причём тут аргументы? Никто не спорил с тем, что Питон обычно медленнее JS раза в полтора. Вопрос в том насколько принципиальна такая разница в быстродействие — это уже вопрос личных вкусов. Ты выразил это фразой "убогий тормоз". Ну ОК, это твоё право. Только в таком случае и тот же C# заслуживает аналогичного эпитета. И все они вместе вообще невообразимые тормоза в сравнение с C++. Я в целом не против такой системы координата — это твоё личное дело, только надо тогда быть последовательным... )))

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

I>>>Наоборот. Это в джаве он новичок. Соответственно, будет пытаться ехать на старом опыте. Например, я уже говорил, память он продолжает использовать как сиплюсник — пытается всё руками контролировать, но при этом не знает ничего про неявно создаваемые объекты и тд.
_>>Ну так и как он будет контроливать память в Java? Ты покажи конкретный пример кода...
I>Зачем ?

Чтобы не оказаться болтуном в глазах всего форума. )))

I>>>Типичный сиплюсник например вместо внятного ORM выберет какой нибудь jdbc просто потому, что опыта работы с ORM нет (чего ты сам продемонстрировал). С точки зрения С++ разработчика ОРМ это дико тормозная и абсолютно не нужная вещь.
_>>О, т.е. один из навыков работы на C++ — это не использование ORM. Какие у нас тут очаровательные факты то открываются...
I>Это одна из особенностей. Ты, например, демонстрировал это в течении нескольких месяцев, после чего люди объясняли тебе же как работает твой недо-ОРМ и какие с ним проблемы.

Ой, так оказывается C++'ки всё же предпочитают пользоваться ORM? Как же так? Ты же ведь только что утверждал обратное... )

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

V>>Да, периодически "конфигурации" 1C выдают ошибки именно у клиента.
V>>Тоже мне новость.
S>Ну если не делать тесты, то и от логических ошибок никто не застрахован.

Предлагаешь обсуждать банальности? ))
Вероятность чисто логических ошибок и там и там одинакова.
Речь не про ошибки в логике.


S>Ну дык и C# с динамиками тоже опциональна.

Не опционально, надо явно указывать, что это dynamic. Никакого автоматического fallback до object или dynamic в случае автовывода типов не будет, будет ошибка компиляции.


S>Да и Object тоже.

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

Даже от reflection, считай, уже отказываются.
К примеру в .Net Netive.


S>По твоей логике C# и Java не нужны.

Это тебе захотелось так допилить мою логику.


V>>Ты с кем тут споришь? Сам с собой? Оставить тебя наедине? ))
S>Ну ты же говоришь, что TS не нужен ибо типизация опциональна.

Верно, но ты не хочешь обсуждать последствия опциональности типизации. Тебе хочется перескочить этот момент и сразу перейти к тому месту, где тебе нравится показывать преимущества TS над JS. И я уже порядком устал, если честно, напоминать тебе, что я НЕ спорю с тем, что TS лучше JS. Я лишь утверждаю, что оба негодны.


V>>Ладно бы взять TS для продолжения уже имеющегося проекта, тут вопрос "одно лучше другого" при сохранении обратной совместимости прокатывает, ОК.
V>>Но когда кто-то говорит о НОВЫХ больших проектах на TS — сорри, это уже клиника.
S> А на чем предлагаешь делать?
S>То есть куча Web программистов использующих Angular 2 это больные люди?

Есть Angular 2 для Dart, что мешает?
Ты только вдумайся, если сейчас начинается некий проект, он несколько месяцев-год делается, а потом должен еще хотя бы лет 5-7 прожить. Это чудовищная ошибка сейчас закладывать в проект мину, основанную в базе на всё том же JS.

Ведь не проблема была бы в некоем TS сделать нормальную типизацию. Это, как раз, не сложно. Фишка ведь в том, что имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.

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

_>>>Угу, никаких подробностей, не считая только прямо самого работающего теста на JS. Похоже что тебя надо учить пользоваться функцией просмотра исходников в браузере...
I>> Думаешь, одного результата хватит, что бы убедиться в достоверности остальных результатов ? Какие подробности должны намекнуть, что с таблицей все в порядке ?

_>Проверь сам, если сомневаешься)))

Так где подробности ?

_>>>Если сливаешься, то лучше делай это молча. )
I>>Я напомню, что была речь про 'Питон тормоз по сравнению с JS'. Смотри, чего ты пишешь
I>>

>>> Не тормоз, а всего на десятки процетов
>>> Не тормоз, потому что C# vs Java тоже десятки процентов
>>> Не тормоз, потому что С++ vs `остальные языки` огого

I>>Ты всерьез это аргументами считаешь ?

_>Причём тут аргументы? Никто не спорил с тем, что Питон обычно медленнее JS раза в полтора. Вопрос в том насколько принципиальна такая разница в быстродействие — это уже вопрос личных вкусов. Ты выразил это фразой "убогий тормоз". Ну ОК, это твоё право. Только в таком случае и тот же C# заслуживает аналогичного эпитета. И все они вместе вообще невообразимые тормоза в сравнение с C++. Я в целом не против такой системы координата — это твоё личное дело, только надо тогда быть последовательным... )))

Это ты мне отомстить за Питон что ли хотел и решил про C# выдать непойми что ? Так я на JS пишу Чего сказать хотел ?

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

_>>>Ну так и как он будет контроливать память в Java? Ты покажи конкретный пример кода...
I>>Зачем ?

_>Чтобы не оказаться болтуном в глазах всего форума. )))

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

I>>Это одна из особенностей. Ты, например, демонстрировал это в течении нескольких месяцев, после чего люди объясняли тебе же как работает твой недо-ОРМ и какие с ним проблемы.

_>Ой, так оказывается C++'ки всё же предпочитают пользоваться ORM? Как же так? Ты же ведь только что утверждал обратное... )

Экспериментальный Недо-ОРМ совсем не орм. Его автор так и сказал. Более того, им никто всерьез и не пользуется, поскольку слишком экспериментальный.

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


S>>Ну дык и C# с динамиками тоже опциональна.

V>Не опционально, надо явно указывать, что это dynamic. Никакого автоматического fallback до object или dynamic в случае автовывода типов не будет, будет ошибка компиляции.

И в чем разница? Опять же настраивай компилятор и посыпятся ошибки.

S>>Да и Object тоже.

V>Но ты не можешь вызывать никакие методы целевого объекта через Object, в этом смысл.
V>Сначала приведи к нужному типу, потом вызывай, если такое приведение было успешным.
V>Подобных ср-в в TS нет и быть не может.

А с dynamic могу

V>Даже от reflection, считай, уже отказываются.
V>К примеру в .Net Netive.
Нет не отказались. Просто нужно указать к каким типам применяется рефлексия, так как нет динамической компиляции.
https://msdn.microsoft.com/ru-ru/library/dn600638(v=vs.110).aspx

S>>По твоей логике C# и Java не нужны.

V>Это тебе захотелось так допилить мою логику.

Ну как же тебя понять если ты за строгую типизацию. А Java и C# таковыми не являются иобо приведение типа может вызывать исключения.
V>>>Ты с кем тут споришь? Сам с собой? Оставить тебя наедине? ))
S>>Ну ты же говоришь, что TS не нужен ибо типизация опциональна.

V>Верно, но ты не хочешь обсуждать последствия опциональности типизации. Тебе хочется перескочить этот момент и сразу перейти к тому месту, где тебе нравится показывать преимущества TS над JS. И я уже порядком устал, если честно, напоминать тебе, что я НЕ спорю с тем, что TS лучше JS. Я лишь утверждаю, что оба негодны.

У меня включена опция определения типа. Так что у меня типизация присутствует и я где тип неопределен пишу any.

V>>>Ладно бы взять TS для продолжения уже имеющегося проекта, тут вопрос "одно лучше другого" при сохранении обратной совместимости прокатывает, ОК.
V>>>Но когда кто-то говорит о НОВЫХ больших проектах на TS — сорри, это уже клиника.
S>> А на чем предлагаешь делать?
S>>То есть куча Web программистов использующих Angular 2 это больные люди?

V>Есть Angular 2 для Dart, что мешает?
V>Ты только вдумайся, если сейчас начинается некий проект, он несколько месяцев-год делается, а потом должен еще хотя бы лет 5-7 прожить. Это чудовищная ошибка сейчас закладывать в проект мину, основанную в базе на всё том же JS.

И чем Dart лучше TypeScript? И используют именно TS а не Dart ибо у TS больше премуществ. А на голом JS пишут только те, кто хочет стрелять себе в ногу.
Рассматривай JS как ассемблер для TS и Dart

Кстати в том же dart есть о Object и dynamic
https://www.dartlang.org/articles/language/optional-types

Object lookup(String key) { /* ... */ } // a lookup method in a heterogenous table
String s = lookup('Frankenstein');

[/q]
Of course, if you don’t use types at all, checked mode won’t get in your way.
[/q]

my_add(s1, s2) {
  return s1 + s2;
}

my_add(3, 4); // 7
my_add(new Point(3, 3), new Point(4, 4)); // Point(7, 7)

В дарте тоже типизация опциональна.

If we are correct in our assumption that the lookup returns a string, checked mode will execute smoothly. If we’re wrong, it will catch our mistake for us. In production mode, the code will run without complaint. Assume the lookup actually returns an object that isn’t a string, say an instance of class Frankenstein. The variable s will contain that instance. In no case will Dart do a magical coercion into a string. If it did, that would mean the type annotation was modifying the behavior of our program, and types would not be optional anymore.

V>Ведь не проблема была бы в некоем TS сделать нормальную типизацию. Это, как раз, не сложно. Фишка ведь в том, что имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
Это зависит от программиста. Еще раз TS позволяет писать строго типизированные приложения с автоматическим выводом типа для результата функций и тд.
И ничем он не хуже того же C#.
Например никто же на C# не использует динамики напрополую. Только там где это необходимо. Так же и в TS.

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

S> Ну как же тебя понять если ты за строгую типизацию. А Java и C# таковыми не являются иобо приведение типа может вызывать исключения.
Это то тут причём? Любой "dynamic cast" можно реализовать на самопальных enum ObjectType и виртуальном Object::GetType(), при этом заметь, если при попытке каста нам попался непонятный ObjectType — получаем то самое исключение. Для этого не нужно со стороны языка/рантайма поддержка RTTI.

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

I>В джаве много чего не взлетело и что с того?
С того, что WASM пока не дает ничего нового по сравнению с jvm applets. Все или так же или хуже.

I>Байндинги прокидывать достаточно легко. Речь не только про интеграцию с объектами браузера. Нужно общее решения и для секурити, и для общего хипа и тд и тд.
Байндинг к сущностям плюсов делается легко, а тут будет слойка с двумя GC и wasm-ом между ними. Я имел удовольствие поработать на проекте где в одном процессе крутился jvm и .net — удовольствие ниже среднего.

I>Фактически, wasm дает делает браузер полноценной платформой.
Это будет, только если WASM обретет VM без браузера. ИМХО так и надо было делать. Сначала просто VM с CoreAPI, потом: tracking GC, интеграция в браузер с DOM API, прочие языки (включая JS).

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

S> Если мы говорим про TS и Angular 2. Там куча библиотек.
S>А динамика нужна там, где с типизацией нужно кучу оберток делать.
S>Как правило это небольшой объем кода.

все вы так говорите.
Типичный говнокодер Тут нам слишком много писать, поэтому мы подставим костыль — так быстрее. Куда тебе до больших проектов...

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

_>>Проверь сам, если сомневаешься)))
I>Так где подробности ?

В описание моих тестов была ссылка на работающий прямо на страничке JS тест. Открываешь его исходник и видишь функцию Update — это по сути и есть весь тест, остальное мишура. И этот тест в силу свой простоты записывается практически одинаково на большинстве императивных языков. Разве что есть разница в том, что в нормальных языках там вокруг этой функции стоит бесконечный цикл, а в убогом однопоточном JS приходится вызывать её по таймеру, но на измерения это никак не влияет. Кстати, WASM вариант пока ещё тоже через тот же таймер работает, но это (вместе с SIMD) у них стоит в приоритете на разработку (http://webassembly.org/docs/future-features/), так что уже скоро WASM станет действительно почти как нативный код. Ну да ладно, это я что-то отвлёкся. Так вот, берёшь этот простейший алгоритм, переписываешь его под все нужные языки, собираешь правильно (не забудь использовать максимальные опции оптимизации на каждой целевой платформе), тестируешь и потом сраниваешь с моим результатом. )))

_>>Причём тут аргументы? Никто не спорил с тем, что Питон обычно медленнее JS раза в полтора. Вопрос в том насколько принципиальна такая разница в быстродействие — это уже вопрос личных вкусов. Ты выразил это фразой "убогий тормоз". Ну ОК, это твоё право. Только в таком случае и тот же C# заслуживает аналогичного эпитета. И все они вместе вообще невообразимые тормоза в сравнение с C++. Я в целом не против такой системы координата — это твоё личное дело, только надо тогда быть последовательным... )))
I>Это ты мне отомстить за Питон что ли хотел и решил про C# выдать непойми что ? Так я на JS пишу Чего сказать хотел ?

Нет, просто на мой вкус термин "убогий тормоз" при сравнение Pyhton и JS неуместен. На мой взгляд эти языки относятся к одному классу по производительности. И весь этот класс является "убогим тормозом" по отношению к скажем C++. Причём данный факт абсолютно нормален для той ниши, которую занимают эти языки.

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

I>>>Зачем ?
_>>Чтобы не оказаться болтуном в глазах всего форума. )))
I>У тебя целая ссылка примеров.

У тебя была ссылка с примерами плохого Java кода. Только вот непонятно какое отношение эти примеры имеют к написанию ПО в стиле современного C++.

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

Ну т.е. примеров плохого кода на Java, написанного в стиле C++, не будет? )

I>>>Это одна из особенностей. Ты, например, демонстрировал это в течении нескольких месяцев, после чего люди объясняли тебе же как работает твой недо-ОРМ и какие с ним проблемы.
_>>Ой, так оказывается C++'ки всё же предпочитают пользоваться ORM? Как же так? Ты же ведь только что утверждал обратное... )
I>Экспериментальный Недо-ОРМ совсем не орм. Его автор так и сказал. Более того, им никто всерьез и не пользуется, поскольку слишком экспериментальный.

Что-то запутался в твоих теориях. ))) Так что именно по твоему является характерным свойством C++'ов, желание использовать инновационные ORM или что? )))

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

I>>В джаве много чего не взлетело и что с того?
N>С того, что WASM пока не дает ничего нового по сравнению с jvm applets. Все или так же или хуже.

Как минимум лучше отсутствием привязки к той самой JVM. )))

I>>Байндинги прокидывать достаточно легко. Речь не только про интеграцию с объектами браузера. Нужно общее решения и для секурити, и для общего хипа и тд и тд.
N>Байндинг к сущностям плюсов делается легко, а тут будет слойка с двумя GC и wasm-ом между ними. Я имел удовольствие поработать на проекте где в одном процессе крутился jvm и .net — удовольствие ниже среднего.

Ой, вот только не стоит сравнивать подобные вещи. Интеграция например Python'а и C++ кода — это идеально проработанный и прозрачный механизм, который является не какой-то экзотикой, а является основной работы множества крупных проектов. Так что тут не просто всё хорошо и уже прямо сейчас (!) готово к использованию, а можно сказать всё великолепно. ))) И для многих других скриптовых языков ситуация аналогичная. Что же касается интеграции с браузером и его GC, то тут конечно всё сложнее и требуется разработка с нуля (благо этим занимаются не энтузиасты, а специалисты на зарплате, причём из команд разработки ведущих браузеров). И по некоторым данным возможно там будет использоваться новое нативное API (в котором никакого GC просто не надо).

I>>Фактически, wasm дает делает браузер полноценной платформой.
N>Это будет, только если WASM обретет VM без браузера. ИМХО так и надо было делать. Сначала просто VM с CoreAPI, потом: tracking GC, интеграция в браузер с DOM API, прочие языки (включая JS).

Так как раз всё именно таким образом и сделано. Т.е. платформа WASM вполне отделена от браузера и имеет свою отдельную спецификацию. Более того, разработчики не только предоставляю готовую библиотечку для встраивания исполнителя WASM в своё приложение, но и даже в их наборе инструментов разработке присутствует такая штука как wasm-shell — консольный исполнитель для wasm модулей.

Ну и хочу заметить, что VM у WASM имеется только в том же смысле, что и LLVM, а не как JVM или CLR. )))

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

_>>>Проверь сам, если сомневаешься)))
I>>Так где подробности ?

_>В описание моих тестов была ссылка на работающий прямо на страничке JS тест. Открываешь его исходник и видишь функцию Update — это по сути и есть весь тест, остальное мишура.

И как я найду ошибку в остальном твоем коде, телепатией или домыслами ?


I>>Это ты мне отомстить за Питон что ли хотел и решил про C# выдать непойми что ? Так я на JS пишу Чего сказать хотел ?

_>Нет, просто на мой вкус термин "убогий тормоз" при сравнение Pyhton и JS неуместен. На мой взгляд эти языки относятся к одному классу по производительности. И весь этот класс является "убогим тормозом" по отношению к скажем C++. Причём данный факт абсолютно нормален для той ниши, которую занимают эти языки.

Я так и подумал. Но почему то вспомнил, что как только речь про C#, так ты придираешься к каждой доле процента скажем, в сравнении с джавой или питоном. Парадокс! Расскажи, чем тебя шарписты обидели ?

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

_>...Что же касается интеграции с браузером и его GC, то тут конечно всё сложнее и требуется разработка с нуля (благо этим занимаются не энтузиасты, а специалисты на зарплате, причём из команд разработки ведущих браузеров).
Я собственно именно это и написал. Два GC в одном процессе = ад.

_>И по некоторым данным возможно там будет использоваться новое нативное API (в котором никакого GC просто не надо).
Дело не в статическом нативном API, a в модели памяти и взаимодействии.

N>>Это будет, только если WASM обретет VM без браузера. ИМХО так и надо было делать. Сначала просто VM с CoreAPI, потом: tracking GC, интеграция в браузер с DOM API, прочие языки (включая JS).
_>Так как раз всё именно таким образом и сделано. Т.е. платформа WASM вполне отделена от браузера и имеет свою отдельную спецификацию. Более того, разработчики не только предоставляю готовую библиотечку для встраивания исполнителя WASM в своё приложение, но и даже в их наборе инструментов разработке присутствует такая штука как wasm-shell — консольный исполнитель для wasm модулей.
Я знаю. Мои возражение сводятся к тому что ключевой вопрос (GC) платформы до сих пор не проработан, а ее уже интегрируют корявым способом в браузер.

_>Ну и хочу заметить, что VM у WASM имеется только в том же смысле, что и LLVM, а не как JVM или CLR. )))
И это правильно. Я вообще надеюсь, что jvm и .НЕТ языки когда-нибудь можно будет нацелить прямо на wasm.

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

N>>Однако смотря на Minecraft, сдается мне, что скорость для всего, что вообще имеет смысл запустить в браузера с песочницей, может быть вполне себе приемлема.
_>Ну скажем для какого-нибудь декодера видео из гиппотетического революционного стандарта h.365 скорость может быть вполне критичной.
Редкая ниша, где wasm скорее всего не при чем. Нужен GPGPU, etc.

_>Вообще то если уж Qt умудряются скомпилировать под asm.js, то уж с Питоном (встраивание которого в C++ приложения является давно отработанной техникой) то точно не должно быть никаких проблем — просто пересобрать под wasm и всё.
Вообще то Питон без доступа к DOM-у нафиг никому не нужен. Это как бы основной посыл.