Comments 288
Сейчас с WebAssembly есть риск, что обновление версии браузера может сломать работу приложения. Из недавнего обновление Safari до 13.
Как по мне javascript (ровно как и react) уже набрал свою критическую массу и сдвинуть его будет ой как тяжело.
И я бы не говорил что WebAssembly это убийца, скорей шанс для TC39 увидеть что-то интересное
И я бы не говорил что WebAssembly это убийца, скорей шанс для TC39 увидеть что-то интересное
Любое тяжелое легаси непросто забыть, если оно еще нужно)
Последние годы Javascript перенял много фич, которые первоначально появились в Typescript (OOП модель, асинхронные обёртки типа promises и async/await, и многое другое), да и вообще начал быстро развиваться в конструктивном направлении. Вот если когда-нибудь он переймет и основную фичу Typescript — статическую типизацию, то сдвинуть его каким-либо другим языком будет практически нереально.
Согласен
Но JavaScript перенимает очень медленно, что на типы и не приходится надеятся.
К примеру только сейчас появляется Optional Chaining, который был в CoffeeScript уже больше 5 лет назад
А можно на пальцах? Вот чем динамическая типизация хуже статической? Просто это всё как мантра из поста в пост передаётся.
UFO just landed and posted this here
Что одновременно сразу резко повышает трудозатраты на разработку. JS ведь стал таким популярным не потому что он так хорош, а что это некий вменяемый компромисс между порогом вхождения в разработку и качеством продукта.
Статическая типизация — это же никакая не панацея.
Статическая типизация — это же никакая не панацея.
UFO just landed and posted this here
Как и не надо говорить о статичнской типизации как о строгой и мощной системе типов по умолчанию.
Погодь — так разве Java не язык с строгой статической типизацией?
А в С++ напротив типизация динамическая — привет "*_cast<>" — ам
А в С++ напротив типизация динамическая — привет "*_cast<>" — ам
UFO just landed and posted this here
JS стал таким популярным, потому что его поддержали браузеры без дополнительных плугинов.
JS ведь стал таким популярным не потому что он так хорош, а что
… был и остаётся монополистом.
UFO just landed and posted this here
Чтобы когда в проекте из сотен js-файлов наводишь на функцию в своей любимой IDE'шке, и она сразу показывает, что в эту функцию передается.
Я думал, JS из ActionScript'а тащит фичи. Век живи, век учись…
Все то что вы перечислили что JS перенял из TS-а это не правда, классы были во времена ES4 (2000-2008), промисы предложили для стандарта ES6 в 2012 когда TS только появился на свет, до этого еще в 2011 были deffered objects в jQuery, async/await взят из C#. TypeScript еще никак не повлиял на развитие синтаксиса JavaScript или на другие части языка, да, он дополняет JavaScript своими типами, областью видимости, интерфейсами, enum-ами, и так далее, но пока что ничего из того что TypeScript предоставляет не было добавлено в стандарт EcmaScript.
Когда промисы приняли в JS, это было в версии ES6, то есть 2015 год, в TS они уже 3 года как работали, и синтаксис был такой же. Да, async/await взят из C#, но создатель C# и создатель Typescript — это один и тот же человек, Андерс Хайльсберг. То есть, получается, С# имеет влияние на TS, а TS в свою очередь на JS.
ООП в JS было с самого начала. Не было именно синтаксиса class, но это уже на вкус и цвет. Мне, к примеру, обычный синтаксис нравится немного больше, чем class.
Я не верю в полноценное убийство жаваскрипта вебассемблей просто потому, что на JS очень удобно писать glue code, высокоуровневую бизнес-логику. То, что сейчас происходит (ну, начинает происходить) — «тяжелые» библиотеки переползают на WebAssembly (см. например libsodium), высокоуровневый код остается на JS, и все более-менее счастливы.
Многие проекты выработали аналогичную структуру, двигаясь в обратном направлении: начали с «библиотечного» С++, а затем прикрутили сверху скриптовый язык для glue code. В World of Warcraft для скриптинга выбрали Lua, в Qt теперь QML (== жаваскрипт вид сбоку), и так далее.
Многие проекты выработали аналогичную структуру, двигаясь в обратном направлении: начали с «библиотечного» С++, а затем прикрутили сверху скриптовый язык для glue code. В World of Warcraft для скриптинга выбрали Lua, в Qt теперь QML (== жаваскрипт вид сбоку), и так далее.
QML ни разу не легковесный. Разработчикам Qt пришлось писать AOT и JIT компиляторы.
Но удобный != легковесный. (Ну т.е. легкость использования != простота имплементации.)
Алсо есть же LuaJIT например.
Алсо есть же LuaJIT например.
А LuaJIT не заведется на iOS.
Ну и что? QML JIT тоже, только это ведь не относится к предмету дискуссии никоим образом.
AOT != JIT. И на iOS он не JIT. QML никогда не позиционировался как язык, для glue code, потому что это декларативный язык разметки нацеленный на UI.
UFO just landed and posted this here
ИМХО язык никого не может в принципе побуждать писать плохой код. Лично лицезрел приложение на Java, втиснутое в один класс и в цикле, загружающее рекламу и расписание показа с удаленного сервера и показывающее эту самую рекламу. Кода было экранов на пять. Не язык программирования красит разработчика ;)
UFO just landed and posted this here
UFO just landed and posted this here
- Это правда, но то, насколько сильно нужно постараться, чтобы написать не говнокод, от языка к языку сильно различается. И дело не в криворуких программистах, а именно в концепциях, на которых строится дизайн языка.
- Ничего подобного — сравните developer experience, когда среда сама подсказывает вам все аргументы\поля\методы, и когда вам на каждый чих нужно лезть в документацию на гитхабе (которая может быть неполной, неактуальной или вообще отсутствовать).
- См. пункт 1.
- Если работаешь с вебом — избежать работы с джиесом, увы, невозможно.
И дело не в криворуких программистах, а именно в концепциях, на которых строится дизайн языка.
Вы пишете какой-то поэзией там, где неплохо бы как раз применять точные термины. «Дизайн языка» — это что?
Базовые концепции всех императивных языков примерно одинаковые и функционируют примерно одинаково везде. Концепции DSL (взаимодействие с браузером и документом) в нынешнем JS реализованы очень банально и просто, говнокодить там просто негде. Дополнительные плюшки, «синтаксический сахар» (хотя, строго говоря, не обязательно именно синтаксический), артефакты обратной совместимости — существование этого всего можно просто игнорировать, если вам не нравится качество (скажем, сегодня никто вас не заставляет руками составлять XML из базовых типов, хотя это безусловно возможно сделать). И конкретно для JS на ваше
Это правда, но то, насколько сильно нужно постараться, чтобы написать не говнокод, от языка к языку сильно различается.
я вам могу просто ответить «Изучайте современный JS. Не изучайте JS десятилетней давности», и вопрос будет исчерпан.
Ничего подобного — сравните developer experience, когда среда сама подсказывает вам все аргументы\поля\методы
Возможности IDE и ограничения языка — это две абсолютно разные вещи. Вам писали про второе, а вы ответили первым. Если (чисто как пример) в языке не существует циклов, то никакая IDE вам его не сделает настолько удобным, что вы его предпочтете языку с циклами.
Базовые концепции всех императивных языков примерно одинаковые и функционируют примерно одинаково везде.Смешно, что многие из этих базовых концепций работают одинаково во всех остальных языках, но не в джиесе :)
Изучайте современный JSА что там исправили? Запретили monkey patching объектов, неявное приведение, передачу несовпадающего количества аргументов в функцию, исправили семантику `Foo() / new Foo()`, устранили возможность абсолютно любому скрипту нагадить в глобальную область или подменить функцию стандартной библиотеки? Из полезного добавили разве что приватные поля — да и то с костылями из-за проблем с обратной совместимостью.
Возможности IDE и ограничения языка — это две абсолютно разные вещи.Кто вам сказал такую глупость? Эти вещи тесно взамосвязаны. Из-за динамической природы языка для джиеса впринципе невозможно реализовать автокомплит\рефакторинги уровня IDEA\R#.
А что там исправили? Запретили
Вы тоже из тех, кто возможность выстрелить себе в ногу приравнивает к выстрелу?
Как насчёт того, чтоб просто не стрелять?
И нет, аргумент «в более крутых языках возможностей выстрелить себе в ногу меньше, а поэтому там пишут меньше говнокода» не принимается, пока вы его не докажете. Моя практика показывает, что объем говнокода почти исключительно зависит от общего объема пишущегося кода, а не от языка. Стала ява чуть более популярной, и вот уже никакая «строгость» не мешает людям сделать рефлексией то, что им компилятор не даёт сделать напрямую. Если в какой-то момент какой-нибудь хаскель станет жутко популярным (впрочем, навряд ли) — мы увидим множество интересных способов отстрелить себе ноги там.
Эти вещи тесно взамосвязаны.
Возможности IDE вытекают из ограничений языка, а не наоборот. Поэтому не стоит на аргумент об ограничениях языка отвечать «а вот IDE оооо!». Я вам писал именно об этом. Вы предпочли этого не заметить, а избирательно процитировать и спорить дальше.
Как насчёт того, чтоб просто не стрелять?Для этого надо быть сверхчеловеком, который сам никогда не ошибается, не работает с джунами, не поддерживает легаси и вообще не использует сторонние библиотеки. К сожалению, в реальном мире я таких не знаю.
Стала ява чуть более популярной, и вот уже никакая «строгость» не мешает людям сделать рефлексией то, что им компилятор не даёт сделать напрямую.Так это правильный баланс между гибкостью и надежностью. Нет такого языка, который мог бы вообще не дать написать на нем некорректную программу. Однако в той же джаве «целевое» использование объектов заметно проще и короче, чем «нецелевое» с помощью рефлексии, а в джиесе они равнозначны.
Я вам писал именно об этом.Изначальный постулат был — «ограничения усложняют разработку». Я привел пример того, как некоторые ограничения ее наоборот упрощают. Вашу же мысль я в обоих сообщениях так и не уловил…
UFO just landed and posted this here
Я про себя знаю, что я глупый, забывчивый и иногда бываю невыспавшимся.
Мне сложно себе представить, что я от забывчивости или от недосыпа вдруг начну применять в яве рефлексию просто потому что. Или в JS буду на лету патчить прототип.
От таких вещей можно написать нерабочий код, но не говнокод через использование заведомо глубоко небезопасных фич языка. А глупость стоит лечить образованием.
Тесты? Как насчёт того, чтобы просто не делать ошибок?
Рефакторинг? Как насчёт того, чтобы сразу писать нормально?
Джаваскрипт на бэкенде? Как насчёт того, чтобы выучить C++ за 21 день и на нём быстро писать?
Вы передергиваете. Изначальная соль метафоры с «выстрелом в ногу» как раз и заключается в том, что в ногу можно стрелять, а можно не стрелять. И стреляя — нужно осознавать последствия.
Если у языка есть глубоко небезопасные и вообще кривоватые фичи — их можно не использовать. Это совсем далеко не то же самое, что «не делать ошибок». Мне очень странно, что вы тут сделали вид, что не понимаете разницы.
Но нет, способов выстрелить в ноги там очень мало.
Про яву так в свое время тоже говорили. Всерьез говорили.
UFO just landed and posted this here
К сожалению, в проектах, которые я пишу, кроме моего кода есть ещё и чужой код, и он даже иногда обновляется. И какую ерунду он там делает, мне верифицировать каждый раз неохота.
К счастью, для этого придумали средства. От code review до автоматического линтинга с запретом всего, что стоит запретить. Если ими пользоваться — большая часть проблем таки решается.
А если 30 человек фигачат в блокнотах и пушат в мастер — ну, кто ж им доктор.
UFO just landed and posted this here
Проблема стороннего кода (и пакетных менеджеров, до кучи) вообще ни разу не сопрягается с языком. Вы используете какой-либо чужой код (от библиотек до функций ОС)? А как вы убеждаетесь, что он биткоины не майнит?
И абсолютно не важно, на чём это всё написано, и на чем написан ваш код.
И абсолютно не важно, на чём это всё написано, и на чем написан ваш код.
UFO just landed and posted this here
Если это так, то можно дальше даже не смотреть, если не так, то разбираюсь внимательнее (но это на моей практике бывало очень редко).
Вы же понимаете, что вы сейчас описали страну розовых пони вида «мне мало что нужно, а что нужно, то есть в опенсорсе, и в моем языке небезопасные вещи объявляются отдельно»?
Что нисколько не решает проблему в общем виде. С тем же успехом могли бы сказать «я не использую чужого кода» (а моя ОС написана мной самим). Вышли бы те же розовые пони.
UFO just landed and posted this here
потому что я этот подход успешно реализую на практике
И делаете ошибку выжившего в разговоре вот сейчас.
UFO just landed and posted this here
Я привел контрпример, когда язык вполне даёт возможность гарантировать, что какой-то код так не делает.
Вы привели контрпример, в котором сделано множество допущений. Начиная с того, что вам доступен исходный код и вы собираете его сами достоверно надёжными средствами сборки (которые вы тоже собрали сами), в достоверно надёжном окружении (которое вы сами — что? правильно, начиная от самого железа), заканчивая тем, что, дескать, если чо, то вы будете «разбираться внимательнее» (без подробностей).
Ваш тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов возможно всегда и не зависит от языка.
Вы передергиваете. Мой тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов в условиях среднестатистического окружения никак не коррелирует с тем, на каком языке написан ваш (ключевое слово) код.
С «возможно всегда», которое вы сами придумали и которое доблестно попытались развенчать — сами и воюйте, если вам интересно.
UFO just landed and posted this here
Кроме того, code review и линтинг предложили вы сами.
Как средство борьбы с появлением плохого кода у себя.
Как средство контроля внешнего кода — это такой себе выход, эффективность которого сомнительна в произвольной степени.
Зачем? Это не нужно для того, чтобы обезопаситься от кривой библиотеки.
Затем, что в конечном счете разговор о майнерах и снифферах в контексте «в моем коде этого нет» не имеют ни малейшего практического смысла. Либо майнера и сниффера у вас нет совсем и вы можете гарантировать, что исполняемый код, так или иначе связанный с запуском вашей крутой программы, не несет в себе потенциальных угроз, или это всё пустые разговоры а-ля «в исходниках нет, а прочие проблемы меня не волнуют». Чудесный код, сам по себе не делающий ничего особенного, а-ля, скажем, TeamViewer — может быть использован для множества очень интересных сценариев, если будет написан с определенными уязвимостями.
В контексте этого разговоры «я если чё почитаю код и оценю, насколько в нём всё ок» — это тоже мир розовых поней. Вы не всесильны и не всезнающи.
Давайте ещё раз на него посмотрим
Попробуйте не вырывать предложения из контекста, и всё будет гораздо лучше.
UFO just landed and posted this here
Мы не можем гарантировать отсутствие закладок в компиляторе и ОС, поэтому давайте забьём на любой анализ последнего left-pad. Понятно.
Ложная дихотомия.
Я вам о том, что можете заисследовать left-pad, а ваш софт всё равно в итоге будет майнить.
К счастью, пока что во всех случаях, когда я натыкался на unsafePerformIO, unsafeCoerce и тому подобные вещи в коде чужой библиотеки, их удавалось избежать и переписать.
Вы опять взялись за «я делаю всё хорошо и правильно, значит в мире всё окей».
Я специально указал, что (на мой взгляд, конечно же) про среднестатистическое окружение в вашем комментарии ничего не было
В моем комментарии так же не было и «помайнить возможно всегда», на которое вы уже который комментарий пытаетесь наехать с позиций особых лабораторных условий, в которых таки кое-что будет невозможно. А было только лишь «помайнить равновероятно можно в коде на любом языке».
если вы согласитесь, что есть языки, предоставляющие возможности проверять библиотеки без ложноотрицательных (т. е. не нашли ерунду, когда она там на самом деле есть) срабатываний и с очень малой долей ложноположительных срабатываний, то вопрос будет исчерпан сам собой
Как только вы обоснуете это чем-нибудь более интересным, чем «я вот что-то там пишу, и оно у меня пока что не майнило, и я считаю, что и не сможет» — непременно.
UFO just landed and posted this here
Но я топлю не за это, а за то, что вы можете решить кучу проблем относительно бескровным методом.
Конечно. Один из таковых методов называется «не пользуемся пакетными менеджерами». К языку отношения не имеет.
Если у вас в типе функции нет IO и она не использует полтора unsafe-хака (которые может проверять компилятор), то она не может майнить. И вызываемые ей функции не могут майнить. И так далее.
Функционально такой же (но плохой и непроверяемый) код на JS, никак не взаимодействующий с внешним миром — равновероятно не может майнить.
Вы упираете в то, что вы можете «просто глянуть на типы» и быть в чём-то там уверенным. Я вам говорю о том, что просто глянув на типы вы можете быть уверенным в чём угодно, но только не в том, что в итоге оно всё не будет майнить. Для серьезного повышения уверенности — вам нужно или писать очень специфический камерный код (но в этом случае вы и на JS можете писать камерный код), или вы так или иначе будете взаимодействовать с чем-то за пределами вашего кода, для чего безопасность вы не обоснуете.
UFO just landed and posted this here
А может и майнить.
Ваш мобильник не управляет вами, даже если вы в этом не уверены.
Аналогично, код, который не майнит — не майнит. Проверяете вы ли его тайпчекером, ревьюверами, статанализом, или, наконец, файрволлом.
Мой тезис про равновероятность на разных языках — он всё таки «при прочих равных», а не «на хаскеле у меня один код, а на JS другой, и первый скорее всего не майнит, а второй скорее всего да».
UFO just landed and posted this here
Смысл в том, что когда вы начнете писать что-то, что взаимодействует с внешним миром — вы больше не сможете сказать, что раз у вас в коде типы норм, то ничего майнить не будет.
UFO just landed and posted this here
Безусловно, тогда мне придётся просмотреть реализацию того, что взаимодействует с внешним миром.
Что ничего не гарантирует.
Более того, для вещи, которая взаимодействует с внешним миром в виде работы с БД, у меня всё равно могут быть гарантии, что она не читает из файлов или не шлёт запросы по HTTP.
Но раз уж мы тут довели беседу до таких глубин — то вообще-то отсутствие связей с внешним миром — тоже такой себе гарант невредоносности кода. Код может вредоносить банальным отжиранием ресурсов во время выполнения.
UFO just landed and posted this here
Интересно, чем это джаваскрипт способствует написанию плохого кода? Крайне удобный язык и часто им пользуюсь
Я не знаю способствует он или нет. И возможно это просто я один такой везучий. Но почему то на JavaScript мне попадалось и всё ещё попадается гораздо больше плохого(а местами даже просто ужасного) кода чем на других языках.
Неявное приведение типов, неконсистентность стандартной библиотеки, легкость monkey-patching'а, отсутствие поддержки приватного состояния (по крайней мере до недавнего времени)… Вот нескольки смачных примеров: https://wtfjs.com/
UFO just landed and posted this here
UFO just landed and posted this here
Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.Ну вот сходите по ссылке и посмотрите, сколько из примеров вы сможете полноценно объяснить знанием нескольких базовых правил :)
Современные браузеры очень консистентныМой любимый пример: `new Date(2019, 10, 23) == new Date(«2019-10-23»)` дает `false`, попробуйте угадать почему.
Типичные аргументы хейтеров, не прочитавших хоть какую-нибудь документацию. Эффект «утёнка»: «а у нас в языке не так!»Ровно наоборот: работа с несколькими языками дает возможность сравнить и понять их сильные\слабые стороны, а вот если человек кроме джиеса ничего не знает — то он вполне ожидаемо будет по-утиному оправдывать его недостатки…
UFO just landed and posted this here
два разных объекта
Тут скорее всего имелось ввиду, что при передаче аргументов конструктора в виде чисел 10 — это ноябрь.
Тоже самое что сравнивать
({} == {})
А вот сравнение объектов (< или >) выполниить нельзя, а даты — пожалуйста.
Никто в здравом уме не будет писать такой код в продакшенС джунами никогда не работали?
два разных объекта (любых непримитивов) никогда не равны друг другуОкей, немножко усложним:
new Date(2019, 10, 23).toString() == new Date("2019-10-23").toString() все еще дает false…UFO just landed and posted this here
Объясните балбесу в чём тут прикол. Я не понял. Не прикалываюсь, действительно интересно.
В двух примерах это разные даты. Так же тут ещё есть всякие зоны, летнее время и т.д.
В двух примерах это разные даты. Так же тут ещё есть всякие зоны, летнее время и т.д.
UFO just landed and posted this here
Вроде логично — сравниваются строки, а не сами даты. Если строки не совпали, то это false.
Почему-то думал, что тут какая-то нелогичная магия, а тут вроде по делу.
Почему-то думал, что тут какая-то нелогичная магия, а тут вроде по делу.
Логично ли, что умолчательные таймзоны необоснованно разные?
UFO just landed and posted this here
Ничего не мешало сделать семантику конструкторов консистентной, в ту или другую сторону. Предположения авторов неочевидны для читателя.
Кому какое дело? Эта милая особенность — это на многие годы часть стандартной библиотеки языка.
Ведь даже в Java, на которую, как мне кажется, тут кивают, уже успели добавить адекватную стандартную замену с недвузначными именами (
весь Date — это заимствованные методы.
Кому какое дело? Эта милая особенность — это на многие годы часть стандартной библиотеки языка.
Ведь даже в Java, на которую, как мне кажется, тут кивают, уже успели добавить адекватную стандартную замену с недвузначными именами (
LocalDateTime и ZonedDateTime).UFO just landed and posted this here
даже непрошедшие испытательный срок таких ошибок не делалиОстается только позавидовать вашей сверхъестественной везучести, опровергающей закон Мёрфи, и вере в человечество :)
Date — это не javascript-way сущность, и потому совсем не показательно с точки зрения языкаЧто она тогда делает в стандартной библиотеке? Почему ее нельзя было сделать javascript-way? Или javascript-way — это собрать некое подмножество хорошо удавшихся вещей, а про остальные сделать вид, будто их не существует?
UFO just landed and posted this here
Или javascript-way — это собрать некое подмножество хорошо удавшихся вещей, а про остальные сделать вид, будто их не существует?
Именно. javascript очень повезло тем, что в него не стесняются вводить хорошее и новое, по сути отказываясь от старого. И javascript поразителен тем, что для того чтобы на нем писать адекватный код, достаточно знать всего три вещи: как объявить функцию/замыкание/класс/объект (используя всего одну языковую конструкцию), что такое async/await, и что такое Typescript.
Я много лет потратил на изучение С++. Каждый год чувствовал, что вот теперь я что-то понимаю. И каждый раз решая простейшую задачу, которая обычно сводится к банальному «вызови мне то, пока я сам не знаю что» городил многоэтажные конструкции из наследования, шаблонов, а порой и директив препроцессора… Радовался, как у меня тут все безопасно вызывается. Ухмылялся, читая статьи про javascript вроде «посмотрите на это уродство — не укажите radix в parseInt и все, не оберетесь»,- и почему-то забывая, насколько уродливо та же операция делается в С++.
Вот Вам приходилось на С++ строку разбить на подстроки, если разделитель не пробел? Как Вы думаете, там это выглядит, str.split(x)? Как бы не так. Нужно написать десяток строк магии перенаправления одних потоков ввода-вывода в другие, посмотрев на которые человек, даже знающий С++, не сразу скажет, что они делают. И там вся стандартная библиотека такая. И поколения программистов еще умудряются этим гордиться. Что они поняли и выучили эту хрень. А самое грустное, следовать подобному стилю. Что написать str.split(x) — это по какой-то причине жутко не эффективно, потоконебезопасно, и вообще придумано для домохозяек, которые нормальный язык освоить не могут.
А я теперь стал «домохозяйкой» и последние три года пишу на javascript. Он меня радует каждый день. Меня в нем ничего не бесит. Потому что все, что могло бы бесить, можно просто не использовать ("===" почему-то не бесит, честно). И эта возможность поразительна.
И поэтому я уверен, что если бы мне сейчас предложили научить человека с улицы не писать говнокод, я бы учил его javascript. Потому что грамматику языка, которую он будет использовать 95% времени, можно объяснить за два часа, а все оставшееся время посвятить тому, что такое говнокод и как его не писать. В то время как с С++ новичок бы просто утонул в виртуальных деструкторах и итераторах, и там вообще первые пару лет было бы не до обсуждения, что такое говнокод, а что нет.
Можно возразить, что дескать, сравнил теплое с зеленым, но ведь статья как раз об этом, с посылом — «Ох, как круто, сейчас запилим наш любимый [подставить название языка] в браузер и заживем!».
два разных объекта
Тут, скорее всего, имелось ввиду, что 10 — это ноябрь, при передаче аргументов в конструктор в виде чисел.
Тоже самое что сравнивать
({} == {}) // false
Даже интересно стало, а какие языки способствуют написанию хорошего кода?
Целый один класс на 5 экранов с циклом называть громким именем «приложение» как-то неправильно.
Только в период замены — начнётся такая неразбериха… Как лет 10 назад — когда постоянно приходилось выбирать — JS или Flash. Только-только всё устаканилось… Ориентироваться вообще надо сейчас только на один движок — Chromium. Один язык. Одни возможности. И давайте снова революцию устроим?
Вангую, что кода webassembly притрётся, все будут говорить: «Вы знаете, на PHP/Python/Rust/Java/Kotlin/C#/Haskel/Go/ELM/Scala/C++/Ruby очень удобно писать glue code, высокоуровневую бизнес-логику» и никто не будет ничего доказывать, потому как ну и так же всем ясно.
UFO just landed and posted this here
Про QML — ну основное окно 3D редактора точно на C++ пришлось бы делать, а всякие обвязки и менюшки вполне можно на QML. Plasma ведь переписали на нем.
А TypeScript например? Вполне няшевый язык же.
Вообще это вопрос зоны комфорта, я могу запросто eumorozov из треда выше понять, про идиосинкратическое неприятие. У меня с руби такое, прямо соки говн. А к жаваскрипту привык, уже вроде и нормик.
Вообще это вопрос зоны комфорта, я могу запросто eumorozov из треда выше понять, про идиосинкратическое неприятие. У меня с руби такое, прямо соки говн. А к жаваскрипту привык, уже вроде и нормик.
«Always bet on JavaScript» ©Brendan Eich
WA обречён быть нишевым. Ибо JS — не единственное легаси в web. HTML/CSS также преисполнены неочевидных решений, из-за того, что развивались эволюционно. И JS с их замороками отлично интегрируется — взять хоть возможность доступа к элементу по ID тупо через сверхглобальный скоуп, или хэш style с приведёнными в camelCase CSS-свойствами. А уж возможность превратить весь интерфейс приложения в RichText-редактор установкой единственного свойства contenteditable — вообще кошмар в плане учёта нюансов, с которыми приходится бодаться разработчикам браузерных движков.
Родной брат HTML — XML — в своей нише практически убит JSON'ом. Причина — он слишком «текстовый»: отступы смешаны с текстом, есть два независимых средства иерархии (атрибуты и вложенный текст/теги), извращённое экранирование. HTML, в то же время, жив, и страдает не только от этих, но и от большего количества проблем (особенно HTML5, в котором понаразрешали всякую дичь). Особая беда — возможность мешать теги с текстом, что приводит к наличию TextNode, которые не являются полноценными элементами и усложняют написание стилей и обработку событий.
CSS же — как Perl; в нём соседствуют по нескольку способов сделать одно и то же, из разных эпох: строчные/блочные элементы, абсолютное/относительное позиционирование, таблицы, float'ы, flexbox'ы, grid'ы… По отдельности они более-менее предсказуемы, но превращаются в труднопредсказуемый кошмар, если смешаны вместе. И могут серьёзно влиять на производительность рендеринга страницы из-за мелкой оплошности.
В результате имеем ситуацию, когда популярные фреймворки нахлобучивают поверх всего этого инновационные, более строгие технологии. JS уже этим «переболел», многочисленные препроцессорные языки (кроме, пожалуй, TypeScript) умерли, ибо реально стоящие инновации принимаются в стандарт языка, а Babel позволяет использовать их до достижения поддержки установленными у пользователей браузерами. В то же время препроцессоры для HTML (JSX/Pug/Polymer/etc.) и для CSS (SASS/Stylus/CSS-in-JS/etc.) живут и здравствуют.
И пути решения проблемы тут два: либо сделать новый HTML6, даже более строгий, чем XHTML, но сохраняющий всю гибкость современного web, — либо заменить нахрен весь технологический стек, и от web останется одно название (привет Skype и Nokia). Вполне возможно, что это будет сторонняя библиотека, отрисовывающая GUI, например, поверх WebGL, которую позднее включат в браузеры — как это было с LWUIT для J2ME, и как было с fetch и Promise'ами в самих же браузерах. Особенно вероятно, что такая технология «выстрелит», если она будет поддерживать создание интерфейса одновременно для VR/AR и для классических 2D-экранов — HTML/CSS для подобного не подходят вообще.
Зачатком чего-то революционного является AMP, но он слишком ограниченный. Ещё была библиотека DreemGL от Samsung, которая скорее мертва. Возможно также появление WebGL-бэкендов у уже использующихся фреймворков, по аналогии с React Native/Vue Native. Но пока web представляет собой тонну легаси, которое по сути своей не может быть высокопроизводительным и надёжным, несмотря на тонну оптимизаций в движках — замена одного лишь JS на WA ситуацию не спасёт.
либо заменить нахрен весь технологический стек, и от web останется одно название
Ставлю на этот вариант в исторической перспективе.
(привет Skype и Nokia).
А что именно у них имеется в виду?
создание интерфейса одновременно для VR/AR и для классических 2D-экранов
Пока что такие интерфейсы не пользуются популярностью, сомнительно, что это нужно.
А что именно у них имеется в виду?От них остался один лишь бренд. Современный Skype ни технически, ни даже по функциональности не имеет отношения к тому, который был до покупки Microsoft'ом — это перекрашенный MSN Live с поддержкой учёток от Skype, по сути. О Nokia и говорить нечего, все наработки мобильного подразделения (Symbian/Meego/Series 30/Series 40, шрифты, патенты и т.д.) остались у Microsoft; HMD просто паразитирует на известности бренда и продаёт совершенно не имеющие отношения к «той» Nokia мобильники на Android/KaiOS.
Пока что такие интерфейсы не пользуются популярностьюПросто их время ещё не пришло. Текущие VR/AR-разработки опережают своё время, как Apple Newton и webOS. Для них пока нет достаточно распространённого высокоскоростного доступа в Интернет, да и сами очки поныне слишком громоздкие — в идеале они должны стать не более громоздкими, чем обычные, чтобы обрести массовость.
UFO just landed and posted this here
Dart слишком давно мёртв, чтобы вышло его зафорсить. Он появился именно как один из «препроцессоров» для JS, в этой роли не взлетел — а сейчас-то у него и подавно весомых преимуществ нет, кроме «языка для Flutter».
А в случае агрессивного форса и замены Android на Fuchsia, Google рискует повторить историю с Windows Mobile/Windows Phone. Подсуетится Samsung с Tizen, китайцы тоже чего-то замутят — и кому станет нужна операционка от гугла?
У гугла есть козырь: обратная совместимость. Также как сейчас можно запустить APK на хромобуках, в фуксии будет нечто аналогичное, если, конечно, она выйдет как конечный продукт. А у майкрософта такой возможности не было, перенести винмобайл приложухи без пальце-ориентированного интерфейса в WP было бы безумием. Они конечно подсуетились с выходом WP10, сделали некий конвертер приложений iOS/Android в WP, даже инстаграм сконвертировали, но как технология дерьмо, да и шанс они свой давно упустили.
обратная совместимостьBB OS 10 и Sailfish OS как-то не особо помогла совместимость с Android-приложениями. Мало того — Google уже ломает совместимость со старыми приложениями в Android, и будет ломать дальше. Странно полагать, что в Fuchsia с совместимостью будет хорошо.
в фуксии будет нечто аналогичное, если, конечно, она выйдет как конечный продуктЭтого мало. Android в своё время убил целую кучу операционок, как смартфонных, так и фичерфонных. Причина — открытость и единые дрова, хоть и проприетарные. Проще смешивать в одном аппарате запчасти от разных производителей. Проще войти на рынок, отчего расплодилась тонна Android-ноунеймов, затмившая даже гору MTK-ноунеймов «с телевизором» в 00-х. По этой же причине проще войти на рынок операционкам, основанным на Android или совместимым с ним на низком уровне: YunOS, B2G/KaiOS, Tizen — они выпускаются в виде кастомов, иногда официально в виде дуалбута или вариантов аппарата с разными ОС, также просто в аппаратах на этих ОС переиспользуется железо, которое уже применяется в Android-мобильниках.
В Fuchsia же — полностью не совместимое ни с чем ядро. Соответственно, стоять будет лишь на гугловских девайсах (Pixel или новая линейка), и у тех полутора производителей, которые заинтересованы именно в сотрудничестве с Google и предоставлении гуглосервисов (потому что своих нет). Остальных интересует в первую очередь экосистема драйверов, и тут Fuchsia вообще не конкурент Android. Если Google бросит Android — они скорее подхватят его и общий форк сделают, или возьмут что-то другое линуксовое.
перенести винмобайл приложухи без пальце-ориентированного интерфейса в WP было бы безумиемВполне вероятно, что ко времени выхода Fuchsia парадигма управления опять изменится.
Google уже ломает совместимость со старыми приложениями в Android
Конкретнее? Я не замечал такого.
В Fuchsia же — полностью не совместимое ни с чем ядро
Ну и что? Для рядового девелопера ядро ничего не значит, как я уже сказал выше. Если будет совместимость с уже текущими тулчейнами и приложениями, никто и не заметит изменений. Проблема будет только с вендорами, поскольку явно придётся бекпортировать драйверы, хотя функсия уже содержит в себе стандартный набор драйверов.
Конкретнее? Я не замечал такого.https://developer.android.com/about/versions/marshmallow/android-6.0-changes и аналогично по другим версиям. Некоторые изменения, в особенности касающиеся прав доступа, затрагивают и старые приложения.
никто и не заметит измененийИзменения неизбежны, иначе овчинка выделки не стоит. Fuchsia — не «Android с новым ядром», а принципиально новая ОС. Подобное уже было с Mac OS X: несколько релизов подержали Rosetta для старых приложений, потом выкинули.
Для рядового девелопера
Проблема будет только с вендорамиВы считаете, что девелоперы важнее вендоров? Оно отчасти так, компании подстраиваются под предложение на кадровом рынке. Вот только под что девелоперы писать будут, если Fuchsia станет маргинальщиной, как Windows Phone? Вон орава дельфистов побежала переучиваться, потому что разработка только под десктопную винду стала неактуальной.
Некоторые изменения, в особенности касающиеся прав доступа, затрагивают и старые приложения.
Не затрагивают они никого, вы заблуждаетесь. Затрагивают только если у приложения Target API равен или выше 6.0, то есть для новых версий приложений (и то если разраб захочет, или гугл повысит требования в плей маркете). Поэтому старые версии всегда и везде работают так, как и работали до этого.
Вы считаете, что девелоперы важнее вендоров?
Что у гугла, что у майкрософта сильные связи с вендорами. И в общем то WP была далеко не маргинальщиной: на старте она заинтересовала многих вендоров (ибо это сделал именитый майкрософт): htc, samsung, nokia, lg, dell, fujitsu, alcatel, zte, acer, даже prestigio выпустили девайс на WP8. А потом майкрософт допустил две стратегические ошибки: 1) сменили ядро у WP8 (было CE стало NT) и автоматом сделали невозможным обновление WP7 до WP8 2) приложения WP8 не были совместимы с WP7, это можно рассматривать как кидалово относительно новых пользователей WP, которых по сути заставили снова покупать устройства, только уже с WP8, если они хотели апдейты и новые приложения.
Ну а дальше рассказывать нет смысла, такие косяки со стороный майкрософта в новой ОС попросту не привлеки пользователей, а значит и девелоперов тоже, плюс к этому рынок был насыщен андроид-устройствами, и будучи андроид или ios разрабом, необходимо было изучать новые инструменты и языки, чтобы писать на WP, что также мало кого интересовало на фоне низкой доли на рынке. И вины вендоров тут попросу нет, ибо они изначально были заинтересованы данной ОС и выпускали свои девайсы. А перестали выпускать только лишь из-за низкой реентабельности, причины которой рассмотрены выше.
Так что решать вам, кто важнее в данной ситуации — девелопер или вендор.
Поэтому старые версии всегда и везде работают так, как и работали до этогоНу чтобы прямо не запускались — такого вроде нету. Но некоторую функциональность ломают. Например, статистику использования контактов. В менее печальных случаях (например, доступ к общей ФС) может понадобиться выдать приложению права через настройки.
Что у гугла, что у майкрософта сильные связи с вендорамиБыли. Сейчас эти вендоры ушли на второй план. Европейские компании продали мобильные направления китайцам, из азиатских некитайцев держат планку только Samsung и худо-бедно LG/Sony.
ибо это сделал именитый майкрософтНу только это на первых порах и спасало, дав долю рынка чуть выше плинтуса. Для того же приобрели бренд Nokia: многие покупали Lumia из-за верности бренду.
и автоматом сделали невозможным обновление WP7 до WP8Велика беда. Apple на старые айфоны бесконечно новую iOS не портирует, а если и портирует, то она заведомо начинает тормозить, стимулируя купить новый. В Android-зоопарке с обновлениями ещё печальнее. M$ на этом фоне наоборот — выглядят выгоднее, ибо исправились и обеспечили обновление с WP8 до WM10.
плюс к этому рынок был насыщен андроид-устройствамиА до этого был насыщен J2ME, Symbian, WM. Чего ж разработчики-то перебежали? Ладно WM умер, но Symbian имел внушительную долю относительно Android/iOS, пока его M$ же не похоронил ради насаждения WP. А китайфоны с Java-машиной выпускаются до сих пор, несмотря на то, что Java ME уже лет пять как с точки зрения девелоперов мертва, даже Opera Mini и Gameloft'овские игры выпускать перестали. С Symbian наоборот: девелоперов-энтузиастов, пилящих софт под старые смартфоны, полно, но вендоров уже нет.
Европейские компании продали мобильные направления китайцам
Так это было и во времена WP, сути не меняет.
Велика беда. Apple на старые айфоны бесконечно новую iOS не портирует
У майкрософта нет «магии эпл», поэтому не сработало, тем более для только что вышедшей ОС.
А до этого был насыщен J2ME, Symbian, WM. Чего ж разработчики-то перебежали?
Причин множество, для типичного девелопера/конторы в первую очередь — возможность заработать. А гугл/эпл давал новый на тот момент формат продаж — Android Market/App Store. Мог ли предложить такой формат симбиан/j2me? win mobile сделал это в 2009, но у wm корпоративная направленность, да и сам он был еле живой с падающими 10% рынка, в то время как android/ios поднимались выше и выше.
Так это было и во времена WP, сути не меняет.То времена другие были, гугл ещё худо-бедно держал планку «корпорации добра». А сейчас гайки закручивает, да и США торговыми санкциями грозятся.
У майкрософта нет «магии эпл»А при чём тут Apple, если у Android с обновлениями ещё хуже, но взлететь это ему не помешало?
А гугл/эпл давал новый на тот момент формат продаж — Android Market/App StoreТак M$ тоже шмаркет свой открыл. У них ведь беда как раз в том, что пошли по пути Apple, сделав максимально огороженную платформу с дорогими девелоперскими учётками и единым магазином приложений с жёсткой модерацией. И как раз тут «магии» не хватило. Были б пооткрытей к сообществу — может, чего бы и выгорело.
Майки нормально шли по пути яблок, пока сами себе же не понаставили подножки, выкидывая на помойку один виндофон за другим. Пользователей и разработчиков было далеко не большинство, конечно, но и не полтора гика, гоняющихся за экзотикой.
Возможно, привыкли к успеху десктопной винды, и 5-10% рынка посчитали неудачей.
Возможно, привыкли к успеху десктопной винды, и 5-10% рынка посчитали неудачей.
Он очень даже. На серверах, в мобилках, в приятном ламповом фронтенде wrike.
UFO just landed and posted this here
— Ведь я умный, красивый, в меру упитанный мужчина — ну в полном расцвете сил!
— Да, но на телевидении этого добра хватает без Вас!
Этих кроссплатформенных технологий уже и так валом. Qt, Haxe, Kivy, вышеупомянутые React/Vue Native, всяческие web-обёртки типа Cordova. Вот только они либо непригодны для реального использования, либо пригодны лишь чтобы быстрее конкурентов настрогать прототип и потом всё равно выпустить нативные приложения. Особенно на iOS, где один хрен для сборки всей этой якобы кроссплатформы нужен пайплайн из макинтошей, XCode, дорогих девелоперских учёток и верификации (для прохождения которой всё равно iOS-специфичные изменения наверняка потребуются). Особого преимущества перед тем, чтобы сразу писать нативно, нет.
чтобы быстрее конкурентов настрогать прототип и потом всё равно выпустить нативные приложения
Какая жалость, что большинство софта так и остаётся на стадии прототипа. А вон скайп вообще назад во времени переместился.
А вон скайп вообще назад во времени переместился.Skype давно мёртв. После его покупки Microsoft'ом бывшие разработчики собрались и создали новый мессенджер — Wire. Microsoft же плавно, чтобы пользователи не заметили, слил Skype с собственным, изначально браузерным, мессенджером — MSN Live!
Но пользователи заметили. После того, как отключили Skype 7 — последнюю нативную версию для Windows — даже закоренелые юзеры, для которых Skype — синоним звонков через Интернет, стали плеваться от тормозной электроноподелки и подумывать о замене.
UFO just landed and posted this here
flutter предлагает кардинально новый подход к пользовательскому интерфейсу — отсутствие декларативной верстки и декларативных стилей
Да? А мужики, писавшие в ранние нулевые интерфейсы на… да на практически всём, отличном от Delphi — и не знали, что они около 20 лет назад занимались «кардинально новым подходом к пользовательским интерфейсам».
либо заменить нахрен весь технологический стек, и от web останется одно названиеВероятнее всего. Уже сейчас web это не web, а легковестное и мобильное приложение.
Конечно, лет через пять новые фреймворки вытеснят Angular, React, Vue точно так же как они когда-то пришли на замену другим фреймворкам. Эта бесконечная чехарда и фрагментация может закончиться только еще большей фрагментацией с последующей консолидацией и переходом в проприетарную олигополию. С вероятностью 99% WASM или нечто похожее станет основой Web 3.0 где появится конкуренция не просто фреймворков, а проприетарных технологических платформ. А поскольку основные платформы принадлежат крупным вендорам, появятся новые способы монетизации, например, открываешь в 2025 газету «Ведомости», а она написана на Kotlin и требует платную подписку в Google Play, причем Chrome автоматически списывает средства с кошелька читателя.
Что мешает разработчикам добавить в браузер dart? В сайтах где используется js будет включатся js, а на сайтах где используется dart будет включатся dart.
Так уже было с VBScript, ну и где он?
Так уже было с флешем.
Так уже было с сильверлайтом.
И я думаю, на этом еще таки не уймутся, и запилят что-нибудь еще, что благополучно помрёт.
Поддержка не слишком полезных пимпочек в коде браузера имеет вполне себе выразимую в человеко-часах * зарплату в час стоимость. Кто будет оплачивать банкет? Гугл? Гуглу тоже не сдался этот ваш дарт.
Так уже было с сильверлайтом.
И я думаю, на этом еще таки не уймутся, и запилят что-нибудь еще, что благополучно помрёт.
Что мешает разработчикам добавить в браузер dart?
Поддержка не слишком полезных пимпочек в коде браузера имеет вполне себе выразимую в человеко-часах * зарплату в час стоимость. Кто будет оплачивать банкет? Гугл? Гуглу тоже не сдался этот ваш дарт.
Dart вроде как в следующей после андройда, ОС Fuchsia собирались внедрить повсеместно. Google, единственная компания которая может при желании его протолкнуть его как стандарт и заставить все остальные браузере его добавить. Было бы отлично иметь наличие альтернативы js.
Google, единственная компания которая может при желании его протолкнуть его как стандарт и заставить все остальные браузере его добавить.
Он компилируется в js, и в силу этого теперь уже нафиг не нужен в браузерах «прям так». А «протолкнуть как стандарт» гугл его пытался в 2015 через свой хром. Не вышло.
И единственная причина, по которой он живёт в Flutter — это как раз то, что у гугла уже есть компиляция дарта в js с одной стороны и в машинный код для андроида с другой стороны. Если это всё еще и работать будет единообразно, а не как обычно работают такие вещи — то получим очередное <...> Native, позволяющее писать одновременно на мобилки и в веб, в что гугл собственно и целится.
Но это никак не означает, что гуглу нужен именно dart. Flutter — да, dart — лишь потому, что инструментарий уже есть.
Он был. См. Dartium.
UFO just landed and posted this here
Вот, да, тоже так считаю. Дарт это какая-то жава, но без тех вещей, которые делают жаву полезной.
В чем его уродство? Он приятный, он типизированный, у него есть настоящие классы. Для него написаны удобные api future и stream.
UFO just landed and posted this here
Никогда не писал на ts. Можно легкий ревью косяков дарта? Просто со своей стороны я не могу этого увидеть.
UFO just landed and posted this here
Блин, все что ты описал я воспринимаю как приятные фишки. Это особенности языка и привычек уже нврн.
Ps автодополнение лучше всего работает в vs code как и другие фишки, в том числе кодогенераторы. Private и protected уже по привычке в голове на подчеркивание меняется
UFO just landed and posted this here
> Весь мир пришел к ts
Может хватит за весь мир говорить?
> Dart используют только в flutter по безысходности
Прям настоящая мука. Ага. Стонем и плачем. Вы в начале попробуйте десктопный софт написать или мобильное приложение на своем TS создать, а потом говорите.
Может хватит за весь мир говорить?
> Dart используют только в flutter по безысходности
Прям настоящая мука. Ага. Стонем и плачем. Вы в начале попробуйте десктопный софт написать или мобильное приложение на своем TS создать, а потом говорите.
UFO just landed and posted this here
TS это просто обертка над JS. Проблем JS не решает, зато добавляет главную проблему — необходимость хорошо знать JS перед тем как писать на TS.
UFO just landed and posted this here
Некоторые проблемы JS он как раз решает. Собственно почему и получил такую популярность.
Как раз наоборот — TS избавляет от необходимости знать тонкости JS. Вместо неочевидного поведения в рантайме сразу будет ошибка компиляции.
В реальности это разбивается о взаимодействие с JS или JSON, ибо проверки типов заканчиваются в компайлтайме. Далее отладка идет уже по правилам JS.
В реальности небезопасные обращения к внешним API и отсутствие проверок целостности приходящих данных в любом языке заканчивается в дебаггере в случае любых проблем.
Ну, тот же дотнет имеет рантаймовые проверки, неправильный каст чего-то неизвестного из вражеской сборки тут же завалится с InvalidCastException, а не будет дрейфовать по приложению в виде какого-нибудь NaN, поганя данные и увеселяя отладку.
Падать при невозможности десериализовать JSON в объект конкретного типа — это тоже задача решенная.
Падать при невозможности десериализовать JSON в объект конкретного типа — это тоже задача решенная.
Тот же JS (и TS) никак не мешает вам сделать рантаймовые проверки.
JS (и TS) никак не мешает
Но ведь и не помогает.
Могу добавить рантаймовые проверки. Могу и тестами обложить. А могу забыть, забить или сделать неправильно. Привет суровый JS-рантайм.
Прелесть TS в неявности его проверок, что они создаются и контролируются без прямого участия программиста, просто по факту использования объявленных типов. Но для поддержки развесистых типов в рантайме нужно писать дополнительный код, использовать сторонние средства.
С этим есть проблема, да, но можно воспользоваться io-ts.
Вы в начале попробуйте десктопный софт написать
А ведь в комментах уже написали волшебные буквы «Electron». Пока одни ноют, что это много жрет ресурсов (и правда много) — другие просто запускают свой вебкод в том числе как десктопное приложение, и не жужжат.
или мобильное приложение
React Native (и вам не обязательно писать именно на реакте, есть вещи, которые транспайлят откуда-то еще в react native).
Вы всерьез думаете, что кроме флаттера в мире ничего нет, что ли?
Flutter куда проще и универсальнее всех этих Электронов и React Native.
Весь мир пришел к ts
Я чет не вижу. TS слишком захламляет код.
Честно говоря, эти недостатки выглядят как «а почему не так, как я привык?».
Автоматические импорты были сделаны, не очень давно правда, наверное с год назад. При этом show / hide import combinators не используются. Если необходимо, в IntelliJ есть Quick Assist, который добавляет show с именами символов, которые реально используются в текущей библиотеке из импортированной.
Автоматические импорты были сделаны, не очень давно правда, наверное с год назад. При этом show / hide import combinators не используются. Если необходимо, в IntelliJ есть Quick Assist, который добавляет show с именами символов, которые реально используются в текущей библиотеке из импортированной.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Хайлоад и ФП разве друг друга не взаимоисключают? Стейт мутировать дешевле, чем плодить сущности под каждое изменение.
UFO just landed and posted this here
Вы про этот пост? Так это ограничение KPHP
UFO just landed and posted this here
А вы не путаете функциональное программирование с процедурным? function в PHP иногда может біть функцией в смысле ФП, но прежде всего она процедура
UFO just landed and posted this here
Академически процедурное программирование прямая противоположность функциональному, а ООП — его развитие. На практике в мультипарадигменных языках эти грани стираются. Например, процедура, написанная как функция позволяет применять к ней ФП подходы, причём само тело функции может как отвечать требованиям ФП, так и не отвечать, но это "Не отвечать" может быть инкапсулировано.
так и в существующие ООП-языки перетаскиваются элементы функционального программирования (например, Stream API в Java, pattern matching в C#). А в новых языках ФП вообще из коробки (Rust, Kotlin).
Только Stream API, pattern matching, лямбы и всё-всё-всё остальное не противоречит ООП, как не противоречит ему иммутабельность, и не противоречит само функциональное программирование ООП.
А если где-то и противоречит, то только в головах людей которые не разобрались ни с первым ни со вторым и до сих пор думают что ООП это про классы/наследование/полиморфизм подтипов или геттеро-сеттеры(наивно зовущиеся инкапсуляцией)
UFO just landed and posted this here
Согласен. А что дадут «настоящие классы»?
Так можно и без классов, например взять опеределение о том, что ООП это модель параллельных вычислений, и писать себе ООП программы на Erlang/Scala(Akka)/Actix/других решениях для Actor Model.
Но на самом деле лучше брать понятные термины с общепринятыми определениями, или обсуждать конкретные решения в конкретных контекстах, а не пытаться спорить об ООП vs ФП.
Вся мода на ООП/ФП это лишь раздувание хайпа для привлечения внимания к себе/своим проектам
Если что про ООП, actor model и другое от Кея и Армстронга — тут
UFO just landed and posted this here
Однако эта ветка началась с того, что в Dart, в отличие от JS, есть «настоящие классы». Значит для автора ветки «ООП это про классы/наследование/полиморфизм подтипов»?
Ну, в контексте dart/js «настоящие классы» от комментатора выше я понимаю как наличие классов как языковой конструкции в более привычном виде по отношению мейнстрим-языкам вид, а я сюда влез потому что пошли попытки выставить ООП/ФП как преимущество языка.
Болтовня это всё. Обычно понимание ФП ограничивается заменой for на map/reduce. Кодер, думает, что ФП — это когда функции находятся в модуле, а ООП — это когда функции в виде статических методов. Кроме того, из JS хреновый ФП-язык, нет ни карринга ни пэттерен-мэтчинга, да вообщее ничего, кроме функций первого класса. В остальных ООП языках не лучше. Попрбуйте, например, найти Dependency Injection библиотеку для С#, которая бы внедряла делегаты вместо интерфейсов по соглашению (язык ни причем, но экосистема мыслит в ООП-стиле). Поэтому, в результате, все равно приходится откатываться обратно на ООП если язык изначально не для ФП.
Как там дела с поддержкой слабых ссылок, деструкторов и всего того, чего так отчаянно не хватает в JavaScript?
UFO just landed and posted this here
UFO just landed and posted this here
Я, возможно, сейчас напишу ерунду и меня закидают помидорами минусами, но, по моему мнению, новая мода всё тащить в Веб — очень плохая.
Т.е., смотрите, у нас были десктопные приложения — сейчас всё делают на веб-технологиях, заворачивая это в Electron. Как результат — это безбожно тормозит, жрёт ресурсы, в т.ч. память (приложение с урезанным, по сравнению с дестопом, функционалом начинает весить гигабайты) Skype, uTorrent, pgAdmin и другие просто вызывают боль.
И причина этого — тяжелое эволюционное наследие: HTML, как ни крути, сильно избыточен и пересыщен фичами, друг друга перекрывающими и пытающимися исправить косяки друг друга. CSS — изобилует исторически сложившимися стандартами. JS также стонет под грузом обратной совместимости. Все 3 основные технологии, со своими костылями, со своим синтаксисом и собственным наследием не могут жить друг без друга, но в одной экосистеме не позволяют друг другу жить хорошо. Браузер как платформа вынужден поддерживать каждый исторический выкидон их развития. Как и в Java, принцип «написано один раз — работает везде» обернулся принципом "выеживаемся пишем сразу для всех браузеров собственные хаки".
И новые фичи. Да, конечно, очень круто, что для проигрывания видео теперь не нужен Flash, нужно только написать >video< Очень круто, что у нас есть и рисовалка Canvas для рисования любой безумной хрени и для этого не надо строить хитрый DOM, поддержка OpenGL и управления звуком тоже впечатляет. Но за всё надо платить. А платим мы тем, что браузеры тяжелы, неповоротливы и прожорливы, при тяжёлой странице начинают (вынуждены?) дико тормозить.
Почему? Потому что Веб должен был остаться текстовым, но туда потащили сначала SPA-страницы, а затем полноценные приложения.
Как итог, мы имеем технологии, задавленные тяжестью собственного наследия, вынужденные работать в песочнице, ограниченной браузером, а браузер сейчас по сути является целой операционной системой… Работающей внутри еще одной операционной системы.
Ради чего? Ради того, чтобы щелкнуть на ссылку и начать работать с нужным приложением, не проходя процедуру инсталляции? Ради того, чтобы любой, купивший компьютер, мог за несколько часов сваять свое чудо-приложение? Платить каждый раз?
Нет, мой ответ. Мы идем не туда. Честно, я бы предпочел нативные приложения, весящие килобайты и работающие молниеносно. Но для этого надо избавиться от лишнего жира. От избыточности (X)HTML — к более лаконичной разметке вроде JSON или Yaml. От чудаковатового CSS к описательным стилям и раскладкам в том же синтаксисе (JSON\Yaml или какой будет разметка). От не менее странного JS к более строгим (но вместе с тем простым) императивным языкам — и пожалуйста, никакой обратной совместимости!
А еще нам нужно избавиться от браузера. Совсем. Пусть будет тонкий рантайм, который будет понимать свой байт-код, пусть это будет WASM или что-то другое, который будет контролировать разрешения приложений и не давать делать им ничего лишнего — и всё! И пусть он будет частью ОС, а не как сейчас браузер — ОС внутри ОС. Т.е. нам нужна новая ОС, которая заменит браузер, и будет более или менее стандартизирована при своей открытости, как это случилось с Linux и Android.
Революция — завершающий этап эволюции, она нам нужна. Нам нужно не убивать живущее, но нам нужно похоронить наших зомби.
Перемен требуют наши сердца! (ц)
Т.е., смотрите, у нас были десктопные приложения — сейчас всё делают на веб-технологиях, заворачивая это в Electron. Как результат — это безбожно тормозит, жрёт ресурсы, в т.ч. память (приложение с урезанным, по сравнению с дестопом, функционалом начинает весить гигабайты) Skype, uTorrent, pgAdmin и другие просто вызывают боль.
И причина этого — тяжелое эволюционное наследие: HTML, как ни крути, сильно избыточен и пересыщен фичами, друг друга перекрывающими и пытающимися исправить косяки друг друга. CSS — изобилует исторически сложившимися стандартами. JS также стонет под грузом обратной совместимости. Все 3 основные технологии, со своими костылями, со своим синтаксисом и собственным наследием не могут жить друг без друга, но в одной экосистеме не позволяют друг другу жить хорошо. Браузер как платформа вынужден поддерживать каждый исторический выкидон их развития. Как и в Java, принцип «написано один раз — работает везде» обернулся принципом "
И новые фичи. Да, конечно, очень круто, что для проигрывания видео теперь не нужен Flash, нужно только написать >video< Очень круто, что у нас есть и рисовалка Canvas для рисования любой безумной хрени и для этого не надо строить хитрый DOM, поддержка OpenGL и управления звуком тоже впечатляет. Но за всё надо платить. А платим мы тем, что браузеры тяжелы, неповоротливы и прожорливы, при тяжёлой странице начинают (вынуждены?) дико тормозить.
Почему? Потому что Веб должен был остаться текстовым, но туда потащили сначала SPA-страницы, а затем полноценные приложения.
Как итог, мы имеем технологии, задавленные тяжестью собственного наследия, вынужденные работать в песочнице, ограниченной браузером, а браузер сейчас по сути является целой операционной системой… Работающей внутри еще одной операционной системы.
Ради чего? Ради того, чтобы щелкнуть на ссылку и начать работать с нужным приложением, не проходя процедуру инсталляции? Ради того, чтобы любой, купивший компьютер, мог за несколько часов сваять свое чудо-приложение? Платить каждый раз?
Нет, мой ответ. Мы идем не туда. Честно, я бы предпочел нативные приложения, весящие килобайты и работающие молниеносно. Но для этого надо избавиться от лишнего жира. От избыточности (X)HTML — к более лаконичной разметке вроде JSON или Yaml. От чудаковатового CSS к описательным стилям и раскладкам в том же синтаксисе (JSON\Yaml или какой будет разметка). От не менее странного JS к более строгим (но вместе с тем простым) императивным языкам — и пожалуйста, никакой обратной совместимости!
А еще нам нужно избавиться от браузера. Совсем. Пусть будет тонкий рантайм, который будет понимать свой байт-код, пусть это будет WASM или что-то другое, который будет контролировать разрешения приложений и не давать делать им ничего лишнего — и всё! И пусть он будет частью ОС, а не как сейчас браузер — ОС внутри ОС. Т.е. нам нужна новая ОС, которая заменит браузер, и будет более или менее стандартизирована при своей открытости, как это случилось с Linux и Android.
Революция — завершающий этап эволюции, она нам нужна. Нам нужно не убивать живущее, но нам нужно похоронить наших зомби.
Перемен требуют наши сердца! (ц)
А что делать с мультиплатформенностью? Есть десктоп с Windows, MacOs, Linux, есть мобильные с Android и iOS — все это разные операционные системы, сильно разные.
Величие современного веба в том, что он работает под ними всеми, именно отсюда растут корни того, что все пытаются в него обернуть.
Вот разрабатываете Вы интернет магазин, например, и что писать нативные приложения под все платформы? Сколько это обойдется в деньгах на разработку и поддержку?
А мне, как посетителю, зачем 100500 приложений на моей десктопной или мобильной машине, если я Вашим магазином может один раз воспользуюсь, а может только прайс полистаю и откажусь от покупки?
Величие современного веба в том, что он работает под ними всеми, именно отсюда растут корни того, что все пытаются в него обернуть.
Вот разрабатываете Вы интернет магазин, например, и что писать нативные приложения под все платформы? Сколько это обойдется в деньгах на разработку и поддержку?
А мне, как посетителю, зачем 100500 приложений на моей десктопной или мобильной машине, если я Вашим магазином может один раз воспользуюсь, а может только прайс полистаю и откажусь от покупки?
Добавлю, что не просто есть разные операционные системы, а разные операционные системы разных версий. Пускай даже заявленная обратная совместимость и была бы чистой правдой, но хочется (рынку), чтоб современные фичи ОС приложениями использовались. А это значит что для каждой ОС надо поддерживать минимум несколько версий приложений. Не важно явно, или через проверку доступности фичи в рантайме и переходу к какому-то фоллбэку, если недоступна.
На это я писал:
Т.е. нам надо, чтобы Веб был частью ОС, но не в том виде, в котором сейчас — с глубоким стеком не очень подходящих технологий. Т.е. эти технологии были хороши для Веба 1.0, но поскольку он развился и стал действительно сложным — нужно не бесконечно усложнять инструменты, дублируя их функциональность, а интегрировать их друг с другом.
Т.е. нам нужна новая ОС, которая заменит браузер, и будет более или менее стандартизирована при своей открытости, как это случилось с Linux и Android.
Т.е. нам надо, чтобы Веб был частью ОС, но не в том виде, в котором сейчас — с глубоким стеком не очень подходящих технологий. Т.е. эти технологии были хороши для Веба 1.0, но поскольку он развился и стал действительно сложным — нужно не бесконечно усложнять инструменты, дублируя их функциональность, а интегрировать их друг с другом.
Т.е. нам надо, чтобы Веб был частью ОСНе должен быть Веб частью ОС, точно также как не должен быть частью ОС офисный пакет и т.п. прикладные самостоятельные вещи.
Веб должен обрабатываться специализированной программой — браузером, как и сейчас. Проблема не в том, что между ОС и Вебом есть посредник в виде браузера.
но не в том виде, в котором сейчас — с глубоким стеком не очень подходящих технологий. Т.е. эти технологии были хороши для Веба 1.0, но поскольку он развился и стал действительно сложным — нужно не бесконечно усложнять инструменты, дублируя их функциональность, а интегрировать их друг с другом.А вот с этим соглашусь — современные Веб-стандарты это действительно адская каша из HTML, CSS, JavaScript с кучей легаси, поверх которых еще сидит куча фреймворков, сборщиков и т.п. Вот заменить все это единой стройной интегрированной технологией было бы просто замечательно.
Но для этого должны прежде всего договорится о едином подходе крупные Веб-разработчики, такие как Facebook, Google, Amazon и т.п. и разработчики браузеров — Google, Apple и Mozilla.
JS также стонет под грузом обратной совместимости
Мне кажется вы преувеличиваете.
UFO just landed and posted this here
Я приплел его сюда только за его лаконичность, чем-то напоминающий питоновскую философию.
Я бы HTML был бы доволен видеть хотя бы таким:
html {
body {
div {
a(«link») {
target = blank
«Main site»
}
}
}
Я бы HTML был бы доволен видеть хотя бы таким:
html {
body {
div {
a(«link») {
target = blank
«Main site»
}
}
}
Платить каждый раз?
По факту все выбирают платить и поддерживать совместимость. Если ваш подход даст мегапреимущество, это всех завоюет. Но он не дает. Рантаймы и нативные приложения есть и известны, он не вытесняют веб
Честно, я бы предпочел нативные приложения, весящие килобайты и работающие молниеносно.
Вам кто-то С отменил? Пишите. Только не обижайтесь, что пока вы напишете килобайтное и работающее молниеносно приложение (и скомпилируете его везде, куда вам надо) — вы обнаружите, что рынок уже давненько поделен.
Т.е., смотрите, у нас были десктопные приложения — сейчас всё делают на веб-технологиях, заворачивая это в Electron.
Упущен один очень важный момент. Это просто дешевле и быстрее. Вы думаете, что Facebook и ВК были рады корявиться со своим php? Нет, у них не было выбора. Так что весь ваш пост — это возмущение насчёт того, что вода течёт вниз.
UFO just landed and posted this here
А платим мы тем, что браузеры тяжелы, неповоротливы и прожорливы, при тяжёлой странице начинают (вынуждены?) дико тормозить. Почему? Потому что Веб должен был остаться текстовым, но туда потащили сначала SPA-страницы, а затем полноценные приложения.
Нет, не должен был. Эволюция закономерна. Вот то, что эти новомодные фичи используются без ума — это да. Ну так...
На js плохие проги не из-за js, а потому что он для веба. Если бы сайтописцам надо было кодить на хаскеле, они бы говнокодили на хаскеле, и все бы говорили: хаскель такой плохой язык, я на нём много плохих программ видел.
Динамическая типизация же необходима: если у вас серьезный проект, вы можете выбрать язык по вкусу и настроить транспилятор при сборке. А большинство проектов несерьёзные — и в них никому не интересно типизировать json-подобные структуры.
Динамическая типизация же необходима: если у вас серьезный проект, вы можете выбрать язык по вкусу и настроить транспилятор при сборке. А большинство проектов несерьёзные — и в них никому не интересно типизировать json-подобные структуры.
UFO just landed and posted this here
А как вы с ними работаете тогда? Вот когда вы пишете json[«foo»], что вы имеете в виду?
Как бог на душу положит, в самом-то деле. У большинства сайтов ведь практическая функция — отображать на экране текст с картинками, не более. Нет поля в объекте — выведется на сайте пустая строка, или там undefined, всего делов.
Мне из Алиэкспресса каждая вторая посылка приходит с надписью Phone number: +972undefined почему-то. Это, конечно, баг. С другой стороны, покупатель доволен. Продавец доволен. Джек Ма доволен. У этой истории нет морали.
Мне из Алиэкспресса каждая вторая посылка приходит с надписью Phone number: +972undefined почему-то. Это, конечно, баг. С другой стороны, покупатель доволен. Продавец доволен. Джек Ма доволен. У этой истории нет морали.
Хм… я вот подумал, а что будет, если Вам придет письмо с текстом: «Уважаемый undefined, Вам отправлена посылка undefined по адресу undefined»?
Письмо, наверное, придет владельцу ящика undefined@gmail.com :)
В этом случае магазин заработает NaN денег, и тикет в баг-трекере тотчас же засияет новыми красками, и эту штуку быстро-быстро починят.
То, что критично для бизнеса, будут писать на строго типизированных языках, и применять JSON Schema, и всякое дефенсивное программирование, и QuickCheck, и фаззинг, и аудит кода проводить.
А где некритично (т.е. остальные 99% кода) — и так сойдет.
(Всё это, конечно, не относится к хобби-проектам.)
В этом случае магазин заработает NaN денег, и тикет в баг-трекере тотчас же засияет новыми красками, и эту штуку быстро-быстро починят.
То, что критично для бизнеса, будут писать на строго типизированных языках, и применять JSON Schema, и всякое дефенсивное программирование, и QuickCheck, и фаззинг, и аудит кода проводить.
А где некритично (т.е. остальные 99% кода) — и так сойдет.
(Всё это, конечно, не относится к хобби-проектам.)
с надписью Phone number: +972undefined почему-то. Это, конечно, баг
Ой ли? Может, просто маска такая. Задачу скрыть номер ведь выполняет, девелоперы просто бахнули что-то вида if (print_on_posylka) delete nomer.main; — и та-а-ак сойдёт, тикет закрыт за 0.3 c, менеджер доволен. А намудрили бы чего-то сложнее — был бы оверинжиниринг.
В голове типизируем JSON в большинстве случаев, хоть на бэке, хоть на фронте, хоть на JS, хоть на TS, хоть на JS. Есть JSON Schema в теории, но на практике пока формальные проверки на соответствие ей не встроены в язык или хотя бы во флоу разработки, то их дорого выходит поддерживать, чтобы на их основе писать полноценные тайп-гварды.
UFO just landed and posted this here
UFO just landed and posted this here
Хм. А не возможно ли оставить плюсы, такие как скорость разработки, легкость сопровождения и кроссплатформенность, и при этом избавиться от минусов в виде требовательности к ресурсам и тормозам в рантайме?
Возможно, кроссплатформенность и есть тот самый неверный критерий, и возможно, нам требуется некий общий знаменатель, т.е. стандарт, который позволит выкинуть побольше хаков для истинной кроссплатформенности.
Возможно, кроссплатформенность и есть тот самый неверный критерий, и возможно, нам требуется некий общий знаменатель, т.е. стандарт, который позволит выкинуть побольше хаков для истинной кроссплатформенности.
Мне интересно — как отреагирует эппл, если вебасм взлетит и станет популярным?
Ведь сейчас у них на телефонах выполняется только то, что одобрено самим эпплом, в том числе и в вебе (все айфонные браузеры — надстройки над сафари)
Ведь сейчас у них на телефонах выполняется только то, что одобрено самим эпплом, в том числе и в вебе (все айфонные браузеры — надстройки над сафари)
Никак не отреагирует. WASM в iOS Safari поддерживается, доступа к чему-либо за пределом API веб-приложения WASM не дает.
В iOS 13 в вебките был баг WebAssembly BBQ should switch compile mode for size of modules, который ломает реальные проекты. К сожалению до 13.1.3 фикс так и не дошел. workaround загружать asm.js если он есть. Всё бы ничего, только Apple не в первый раз так ломает wasm.
Очень мило.
Так что же мы всё таки делаем?
Меняем тег
или не будем?
На самом деле было интересно узнать, что решение моих проблем всё же есть. Огромное количество данных (текстовые файлы csv, более 2 гигов самый маленький), чехарда C# Python, ну и javascript, разумеется, в одном проекте. Так что wasm, мне лично, юзать уже хочется, наверное.
Так что же мы всё таки делаем?
Меняем тег
<marquee>evolution</marquee>cirCus.Tent(new Revolution(true));, или не будем?
На самом деле было интересно узнать, что решение моих проблем всё же есть. Огромное количество данных (текстовые файлы csv, более 2 гигов самый маленький), чехарда C# Python, ну и javascript, разумеется, в одном проекте. Так что wasm, мне лично, юзать уже хочется, наверное.
Я вижу в WASM намек на правильное направление, а именно — универсальную виртуальную машину, которая позволяет писать хоть на Ассемблере, хоть на Си, хоть на Брейфаке, при этом предлагая хорошую скорость.
Я все-таки хотел бы видеть дальнейшее развитие — что-то вроде WASM, но не в браузере, а в ОС. Но, тогда, конечно, это будет совсем иное, нежели WASM. Даже не предполагаю, какое именно.
Я все-таки хотел бы видеть дальнейшее развитие — что-то вроде WASM, но не в браузере, а в ОС. Но, тогда, конечно, это будет совсем иное, нежели WASM. Даже не предполагаю, какое именно.
JavaScript от нас скорее всего не уйдет. Google пытались Dart пропихнуть но даже у них не получилось.
Про тонны легаси на JS смешно слышать. Ребята, вы реально верите, что проекты написанные сегодня сохранятся через 7-8 лет в первозданном виде? Да за это время половину помрет, а вторая половина будет переписана и не один раз. Нужно быть очень большим оптимистом, чтобы верить, что какой-то код проживет дольше чем 5 лет.
JS крайне сложен и запутан. Чего стоит только this и разные приколы типа [] + [] + true. Dart несоизмеримо проще.
JS крайне сложен и запутан. Чего стоит только this и разные приколы типа [] + [] + true. Dart несоизмеримо проще.
Нужно быть очень большим оптимистом, чтобы верить, что какой-то код проживет дольше чем 5 лет.
Вы не верите, а я с этим работаю. Но вы и дальше можете не верить.
Кода для веб, прожившего больше 5 лет — море. Прожившего больше 10 лет — тоже очень порядочно.
JS крайне сложен и запутан. Чего стоит только this и разные приколы типа [] + [] + true.
Вы измеряете сложность языка количеством способов отстрелить себе ногу?
А не стрелять — пробовали?
Нужно быть очень большим оптимистом, чтобы верить, что какой-то код проживет дольше чем 5 лет.
Примеры:
- Gmail – редизайн ему сделали, а внутри все то же легаси. Подробный анализ был вот тут.
- https://craigslist.org довольно известный своим консервативным дизайном сайт
- https://www.wetteronline.de/ – этот сайт известен тем, что из-за него не получилось добавить в стандарт Array.prototype.flatten, потому что это ломало легаси-библиотеку MooTools, используемую на этом сайте
И это только публичные примеры. Как и JustDont, я периодически сталкиваюсь с легаси в своей работе, вроде кода на jQuery 1.7, требующего обновления.
Насчёт вытеснить — врядли.
Скорее всего WebAssembly возьмёт на себя высокопроизводительную часть приложения.
Скорее всего WebAssembly возьмёт на себя высокопроизводительную часть приложения.
Забавно, как люди пытаются бороться с намеренными особенностями языка, создавая даже другие языки, которые конвертируются в Javascript.
Забавно, как люди пытаются бороться с намеренными особенностями языка, создавая даже другие языки, которые конвертируются в Javascript.
Ну так причина же в том что выбора особо не было долгое время, да и сейчас нету, браузеры хотят JS, намеренные особенности или не намеренные не играет роли если они для кого-то являются недостатками
Некоторые "намеренные особенности" создавались совсем не для тех целей, в которых сейчас используется JS. А альтернативы по сути нет, кроме как пытаться спрятать эти особенности под капотом другого языка
Намеренная особенность языка была — сделать очень простой язык, с простой философией, чтобы на нём создавать простые скрипты.
Но для сложных приложений эти особенности начинают мешать. Появляется потребность в фичах более сложных языков, которых в JSнет очень долго не было.
Но для сложных приложений эти особенности начинают мешать. Появляется потребность в фичах более сложных языков, которых в JS
Лет 10 назад каждый день писали про падение доллара, что вот-вот и все, лет 5 назад мы каждый день читали про «убийц» ipad, теперь про «убийц» js.
Мир попробует перейти на webassembly, если кто из гигантов на него перейдет, что вряд ли.
Мир попробует перейти на webassembly, если кто из гигантов на него перейдет, что вряд ли.
Microsoft обещают Blazor WebAssembly в мае 2020
Blazor на WebAssembly – очень спорная штука. Если в случае с JS в браузер тащат только left-pad и другие мелкие недостающие функции, то с случае с Blazor туда потянут полноценную VM со своей реализацией строк, классов и т.д. На скорости загрузки это скажется соотвествующе.
Поэтому Blazor кажется полезным только в очень специфических ситуациях – много тысяч строк кода на C#, и в команде совсем никто не хочет/не может в JS.
Хоронили тёщу — порвали два баяна (ц)
Заголовок (да и общий тон) статьи намеренно чересчур претенциозен.
Заголовок (да и общий тон) статьи намеренно чересчур претенциозен.
UFO just landed and posted this here
JavaScript сейчас берёт на себя груз обеспечения совместимости между версиями. То есть, можно написать if (нечто.ИмяМетода), и так просто и понятно проверить, а есть ли он, этот метод (какова версия реализации). И, соответственно, поработать с той или иной версией реализации. Наследование если на JavaScript делать, наследованные методы автодобавляются в унаследованные экземпляры, и тогда потомкам не обязательно знать, что у них что-то добавилось. Ну, правда, если имена совпали, тогда ой.
А вот если обратиться к нативу, как в WASM, то старые проблемы всплывают вновь. Ими активно занимались все 1990е, а потом вроде как их решила Java. В C++ 98 не вошло ничего из IBM Direct To SOM, Sun OBI, SGI Delta/C++. А когда ближе к концу 2000х, обломав зубы на чисто-Java-браузере HotJar и прочей чисто-джавовости, которые получились как-то не очень, в отличие от Apple CyberDog на SOM и OpenDoc, начали понимать, что Java — это не всё, это вылилось в обновление C++ 2009, но от наработок 1990х там всё так же ни следа. Только в Objective-C сохранились наработки 1990х, и даже были чуть улучшены в 2006м, там это назвали nonfragile ivars.
И вот теперь, получив в руки инструмент WASM, мы осознаём, что всё на том же перекрёстке. Мы так и не пережили 90е. Нам в нативе нужен инструмент сопряжения изменчивых компонент, а его нет. Значит, в роли такого придётся, чтоб был JavaScript. Нам постоянно придётся в него выходить, потому что в WASM решать свои проблемы не умеем. Либо какая-то ВМ заменит шило на мыло. Вместо фигового JS будет очередная фиговая ВМ.
Просто попробуйте начать активно использовать разделяемые библиотеки в EmScripten. Да там даже интерфейсы по типу COM нагородить между независимо собранными wasm — победа. До наследования без проблемы хрупкого базового класса как до Луны пешком. Всё реальное применение WASM скатывается к здоровенным статически собранным блобам, обновляемым как единое целое. Хотя, учитывая, как без фундаментальной научной работы такие проблемы в прошлом решались разрозненными участниками рынка, заинтересованными только в повышении наших на них расходов, но не в улучшении ситуации в целом, мы и впрямь можем дожить до того, чтоб глянуть один твит, нужно будет загрузить 65Мб WASM, ведь тот, что в кеше, успел протухнуть.
А вот если обратиться к нативу, как в WASM, то старые проблемы всплывают вновь. Ими активно занимались все 1990е, а потом вроде как их решила Java. В C++ 98 не вошло ничего из IBM Direct To SOM, Sun OBI, SGI Delta/C++. А когда ближе к концу 2000х, обломав зубы на чисто-Java-браузере HotJar и прочей чисто-джавовости, которые получились как-то не очень, в отличие от Apple CyberDog на SOM и OpenDoc, начали понимать, что Java — это не всё, это вылилось в обновление C++ 2009, но от наработок 1990х там всё так же ни следа. Только в Objective-C сохранились наработки 1990х, и даже были чуть улучшены в 2006м, там это назвали nonfragile ivars.
И вот теперь, получив в руки инструмент WASM, мы осознаём, что всё на том же перекрёстке. Мы так и не пережили 90е. Нам в нативе нужен инструмент сопряжения изменчивых компонент, а его нет. Значит, в роли такого придётся, чтоб был JavaScript. Нам постоянно придётся в него выходить, потому что в WASM решать свои проблемы не умеем. Либо какая-то ВМ заменит шило на мыло. Вместо фигового JS будет очередная фиговая ВМ.
Просто попробуйте начать активно использовать разделяемые библиотеки в EmScripten. Да там даже интерфейсы по типу COM нагородить между независимо собранными wasm — победа. До наследования без проблемы хрупкого базового класса как до Луны пешком. Всё реальное применение WASM скатывается к здоровенным статически собранным блобам, обновляемым как единое целое. Хотя, учитывая, как без фундаментальной научной работы такие проблемы в прошлом решались разрозненными участниками рынка, заинтересованными только в повышении наших на них расходов, но не в улучшении ситуации в целом, мы и впрямь можем дожить до того, чтоб глянуть один твит, нужно будет загрузить 65Мб WASM, ведь тот, что в кеше, успел протухнуть.
У меня есть небольшой оптимизм на счёт замены JS чем-то более приятным за счёт доминирования Chrome/Chromium-based. То есть если гугл сильно захочет, и вложится в свой Dart (как пример — я не агитирую за него) по полной, то это будет уже бОльшая часть рынка — миллиарды устройств. После этого останется дождаться падения «стены» на стороне Safari, и тогда все остальные будут вынуждены адаптироваться. То есть в какой-то мере браузерный монополизм может сыграть положительную роль в том, чтобы освежиться и отбросить легаси в виде не самого приятного языка.
JS и WASM — это две технологии, которые помогают друг-другу, а не пытаются друг-друга убить. По моему, у аудитории обнаруживается фудоментальное непонимание того, зачем нужен WASM, и почему он не может заменить JS: просто подумайте почему в WASM нет доступа к DOM, неужели просто потому, что было сложно пробросить интерфейс? Нет, все дело в безопасности.
Можете пояснить, что (недопустимое с т.з. безопасности) сможет сделать WASM при прямом доступе к DOM, чего не может JS?
Если коротко — то DOM — это, кроме прочего, и те самые пользовательские поля ввода паролей и иных конфиденциальных данных. JS — это скриптовой код, ход исполнения которого, можно полностью контролировать в рантайме, блокируя любую нежелательную активность. С высокопроизводительным скомпилированным кодом так не получится, поэтому нужна прослойка. Помимо этого, узким местом в воронке производительности веб-приложения, часто являются сложные вычисления при отрисовке DOM, и вся эта логика работает не на JS, поэтому замена JS на что-то более производительное ситуацию никак не изменит.
UFO just landed and posted this here
Я слышал, что это временно:
Примечание: В будущем планируется позволить WebAssembly напрямую вызывать Web API.
Сотни тысяч «яваскрипт-программистов» вдруг станут писать на Си? да нет туториалов таких на ютубе )
Я мало того, что не веб-программист, но и представление о данном направлении имею слабое.
У меня вопрос к знатокам Angular — википедия говорит, что "… Angular — это открытая и свободная веб-платформа для разработки веб-приложений...".
Я так понимаю, что если веб-платформа, то ее кишки размещаются где-то на сервере или нескольких. Допустим, у меня есть сервер и я хочу эту открытую и свободную веб-платформу Angular установить на нем и разрабатывать веб-приложения, которые, возможно, я на этом сервере и установлю.
Вот я захожу на angular.io в поисках ссылки на скачивание и не нахожу там вообще слова «скачать» — там только кнопка «начали». Я ее нажал и опять же нигде не увидел возможности это открытое и свободное скачать к себе на сервер даже за деньги.
Совершенно ничего не понимаю.
У меня вопрос к знатокам Angular — википедия говорит, что "… Angular — это открытая и свободная веб-платформа для разработки веб-приложений...".
Я так понимаю, что если веб-платформа, то ее кишки размещаются где-то на сервере или нескольких. Допустим, у меня есть сервер и я хочу эту открытую и свободную веб-платформу Angular установить на нем и разрабатывать веб-приложения, которые, возможно, я на этом сервере и установлю.
Вот я захожу на angular.io в поисках ссылки на скачивание и не нахожу там вообще слова «скачать» — там только кнопка «начали». Я ее нажал и опять же нигде не увидел возможности это открытое и свободное скачать к себе на сервер даже за деньги.
Совершенно ничего не понимаю.
Sign up to leave a comment.
Кто он — убийца JavaScript?