Здравствуйте, Serginio1, Вы писали:
_>>Т.е. ты спрашиваешь как избавиться от JS с помощью WASM? Когда WASM дадут доступ к API браузера это будет элементарно — просто пишем на любом скриптовом языке нужный на код (кстати html тег script отлично это поддерживает) и дополнительно подгружаем движок этого языка скомпилированный под wasm. Тот при своей инициализации возьмёт данные из этих тегов и запустит их на исполнение. Не вижу вообще никаких сложностей. _>>Кстати, формально говоря некое подобие можно реализовать и прямо сейчас, реализовав поддержку браузерного API через Emscripten, но это будет очевидно суррогат "избавления от js", т.к. поддержка функций браузера в Emscripten через тот самый JS и реализована (т.е. в дополнение к своим скриптам на неком произвольном языке придётся подключать ещё и набор жирных js библиотек от Emscripten). Так что лучше набраться терпения и подождать пока разработчики wasm доберутся до браузерного API. S> Угу давай смотреть. Внедренный код должен кроме всего прочего взаимодействовать с уже внедренным. Это по сути аналог плагинов в .Net. S>Мы можем загрузить сборку, но она должна иметь в метаданных ссылки на общие интерфейсы иметь доступ к статическим методам и свойствам к классам уже загруженных сборок и если они не загружены загружать, проблемы с версиями (они правда есть и в JS) итд. S>Кроме того в HTML события могут иметь как имя метода так и реализацию. Это рефлексия. А значит движок должен быть аля .Net и Java и сборки с соответствующими метаданными.
Хы, ты похоже не понимаешь очевидного. ))) Любые динамические языки априори имеют то, что мы называем "рефлексией" и "боксингом" в статических языках. Только в их случае это не какой-то дополнительный отключаемый инструмент, а собственно основа их функционирования. )))
S> Вспоминаем про ограничения рефлексии в .Net Native. И по сути то будем иметь тот же Фреймворк который и сейчас, только созданный заного.
Так рефлексия времени исполнения — это бред для статически типизированного языка. А для динамических ситуация совершенно другая.
S> Вот например код из Angular 2 S>
S><tr *ngFor="let rows of RowsRange; let row = index">
S> <td *ngFor="let col of ColsRange; let i = index">
S> <input type="text" (keypress)="KeyPress($event,Puzzle[row*9+i].value)" (click)="Click(Puzzle[row*9+i])" [class.IsFocused]="Puzzle[row*9+i].IsFocused"
S> [(ngModel)]="Puzzle[row*9+i].value" [disabled]="Puzzle[row*9+i].disabled" size="3" maxlength="1">
S> </td>
S> </tr>
S>
S> При этом в С++,C# есть перегрузка методов, дженерики, а значит нужно искать методы по параметрам и дженерик методы с созданием метода по типу параметру, а если его нельзя вывести, то нужно указвать типы дженерик аргументов.
Ты какую-то ерунду пишешь) Никто не собирается втаскивать в C++ элементы DOM как первоклассные сущности. А просто работать с xml-подобными данными умеет даже C (более того, как раз на этом языке самый лучший парсер и написан).
Здравствуйте, gandjustas, Вы писали:
G>>>2) Перегрузки оператора ->, () V>>И это тоже. Смарт-поинтеры и функторы. V>>В этом смысле в дотнете всё печально — или пиши a.b.c.d.TargetMethod, или пиши делегирующий код на каждом уровне. G>Это чисто C++ костыль, в других языках не нужен.
Нужен-нужен. В VB хотя бы есть оператор with, а в C# пишут вот это г-но: a.b.c.d.TargetMethod
V>>Для чего угодно, для сериализации, форматирования и т.д. G>Зачем нужна перегрузка для социализации и форматирования?
А ты никогда не писал на C# ручную бинарную сериализацию?
В сравнении с плюсами писать бинарную сериализацию на C# — это ж застрелиться по трудоёмкости и в плане плохой отлавливаемости ошибок.
А своё форматирование тоже не писал?
Ну вот у тебя есть некий свой тип, для него надо изобрести свои спецификаторы форматирования.
Твои действия в C#?
G>>>Я хочу понять реальные кейсы полезного использования. V>>Парсеры, ленивые комбинаторы, мета-вычисления. V>>Сложить два своих "future", например — получить их комбинацию и т.д. G>Ты конкретный пример привести можешь? Складывание двух future — плохая идея от слова совсем.
Логические операции над future — это основа основ оперирования ими.
Именно так строится роутинг событий.
Операция when_all_ok — это логическое умножение.
Операция when_any_ok — это логическое сложение.
Переопределяешь операторы и так и записываешь:
auto waitOn = fu1 & (fut2 | fut3 & fut4);
В отсутствии операторов будет то же самое, что записывать арифметические операции через ф-ии sum/add/mul/div и т.д.
G>Не надо приводить примеры в духе "пишу потому что могу". Ты же говоришь что перегрузка операторов — фича востребованная, приведи примеры кейсов, где она действительно востребованная за пределами C++.
Здравствуйте, vdimas, Вы писали:
У нас сейчас разговор про Dart в котором можно вообще типы не указывать.
А проблему JS я описал здесь http://rsdn.org/forum/flame.comp/6736015.1
V>>>Нужно еще не врать, чтобы коллегам не приходилось бороться с желанием послать тебя подальше после каждого твоего вранья. S>> Ну ты посмотри на себя. Самому то не стыдно. Я тебе уже кучу ссылок привел на твои ошибочные суждения.
V>Опять же вранье. V>Ты еще не показал ни одной моей ошибки, бо сам плаваешь в азах буквально в каждом сообщении.
Даааааа.
V>Собсно, по итогам твоих высказываний я вижу, что ты НЕ понимаешь зачем Гугл сделал Dart. V>Ты заблудился натурально в 3-х соснах и не можешь найти выход из этой "густой чащи". ))
Так Dart сейчас используется где то со своей VM?
TS тоже может компилироваться в это VM. Проблема не в языке.
V>Dart — это попытка вытянуть индустрию из болота кривой типизации JS. V>И, наоборот, TS — это попытка замаскировать дурной запах такого болота, оставив всё как есть, мол "да ничего такого, немного дезодорантом побрызгали, а тут и тут не принюхиваемся!".
И где это VM для Dart?
V>Два этих подхода располагаются на противоположных полюсах в плане своих целей и задач. V>Ставить м/у ними знак равенства — это чудовищное дилетанство.
И где эта VM о гуру всего на свете?
Давай опровергай. Раз TS можно скомпилировать в Dart, то значит можно скомпилировать и Dart VM.
Тогда в чем отличие языков?
S>>Ты можешь только хамить.
V>Ну а кто тут бежит впереди паровоза насчет "надо знать предмет", я что ле? V>Прежде чем заявлять "я выиграл спор" его надо действительно выиграть, иначе получается только так:
Ты не знаешь ни TS ни Dart, но при этом судишь о их достоинствах.Скольео кода ты написал на Dart и TS?
S>>Так в дарте по умолчанию ести тип не задан то он any. S>>Так и TS any это аналог dynamic.
V>В TS любой тип — это и есть dynamic, независимо от аннотации типа. V>Вот я выше показал на примерах весь кошмар этого языка. V>Защиты от этого кошмара в TS де-факто НЕТ. Иначе бы я даже не участвовал в этом споре, разумеется
V>Собсно, dynamic в C# — это то, чем изначально должен был быть их Object. Т.е. вместо непосредственного вызова reflection должен был быть такой хелпер.
DLR это совсем другая песня. Его изначально не было как и деревьев выражений.
При этом C# компилируется в TS. Значит и C# отстой?
V>В Dart эту ошибку учли и сразу сделали как правильно. Точно так же учли ошибку дизайна функциональных типов в дотнете — гребанных их делегатов. В Dart сигнатура функционального типа и определяет его тип, как и должно быть.
Ну дык и в TS тоже самое. Я не вижу разницы?
V>Так же в Dart добавили еще несколько удобных, но при этом абсолютно прозрачных вещей (в сравнении с C#/Java): V>* compile-time вычисления; V>Т.е. любые твои прикладные классы с final-полями и любые твои ф-ии могут быть использованы для вычислений времени компиляции. В точно таких же сценариях в C#/Java вычисления происходят в рантайм.
Где эта VM?
V>* ограничения генериков включаются в определения типа;
V>* идиома nameof в лаконичной форме: memberInfo = #memberIdentifier;
V>* локальные ф-ии;
V>* итерация по реактивным коллекциям await for, await for-in (C# foreach-in);
V>* решена проблема принадлежности оператора break через опциональный break label;
V>* язык является одновремено компиллируемым и скриптовым, у скрипта в начале файла стоит #! бла-бла-бла
О. Изучил Dart. Теперь чего нет в TS?
V>Кароч, лично я вижу в Dart хорошо проделанную работу над детскими ошибками в современных мейнстримовых VM-языках. V>Причем, мне хватило когда-то 15 мин побаловаться и всё это увидеть. V>Но тебе даже если разжевать и в рот положить — ты проглотить не можешь. V>Как так? ))
И где VM?
S>>Но ты кричал здесь, что раз any можно не указывать то он отстой, я показываю тебе, что в Dart можно не указывать тип ты называешь меня обманщиком?
V>Я уже более чем доступно показал тебе, в чем ты обманщик: в выдавании желаемого за действительного и в обвинении оппонента в ошибках при полном неумении (невозможности?) эту ошибку показать сугубо технически.
V>Итого, ты врёшь тут как дышишь как насчёт якобы "типизации в TS", так и насчёт "в Darte всё точно так же". V>А уж в случае "я показал тебе твою ошибку" — это уже за гранью добра и зла. V>Ты ничего не показал, от тебя новой инфы для меня — зеро. V>Чтобы показать мне мою ошибку ты должен дать мне какуюнить новую инфу, чтобы я такой впечатлился: "ммм... а ведь действительно!".
V>>>>>имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па. S>>>>Он может писать и на Dart писать без типов. V>>>Т.е., ты отказываешься отвечать на мои аргументы? S>>Твои аргументы в том, что в Dart нужно указывать тип явно.
V>Т.е. ты ОПЯТЬ отказываешься отвечать на мои аргументы: V>
V>имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
V>Это у тебя принципиальная позиция, что ле — непременно переводить стрелки, отвечать невпопад, цитировать не то, на что ты реально отвечаешь? V>Слабо сосредоточиться и ответить на мой аргумент?
S>>Я тебе показал, что ты не прав.
V>Ты пока показал своё невладение азами, больше ничего.
S>>Мало того в TS выставлен флаг по умолчанию, что нужно обязательно указывать тип.
V>А толку, если типизация не работает? V>В TS ты выставляешь типы сугубо для intillesence.
Еще раз где используется VM для Dart?
TS тоже может компилироваться в эту VM, может в Dart.
Если Dart компилируется в JS то чем он лучше TS?
Если в Dart не нужно писать тип, а ты утверждал, что тип в Dart обязателен, то как это называть?
И мне очень жаль. я был значительно Большего мнения о тебе.
В
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Ты какую-то ерунду пишешь) Никто не собирается втаскивать в C++ элементы DOM как первоклассные сущности. А просто работать с xml-подобными данными умеет даже C (более того, как раз на этом языке самый лучший парсер и написан).
так в итоге то каков смысл в замене JS? И сейчас HTML со скриптами прекрасно парсится, компилируется где надо, а где надо интерпретируется.
При этом код и данные из одного скрипта может использоваться в другм
Вызываются нативные методы через плагины, webAssembly.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Собсно, по итогам твоих высказываний я вижу, что ты НЕ понимаешь зачем Гугл сделал Dart. V>>Ты заблудился натурально в 3-х соснах и не можешь найти выход из этой "густой чащи". )) S>Так Dart сейчас используется где то со своей VM?
So a couple of years ago, when we were starting to think about building a new version of AdWords with much improved UI and performance.
We wanted to use a stack that will enable building very large mission critical applications such as AdWords with very good user experience, application latency and feature velocity.
We wanted to provide a lot of flexibility to our UX designers to innovate and build a visually appealing and productive UI.
We also wanted to have world class application latency. A lot of people stay logged into AdWords all day working with large amounts of data. So, having a very fast application is critical.
I think Dart and Angular2/Dart are especially suitable for large scale business web applications. The tooling support and static correctness checking are particularly valuable for those types of applications.
With the ongoing work on Flutter, Dart could become a good option to consider also for teams that need to build native mobile apps across Android and iOS.
S>TS тоже может компилироваться в это VM.
Ты мне покажи именно это:
Dart execution is always type-safe
Покажи, что в случае TS есть возможность строить типобезопасные приложения.
V>>Dart — это попытка вытянуть индустрию из болота кривой типизации JS. V>>И, наоборот, TS — это попытка замаскировать дурной запах такого болота, оставив всё как есть, мол "да ничего такого, немного дезодорантом побрызгали, а тут и тут не принюхиваемся!". S>И где это VM для Dart?
Здравствуйте, vdimas, Вы писали:
_>>Ну и хочу заметить, что VM у WASM имеется только в том же смысле, что и LLVM, а не как JVM или CLR. ))) V>Это пока GC не прикрутили. V>Как прикрутят, так будет аналогично.
GC точно не будет. ) Будут три отдельные возможности:
1 (основное, есть уже сейчас). Линейная память.
2. Некие внешние ссылки (по сути аналог дескрипторов из обычного OS API) — этого уже более чем достаточно для полной реализации работы с web api.
3. Для случая реализации wasm в приложение с GC (wasm же подразумевается не только для браузеров) будет прямой доступ к работе с ним. Хотя это и не особо ценная необходимость — имеет смысл разве что для прямой интеграции с JS (вернуть там скажем нужный объект прямо из wasm функции).
При чем во всех проектах TS перекрывает Dart.
При этом Google для Angular 2 основным языком выбрала TS.
Значит в Google идиоты?
При этом по твоим ссылкам Dart компилируется в JS, а значит все то о чем ты так расхваливал Dart
и уничтожал TS в итоге свелось к компиляции в твой ненависный JS. И все достоинства Dart идут лесом.
А вот народ для компиляции в JS выбирает TS. И я в том числе. В том числе потому, что поддержка в VS
Куча заголовочных файлов.
Здравствуйте, Serginio1, Вы писали:
_>>Ты какую-то ерунду пишешь) Никто не собирается втаскивать в C++ элементы DOM как первоклассные сущности. А просто работать с xml-подобными данными умеет даже C (более того, как раз на этом языке самый лучший парсер и написан). S> так в итоге то каков смысл в замене JS? И сейчас HTML со скриптами прекрасно парсится, компилируется где надо, а где надо интерпретируется. S> При этом код и данные из одного скрипта может использоваться в другм S>Вызываются нативные методы через плагины, webAssembly.
Смысл в том, что кому-то возможно не нравится синтаксис JS, но нравится синтаксис Lua или Python или Ruby или вообще Lisp. ))) Но они не могли использовать эти языки в браузере — там пока только JS (ну и C++ теперь, но это не динамический язык для спец. применений с тяжёлыми вычислениями). А после того как в wasm добавят прямой доступ к web api и авторы (или просто какие-то энтузиасты, т.к. все движки открытые) движков этих динамических языков скомпилируют их под wasm, такая возможность уже появится.
_>Смысл в том, что кому-то возможно не нравится синтаксис JS, но нравится синтаксис Lua или Python или Ruby или вообще Lisp. ))) Но они не могли использовать эти языки в браузере — там пока только JS (ну и C++ теперь, но это не динамический язык для спец. применений с тяжёлыми вычислениями). А после того как в wasm добавят прямой доступ к web api и авторы (или просто какие-то энтузиасты, т.к. все движки открытые) движков этих динамических языков скомпилируют их под wasm, такая возможность уже появится.
Ну дык и сейчас TS и Dart прекрасно компилируются в JS.
Другое дело, был бы аналог байт кода в который могли бы компилироваться эти языки и JS в том числе, то было бы интересно.
А так ничего нового. Есть плагины и сейчас. Делай порты ко всем языкам как я например. Ссылки уже давать не буду
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Смысл в том, что кому-то возможно не нравится синтаксис JS, но нравится синтаксис Lua или Python или Ruby или вообще Lisp. ))) Но они не могли использовать эти языки в браузере — там пока только JS (ну и C++ теперь, но это не динамический язык для спец. применений с тяжёлыми вычислениями). А после того как в wasm добавят прямой доступ к web api и авторы (или просто какие-то энтузиасты, т.к. все движки открытые) движков этих динамических языков скомпилируют их под wasm, такая возможность уже появится. S> Ну дык и сейчас TS и Dart прекрасно компилируются в JS. S> Другое дело, был бы аналог байт кода в который могли бы компилироваться эти языки и JS в том числе, то было бы интересно. S>А так ничего нового. Есть плагины и сейчас. Делай порты ко всем языкам как я например. Ссылки уже давать не буду
Компилируется в JS множество языков, но это всего лишь суррогат от безысходности. А здесь речь о том, чтобы html страница стала выглядеть так:
Ну как так-то?! По твоей же ссылке они первым же делом после high-level goals они говорят об интеграции web api (включаяя DOM, отдельный пункт у них — для тех кто не в курсе что это часть webapi), а другой — про GC...
[quote]efficiently allocate and manipulate GC objects directly from WebAssembly code[/quote]
это не поддержка GC? В эту фразу вписывается самый натуральный общий с JS/DOM GC. Более того, не знаю как у других — wasm и так обслуживает V8. У них и GC есть готовый.
Из количества вопросов на SO я делаю ровно один вывод, причём и по отношению других библиотек: куча вопросов = мегапопулярность или плохая популярность и сложный (или слабо документированный) продукт. Всё. Обычно второе. Третий вариант: всё на высоте, но аудитория подкачала. Бывает и такое.
Из твоих данных ясно, что количество WTF в секунду:
— в JS зашкаливает (ну и конечно же, туда попадают все общие вопросы по поведению браузеров) + время и распространение. (Более того — причина этому — отсутствие нормальных средств разрабоики, 17-ая студия только щас осилила нормальные док комменты понимать — и то — этого всё равно мало в силу динамичности языка). IDE — должны понимать и requires и provides в любых формах. И неважно что за либа. И лайаут директорий. Поэтому ясно дело что народ жрёт кактус. А в сложных случаях где важно скорее поведение браузеров нежели самого JS — имеем вопросы. Уверен там бОльшая половина вопросов вообще не про JS как таковой. Вот например: el.getBoundingClientRect возвращает объект с пропами. Но JSON.stringify — пропы не сериализирут. И поди пойми что это и как правильно? (Если посмотреть на это со стороны разработчика браузера и попытаться ответить на вопрос — как же оно должно быть)?
— TS/Dart — считай оба на нуле, по отношению к JS.
— но WTF-ы чаще у пользователей TS.
PS: Я довольно плохо отзывался о Dart совсем недавно, но в свете новой информации — имхо — опять паритет. TS — няшный. Dart — банально мощнее, его VM имхо была лучше ноды даже когда я его смотрел. Щас думаю ещё лучше.
Здравствуйте, Mystic Artifact, Вы писали:
_>>GC точно не будет. ) Будут три отдельные возможности: _>>Вообще все их планы есть здесь: https://github.com/WebAssembly/design/blob/master/GC.md. MA> Ну как так-то?! По твоей же ссылке они первым же делом после high-level goals они говорят об интеграции web api (включаяя DOM, отдельный пункт у них — для тех кто не в курсе что это часть webapi), а другой — про GC... MA>[quote]efficiently allocate and manipulate GC objects directly from WebAssembly code[/quote] MA>это не поддержка GC? В эту фразу вписывается самый натуральный общий с JS/DOM GC. Более того, не знаю как у других — wasm и так обслуживает V8. У них и GC есть готовый.
Ну так это же речь не про встроенный в VM GC (как в JVM и CLR), а про доступ к некому внешнему. В этом смысле и разный C++ код браузера имеет доступ к функциям этого GC, но при этом же никто не говорит что браузер написан на платформе/языке с GC — он там живёт только внутри движка JS...
Это если они вообще это реализуют, т.к. для интеграции web api этого не требуется (достаточно внешних дескрипторов), а требуется только для удобной (простая на базе линейной памяти и примитивных типов есть уже сейчас) интеграции с JS. Но кто сказал, что после добавления доступа к web api этот js вообще будет нужен? )))
Здравствуйте, alex_public, Вы писали:
_>Ну так это же речь не про встроенный в VM GC (как в JVM и CLR), а про доступ к некому внешнему.
Ты ж сам знаешь как доступ к внешнему работает. Работает на пинах объектов и опциональном счетчике ссылок поверх. Angular 1 именно тёк по памяти в Хроме из-за этого со страшной силой когда-то.
У меня лично претензий к такому интеропу нет, — я и на JS делал "disposable" и все компоненты кто держали ссылки должны были это делать нормально (зануливать). Иначе память убегала. Хоть это было и не так давно — но я боюсь все просто офигеют если элементы начнут течь в wasm, а средств отладки не будет. Опять же — их в этом случае не будет — объект отправился во вне — GC его не трогает и хорошо. Но хорошо кому?
Вы тут все такие умные и разрулите эти ситуации наверное, в идеале — не дав шанса им возникнуть. А в реале — будет, у "индусов" — будет иначе. Я просто очень плотно отлаживал утечки в JS, в основном свои. Не мои — это ангуляр. Смешное в ангуляре что у них и метод clear был, да ссылки не зануливал.
А ещё смешнее — что проблему поставили как баг Хрома т.к. в FF и IE на тот момент работало. Смешно прежде всего потому, что кто им блин обещал GC не на основе подсчета ссылок — неясно. А второе — жалко 3 строчки и экономия 80Мб на форме?!
_>Это если они вообще это реализуют, т.к. для интеграции web api этого не требуется (достаточно внешних дескрипторов), а требуется только для удобной (простая...
DOM и JS неявно требует GC. Вот только это. В остальном — любые API отлично ложаться на разные языки. Ну DOM API влезет даже в C++ без изменений практически.
PS: Впрочем если бы браузеры не писали приплюсплюснутые люди и в них бы не было жесткого подавления ошибок и константных конверсий между std::string и WTFString — то толку было бы всем больше безо всякого переписывания и новотеха. Одно другому не мешает конечно.
Здравствуйте, alex_public, Вы писали: _>Компилируется в JS множество языков, но это всего лишь суррогат от безысходности. А здесь речь о том, чтобы html страница стала выглядеть так: _>
Вот не читаешь ты мои сообщения.
1. Как будут взаимодействовть wasm модули между собой?
2. wasm это другой домен, а значит задержки на вызовы
3. Уже существующие фреймворки ориентированы на JS
Лучше изучайте Angular 2 и TypeScript.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Mystic Artifact, Вы писали:
MA> PS: Я довольно плохо отзывался о Dart совсем недавно, но в свете новой информации — имхо — опять паритет. TS — няшный. Dart — банально мощнее, его VM имхо была лучше ноды даже когда я его смотрел. Щас думаю ещё лучше.
Чем Dart мощнее, и где используется его VM.
Ржание сферического коня представляет собой монофоническую гармонику и распространяется без рассеяния даже в вакууме. Копыта сферического коня соударяются с плоской горизонтальной поверхностью абсолютно упруго
и солнце б утром не вставало, когда бы не было меня
Соотношение в 4 раза всего?
При том, что в первом случае у нас говнокодеры, а в другом люди сознательно выбрали альтернативу именно TS, т.е. поднялись еще на ступень выше?
Блин, да это чертовски отличное соотношение.
Это фактически победа, учитывая, что Dart пошел в массы вот буквально осенью 2016-го.
Нифига себе, вот это скорость...
Два: https://www.tiobe.com/tiobe-index/
По индексу TIOBE у языка С 16.4%, у языка JS — 2.7%, т.е. язык С получается в 6 раз более востребованный.
Однако, по нему задают в 5.5 раз меньше вопросов, итого, "коэфициент нормировки" для суждений по сайту stackoverflow о языке JS — 33 раза.
Но это только начало. Ты приготовился к неожиданностям?
Посмотри на каком месте язык Swift в TIOBE.
На 10-м с 2.3%!!!
Поднялся за 2 года с 0-ля, считай.
Т.е., вот тебе щелчок по носу — никогда не смотри на статику, смотри на динамику процессов.
Итого, при одинаковой примерно популярности JS и Swift, по первому получается примерно в 10 раз больше вопросов.
Почему так? ИМХО, ответ очевиден — говнотехнология, грабля на грабле.
S> При чем во всех проектах TS перекрывает Dart. S>При этом Google для Angular 2 основным языком выбрала TS.
Это для Angular 1.
А вот Angular 2 разрабатывался уже с учётом портирования его на Dart.
S>Значит в Google идиоты?
Потому что применяют Dart в своих mission-critical бизнес-приложениях?
Может и идиоты, ХЗ.
Наверно только идиоты могут зарабатывать миллиарды на программах, написанных на Dart-е. ))
S>При этом по твоим ссылкам Dart компилируется в JS
Это одна из опций. Для нубов.
Там же по ссылкам дан серверный тулкит с VM, который юзает гугл.
S>а значит все то о чем ты так расхваливал Dart
А значит тебя пора уже забанить за неумение честно спорить.
Ну реально. Ты тут натурально жирнующщий бессовестный тролль. ))
А злостный троллинг наказуем.
S>и уничтожал TS в итоге свелось к компиляции в твой ненависный JS.
У кого свелось? Из какого пальца ты насасываешь свою брехню? ))
S>И все достоинства Dart идут лесом.
Не идут. Идёшь лесом ты за враньё.
S>А вот народ для компиляции в JS выбирает TS.
Потому что говнокодеры.
S>И я в том числе.
))
S>В том числе потому, что поддержка в VS
Попробуй WebStorm и не приводи в пример этот кошмар. ))
S>Куча заголовочных файлов.
Это портал в туалетную дыру.
Потому что у JS нет стандартной библиотеки.
Поэтому, ты подключаешь кучу разных наколенных глючных либ, 50% функциональности которых к тому же дублируется.
Зато баги из таких либ нифига не дублируются, а прекрасно складываются. ))
А у Dart есть нормальная продуманная стандартная либа.
S>А Dart VM даже не знаю кто пользуется.
А я не знаю, кто TS пользуется, и?
Посмотри еще раз на TIOBE.
Там твой TS не вошел даже в первые 50 языков, зато Dart уже вошел в 20-ку с результатом 1.2%.
Т.е. всего ~2 ниже, чем JS.
Не впечатлило разе?
Это очень быстрый рост популярности. Примерно как со Swift полтора года назад.
Сначала все хихикали в сторону этого Swift, а потом быстро заткнулись.
Отлично. На GIT обычно лежит то, чего не хватает в стандартной поставке.
Т.е., согласно GIT, беднее всех выглядит JavaScript.
ЧТД. ))
S>В который кстати Dart и не попал. Обрати внимание на рост в 250% S>Ангулар 2 уже дал знать в сентябе прошлого года, когда в релиз еще не вышел
И опять брехня.
На сетевой диаграмме показано, что максимум TS-проектов приходится на плагины к VsCode.
Ы-Ы-Ы, это натуральный джекпот в этом споре.
Обсыхайте, господа, обсыхайте.
================
Тебе еще не надоело настолько подставляться?
Нет, чтобы быть мужиком и честно сказать, так мол и так, ну вот выбрал TS, это моё личное дело, никого не касается...
Нет же, надо изворачиваться до последнего...
Такое ощущение, что ты уже сам себя уговариваешь, но у тебя это плохо получается. Получалось бы хорошо, ты бы не бегал от моих аргументов, ты бы знал что ответить на каждое замечание, а не бросался бы к "последнему бастиону" — статистике вопросов от стада обезъянок на SO. И не прибегал бы к прямой брехне в каждом посту. ))
Здравствуйте, Serginio1, Вы писали:
MA>>PS: Я довольно плохо отзывался о Dart совсем недавно, но в свете новой информации — имхо — опять паритет. TS — няшный. Dart — банально мощнее, его VM имхо была лучше ноды даже когда я его смотрел. Щас думаю ещё лучше. S>Чем Dart мощнее, и где используется его VM.
На сервер-сайде используется. Под дартовской либой Angular 2.
А ты думал, умные люди будут крутить тормозной node.js?
Смысл тогда было бы переходить на Dart?
Здравствуйте, Somescout, Вы писали:
S>PS. Похоже весеннее обострение — реальная проблема, какой-то бред на форумах и причём массовый.
Это не первый раз.
Скриптовики периодически тут начинают задвигать что-то важное про "удобства", заслуженно получают по щам и отваливаются на несколько лет.
Потом опять... ))
Никак до них не дойдёт, что скрипт хорош для автоматизации лишь небольших задач.
