Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, TimurSPB, Вы писали:
TSP>>>>Есть байт-код, есть нативный машинный код, и есть JS. Это всё разные вещи. И каждый слой должен оправдывать своё существование. G>>>Тебе никто ничего не должен. TSP>>Ну так себе аргумент. Пиши уж сразу "ой, всё!" G>Каждый раз когда ты пишешь что кто-то должен означает что ты сам недостаточно в теме.
Кто-то? Тут слой это неодушевленное абстрактное понятие. Ты слышал про Оккама и его бритву?
TSP>>Все эти слои имеют недостатки, которые всё равно не получится игнорировать. G>Какие именно недостатки?
Отладка через одно место, трудности профилирования, горы загружаемых зависимостей, расход памяти браузером и многое многое другое.
TSP>>Я бы не сказал что он развитый. Я про ES5, про то что есть сейчас. Не про светлое будущее. G>Мало ли что бы ты сказал. Ты не сильно в теме, твое мнение не авторитет.
Давай ссылки на авторитетов, которых чтишь и любишь. Я с удовольствием почитаю.
TSP>>С точки зрения результата(продукта) не важно что там хромает. Должно работать. G>См выше про "должно".
У тебя проблемы с этим словом?
TSP>>Внутри да — он монструозен. N>Никакого "внутри" в плюсах/бусте нет. Чтобы разобрать гирлянду бессмысленных ошибок пользователю в 100% случаях надо лезть в это "внутри". Это просто классический пример как текут абстракции и как быть не должно.
А как должно быть тогда? Речь про ошибки на этапе сборки?
Здравствуйте, gandjustas, Вы писали:
V>>Для сравнения, Хаскель до сих пор живее всех живых и переживёт любое г-но типа JS многократно, ес-но. G>Улыбнуло. Есть подозрение, что за все время существования хаскела на нем написано меньше кода, чем пишется ежегодно (может даже ежемесячно) на JS.
Я тебе больше скажу. Во времена бешеной популярности Перла на нём тоже писалось больше строк, чем на Хаскеле.
И где теперь этот Перл, а где Хаскель?
V>>В рамках JS не изобретено ни одной идиомы. G>Ты не знаешь JS.
Я знаю его намного лучше тебя.
V>>А пользоваться сегодняшним JS — это как если бы мы всё еще пользовались компиляторами С++ 93-го года выпуска. G>Похоже ты до сих пор в 93 году. Современный JS видел хотя бы?
Если ты про async/await/future, то они в браузерном JS всё еще не закреплены стандартом и вряд ли когда-нить будут.
Остальное не принципиально, потому что вне браузерных технологий JS совсем-совсем не нужен. ))
Затем подтвердили (т.е. Гугл подтвердил) свои намерения 2 года назад (полноценный релиз VM для Dart) и вот на днях похоронили JS окончательно, синхронно начав выпускать Хром и Мозиллу с поддержкой текущего драфта webasm. Это приплызд, собсно.
Думаю, за пяток лет технология устаканится окончательно, т.е. обрастёт библиотеками, фреймворками, своими аналогами nuget-ов (стандартов распространения библиотек), только сугубо для браузеров и т.д. и т.п.
G>Но даже это не имеет значения. Сейчас надо деньги зарабатывать и сейчас JS для этого очень пригодится.
Тут согласен. По-инерции он еще лет ~5 после окончательного перехода на webasm будет живее всех живых. Примерно так же, как был жив VB/VBA ~5 лет после появления VB.Net. Тут ради бога. Про вас будут говорить "олдскульные жабаскриптеры". ))
Здравствуйте, gandjustas, Вы писали:
G>Так говорили и 5, и 10 лет назад G>Но даже это не имеет значения. Сейчас надо деньги зарабатывать и сейчас JS для этого очень пригодится.
Здравствуйте, gandjustas, Вы писали:
N>>NodeJS взлетел исключительно потому, что код относительно легко можно переместить между клиентом и сервером. G>А ты вообще пробовал это сделать? Ничего что модули node не поддерживаются в браузере без приседаний?
На фоне обычного "с ластами в гамаке" с JS, добавить 3 строчки сущая мелочь.
N>>"Один язык" это суперфича. С точки зрения серверной платформы Python/Ruby/JVM/.NET уделывает NodeJS и в хвост и в гриву. G>Зависит от решения. Я использую node для socket.io сервера. Покажи как их уделает ruby.
Под "уделает" понимается что в них у меня есть модули, потоки, актеры, отладчики, классы, нормальная типизация, математика и тд и тп., которых нет в JS.
G>LUA вообще за пределами C++ мира не применяется.
А куда скриптинг еще встраивать-то надо? В .net/jvm обычно подсовывают dll/jar в IoC. В Питоне/Руби есть тот же самый eval, что и у тебя.
G>Да-да, где ваш пример про excel в 30 строк?
А если напишу в 50, что дашь?
I>>JS к твоему сведению легко пролез чуть не везде. NodeJS тоже думаешь благодаря DOM взлетел ? N>NodeJS взлетел исключительно потому, что код относительно легко можно переместить между клиентом и сервером. "Один язык" это суперфича. С точки зрения серверной платформы Python/Ruby/JVM/.NET уделывает NodeJS и в хвост и в гриву.
Если нужна "масштабируемость для бедных" и нет сложной логики, то нода норм.
Здравствуйте, TimurSPB, Вы писали:
N>>Никакого "внутри" в плюсах/бусте нет. Чтобы разобрать гирлянду бессмысленных ошибок пользователю в 100% случаях надо лезть в это "внутри". Это просто классический пример как текут абстракции и как быть не должно. TSP>А как должно быть тогда? Речь про ошибки на этапе сборки?
Именно. Если бог не дал нормальной системы типов, то ждем-с хотя бы костыли (констрайны или как они там будут по плюсовому — концепты, кажется). А пока в этой динамической белиберде все кишки вываливаются успешно наружу.
Для тех, кто недостаточно хорошо ориентируется в английском, кратко:
— поддержка доступа к DOM даже не планируется изнутри WebAssembly первые несколько лет повсеместного использования;
— если даже такая поддержка когда-нибудь случится, то это может быть вовсе не DOM, бо последний изначально был рожден исключительно в терминах языка JS, а некий другой, где будет JS упоминаться лишь в разделе правил маппинга на него. ))
Предлагаю посмаковать тут каждое слово:
Overall, the goal of mapping WebIDL to WebAssembly builtin modules is to avoid the need to define a duplicate WebAssembly interface for all Web APIs. In practice, some WebIDL patterns may have an unnatural or inefficient mapping into WebAssembly such that new overloads and best practices would need to be adopted.
Итого, нынешний DOM, считайте, уже предан анафеме и будет переписан как для нужд строго-типизированных программ, так и для языков без GC или даже без подсчета ссылок.
Само построение подобных фраз в изначально "сухой" документации — это непрекрытая травля, собсно.
Здравствуйте, novitk, Вы писали:
mgu>>Для гибкости существуют библиотеки. И вообще я удивляюсь, что до сих пор не изобрели качественные переводчики с одного программного языка на другие.
N>Что ты подразумеваешь под словом "качественные"?
На рынке полно некачественных, они сбиваются на вложенных операторах.
N>Подумай можно ли сделать "качественный" транслятор из C++ в Basic?
А почему бы и нет? Задача вполне детерминированная, это гораздо проще, чем машинно переводить человеческие языки, и то в последнее время наметился прогресс. Можно было бы начать с ещё более простой темы -- несовместимость устаревших версий, сейчас, например, всё прогрессивное человечество переводит Angular с 1-го на 2-й, а что будет с 3-й версией?
Здравствуйте, neFormal, Вы писали:
mgu>>1. Почему ничто другое не вытеснило это говно? mgu>>JS сам вытеснил VBScript, который был в общем зачёте лучше. Много званых, но мало избранных. Спросите у знакомой блондинки, почему она выбрала именно текущего партнёра из множества женихов.
F>эм, js выбрали потому, что разработчики тупые? ~_^
Это так ваша знакомая блондинка ответила? Типа, я вышла замуж за Васю, т. к. я тупая?
TSP>>А как должно быть тогда? Речь про ошибки на этапе сборки? N>Именно. Если бог не дал нормальной системы типов, то ждем-с хотя бы костыли (констрайны или как они там будут по плюсовому — концепты, кажется). А пока в этой динамической белиберде все кишки вываливаются успешно наружу.
Не могу сказать, что ошибки компиляции это самое плохое в бусте.
Здравствуйте, gandjustas, Вы писали:
G>Это ты пошутил так, да? Java взлетела именно потому что вытеснила C\C++ в банкинге и трейдинге,
Брехня же. Java сначала вытеснила VB в корпоративе, а не С/С++.
До прихода джавы в трейдинг было еще целых 8-10 лет, потому что там ограничением было быстродействие серваков на джаве.
G>а в дальнейшем во всем остальном сервер-сайде. Это случилось в районе начала-середины 90-х.
И опять брехня. Джава взлетела сначала на некритичном сервер-сайде в конце 90-х. И только в начале 2000-х её стали брать на что-то критичное.
Потому что до стандарта Джавы-2 это был дырявый матрас, а не "защищённая среда". Первый стандарт Джава-2 вышел в 99-м году, но до версии 1.3 (2000-й год) на что-то серьёзное Джаву никто не брал. Банковские джава-апплеты более-менее широко распространились как раз после выхода Джава-2.
Здравствуйте, gandjustas, Вы писали:
G>Факты, сестра, факты! В этой теме еще никто не привел конкретного факта почему именно JS плох.
Гугл проводит ежегодные конференции на тему того, почему JS плох и почему Гугл отказыватся во внутренних ключевых своих разработках от JS.
Тебе сколько видео с конференций гугла на эту тему накидать? 10? 20? Ты ни одного доклада не смотрел/не читал? ))
G>В современном стандарте есть import и arrow functions, в стандарте 2015 года появились. А примерно с 2014 были доступны в TS. Фактически 3 уже года можно использовать.
Нельзя. Потому что совместимость. Т.е. если еще в каком-нить node.js можно, то на веб-страницах — нет.
Здравствуйте, gandjustas, Вы писали:
AK>>UI, по очевидным причинам, в 30 строк не влезет. Он и в JS не влезет — он просто не является частью самого языка, он является частью платформы, на которой JS запускается. AK>>Тот ваш замечательный 30-строчный excel, скорее всего, не будет работать под Visual Studio Code, ибо оно не предоставляет того же рантайма, что и браузер. А язык тот же, JS. G>Ну то есть на .net этого нельзя сделать.
Ты сам исходник-то смотрел? ))
Там JS не при чем от слова совсем.
Такой же код можно было и на VBS накатать.
Тебе коллега правильно сказал — там используется функциональность браузера (АПИ DOM), а не языка JS.
От JS там только динамическое выполнение кода в ячейках, но это умеют, наверно, вообще все динамические языки.
Здравствуйте, gandjustas, Вы писали:
G>Во-вторых среди ищущих замену подавляющее большинство тех, кто JS не знает. G>В-третьих найти грамотного программиста — проблема не зависимо от языка.
Увы. Я одно время плотно разрабатывал под Офис, общался на форумах с VB-программистами.
Так вот, средний уровень программиста от языка зависит напрямую.
Там был местами просто ужос! ))
И эти люди вполне себе приносят некую пользу на своих проектах, почти всегда не понимая до конца, как "оно" устроено и работает.
А если программист начинает что-то понимать, то он обычно уходит на другие языки.
Аналогично с JS.
Например, я не раз наблюдал примерно такую деэволюцию у коллег: Дельфи -> Джава/C# -> JS (распространённый сценарий, кста).
Но никогда не JS -> Джава/C# -> С++. ))
Здравствуйте, gandjustas, Вы писали:
G>Разница в том, что в .NET очень много всего входит в стандартную библиотеку, в том числе UI. В JS в стандарт не входит почти ничего и около десятка ui-фреймворков существует и около сотни всяких байндингов одного к другому. Естественно при таком количестве внешних зависимостей они будут отваливаться. G>Ровно ту же самую картину можно наблюдать в python.
Здравствуйте, vdimas, Вы писали:
V>Ты сам исходник-то смотрел? ))
Смотрел
V>Там JS не при чем от слова совсем. V>Такой же код можно было и на VBS накатать.
V>Тебе коллега правильно сказал — там используется функциональность браузера (АПИ DOM), а не языка JS. V>От JS там только динамическое выполнение кода в ячейках, но это умеют, наверно, вообще все динамические языки.
Накатай на любом удобном тебе языке. Уложись в 30 строк. Представь что у тебя в любом языке есть DOM API и уложись в 30 строк.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Разница в том, что в .NET очень много всего входит в стандартную библиотеку, в том числе UI. В JS в стандарт не входит почти ничего и около десятка ui-фреймворков существует и около сотни всяких байндингов одного к другому. Естественно при таком количестве внешних зависимостей они будут отваливаться. G>>Ровно ту же самую картину можно наблюдать в python.
V>Так и в чем прикол продолжать есть кактус?
На самом деле сейчас Angular 2 может подмять под себя кучу Фреймворков. Другое дело, что TS ориентирована JS с ограничениями по типам,
неудобно писать постоянно this при обращении к полям класса, хотя конечно он значительно приятнее es5 и все таки поддержка типов и аннотаций значительно предпочтительнее чем es6
.
и солнце б утром не вставало, когда бы не было меня
