Поднимаем JSON с диска, парсим его в тип бала, в котором у нас есть поле бла, а на диске у нас лежала стринга. Что мы получаем? Мы получаем полу-статическую типизацию.
К сожалению это следствие того, что JSON.parse возвращает any, это легаси с тех времён, когда unknown ещё не придумали. Если б там был unknown, компилятор от вас потребовал бы :)
Что же, прощай, TypeScript. Пусть ты принесешь много строгости и удовлетворения своему племени, позволяя остальным наслаждаться JavaScript в том славном духе, в котором он был изначально задуман: Свободным от сильной (строгой) типизации.
Не знаю, в каком там духе был задуман JavaScript, по-моему его вообще не задумывали писать больше 100 строк кода в одном приложении. Это теперь его толковые люди пытаются дотянуть до приличного уровня, как улучшением самого ECMAScript, так и новыми языками. Я не могу относится серьёзно к языку, в котором до сих пор нет нормальной возможности создать композитный тип с equality-by-value, т.е. запись.
Ну а вообще, я думаю всё зависит от ожиданий от языка и вообще от написания кода. Вот допустим для чего лично я пишу код? Что я ожидаю от результата? Я ожидаю, что путём вложения большого количества времени и путём итеративных улучшений смогу создать систему из большого количества элементов, большинство из которых у меня в голове не могут поместиться за один раз. Но благодаря типам, модулям, проверкам во время компиляции и т.д. я могу с помощью ВРЕМЕНИ и УПОРСТВА (труда) повысить КАЧЕСТВО моего результата. Поэтому я работаю в проектах, где нужно достаточно высокое качество. Я люблю надёжные системы, мне неинтересно писать быстро и на "сойдёт", я уже старый для этого, пора создавать надёжный и полезный код, пара мгновений - и ты уже пенсионер, и слишком медленно тормозишь.
Другие же люди создают стартапы за пару недель, им завтра нужен PoC, а послезавтра - работающая страница оплаты, чтобы брать денежку. И я не могу их в этом винить, они строят бизнес, возможно они завтра будут менять мир вокруг меня. Нужны ли им пляски с типами и с ошибками компиляции? Наверное нет.
Что ж, реализуется предложение от @M_AJ - хотфикс закона, который уже в продакшене.
Ну логично, для политиков все "мутные" организации вокруг - тоже скорее всего политические, обыкновенная профдеформация. С трубопрокатным заводом всё более-менее понятно, а вот что вы там коммитите в этот ваш Mozilla Foundation - дело очень подозрительное.
серверная память - регистровая, т.е. там стоит дополнительная микросхема для повышения стабильности работы.
Ну раз это статья-ликбез, давайте не допускать фактических ошибок. Регистровая память - это всё-таки про снижение электрической нагрузки и про повышенный объём на планку памяти (который будет недоступен на обычной материнке без поддержки регистровой памяти) за счёт большого количества чипов на планке. А "стабильность работы" - это скорее про ECC, что бывает и на unbuffered-памяти. Вот только на днях подыскивал нерегистровую ECC DDR5.
Я думаю такая точка зрения существует из-за фильмов вроде этого, который выглядит сначала как приличный научно-популярный фильм, ссылающийся на какие-то постулаты квантмеха, а потом выясняется что это ньюэйджовое метафизическое чёрти-что. Но выясняется не всеми, к сожалению.
Согласен, расширение exe и загрузчик в начале файла тут только ради удобства запуска. Дотнет-сборкам вообще не особо нужно прикидываться PE-файлами. Я про другое. .NET Framework, по крайней мере определённых версий, считается компонентом Windows. С некоторой натяжкой это в общем-то системное API. Равно как и Direct3D, например. Вопрос - где проходит граница между "программой" и "скриптом на питоне"?) Что должно/не должно быть в бинаре?
Шикарная статья. Всем, кто пишет про "зачем", предлагаю ознакомиться с жанром 64k intro и теми высотами, которых он достиг на современных графических API. Я к тому, что эта статья примерно из той же категории. Спасибо за перевод!
Подтверждаю, отличный проц в домашний комп. В приличном корпусе под тихим NH-U14S (в спецредакции для сокета SP3) не доставляет никаких проблем. Жаль только не за 200 баксов я его брал.
вместо нативных компилируемых приложений пишут веб-приложения или на JS, или на чём-то компилируемом в JS.
Именно об этом и речь. WASM понемногу набирает в популярности, но новый UI для какого-нибудь спортмагазина сейчас будут писать на TS/JS с каким-нибудь реактом.
Другой у пользователя нет и разработчик приложения не может на это повлиять.
В статье как раз перечислены всякие песочницы, которые были, и которые просто не выстрелили. Ну или уже отслужили своё, как Flash. Собственно и браузер не стал бы такой замечательной песочницей, если б работал без всякой магии вроде угадывания классов (см. комментарии ниже). Просто Гугл вложил огромное количество сил в оптимизацию движка, и по сути захватил Веб как платформу, и навязал её всем остальным. Раньше ещё можно было с этим спорить, но сейчас Веб - это Гугл, ибо Хромиум. Firefox остался единственной альтернативной реализацией, и кажется лет через 10 он к сожалению сдохнет. Гугол вполне себе победил всех в плане экосистемы для приложений, чистый бизнес. Нет никакого "веба", когда код браузера и спеки настолько сложны, что уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания приложений. Чем это лучше какого-нибудь WinAPI с точки зрения отсутствия vendor-lock?
Язык ассемблера вполне себе типизирован - его типы совпадают с типами целевой машины. Вместо всяких enum-ов, классов и union-ов высокоуровневых языков у вас байты, машинные слова и производные от них (какие-нибудь значения с плав. точкой в MMX регистрах). Более того, для машинных инструкций всегда точно специфицируется, что она будет делать с данными и какого они размера.
Да-да-да, вот с этого у меня бомбит больше всего. Из-за того, что в качестве целевого языка компиляции мы используем динамический язык, мы сначала теряем кучу полезной информации о типах, о структуре объектов и т.п., а потом V8 сотоварищи начинает это всё угадывать обратно с использованием всякой магии и статистики. И при этом продвинутому разработчику нужно ЗНАТЬ хотя бы в общих чертах, как это происходит, иначе его код свалится в deopt и внезапно начнёт работать в 50 раз медленнее. Отличная абстракция, которую мы заслужили. Приятно видеть, что хоть кто-то ещё обращает внимание на абсурдность ситуации.
Пользователям нужна песочница для выполнения приложений без ритуала скачивания, установки и без риска.
Вот именно! Нужна песочница и очень простая доставка и выполнение логики на машине клиента. В каком месте из этого следует, что нужно переписать приложение на динамический язык? Ну или на статический, который был создан только ради того, чтобы можно было потом без гемора и кучи прослоек скомпилироваться в динамический? Я вот не могу найти ответы. Сколько виртуальных машин с разными свойствами люди успели напридумать за это время. Наконец-то хоть одна (WebAssembly) подошла.
Я предположу, что WebAssembly постепенно захватит весь современный мир фронтенд-разработки, и мир ПО эволюционным образом превратится в совершенно иной.
Когда это наконец случится, я смогу спокойно умереть. Компилировать статически типизированные языки в динамический только ради возможности доставить логику пользователю - это победа техники над здравым смыслом. Как и вообще необходимость переписывать половину кода в мире только ради того, чтобы засунуть это в браузер. Зачем вообще засовывать приложение в браузер? Зачем делать из браузера операционную систему?
Это как плохой сон, но ты никак не можешь проснуться.
Считаю Far одним из лучших инструментов в плане инвестиций времени - лет 20 одни и те же шорткаты и привычки помогают каждый день. А с учётом того, что я школьником немного застал Нортон и "переходил" с него - то даже больше 20 лет.
К сожалению это следствие того, что
JSON.parseвозвращаетany, это легаси с тех времён, когда unknown ещё не придумали. Если б там былunknown, компилятор от вас потребовал бы :)Не знаю, в каком там духе был задуман JavaScript, по-моему его вообще не задумывали писать больше 100 строк кода в одном приложении. Это теперь его толковые люди пытаются дотянуть до приличного уровня, как улучшением самого ECMAScript, так и новыми языками. Я не могу относится серьёзно к языку, в котором до сих пор нет нормальной возможности создать композитный тип с equality-by-value, т.е. запись.
Ну а вообще, я думаю всё зависит от ожиданий от языка и вообще от написания кода. Вот допустим для чего лично я пишу код? Что я ожидаю от результата? Я ожидаю, что путём вложения большого количества времени и путём итеративных улучшений смогу создать систему из большого количества элементов, большинство из которых у меня в голове не могут поместиться за один раз. Но благодаря типам, модулям, проверкам во время компиляции и т.д. я могу с помощью ВРЕМЕНИ и УПОРСТВА (труда) повысить КАЧЕСТВО моего результата. Поэтому я работаю в проектах, где нужно достаточно высокое качество. Я люблю надёжные системы, мне неинтересно писать быстро и на "сойдёт", я уже старый для этого, пора создавать надёжный и полезный код, пара мгновений - и ты уже пенсионер, и слишком медленно тормозишь.
Другие же люди создают стартапы за пару недель, им завтра нужен PoC, а послезавтра - работающая страница оплаты, чтобы брать денежку. И я не могу их в этом винить, они строят бизнес, возможно они завтра будут менять мир вокруг меня. Нужны ли им пляски с типами и с ошибками компиляции? Наверное нет.
Что ж, реализуется предложение от @M_AJ - хотфикс закона, который уже в продакшене.
Ну логично, для политиков все "мутные" организации вокруг - тоже скорее всего политические, обыкновенная профдеформация. С трубопрокатным заводом всё более-менее понятно, а вот что вы там коммитите в этот ваш Mozilla Foundation - дело очень подозрительное.
Вот именно. Минимализм в UI тоже нужно уметь делать.
Это спинофф к TRON. Вы играете за MCP.
Ну раз это статья-ликбез, давайте не допускать фактических ошибок. Регистровая память - это всё-таки про снижение электрической нагрузки и про повышенный объём на планку памяти (который будет недоступен на обычной материнке без поддержки регистровой памяти) за счёт большого количества чипов на планке. А "стабильность работы" - это скорее про ECC, что бывает и на unbuffered-памяти. Вот только на днях подыскивал нерегистровую ECC DDR5.
Я думаю такая точка зрения существует из-за фильмов вроде этого, который выглядит сначала как приличный научно-популярный фильм, ссылающийся на какие-то постулаты квантмеха, а потом выясняется что это ньюэйджовое метафизическое чёрти-что. Но выясняется не всеми, к сожалению.
Согласен, расширение exe и загрузчик в начале файла тут только ради удобства запуска. Дотнет-сборкам вообще не особо нужно прикидываться PE-файлами.
Я про другое. .NET Framework, по крайней мере определённых версий, считается компонентом Windows. С некоторой натяжкой это в общем-то системное API. Равно как и Direct3D, например. Вопрос - где проходит граница между "программой" и "скриптом на питоне"?) Что должно/не должно быть в бинаре?
А что насчёт этого?) http://demojs.org/ Не имеет права на жизнь?)
Шикарная статья. Всем, кто пишет про "зачем", предлагаю ознакомиться с жанром 64k intro и теми высотами, которых он достиг на современных графических API. Я к тому, что эта статья примерно из той же категории. Спасибо за перевод!
Подтверждаю, отличный проц в домашний комп. В приличном корпусе под тихим NH-U14S (в спецредакции для сокета SP3) не доставляет никаких проблем. Жаль только не за 200 баксов я его брал.
Видимо виртуальных машин было сильно больше одной.
Именно об этом и речь. WASM понемногу набирает в популярности, но новый UI для какого-нибудь спортмагазина сейчас будут писать на TS/JS с каким-нибудь реактом.
В статье как раз перечислены всякие песочницы, которые были, и которые просто не выстрелили. Ну или уже отслужили своё, как Flash.
Собственно и браузер не стал бы такой замечательной песочницей, если б работал без всякой магии вроде угадывания классов (см. комментарии ниже). Просто Гугл вложил огромное количество сил в оптимизацию движка, и по сути захватил Веб как платформу, и навязал её всем остальным. Раньше ещё можно было с этим спорить, но сейчас Веб - это Гугл, ибо Хромиум. Firefox остался единственной альтернативной реализацией, и кажется лет через 10 он к сожалению сдохнет.
Гугол вполне себе победил всех в плане экосистемы для приложений, чистый бизнес. Нет никакого "веба", когда код браузера и спеки настолько сложны, что уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания приложений. Чем это лучше какого-нибудь WinAPI с точки зрения отсутствия vendor-lock?
Язык ассемблера вполне себе типизирован - его типы совпадают с типами целевой машины. Вместо всяких enum-ов, классов и union-ов высокоуровневых языков у вас байты, машинные слова и производные от них (какие-нибудь значения с плав. точкой в MMX регистрах). Более того, для машинных инструкций всегда точно специфицируется, что она будет делать с данными и какого они размера.
Да-да-да, вот с этого у меня бомбит больше всего. Из-за того, что в качестве целевого языка компиляции мы используем динамический язык, мы сначала теряем кучу полезной информации о типах, о структуре объектов и т.п., а потом V8 сотоварищи начинает это всё угадывать обратно с использованием всякой магии и статистики. И при этом продвинутому разработчику нужно ЗНАТЬ хотя бы в общих чертах, как это происходит, иначе его код свалится в deopt и внезапно начнёт работать в 50 раз медленнее. Отличная абстракция, которую мы заслужили.
Приятно видеть, что хоть кто-то ещё обращает внимание на абсурдность ситуации.
Вот именно! Нужна песочница и очень простая доставка и выполнение логики на машине клиента. В каком месте из этого следует, что нужно переписать приложение на динамический язык? Ну или на статический, который был создан только ради того, чтобы можно было потом без гемора и кучи прослоек скомпилироваться в динамический? Я вот не могу найти ответы.
Сколько виртуальных машин с разными свойствами люди успели напридумать за это время. Наконец-то хоть одна (WebAssembly) подошла.
Когда это наконец случится, я смогу спокойно умереть. Компилировать статически типизированные языки в динамический только ради возможности доставить логику пользователю - это победа техники над здравым смыслом. Как и вообще необходимость переписывать половину кода в мире только ради того, чтобы засунуть это в браузер. Зачем вообще засовывать приложение в браузер? Зачем делать из браузера операционную систему?
Это как плохой сон, но ты никак не можешь проснуться.
Считаю Far одним из лучших инструментов в плане инвестиций времени - лет 20 одни и те же шорткаты и привычки помогают каждый день. А с учётом того, что я школьником немного застал Нортон и "переходил" с него - то даже больше 20 лет.
Где по ссылке написано что-либо о предпочтениях разработчика по приёму платежей? Не смог найти упоминаний.