Дело не в JS, GC или финализаторах: при отсутствии гарантий гарантированной передачи данных по коммуникационному каналу по IPC — нужно всегда быть готовым, что удалённая сторона отвалилась. Креши тоже.
А все ресурсы которые требуют высвобождения — должны высвобождаться детерминированно с GC или нет. (Ну порой что-то можно реально оставить на откуп GC — но это чаще про память.)
Финализаторы имеют практическое применение, безусловно. Но посмотри например на XMLHttpRequest — его API не требует никакого GC.
Ещё в JS нет слабых ссылок. Тоже ж печаль.
Ну и таки да — GC может и не вызываться или вызываться гораздо реже, чем думается. Я лет 5 назад насиловал V8 и форсил GC руками. Потом разобравшись в проблеме, исправил JS код (но GC тогда не мог осилить ссылки на DOM — профайлер показывал массу элементов и замыканий(!) которые их держат — и ни туда ни сюда.)
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Представь что у тебя в любом языке есть аналогичный dom с таким же API и оператор eval. Попробуй аналогичный excel записать на другом языке в те же 30 строк. G>>Внезапно окажется, что в других языках нет аналогов with и defineProperty и придется городить костыли в 10 раз длиннее для того же функционала. S>Внезапно, и то, и другое нужно там чисто для работы сырого eval'а. Говнокод как он есть.
И пусть говнокод. Работает отлично, на любом другом языке заняло бы минимум в два раза больше. А на java\c#\c++ в — 10 раз больше.
S>>>До того что там используется сырой eval без какой либо фильтрации данных? Да, это такая мелочь... зато 30 строк. G>>Ты не понял, что этот пример исключительно для демонстрации мощи JS и к реальному приложению не относится? S>Я это как раз понял, это ведь именно вы настаиваете что "эти 30 строчек демонстрируют МОЩЬ JS". А по мне это не больше чем пресловутый однострочник на perl'е — бесполезная, опасная, кривонаписанная хрень. "Зато прикольная", по мнению фанатов.
Вопрос не в конкретном коде, а в возможностях JS. Они превосходят возможности многих современных языков.
S>BTW. Могу напомнить какой красивый код можно было писать на PHP при включённой авторегистрации глобалов. Что-то в итоге все плевались потом с такой красоты.
Есть подозрение что аналог на пыхе займет больше 30 строк.
S>>>JS кривой уже сейчас, и разве в js собираются добавлять возможность аннотации типов? (а это как раз то, что мне нравится в TS). G>>Ты походу не понимаешь. В JS не будет аннотаций типов. S>О чём и речь. Вы можете сколько угодно защищать гениальность такого решения, но с моей колокольни это изначальный дефект языка.
Вот именно. Это лишь твое мнение, которое никому не интересно. А факты остаются фактами — JS очень мощен и не очень сложен при этом. Поэтому он побеждает.
Кому надо — пользуются аннотациями, ts и всей экосистемой.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Сколько склепали и все сдохли Не смогли победить JS, странно да? Такой ужасный язык никто не смог победить. Даже гугл со своим dart не осилил.
S>И что, не смогли победить из-за высокого качества js, или из-за нереального объёма legacy? Учитывая успехи трансляторов, второй вариант куда более вероятен.
Во всех трансляторах что я виде приходилось писать в 2 раза больше кода для получения того же поведения. Вот и не взлетело.
Здравствуйте, Ops, Вы писали:
G>>А ты думал что разработка JS до сих пор ведется в блокноте? И ничем тут мегабайтные скрипты? Как они связаны с arrow functions или модулями? Ops>При том, что это один из способов фактической реализации модульности — свалить все нужное и ненужное в один файл. Или поприседать с require.js и аналогами. Вот вам и import.
"приседать" уже давно не нужно. И сваливать всё в один файл тоже не нужно.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
F> Дело не в JS, GC или финализаторах: при отсутствии гарантий гарантированной передачи данных по коммуникационному каналу по IPC — нужно всегда быть готовым, что удалённая сторона отвалилась. Креши тоже.
F> А все ресурсы которые требуют высвобождения — должны высвобождаться детерминированно с GC или нет. (Ну порой что-то можно реально оставить на откуп GC — но это чаще про память.)
То есть вручную?
F> Финализаторы имеют практическое применение, безусловно. Но посмотри например на XMLHttpRequest — его API не требует никакого GC.
А он может и выступать в качестве синлетона. Это не пример.
F> Ещё в JS нет слабых ссылок. Тоже ж печаль.
F> Ну и таки да — GC может и не вызываться или вызываться гораздо реже, чем думается. Я лет 5 назад насиловал V8 и форсил GC руками. Потом разобравшись в проблеме, исправил JS код (но GC тогда не мог осилить ссылки на DOM — профайлер показывал массу элементов и замыканий(!) которые их держат — и ни туда ни сюда.)
Я просто показал пример одинакового функционала в .Net и JS, где полезны финализаторы.
Ну есть еще проблема используемых типов
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
S>>Внезапно, и то, и другое нужно там чисто для работы сырого eval'а. Говнокод как он есть. G>И пусть говнокод. Работает отлично, на любом другом языке заняло бы минимум в два раза больше. А на java\c#\c++ в — 10 раз больше.
All the evidence points toward the defendant's guilt. I rest my case.
S>>Я это как раз понял, это ведь именно вы настаиваете что "эти 30 строчек демонстрируют МОЩЬ JS". А по мне это не больше чем пресловутый однострочник на perl'е — бесполезная, опасная, кривонаписанная хрень. "Зато прикольная", по мнению фанатов. G>Вопрос не в конкретном коде, а в возможностях JS. Они превосходят возможности многих современных языков.
Соглашусь: по эффективности генерации write-only говнокода он обгоняет даже perl.
S>>BTW. Могу напомнить какой красивый код можно было писать на PHP при включённой авторегистрации глобалов. Что-то в итоге все плевались потом с такой красоты. G>Есть подозрение что аналог на пыхе займет больше 30 строк.
Отдохните, правда. Это была аналогия, не относящаяся напрямую к приведённому вами примеру.
G> Вот именно. Это лишь твое мнение, которое никому не интересно. G> А факты остаются фактами — JS очень мощен и не очень сложен при этом.
G> Поэтому он побеждает.
Как там было, "В голосовании среди одного участника победил аутсайдер?"
Здравствуйте, turbocode, Вы писали:
T>На что то более вменяемое типа C# с хорошей стандартной библиотекой? Сколько можно тянуть этот JS легаси из 90-х годов?
Может быть отсутствие необходимости в такой замене?
Здравствуйте, gandjustas, Вы писали:
G>>>Представь что у тебя в любом языке есть аналогичный dom с таким же API и оператор eval. Попробуй аналогичный excel записать на другом языке в те же 30 строк. G>>>Внезапно окажется, что в других языках нет аналогов with и defineProperty и придется городить костыли в 10 раз длиннее для того же функционала. S>>Внезапно, и то, и другое нужно там чисто для работы сырого eval'а. Говнокод как он есть. G>И пусть говнокод. Работает отлично, на любом другом языке заняло бы минимум в два раза больше. А на java\c#\c++ в — 10 раз больше.
Самое интересное, что это пишет тот же gandjustas, который всего несколько лет назад с пеной у рта доказывал прямо противоположное, а именно — C# да с linq дает много более компактный и читабельный код. Он же, т.е. gandjustas, тогда же плевал в сторону js
Похоже, ты хвалишь не инструмент, а только то, за что тебе деньги платят. Раньше платили за шарепойнт и C#, ты именно это и хвалил. Щас пошли заказы на JS, хвалишь JS. Завтра тебе начнут кидать верстку и html, будешь рассказывать что именно это и есть вершина эволюции. Очень гибкий позвоночник, практически, как его отсутствие.
Здравствуйте, Somescout, Вы писали:
G>> Вот именно. Это лишь твое мнение, которое никому не интересно. G>> А факты остаются фактами — JS очень мощен и не очень сложен при этом. S>
G>> Поэтому он побеждает. S>Как там было, "В голосовании среди одного участника победил аутсайдер?"
У JS во все времена было много конкурентов. Даже сейчас их довольно много. Клиентские веб-приложения на чем только ни писали, а нынче каждый "убийца" Джаваскрипта пылится на обочине.
Здравствуйте, Ikemefula, Вы писали:
I>У JS во все времена было много конкурентов. Даже сейчас их довольно много. Клиентские веб-приложения на чем только ни писали, а нынче каждый "убийца" Джаваскрипта пылится на обочине.
Много это vbscript? У всего остального проблема в том, что оно не может работать в браузере. И в итоге выходило, что если используешь, допустим, gwt, то всё равно имеешь кучу проблем с отладкой и взаимодействием с браузером, т.к. приходится опускаться до js.
Здравствуйте, Somescout, Вы писали:
I>>У JS во все времена было много конкурентов. Даже сейчас их довольно много. Клиентские веб-приложения на чем только ни писали, а нынче каждый "убийца" Джаваскрипта пылится на обочине.
S>Много это vbscript? У всего остального проблема в том, что оно не может работать в браузере. И в итоге выходило, что если используешь, допустим, gwt, то всё равно имеешь кучу проблем с отладкой и взаимодействием с браузером, т.к. приходится опускаться до js.
В свое время в браузере работали разные языки. Не прижились. Конкурентами JS являются и апплеты, и флеш, и сервелат. Аргумент с gwt смешной. Куча геморроя с отладкой именно из за того, что _gwt_ кривой, никак не учитывает особенности vm браузера. Ну нет в Java встроеных возможностей ввести другой численый тип. Нет поддержки динамических объектов. Много чего еще нет. Именно потому gwt и отсох.
Скажем, ASM x86 был еще более убог и крив. Первые двадцать лет отладчики регулярно вывалились в этот самый ASM. И ничего. Языки, которые не научились внятно транслироваться в этот asm, сдохли.
С браузером будет ровно так же. Браузер — это платформа. Не важно, кривая она или нет. Важно, что на неё есть спрос. Переписывать никто не будет. И JS менять, потому что это не нравится некоторым девелоперам, тоже не будут. Потому языки или принимают правила платформы, или идут нахрен, как это было во все времена.
G>>>Так все и работают. Разработка на JS уже давно не в блокноте ведется. TSP>>И считают этой нормой. Вся эта гора костылей а-ля babel это НЕНОРМАЛЬНО. G>Это же не желание людей так делать, а отставание браузеров в поддержке стандарта. G>Ничего что в C\C++ до сих пор препроцессором пользуются? Это вообще ахтунг в 2017 году. TSP>>Я вот представляю себе вариант, когда C++14 конвертируется в С++98, потом компилируется... Ну жесть же. G>Там же все еще интереснее происходит, с учетом препроцессора, obj файлов, линкера и преображования в машинный код. G>Как ты с этим живешь?
У плюсов проблем своих хватает. Например, отсутствие менеджера пакетов. Препроцессор может и ахтунг, но не ахтунг-ахтунг. А вот webpack, requirejs и прочее подобное — это абсолютный и тотальный ахтунг. Как и многое в JS — это средство обхода ущербности языка путем инкостыляции малых модулей в один большой кусок изуродованного кода. Это не средство языка, это не стандартизовано, это самая натуральная жестяная жесть. Большинство этих всех фреймворков не расширяют язык, как скажем boost в плюсах, а создают экосистему затычек и примочек для несчастного JS.
В плюсах после компиляции-линковки получается нативный машинный код. Да всё это не особо здорово, но понятно за что все эти страдания.
Как я с этим живу? Да как все. Основная работа на плюсах тут на форуме этот тернисный путь уже многократно обсуждался во всех деталях.
Плюс побочный проектик, где нужен фронтенд и там во весь рост JS. Как с этим жить? В одну руку берешь костыль VueJS, в другую jQuery и потихоничку ковыляешь в волшебный мир web 2.0.
Здравствуйте, gandjustas, Вы писали:
G>Тогда при чем тут финализаторы? Они перезагружают железки?
Финализируемые объекты знают, в каком состоянии железка.
G>Более того, ты же банально не знаешь в каком состоянии железка была ДО подключения. Поэтому все равно в начала у тебя будет приведение к нормальному состоянию, а только потом запросы и ответы.
Вообще-то знаю. Ибо запускают софтину перед началом смены, когда все роботы в "исходном состоянии". Это ручной процесс, и он осуществим только тогда, когда конвейер остановлен.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Somescout, Вы писали:
I>В свое время в браузере работали разные языки. Не прижились. I>Конкурентами JS являются и апплеты, и флеш, и сервелат.
С каких пор? Все три реализовывали свою среду поверх браузера, и требовали того же грёбанного js для взаимодействия со страницей. Охренеть конкуренты.
I>Аргумент с gwt смешной.
Нука-нука...
I>Куча геморроя с отладкой именно из за того, что _gwt_ кривой, никак не учитывает особенности vm браузера.
WAT? Да он генерил js с учётом особенностей каждого браузера, фактически оптимальный код для всего этого Содома.
I>Ну нет в Java встроеных возможностей ввести другой численый тип. Нет поддержки динамических объектов. Много чего еще нет. Именно потому gwt и отсох.
Да не было никакой нужды ни в первом, ни во втором, ни в третьем. Зато как только появлялась необходимость inter(ж)opa между js и gwt, начиналась дикая магия.
I>Скажем, ASM x86 был еще более убог и крив. Первые двадцать лет отладчики регулярно вывалились в этот самый ASM. И ничего. Языки, которые не научились внятно транслироваться в этот asm, сдохли.
Кривая аналогия: есть ARM, MIPS, PowerPC и прочее, есть NET, Java, Lisp, JavaScript (eye roll) и куча других виртуальных машин.
I> С браузером будет ровно так же. Браузер — это платформа. Не важно, кривая она или нет. Важно, что на неё есть спрос. Переписывать никто не будет. И JS менять, потому что это не нравится некоторым девелоперам, тоже не будут. Потому языки или принимают правила платформы, или идут нахрен, как это было во все времена.
Так я о том же: javascript говно, и говно безалтернативное.
Здравствуйте, TimurSPB, Вы писали:
G>>Ничего что в C\C++ до сих пор препроцессором пользуются? Это вообще ахтунг в 2017 году. TSP>>>Я вот представляю себе вариант, когда C++14 конвертируется в С++98, потом компилируется... Ну жесть же. G>>Там же все еще интереснее происходит, с учетом препроцессора, obj файлов, линкера и преображования в машинный код. G>>Как ты с этим живешь? TSP>У плюсов проблем своих хватает. Например, отсутствие менеджера пакетов. Препроцессор может и ахтунг, но не ахтунг-ахтунг. А вот webpack, requirejs и прочее подобное — это абсолютный и тотальный ахтунг. Как и многое в JS — это средство обхода ущербности языка путем инкостыляции малых модулей в один большой кусок изуродованного кода.
webpack это фактически тот же линкер, как в С++. Уже давно не надо готовить "один большой кусок изуродованного кода"
Здравствуйте, Serginio1, Вы писали:
F>> А все ресурсы которые требуют высвобождения — должны высвобождаться детерминированно с GC или нет. (Ну порой что-то можно реально оставить на откуп GC — но это чаще про память.) S> То есть вручную?
Что значит вручную? В дотнете возьми Stream и Writer к нему — и если кто-то забыл Close/Dispose/Flush — то нет никаких гарантий что все данные окажутся на диске. Соответственно, да, — вручную. Языки по разному только организуют этот процесс (или оставляют на совести). Но финализаторы сами по себе не дают ничего, а для программы которая управляет временем жизни объектов явно — внезапно становятся не нужны.
То, что делается финализаторами в основном — это оборачивание хэндлов в SafeHandle — что нужно, т.к. обычный код не обрабатывает исключения на каждый чих и это считается нормой на платформе. Ну и набор совсем патологических случаев, когда невозможно без трюков возложить работу на финализаторы, навроде закрытия окна в виндовс и некоторые другие.
F>> Финализаторы имеют практическое применение, безусловно. Но посмотри например на XMLHttpRequest — его API не требует никакого GC. S> А он может и выступать в качестве синлетона. Это не пример.
При чем тут синглетон? Я говорю, что объект под собой управляет одним из дорогих ресурсов, но ему по своему API никаких финализаторов не нужно. Это довольно тонкий клиент к stateful серверу в другом процессе который и берёт все тяготы жизни на себя. Сервер же имеет все средства получить всю информацию и правильно реагировать (отменять запросы), в том числе, если клиент отвалился (крешнулся процесс).
Понятно, что как только ты затягиваешь состояние на клиента — случается схема посложнее.
Это же очевидно, что из-за разности языков/средств — один в один оно не ляжет.
Если спустится на уровень ниже, а именно взять в руки C++ и V8 — возможностей будет поболее.
Но они потом перейдут в другую плоскость — GC не вызывается достаточно часто. Это тоже можно порешать. Но это может породить и новый вопрос — теперь стало медленно работать.
S> Я просто показал пример одинакового функционала в .Net и JS, где полезны финализаторы.
А я и говорил с самого начала — они поэтому же и вредны. 15 лет назад народ бодро тянул .net remoting куда только мог в том числе и для межхостового обмена. И что? Прошло время — везде или WCF по возможности без колбэков или вообще web api (в широком смысле этого слова) который ещё проще WCF.
Здравствуйте, Ikemefula, Вы писали:
I>Самое интересное, что это пишет тот же gandjustas, который всего несколько лет назад с пеной у рта доказывал прямо противоположное, а именно — C# да с linq дает много более компактный и читабельный код. Он же, т.е. gandjustas, тогда же плевал в сторону js
А я про linq и сейчас скажу то же самое.
Только дело не в linq, а в клиентском коде. Там linq не сильно помогает. Весь серьезный сервер-сайд я до сих пор делаю на C# и никаких NodeJS.
I>Похоже, ты хвалишь не инструмент, а только то, за что тебе деньги платят. Раньше платили за шарепойнт и C#, ты именно это и хвалил. Щас пошли заказы на JS, хвалишь JS. Завтра тебе начнут кидать верстку и html, будешь рассказывать что именно это и есть вершина эволюции. Очень гибкий позвоночник, практически, как его отсутствие.
Ты почти угадал. Дело не только в том, за что деньги платят, а в том за что деньги можно получить быстро.
Когда занимаешься бизнесом ты зарплату не получаешь и сроки становятся крайне важны. Поэтому инструменты, которые помогают быстрее\проще писать, устанавливать, править становятся гораздо важнее твоего отношения и внутреннего чувства красоты.
