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

I>А кто тебя заставляет такой код писать ? Особенность этих wtf в том, что они встречаются в основном на форумах. Хочешь писать нормальный JS код — пожалуйста, это легко получается.

Как можно отличать "нормальный код" от "ненормального", не понимая внутренней логики языка? Никак. Вот и ищу в js логику.

TSP>>Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода.
F>Байт-код
F>Ну реально, если разрабатываешь с webpack, то модули — это там где ты код пишешь. А объединенный-минимизированный результирующий выходной файл — это суть скомпилированное приложение. Которое скармливается браузеру, а как оно там внутри выглядит, уже не важно, руками его не правят же.
Есть байт-код, есть нативный машинный код, и есть JS. Это всё разные вещи. И каждый слой должен оправдывать своё существование.
В случае JS оправдание — не развитый язык и компенсация его кривой поддержки браузерами.
Нормально это Java, ну или хотя бы .NET. А это всё шляпа.

I>>>webpack это фактически тот же линкер, как в С++. Уже давно не надо готовить "один большой кусок изуродованного кода"
TSP>>Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода.
I>У меня в проектах таких файлов нет, ничем не могу помочь.
Ну *.min.js есть?

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

I>>А кто тебя заставляет такой код писать ? Особенность этих wtf в том, что они встречаются в основном на форумах. Хочешь писать нормальный JS код — пожалуйста, это легко получается.

A>Как можно отличать "нормальный код" от "ненормального", не понимая внутренней логики языка? Никак. Вот и ищу в js логику.

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

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

TSP>>>Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода.
I>>У меня в проектах таких файлов нет, ничем не могу помочь.
TSP>Ну *.min.js есть?

Есть. Что с ними не так ? Тебя бинарники, байткод, объектные файлы тоже расстраивают ?

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

TSP>В случае JS оправдание — не развитый язык и компенсация его кривой поддержки браузерами.

В случае JS это VM которая вся целиком заточена под динамику. Именно отсюда растут проблемы. JS это считай ассемблер в переводе на динамическую типизацию. Скажем, когда я пересаживался на JS, у меня были ровно те же ощущения, как и на ассемблере 20 лет назад.

I>В случае JS это VM которая вся целиком заточена под динамику. Именно отсюда растут проблемы. JS это считай ассемблер в переводе на динамическую типизацию. Скажем, когда я пересаживался на JS, у меня были ровно те же ощущения, как и на ассемблере 20 лет назад.

JS это считай ассемблер в переводе на динамическую типизацию

Мда.. Это вносит ясность

TSP>>Ну *.min.js есть?
I>Есть. Что с ними не так ?

...+e._s(e.getShortName(t.name))+"\n      ")])])}))])},staticRenderFns:[]}}]);....

Открой и посмотри.

I>Тебя бинарники, байткод, объектные файлы тоже расстраивают ?
Иногда да. Но я хотя бы понимаю зачем они такие.

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

TSP>>>Ну *.min.js есть?
I>>Есть. Что с ними не так ?
TSP>

TSP>...+e._s(e.getShortName(t.name))+"\n      ")])])}))])},staticRenderFns:[]}}]);....
TSP>

TSP>Открой и посмотри.

Зачем ? У меня есть исходный код. Кроме того, кто мешает jsnice обработать если таки надо прочесть ?

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

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

I>>>В проектах-однодневках все так и есть.
G>>Это в любых проектах. У меня есть проекты которые уже три года развиваются, и как раз в них JS (на самом деле TS) помогает очень сильно. поправить скрипт на практике на два порядка проще, чем серверный код.

I>Надо же, а как браво начиналось "А я про linq и сейчас скажу то же самое. Только дело не в linq, а в клиентском коде. Там linq не сильно помогает. Весь серьезный сервер-сайд я до сих пор делаю на C# и никаких NodeJS."

I>И вдруг ты сам себя опроверг — оказывается, скрипт на два порядке проще править, нежели серверный код. Скоро узнаешь, что часть бакенда тоже можно делать на скрипте, потому как "поправить скрипт на практике на два порядка проще".
I>Уже хорошо, хоть не в одном абзаце противоречия лепишь.
Где ты противоречие увидел? На js клиентский код, его проще и быстрее править, чем на <подставь любимый язык>. Серверный код на c#. С учетом ef и linq его проще писать на c#.
Соотношение объема клиентского и серверного кода 80/20, клиентский код меняется а порядок чаще. Поэтому js заруливает, ни на одном другом языке так быстро не выйдет.

