Здравствуйте, Somescout, Вы писали:
I>>Куча геморроя с отладкой именно из за того, что _gwt_ кривой, никак не учитывает особенности vm браузера. S>WAT? Да он генерил js с учётом особенностей каждого браузера, фактически оптимальный код для всего этого Содома.
Ога. Он генерит кучу дерьма только из за того, что в джаве совсем другая система типов. При чем здесь JS ?
I>>Ну нет в Java встроеных возможностей ввести другой численый тип. Нет поддержки динамических объектов. Много чего еще нет. Именно потому gwt и отсох. S>Да не было никакой нужды ни в первом, ни во втором, ни в третьем. Зато как только появлялась необходимость inter(ж)opa между js и gwt, начиналась дикая магия.
Я тебе страшное скажу — джава на винде сосёт именно по этой же причине. Джава может внятно работать только внутри своей собственной VM. Именно поэтому и возникают проблемы с gwt.
I>>Скажем, ASM x86 был еще более убог и крив. Первые двадцать лет отладчики регулярно вывалились в этот самый ASM. И ничего. Языки, которые не научились внятно транслироваться в этот asm, сдохли. S>Кривая аналогия: есть ARM, MIPS, PowerPC и прочее, есть NET, Java, Lisp, JavaScript (eye roll) и куча других виртуальных машин.
На x86 остались только те, которые на ней внятно заработали. И ровно то же с остальными платформами. Не язык диктует условия, а платформа.
I>> С браузером будет ровно так же. Браузер — это платформа. Не важно, кривая она или нет. Важно, что на неё есть спрос. Переписывать никто не будет. И JS менять, потому что это не нравится некоторым девелоперам, тоже не будут. Потому языки или принимают правила платформы, или идут нахрен, как это было во все времена. S>Так я о том же: javascript говно, и говно безалтернативное.
Родовые травмы никого не интересуют. Все академически выведеные, вывереные языки нигде никогда не приживались. Вся история ЯП — приживаются уродцы.
Важны не те грабли ,что тебя смущают, а возможности которые представляет JS.
Программирование на любом языке это прежде всего идиомы. И в каждом языке начинаются проблемы, если ты пробуешь писать без этих идиом.
В каждом.
Здравствуйте, gandjustas, Вы писали:
I>>Похоже, ты хвалишь не инструмент, а только то, за что тебе деньги платят. Раньше платили за шарепойнт и C#, ты именно это и хвалил. Щас пошли заказы на JS, хвалишь JS. Завтра тебе начнут кидать верстку и html, будешь рассказывать что именно это и есть вершина эволюции. Очень гибкий позвоночник, практически, как его отсутствие. G>Ты почти угадал. Дело не только в том, за что деньги платят, а в том за что деньги можно получить быстро. G>Когда занимаешься бизнесом ты зарплату не получаешь и сроки становятся крайне важны. Поэтому инструменты, которые помогают быстрее\проще писать, устанавливать, править становятся гораздо важнее твоего отношения и внутреннего чувства красоты.
В проектах-однодневках все так и есть. Ты выбрал модель "за деньги и быстро" + "кастомер всегда прав". Из этого следует, кстати говоря, что ты всегда не прав
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
F>>> А все ресурсы которые требуют высвобождения — должны высвобождаться детерминированно с GC или нет. (Ну порой что-то можно реально оставить на откуп GC — но это чаще про память.) S>> То есть вручную? F> Что значит вручную? В дотнете возьми Stream и Writer к нему — и если кто-то забыл Close/Dispose/Flush — то нет никаких гарантий что все данные окажутся на диске. Соответственно, да, — вручную. Языки по разному только организуют этот процесс (или оставляют на совести). Но финализаторы сами по себе не дают ничего, а для программы которая управляет временем жизни объектов явно — внезапно становятся не нужны.
Ну после вызова
GC.Collect();
GC.WaitForPendingFinalizers();
Вполне себе гарантирует. Обычно так и делвется со ссылками на COM и прочими.
Он подбирает все огрехи и забывчивости.
F> То, что делается финализаторами в основном — это оборачивание хэндлов в SafeHandle — что нужно, т.к. обычный код не обрабатывает исключения на каждый чих и это считается нормой на платформе. Ну и набор совсем патологических случаев, когда невозможно без трюков возложить работу на финализаторы, навроде закрытия окна в виндовс и некоторые другие.
Разные ситуации. Как например у меня.
F>>> Финализаторы имеют практическое применение, безусловно. Но посмотри например на XMLHttpRequest — его API не требует никакого GC. S>> А он может и выступать в качестве синлетона. Это не пример. F> При чем тут синглетон? Я говорю, что объект под собой управляет одним из дорогих ресурсов, но ему по своему API никаких финализаторов не нужно. Это довольно тонкий клиент к stateful серверу в другом процессе который и берёт все тяготы жизни на себя. Сервер же имеет все средства получить всю информацию и правильно реагировать (отменять запросы), в том числе, если клиент отвалился (крешнулся процесс).
При том, что он один и за его жизнью не надо следить. Или выполнил запрос закрылся. F> Понятно, что как только ты затягиваешь состояние на клиента — случается схема посложнее. F> Это же очевидно, что из-за разности языков/средств — один в один оно не ляжет. F> Если спустится на уровень ниже, а именно взять в руки C++ и V8 — возможностей будет поболее. F> Но они потом перейдут в другую плоскость — GC не вызывается достаточно часто. Это тоже можно порешать. Но это может породить и новый вопрос — теперь стало медленно работать.
Иногда просто можно вызвать Collect
S>> Я просто показал пример одинакового функционала в .Net и JS, где полезны финализаторы. F> А я и говорил с самого начала — они поэтому же и вредны. 15 лет назад народ бодро тянул .net remoting куда только мог в том числе и для межхостового обмена. И что? Прошло время — везде или WCF по возможности без колбэков или вообще web api (в широком смысле этого слова) который ещё проще WCF.
Который проще, но значительно тяжелее. А вместо калбеков используют SignalR
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, TimurSPB, Вы писали:
TSP>У плюсов проблем своих хватает. Например, отсутствие менеджера пакетов. Препроцессор может и ахтунг, но не ахтунг-ахтунг. А вот webpack, requirejs и прочее подобное — это абсолютный и тотальный ахтунг. Как и многое в JS — это средство обхода ущербности языка путем инкостыляции малых модулей в один большой кусок изуродованного кода.
Это какбы проблема не языка, а реализации в браузерах. Если все завтра начнут поддерживать ES 2017, то необходимости в приседаниях станет на порядок меньше.
TSP>Большинство этих всех фреймворков не расширяют язык, как скажем boost в плюсах, а создают экосистему затычек и примочек для несчастного JS.
Как раз буст гораздо больше дырок в языке затыкает, чем фреймворки в js. Более того, в новые версии js отлично попадают подобные "затычки".
TSP>В плюсах после компиляции-линковки получается нативный машинный код. Да всё это не особо здорово, но понятно за что все эти страдания.
То есть вся проблема только в твоем отношении.
TSP>Как я с этим живу? Да как все. Основная работа на плюсах тут на форуме этот тернисный путь уже многократно обсуждался во всех деталях.
Ну также в JS. Все давно забили на то, что на выходе. Проблема только в отношении. У многих в голове сидит паттерн "js — плохо, а <подставить любимый язык> — хорошо".
TSP>Плюс побочный проектик, где нужен фронтенд и там во весь рост JS. Как с этим жить? В одну руку берешь костыль VueJS, в другую jQuery и потихоничку ковыляешь в волшебный мир web 2.0.
Ты удивишься, но из 5 последних проектов jquery был только в одном.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>Тогда при чем тут финализаторы? Они перезагружают железки? K>Финализируемые объекты знают, в каком состоянии железка.
Это не решает проблему неизвестного состояния при подключении.
G>>Более того, ты же банально не знаешь в каком состоянии железка была ДО подключения. Поэтому все равно в начала у тебя будет приведение к нормальному состоянию, а только потом запросы и ответы. K>Вообще-то знаю. Ибо запускают софтину перед началом смены, когда все роботы в "исходном состоянии". Это ручной процесс, и он осуществим только тогда, когда конвейер остановлен.
А если упало по середине?
Что-то я вижу слепую веру в то, что приложение всегда запускается и завершается в известном состоянии в заранее известный момент. Это слишком сильное предположение.
Здравствуйте, Ikemefula, Вы писали:
I>В проектах-однодневках все так и есть.
Это в любых проектах. У меня есть проекты которые уже три года развиваются, и как раз в них JS (на самом деле TS) помогает очень сильно. поправить скрипт на практике на два порядка проще, чем серверный код.
I>Ты выбрал модель "за деньги и быстро" + "кастомер всегда прав". Из этого следует, кстати говоря, что ты всегда не прав
Ты хочешь быть правым или быть богатым?
Здравствуйте, gandjustas, Вы писали:
G>Это не решает проблему неизвестного состояния при подключении.
Решает.
G>А если упало по середине?
Если упало, то производство останавливается, и робот вручную приводится в "исходное состояние".
G>Что-то я вижу слепую веру в то, что приложение всегда запускается и завершается в известном состоянии в заранее известный момент. Это слишком сильное предположение.
Что-то я вижу, что ты реальное современное производство видел только на картинках...
I>webpack это фактически тот же линкер, как в С++. Уже давно не надо готовить "один большой кусок изуродованного кода"
Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода.
G>Это какбы проблема не языка, а реализации в браузерах. Если все завтра начнут поддерживать ES 2017, то необходимости в приседаниях станет на порядок меньше.
Отсутствие модулей хоть в каком то виде это проблема языка. А проблемы браузеров не отделимы от языка в случае JS. Зачем нужен язык без реализации?
Нет пока никакого ES 2017, и когда он будет никто не скажет. Если вообще будет.
G>Как раз буст гораздо больше дырок в языке затыкает, чем фреймворки в js. Более того, в новые версии js отлично попадают подобные "затычки".
В самом языке буст ничего не затыкает. Он его расширяет и многое потом отправляется в стандарт. А вот, например, $scope в angular это типичный пример костыля, который требуется понимать и правильно использовать.
G>То есть вся проблема только в твоем отношении.
От моего отношения развитие языков не зависит.
G>Ну также в JS. Все давно забили на то, что на выходе. Проблема только в отношении. У многих в голове сидит паттерн "js — плохо, а <подставить любимый язык> — хорошо".
Большинство забили. Но не думаю, что на больших проектах удасться полностью абстрагироваться от выхлопа этих всех богомерзких тулов.
G>Ты удивишься, но из 5 последних проектов jquery был только в одном.
Точно нет jquery? Покажи папку node_modules.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Ikemefula, Вы писали: I>>Студенты _колледжа_ понимают, а им ажно 18 лет! Может дело в тебе ?
Ops>Дело не в нем. Дело в том, что язык "особенный", "не как все".
Все языки "не как все". Проблемы возникают у тех, кто пишет на одном единственном.
Здравствуйте, neFormal, Вы писали:
F>так это обращение к внешней системе. это нормально.
Оно как бы внешнее, но по сути, с введением интринсиков, уже внутренее. Ну и jquery не вчера появился, пора бы уже и язык расширить под такие задачи, а базовую часть jquery сделать частью стандартной библиотеки.
Здравствуйте, Ops, Вы писали: Ops>Здравствуйте, gandjustas, Вы писали: G>>Факты, сестра, факты! В этой теме еще никто не привел конкретного факта почему именно JS плох. Ops>Ну загугли "js wtf", а то ты тут что-то про 3 странички руководства написал, так эти wtf не меньше потянут.
На js никогда не писал и не изучал его. Всяческие js wtf регулярно веселят, потому что, не зная js, угадать результат многих его выражений трудно. В большинстве случаев, глядя на уже готовый результат, можно придумать такую логику, которая бы его объясняла, но иногда попадаются выкрутасы, которым я не могу придумать объяснения:
Здравствуйте, gandjustas, Вы писали:
I>>В проектах-однодневках все так и есть. G>Это в любых проектах. У меня есть проекты которые уже три года развиваются, и как раз в них JS (на самом деле TS) помогает очень сильно. поправить скрипт на практике на два порядка проще, чем серверный код.
Надо же, а как браво начиналось "А я про linq и сейчас скажу то же самое. Только дело не в linq, а в клиентском коде. Там linq не сильно помогает. Весь серьезный сервер-сайд я до сих пор делаю на C# и никаких NodeJS."
И вдруг ты сам себя опроверг — оказывается, скрипт на два порядке проще править, нежели серверный код. Скоро узнаешь, что часть бакенда тоже можно делать на скрипте, потому как "поправить скрипт на практике на два порядка проще".
Уже хорошо, хоть не в одном абзаце противоречия лепишь.
I>>Ты выбрал модель "за деньги и быстро" + "кастомер всегда прав". Из этого следует, кстати говоря, что ты всегда не прав G>Ты хочешь быть правым или быть богатым?
Похоже, что ты третьего не видишь, не говоря про всю палитру. Наивное предположение, что у всех одна и та же цель — стать богатым. Это только твое видение.
Что касается меня, то я хочу быть самим собой и обязательно счастливым. А правым или богатым — вообще дело десятое. Если самим собой и счастливым, то я бедным спокойно проживу
Здравствуйте, TimurSPB, Вы писали:
I>>webpack это фактически тот же линкер, как в С++. Уже давно не надо готовить "один большой кусок изуродованного кода" TSP>Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода.
У меня в проектах таких файлов нет, ничем не могу помочь.
Здравствуйте, alexzzzz, Вы писали:
A>На js никогда не писал и не изучал его. Всяческие js wtf регулярно веселят, потому что, не зная js, угадать результат многих его выражений трудно. В большинстве случаев, глядя на уже готовый результат, можно придумать такую логику, которая бы его объясняла, но иногда попадаются выкрутасы, которым я не могу придумать объяснения:
А кто тебя заставляет такой код писать ? Особенность этих wtf в том, что они встречаются в основном на форумах. Хочешь писать нормальный JS код — пожалуйста, это легко получается.
S> Вполне себе гарантирует. Обычно так и делвется со ссылками на COM и прочими. S>Он подбирает все огрехи и забывчивости.
Именно, что не гарантирует:
1. Нет никаких гарантий о том в каком порядке будут вызваны финализаторы. В моём примере же порядок важен — Writer буфферизирующий и Stream — буфферизирующий. Очевидно, что реверс порядка приведет к потере данных.
2. Нет никаких временных гарантий. "На пальцах" — забыли закрыть файл (эксклюзивный доступ) — и теперь пытаемся его открыть снова — а сборка мусора ещё не прошла? Что получается? Получается недетерминированное поведение в зависимости от фаз луны. Очевидно, что это — ошибка программы (забыли закрыть файл). Т.е. финализаторы никак не могут тут помочь. Собственно говоря, — если бы не нужно было детерменированное управление ресурсами — то и необходимости в using(IDisposable) не было бы.
С COM-ом при работе из дотнета я обходился ручным управлением, и никаких GC.Collect() звать не нужно было в принципе, хоть и писанины больше — ARC (automatic reference counting) — совершенно не требует никакого GC и тем более финализаторов. То, что в Шарпе многие предпочитают GC.Collect() — это потому что очень трудно или невозможно уследить за ссылками. Впрочем, достаточно спрятать ссылку на COM-объект и дать ей пережить сборку мусора — и тут может случается так, что COM сервер рухнет. Кстати, Excel 2003 по моему так и делал. Так, что я предпочту многословное решение которое точно работает.
F>> При чем тут синглетон? Я говорю, что объект под собой управляет одним из дорогих ресурсов, но ему по своему API никаких финализаторов не нужно. Это довольно тонкий клиент к stateful серверу в другом процессе который и берёт все тяготы жизни на себя. Сервер же имеет все средства получить всю информацию и правильно реагировать (отменять запросы), в том числе, если клиент отвалился (крешнулся процесс). S> При том, что он один и за его жизнью не надо следить. Или выполнил запрос закрылся.
С точки зрения IPC — очень даже надо. У него есть вполне ясные колбэки которые нужно звать. Но для того что бы это высвобождать — финализаторы не нужны.
F>> Но они потом перейдут в другую плоскость — GC не вызывается достаточно часто. Это тоже можно порешать. Но это может породить и новый вопрос — теперь стало медленно работать. S> Иногда просто можно вызвать Collect
Вроде браузеры таких методов не выставляют. Что-то изменилось уже?
S>>> Я просто показал пример одинакового функционала в .Net и JS, где полезны финализаторы. F>> А я и говорил с самого начала — они поэтому же и вредны. 15 лет назад народ бодро тянул .net remoting куда только мог в том числе и для межхостового обмена. И что? Прошло время — везде или WCF по возможности без колбэков или вообще web api (в широком смысле этого слова) который ещё проще WCF. S> Который проще, но значительно тяжелее. А вместо калбеков используют SignalR
Что значит тяжелее, тяжелее чего? Вместо колбэков — думаю и так понятно, что можно использовать web-sockets или другие техники эмуляции обратного канала (навроде long-polling).
Здравствуйте, TimurSPB, Вы писали:
I>>webpack это фактически тот же линкер, как в С++. Уже давно не надо готовить "один большой кусок изуродованного кода" TSP>Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода.
Байт-код
Ну реально, если разрабатываешь с webpack, то модули — это там где ты код пишешь. А объединенный-минимизированный результирующий выходной файл — это суть скомпилированное приложение. Которое скармливается браузеру, а как оно там внутри выглядит, уже не важно, руками его не правят же.
Похоже, что ты третьего не видишь, не говоря про всю палитру. Наивное предположение, что у всех одна и та же цель — стать богатым. Это только твое видение. 