I>>>Ты выбрал модель "за деньги и быстро" + "кастомер всегда прав". Из этого следует, кстати говоря, что ты всегда не прав
G>>Ты хочешь быть правым или быть богатым?

I> Похоже, что ты третьего не видишь, не говоря про всю палитру. Наивное предположение, что у всех одна и та же цель — стать богатым. Это только твое видение.
Да ты дяденька демагог. Сам поставил вопрос "за деньги и быстро" vs "ты в всегда прав". А теперь хочешь в этом меня обвинить.

I>Что касается меня, то я хочу быть самим собой и обязательно счастливым. А правым или богатым — вообще дело десятое. Если самим собой и счастливым, то я бедным спокойно проживу
Еще один демагогический прием, ты конкретные понятия в обсуждении попытался заменить абстрактными.
Давай вернемся к конкретике — при прочих равных что выберешь: Остаться правым или получит деньги?
Сумма значительная. Оставшись правым ты никого ущерба не несешь.

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

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

S>> Ну после вызова
S>>

S>>GC.Collect();
S>>GC.WaitForPendingFinalizers(); 
S>>

S>> Вполне себе гарантирует. Обычно так и делвется со ссылками на COM и прочими.
S>>Он подбирает все огрехи и забывчивости.
F> Именно, что не гарантирует:
F> 1. Нет никаких гарантий о том в каком порядке будут вызваны финализаторы. В моём примере же порядок важен — Writer буфферизирующий и Stream — буфферизирующий. Очевидно, что реверс порядка приведет к потере данных.

Ну если ты используешь BynaryWriter то да. А побольшому счету Stream сам должен иметь эти методы или их добавлять через Extension.
Например BynaryWriter закрывает поток. А например мне это не надо. Мне нужно просто записать в поток (NetStream) но его не закрывать для последующего чтения.

F> 2. Нет никаких временных гарантий. "На пальцах" — забыли закрыть файл (эксклюзивный доступ) — и теперь пытаемся его открыть снова — а сборка мусора ещё не прошла? Что получается? Получается недетерминированное поведение в зависимости от фаз луны. Очевидно, что это — ошибка программы (забыли закрыть файл). Т.е. финализаторы никак не могут тут помочь. Собственно говоря, — если бы не нужно было детерменированное управление ресурсами — то и необходимости в using(IDisposable) не было бы.
F> С COM-ом при работе из дотнета я обходился ручным управлением, и никаких GC.Collect() звать не нужно было в принципе, хоть и писанины больше — ARC (automatic reference counting) — совершенно не требует никакого GC и тем более финализаторов. То, что в Шарпе многие предпочитают GC.Collect() — это потому что очень трудно или невозможно уследить за ссылками. Впрочем, достаточно спрятать ссылку на COM-объект и дать ей пережить сборку мусора — и тут может случается так, что COM сервер рухнет. Кстати, Excel 2003 по моему так и делал. Так, что я предпочту многословное решение которое точно работает.

Угу. Вручную release вызывал? Ну проще GC с определенной переодичностью вызывать А то release будет больше чем сам код

F>>> При чем тут синглетон? Я говорю, что объект под собой управляет одним из дорогих ресурсов, но ему по своему API никаких финализаторов не нужно. Это довольно тонкий клиент к stateful серверу в другом процессе который и берёт все тяготы жизни на себя. Сервер же имеет все средства получить всю информацию и правильно реагировать (отменять запросы), в том числе, если клиент отвалился (крешнулся процесс).

Вообще то он должен кинуть исключение по коду, что бы клиент мог её обработать.
S>> При том, что он один и за его жизнью не надо следить. Или выполнил запрос закрылся.
F> С точки зрения IPC — очень даже надо. У него есть вполне ясные колбэки которые нужно звать. Но для того что бы это высвобождать — финализаторы не нужны.
Если соединение закрыто, то ничего звать не надо. Но при этом мы проседаем по скорости, так как тратим время на соединение.

F>>> Но они потом перейдут в другую плоскость — GC не вызывается достаточно часто. Это тоже можно порешать. Но это может породить и новый вопрос — теперь стало медленно работать.
S>> Иногда просто можно вызвать Collect
F> Вроде браузеры таких методов не выставляют. Что-то изменилось уже?

Так речь то про то и идет, что нет финализаторов, GC.Collect которые упрощают жизнь в .Net

S>>>> Я просто показал пример одинакового функционала в .Net и JS, где полезны финализаторы.
F>>> А я и говорил с самого начала — они поэтому же и вредны. 15 лет назад народ бодро тянул .net remoting куда только мог в том числе и для межхостового обмена. И что? Прошло время — везде или WCF по возможности без колбэков или вообще web api (в широком смысле этого слова) который ещё проще WCF.
S>> Который проще, но значительно тяжелее. А вместо калбеков используют SignalR
F> Что значит тяжелее, тяжелее чего? Вместо колбэков — думаю и так понятно, что можно использовать web-sockets или другие техники эмуляции обратного канала (навроде long-polling).

Так SignalR это и есть вэб сокеты и лонг полинг. Только он практически основан на HTTP за мелким исключением. А он значительно многословен.
A WCF это в том числе и Named Pipes

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

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

F>Короче, что бы вернуться к конструктиву — можно пример на пальцах, если я вдруг пропустил — зачем именно тебе нужны финализаторы в JS?

http://rsdn.org/forum/flame.comp/6726048.1

Автор: Serginio1
Дата: 15.03.17

У меня из JS создаются на стороне .Net объекты, которые сохраняются в хранилище List и на сторону JS возвращается индекс в этом хранилище.
На стороне JS эта ссылка может храниться сколь угодно долго. По этой ссылке вызываются методы, передаются в параметрах.
Но после окончания работы с ней нужно эту ссылку освободить, для сборки мусора.
Приходится это делать вручную. Но иногда бывает, что долгоживущих ссылок может быть много, а вручную муторно освобождать.

По ссылке есть аналогичный вариант, но на .Net с финализаторами.

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

A>>Как можно отличать "нормальный код" от "ненормального", не понимая внутренней логики языка? Никак. Вот и ищу в js логику.
I>Нужно разбираться с готовым кодом. Основной код во всех языках пишется на идиомах. Вот их и нужно осваивать.

А не "основной" читать и писать не нужно?

I>Зачем ? У меня есть исходный код. Кроме того, кто мешает jsnice обработать если таки надо прочесть ?
Что бы убедится что всё это странно. Делать из текста текст, который потом движком V8 переводится в байт-код, который потом выполняется на интерпретаторе.
Как отлаживаться и профилироваться в такой цепочке — это вообще отдельная индустрия костылестроения.

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

I>> Похоже, что ты третьего не видишь, не говоря про всю палитру. Наивное предположение, что у всех одна и та же цель — стать богатым. Это только твое видение.
G>Да ты дяденька демагог. Сам поставил вопрос "за деньги и быстро" vs "ты в всегда прав". А теперь хочешь в этом меня обвинить.

Ну и директор. Учу читать бесплатно:
"за деньги и быстро" — твой подход, ты сам про это пишешь
"клиент в всегда прав" — снова твой подход, ты сам это пишешь.

Вот и выходит у тебя, раз клиент прав, то ты — нет Потому как ты сам перед собой ставишь ненужный выбор.

I>>Что касается меня, то я хочу быть самим собой и обязательно счастливым. А правым или богатым — вообще дело десятое. Если самим собой и счастливым, то я бедным спокойно проживу
G>Еще один демагогический прием, ты конкретные понятия в обсуждении попытался заменить абстрактными.

"правым или богатым" это по твоему конкретные понятия ?

G>Давай вернемся к конкретике — при прочих равных что выберешь: Остаться правым или получит деньги?
G>Сумма значительная. Оставшись правым ты никого ущерба не несешь.

Я выберу быть самим собой и счастливым. Из твоей "конкретики" ничего не ясно.

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

I>>Зачем ? У меня есть исходный код. Кроме того, кто мешает jsnice обработать если таки надо прочесть ?
TSP>Что бы убедится что всё это странно. Делать из текста текст, который потом движком V8 переводится в байт-код, который потом выполняется на интерпретаторе.

И это нормально.

TSP>Как отлаживаться и профилироваться в такой цепочке — это вообще отдельная индустрия костылестроения.

Так же, как и в любом другом ЯП.

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

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

A>>>Как можно отличать "нормальный код" от "ненормального", не понимая внутренней логики языка? Никак. Вот и ищу в js логику.
I>>Нужно разбираться с готовым кодом. Основной код во всех языках пишется на идиомах. Вот их и нужно осваивать.

A>А не "основной" читать и писать не нужно?

Он почти не встречается. Я ужасы JS встречаю в основном на wtf.js, и то, захожу туда посмеяться.

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

G>>Это какбы проблема не языка, а реализации в браузерах. Если все завтра начнут поддерживать ES 2017, то необходимости в приседаниях станет на порядок меньше.
TSP>Отсутствие модулей хоть в каком то виде это проблема языка.
Давай по порядку, какие модули ты имеешь ввиду?
1) Лексические модули — изоляция частей программы, так чтобы внутри части были видны все члены, а снаружи только часть.
2) Рантайм-модули — возможность подгружать части программы во время работы программы и менять их независимо от других частей.
Лексические модули были в JS были всегда за счет объектов и замыканий. Но это не было стандартом и это было некрасиво.
Есть неформальные стандарты amd (require.js) и commonjs (NodeJS) c 2011 примерно.

Если не понял повторяю — уже 7 лет как все желающие имеют модули в JS. Наверное не ошибусь, если скажу что это дольше, чем ты знаком с JS вообще.

Рантайм модули в js, как языке, отсутствуют, но всегда существовали в браузере.

TSP>А проблемы браузеров не отделимы от языка в случае JS. Зачем нужен язык без реализации?
Потому что кроме браузеров есть NodeJS и куча производных от него вещей. А еще есть компиляторы, которые адаптируют код для браузеров без поддержки возможностей.
Внезапно оказалось что почти все нововведения могут быть реализованы небольшой генерацией кода. (это к вопросу о мощности языка)


TSP>Нет пока никакого ES 2017, и когда он будет никто не скажет. Если вообще будет.
Будет. ES это тебе не C++, в комитете по ES вполне здравые люди и хорошие нововведения принимают быстро. Когда это доберется до браузеров — неизвестно. ES 2015 модулей до сих пор нет в браузерах. Но это не мешает использовать модули в react и angular2.

G>>Как раз буст гораздо больше дырок в языке затыкает, чем фреймворки в js. Более того, в новые версии js отлично попадают подобные "затычки".
TSP>В самом языке буст ничего не затыкает. Он его расширяет и многое потом отправляется в стандарт.
Это игра слов, которая по факту смысл не меняет.

TSP>А вот, например, $scope в angular это типичный пример костыля, который требуется понимать и правильно использовать.
$scope это кривость самого ng и без него работает уже давно.


G>>Ну также в JS. Все давно забили на то, что на выходе. Проблема только в отношении. У многих в голове сидит паттерн "js — плохо, а <подставить любимый язык> — хорошо".
TSP>Большинство забили. Но не думаю, что на больших проектах удасться полностью абстрагироваться от выхлопа этих всех богомерзких тулов.
Внезапно удается.

G>>Ты удивишься, но из 5 последних проектов jquery был только в одном.
TSP>Точно нет jquery? Покажи папку node_modules.
Точно нету, там angular.

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

A>В последнем примере отсортировалось, понятно, по алфавиту. Но какого хрена?

Так в стандарте прописано.

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

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

I>>А кто тебя заставляет такой код писать ? Особенность этих wtf в том, что они встречаются в основном на форумах. Хочешь писать нормальный JS код — пожалуйста, это легко получается.

A>Как можно отличать "нормальный код" от "ненормального", не понимая внутренней логики языка? Никак. Вот и ищу в js логику.

Нормальный код — который ты понимаешь и который использует паттерны (идиомы) привычные в этом языке (которые чаще встречаются в книгах). Если одно из условий не выполнено — код не нормальный.

Если ты не знаешь как работают функции или не знаешь идиом языка, то код для тебя не будет нормальным. Особенно ели ты пытаешься применить правила и идиомы из других похожих языков.

Поэтому у C++ников вечно проблема с кодом на Java и C#, а у всех них проблемы с JS.