Comments 102
Ой ой, ну конечно.
Если оно такое уж большое, то и покажите этот стек вызовов, поймет наверное о чем речь идет.
А используют за тем, что там наверняка сотня оптимизаций кем то продуманы.
Да. Опитимизированны и уже придуманны.
Смысл данной статьи в том. Что из - за не знания основ. Начинается полное отсутствие понимания, как сделать приложение удобней пользователю. Менее русурсоёмким для сервера.
Что актуально, ибо закон Мура перестал работать, а требования растут по экспоненте.
Так ведь все и правда придумано и оптимизировано, только основы тут не при чем.
Не надо быть капитаном очевидностью, что бы понимать что выборка лишнего поля выбирает лишнее поле.
10 мб лишнего кода ныне и правда считать не стоит.
10 мб лишней передачи - это да, такое себе.
Но и времена сейчас такие, что кода на столько много, что проверяешь только то что откровенно тормозит
Вот бы человечество придумало что-то вроде анализатора, который бы находил неиспользуемый код в библиотеках (и в пользовательском коде тоже можно, кстати) и удалял из скомпилированного артефакта. Можно даже придумать какое-нибудь прикольное название, например, tree shaking. Тогда не станет проблемы +10 Мб, а библиотеки останутся полезными.
Ну так это известная проблема ООП - нужен банан, а притащишь и гориллу и джунгли.
Дайте вашим ребятам отладочные платы на attiny13 c 1кб Flash))) Сразу зауважают биты и байты :D
Статья говорит о проблеме фокусируясь в основном только на одной из причин - некомпетентности разработчика. Тогда как половина причин, а может и больше это хотелки бизнеса или внутренняя парадигма организации. Разработчик может и хочет что-то там ускорить, но всегда ли ему дадут это сделать?
На рынке конкуренция и надо выпустить MVP быстрее конкурентов? - Нафиг оптимизацию, делаем рабочий прототип на %известный фреймворк% и в продакшн. Оптимизируем потом с ростом нагрузки.
Клиенты жалуются на тормоза приложения? - Подтяните основные метрики. Если надо добавим ресурсов.
70% запросов жрет аналитика? - Ну простите уж, нам надо собирать много, много данных.
Надо провести рефакторинг и пересмотр архитектуры чтобы через пару лет все не навернулось? - Вы о чем вообще? Как я своему менеджеру прокину лишние расходы которые не принесут прибыль в текущем квартале? У нас вообще-то план есть!
А потом в Gmail тормозит интерфейс так, словно они майнят на клиенте крипту.
Не думаю что в Google работают отбитые вчерашние ученики курсов, которые не могут посмотреть вне абстракции.
Хотя, причем тут ученики курсов.
Тут затрагиваются архитектурные вопросы, к которым у джунов по идее не должно быть доступа. Джун не должен проектировать структуру БД. Это задача сеньора, который потом должен бить по рукам тех, кто пишет херовый код или запросы.
Надо провести рефакторинг и пересмотр архитектуры чтобы через пару лет все не навернулось? - Вы о чем вообще? Как я своему менеджеру прокину лишние расходы которые не принесут прибыль в текущем квартале? У нас вообще-то план есть!
Горизонт планирования менеджеров просто крошечный. Да и текучка у них... Я пережил уже троих на этом месте
С жмайлом мне кажется другая история. Они специально сделали его тормознутым, чтобы потом подкрутить хром и чтобы он только там работал прилично
Как минимум я видел перевод статьи от одного из работников Google, который рассказывал про карьерный рост менеджеров в компании через внедрение новых фичей. Если ты будешь просто оптимизировать сервис, ты повышение не получишь. Отсюда периодические переделки интерфейса, появление новых фичей и т.д. - и проблемы с тормозами приложения, которые в последствие могут еще и усиливаться.
Вернем ассемблер в массы! Пусть каждый джун перед запросом в базу напишет драйвер сетевой карты
Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Программирование, как искусство, закончилось тогда, когда ресурсы перестали быть ограниченными. Сейчас шедевра, типа 0x5F3759DF ожидать нечего. Сейчас это ремесло. Более оплачиваемое, чем работа дворника, но ничем принципиально, от нее не отличающееся. «Бери вот тут, кидай туда». Поколение LEGO.
А что в этом плохого?
Деградация профессии, которая к тому же воспринимается многими как "развитие". Это разве не плохо!?
Ещё раз, что в этом плохого? Задачи решаются?
Потребителю нужен не штучный шедевр, а массово работающий софт.
Объем ОЗУ TI59 около 1 КБ, а ПЗУ меньше 3 КБ. Вес widows калькулятора «…совсем небольшой, всего около 10-30 мб…». При этом на TI-59 можно решать уйму задач в автоматическом режиме, а 10-30 мб дают элементарные арифметические функции.
Ничто не мешает портировать калькулятор из старой винды. Я, кстати, где-то на хабре видел, как это сделать. Он и лучше и легче.
Дело в принципе. Чтобы дать мне элементарные функции + - × ÷ он ставит библиотеку с чуть ли не всей высшей математикой и геометрией. Кому есть дело до того, что из этой библиотеке для калькулятора надо доли промилле? За место на диске, память и время работы плачу я, а за длину кода и время программиста — они. Ежу понятно, на чем сэкономят.
Ничего. В юности за скромные, сравнительно, деньги, я шил себе в ателье одежду. Шикарную, по нынешним меркам. Я ее одевал и мне было приятно. Сейчас я одеваю одежду и мне тепло. В принципе это тот минимум, который нужен от одежды. Я бы хотел и сейчас пошить, но у кого? Нету мастеров. Ширпотреб их съел. Те, что остались, могут лиш штанину укоротить. Почему с программами должно быть иначе?
Прочитал простыню, которую можно ужать до "о боже, какой я умный, что вы хотели, старая школа, не какой-то там курсовкатчик". По итогу-то что? Какое решение, кроме брюзжания? Прямо-таки все современные приложения тормозят? Если вы не умеете писать хороший фронтенд, вдумываясь в архитектуру, может стоит заняться самообразованием, а не самолюбованием?
Т.е. Вы призываете работать "за идею" над проектами, за которые платят как за "... и в продакшен"?
Категорически не согласен, то, что вы называете путем добра - это преждевременная оптимизация и это путь зла. Сколько я таких мердж реквестов видел... Разработчик напишет, навертит и в итоге вместо 3х строчек кода я вижу 5 классов с кучей методов, я спрашиваю:
- Зачем?
- А вот когда у нас будет нагрузка, да 5 микросервисов, да шардинг бд...
- Ну щас же у нас такого нет, когда будет нагрузка, тогда и перепишем на твой варинт, а щас у тебя 5 классов по 3 метода в каждом вместо 3х строчек кода
- Ну нет, ну всё равно же, ну у меня же выдуманный мною мир рушится...
Оптимизация должна преследовать какую-то цель. Например, приходит бизнес и говорит: мы сделали исследование дизайна и обнаружили, что у нас страница грузится 500мс, часть пользователей не дожидается всей загрузки и уходит со страницы, если сократить загрузку до 5мс, то мы значительно повысим посещаемость. Разработчики: ок, переписываем на rust-е. У вас же цель, чтобы вам было прикольно, потому что вас триггерят слои абстракции и размер приложения - цель, которая нужна только вам и больше никому.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.
Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн.
Это прописные истины — буквально «нормально делай, нормально будет», что тут принципиально нового? При чем тут несчастный JSON и сериализация?
«Поколение JSON» (которому 25 лет, кстати), «что мы сломали в IT» (регулярно ломаем, кстати), «раздутый софт» (его раздувают инженеры, или бизнес, кстати?), «npm-зависимости» (шуткам про размер node_modules уже сто лет в обед, кстати) — это все, конечно, плохо, но про это (и как с этим бороться) примерно все давно в курсе.
И даже статьи с одной-единственной целью «подпишитесь на мой X, и скачайте оттуда бесплатный Y, пока не случилось Z» — тоже давно не новая тема.
Спасибо, что бесплатный, кстати!
Нет никакой базовой инженерной гигиены, спросите 10 разработчиков про неё, получите 10 различных определений.
API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн.
Вы следуете каким-то универсальным паттернам, а я говорю, что их нет. Каждый раз код пишется исходя из задачи и если у вас нет обоснования, почему нужно убрать лишних 50 полей, то значит вы зря потратили время на оптимизацию. "Нормальный дизайн" - это не обоснование, это маркер, что вы это делаете по привычке, а объяснить не можете.
Senior-а от Middle-а как раз таки отличает то, что Senior не делит подходы на черное и белое, а знает какой когда применять. В моем практике были кейсы и когда 50 полей хорошо и когда 50 полей зло. Когда нужны были uuid-ы, а когда делал внутренние id-и, чтобы не тратить время и их гораздо проще запомнить. Когда-то удобно было распилить монолит на микросервисы, а когда-то наоборот смержить в монолит.
Оптимизация должна преследовать какую-то цель.
Оптимизация всегда преследует одну и только одну цель.
Разработчики: ок, переписываем на rust-е
начать писать сервис на тормознутом питоне, через пол года разработки, а потом + еще пару месяцев танцев с бубнами вокруг различного рода оптимизаций, в итоге поняв, что таки не можем выжать обещанный SLA, принять волевое решение переписать все на go.
Ммм, путь добра :)
Оптимизация всегда преследует одну и только одну цель
Нет. Может быть оптимизация по тактам проца, может по памяти, может по зарплате разработчиков.
Я тоже так умею:
начать писать сервис на тормознутом go, через пол года разработки, а потом + еще пару месяцев танцев с бубнами вокруг различного рода оптимизаций, в итоге поняв, что таки не можем выжать обещанный SLA, принять волевое решение переписать все на Assembler.
Какое решение, кроме брюзжания?
Время идет, а старики всё также брюзжат на тему раньше было лучше.
И вот был разработан первый компилятор. Эту программу назвали Assembler, что переводится как "сборщик". Писать на нем практически так же сложно, как и в машинных кодах, однако теперь уже использовались не числа, а понятные, как показано на рис. 1.5, человеку слова.Теперь все та же команда копирования регистров выглядела так: mov eax, ebx. Да, код на ассемблере не совсем нагляден, но зато намного удобнее, чем то же самое, но в машинных кодах. Вроде все прекрасно и удобно, но почему-то среди программистов возникли споры и разногласия. Кто-то воспринял новый метод с удовольствием. А кто-то говорил, что машинные коды лучше, что программа, написанная в кодах, работает быстрее. Говорят, что эти споры доходили до драк и иногда лучшие друзья становились врагами.
Библия Delphi, 2007й год.
Ну те кто говорил "что машинные коды лучше, что программа, написанная в кодах, работает быстрее. " наверное были не программистами и не понимали сути ассемблера.
Ну так-то не всякая байтовая логика полностью представима на ассемблере, например если некая процедура начинается с байтов A9 06 2C A9 07 2C A9 08 и в разных частях кода существуют переходы на каждый из A9 (при этом команда A9 XX интерпретируется как lda #XX, а 2C XX YY как нечто незначимое), то это будут три процедуры с разными инициализированными значениями аккумулятора и общей последующей логикой и один и тот же байт A9 перед 08 будет выступать в разных ролях
Сказки венского леса. Во-первых, "eax,ebx" появились на два, если не три десятилетия позже ассемблера. Во-вторых, ни разу не видел чтобы кто-то утверждал что в кодах программа быстрее. Хотя сам когда-то в кодах писал.
Там еще забавный черри-пикинг фактов - когда мы хотим показать CPU(или latency) то мы учитываем сжатие json портянок. Когда мы считаем сколько лишнего egress в рублях тратится то про сжатие чудесным образом забываем.
Gzip действительно отлично жмет повторяющиеся ключи в JSON, и реальный egress-трафик будет меньше 'сырых' мегабайтов. Но проблема в том, что уникальные текстовые данные, вложенные структуры и избыточные метаданные (те же длинные токены, id и лишние base64) сжимаются хуже. К тому же, чем больше мы сэкономили на трафике за счет gzip, тем больше тактов CPU смартфона мы сожжем на декомпрессию этого "жира" перед тем, как отдать его парсеру. Так что за мусорные данные мы всё равно платим: либо рублями провайдеру, либо батареей пользователя.
Если размер JSON вырос до мегабайтов, значит проблема не в формате передачи.
Помню времена, когда вместо JSON обычно начинали городить "самопальные" форматы с конкатенацией данных через разделитель - со всеми сопутствующими багами, костылями и благополучной оссификацией уже через 2-3 релиза. А то и какой-нибудь CORBA/DCOM с тайплибами и IDL-компайлерами, если разрабы оказались поэнтэрпрайзнее да помускулистее.
Поэтому когда Microsoft выкатил LSP с просто HTTP и просто JSON-ками, то только тут, наконец, и вздохнул спокойно.
Несколько лет назад я бы сам ворчал, дескать, JSON - текстовый формат, расточительно, неэффективно, бу-бу-бу. Сейчас у нас есть парсеры, ворочающие JSONы гигабайтами в секунду.
Вы никак не отнимите у JSON его огромный плюс - он поддерживается практически любым языком программирования, можно читать даже на тостере или утюге. Так уж сложилось. Поздно брюзжать про бинарные СТАНДАРТНЫЕ форматы.
Вот, вот. Я сам из тех кто начинал программировать еще до DOS, и у меня многие оптимизации уже на автомате пишутся. Они для меня не оптимизации - я просто так думаю и пишу. Но, сколько раз ловил на ревью от молодых коллег, причем достаточно компетентных: "ты занимаешься преждевременной оптимизацией". Только вот для меня зачастую не "заниматься преждевременной оптимизацией" несет большую когнитивную нагрузку - плохо написать надо еще подумать как :)
Выскажусь с противоположной стороны, нельзя рассматривать оптимизацию кода в вакууме. Когда нагрузка на сервис ожидается в районе 1000 запросов в день - он там внутри может мегабайтами JSONов ворочать, лишь бы индивидуальные запросы укладывались в SLA.
Хорошо если приложение из коробки сможет обрабатывать 1000 запросов в секунду на одном инстансе, но если нет - такая оптимизация без нагрузки это пустая трата денег заказчика. В большинстве таких проектов я предпочту код, оптимизированный для чтения, а не для скорости.
Это же палка о двух концах. Допустим ты дефолт разраб у кабаныча. Как объяснить кабанычу, что ты будешь писать фичу не день, а N дней, просто потому что ты хочешь написать ее нормально, при этом результат будет чуть лучше, а не в N раз?
Автопосадка из космоса звучит конечно грандиозно, но на деле это всего лишь решение диффура (формулку запрогать)
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Я конечно сильно извиняюсь, но при чём тут бриджи если вы просто парсите JSON?
Этим занимается hermes или v8 (в классическом варианте), бриджи - это когда вы этот уже скорее всего распарсенный JSON передаёте нативному компоненту или модулю (который ловит его в виде NSDictionary или ReadableMap если ведроид).
Вы правы в деталях механики. Парсингом действительно занимается JS-движок (Hermes/V8). Но проблема возникает как раз на стыке: когда нам нужно прокинуть этот огромный массив данных для рендера списков на нативную сторону. В старой архитектуре это приводило к сериализации/десериализации при переходе через мост. В новой JSI (которую я упоминаю) это решается ссылками на C++ объекты, но аллокация огромного количества памяти под "мусорные" поля из ответа всё равно нагружает GC и съедает ресурсы процессора.
Насколько я помню всё-таки не совсем так, сериализировал только ios, а для андроида там вроде был какой-то конвертер из V8::Object в колхозный ReadableNativeMap прикручен, ну да не суть - разумеется когда некоторое особо талантливые разработчики пытались запихнуть в нативный компонент весь стейт редакса мегабайт этак на 10, это было весело при любой имплементации. Помню один гениальный проект где товарищи очень жаловались а чего это у нас нативный компонент такой плохой что только через пару секунд на изменение стейта реагирует (почти 10 лет назад история была, ещё до реактно-функционального треша, сейчас оно б ещё веселее у них работало).
Но тут скорее не про jsonы рассказ а про то, что вообще не надо пытаться пропихнуть много ненужных данных зараз туда куда их не нужно пропихивать в таком количестве.
А какую проблему мы вообще решаем?
Она меняется привычкой думать о том, что происходит за пределами фигурных скобок.
Зачем?
Давайте перестанем быть просто перекладчиками данных и вспомним, что мы, прежде всего, инженеры.
Инженеры решаю конкретные задачи, за конкретные ресурсы, с конкретными компромисами. И если нет конкретных условий на трафик то никто не будет принимать лишних действий.
Хотя я знаю «Зачем» была написана статья - ради рекламы тг канала
Хорошая статья про ответственность 👍
Автор книги Поколение JSON
А есть возможность получить автограф на бумажном экземпляре?
Без лишней драматургии тут, конечно, не обошлось... JSON победил потому что он читабельный, и все эти побочки в виде тяжеловесности - симптом плохой апишки, на помощь которой и приходят все эти кеширования и синхронизации
А какая простая альтернатива этому ? gRPC ? А как тогда дружить то что физически не дружится ? JSON потому и удобен что все что угодно можно сериализовать в него и десериализовать из него . Ну а про скорость , не надо в запросе 5 тысяч объектов из базы данных получать единоразово , и все.
Смешали все в кучу. V8 парсит мегабайты JSON за миллисекунды. Свистопляска начинается не из-за самого формата, а когда вы пытаетесь засунуть весь этот массив данных в React-компоненты и вызываете каскад лишних ререндеров DOM-дерева
Вот я сам люблю порассуждать о производительности, я получаю удовольствие от возможности оптимизировать какой-то кусок кода и от продумывания чистой архитектуры.
Но последнее время я чаще задумываюсь - а сколько времени (и, соответственно, денег) съест эта оптимизация? Например, мы сэкономим 4 тысячи в месяц на инфраструктуре, но при этом оптимизация будет стоить 2 недели опытного разработчика (200к+ с учетом налогов). Имея эти цифры перед глазами уже можно решать, что выгодней в текущих условиях. И, к сожалению, большую часть оптимизаций оказывается выгодней закрыть увеличением ресурсов.
Оптимизация должна преследовать какую-то цель.
Это можно рассматривать как часть общей культуры, как привычка писать правильно на родном языке.
Нормально работает только когда есть лимиты на размер ответа и мониторинг, иначе любой API со временем распухает
Считаю JSON отвратительным протоколом для пердачи данных. Вы вообще видили как он передаёт байтовые масcивы? Это просто ужас оверхеда. Он превращает их в base64. Вы даже строку нормально передать не сможете. Например в С# используется UTF-16. JSON UTF-8 и главное всю строку надо ещё пройти и заэкранировать.
К чему это я? А к тому что написать протокол который бы не имел этих недостатков - 10 минут. int количестиво переменных. 1 байт тип переменной. По типу определяешь длину переменной. Для массивов и стрингов добаляешь int длины. Всё! Хотите вложенные объекты - ну чуть усложнить. Ах да забыл. На имена переменных тоже по ushort добавить - длина имени. Ну и имя переменной в голых байтах. Это работает максимально быстро без какого либо оверхеда. WEB спокойно перекидывает данные в бинаром виде - нет никаких ограничений на только ASCII символы.
Я хз кому надо смотреть протоколы в сыром виде. Тем более JSON в сыром виде тоже шляпа та ещё - всё в одну строку. В любом случае парсить надо для наглядности. Так вот парсер для протокола который я описал выше - пишется не за 10 минут а за 5.
написать протокол который бы не имел этих недостатков - 10 минут
Protobuf немного постарше. Наверное его поколение json пишет, раз в 10 минут не уложились.
JSON — не протокол, а формат данных. UTF-16 — кодировка. У меня ощущение, как будто вы смешиваете то, что не надо вообще трогать.
JSON прежде всего это про удобство передачи данных. Хотите бинарные данные? Ну отправьте JSON, который укажет откуда брать эти бинарные данные и отдельно их возьмите.
Вы думаете, что такие огромные корпорации как Google не используют JSON? Они используют его на полную вместе с Protobuf, просто есть четкое понимание в какой конкретно ситуации нужно воспользоваться тем или иным инструментом. Фундаментально все зависит от того, как архитектор спроектировал все эти данные.
Поколение JSON
Когда настанет время "Поколения JSON-LD"?
Более приземленные вопросы. Обычно делаю единый код на браузерном JS для работы как на github (иной), так и локально (desktop). И тут конечно же натыкаюсь на "ужасный CORS". Есть какие-то рекомендации, как делать единый код для обхода CORS? Например, файлы конфигураций config.json оборачиваю в config.js. Как-то можно ошибки fetch() или как-то иначе загружать файлы (или только определять откуда и делать разные ветки в коде, если desktop, то с подтверждением пользователя)?
Не про json, а к "Они прорубаются через 7 слоёв инфраструктуры:". В том же проекте
была проблема с <script src="https://cdn.sheetjs.com/xlsx-0.20.2/package/dist/xlsx.full.min.js"></script>
Ошибка: файл XLSX is not defined
Особенно с мобильного инета постоянно нужно было жать несколько раз кнопку "обновить". Как решение - поместил xlsx.full.min.js в папку проекта (заработало), но может быть есть более грамотный выход (или объяснение)?
Не понимаю последнее время такие статьи на хабре. Ну при чем тут json то. Автор, читайте литературу, всё написано уже
Ушло уже время, когда такие статьи были актуальны.
Мы не должны возвращаться к 128 КБ. Но, кажется, нам пора вернуть себе тот уровень инженерной ответственности, который был у создателей «Бисера-4»
Ну, с текущими ценами на оперативку, есть вероятность пересмотра приоритетов. Правда для этого нужна ситуация, что кратно увеличится потребность в ресурсах и придется как-то решать проблему ресурсов.
Да, в современном мире проблема потребления ресурсов ушла на второй план, а если быт ьчестным это вообще не является проблемой, как отмечено, сейчас в любом умном чайнике два ядра, три гига. Когда пытаются рассказать, а вот раньше за 128кб сжали объекты из космоса, а траектории орбит считали по логарифмической линейке, сравнивают несравниваемое.
Как и денег есть инфляция, такая же инфляция есть у технических систем. Тогда требование было одной – она работала корректно. Современные системы имеют огромный список требования, где помимо работоспособности, есть еще требования к безопасности, к подержке, стоимости и времени разработке, многопточности и т.д. А сверху еще слой бизнесовых правил – что мы должны хранить, логировать, что и как передавать и т.д. И при всем при этом система должна быть спроектирована так, чтобы можно было вести паралельную разработку в разных командах и делать это максимально быстро. Да, злые менеджеры со своими метриками.
И при этом, те самы абстракции, которые позволили относительно быстро подключать людей к проекту и получать рабочие системы, не погружая человек глубоко в контекст. Шины, орекестраторы, медиатор, сто пятьсот паттернов и т.д. – все это раздувает и бэкенд, но при этом делает его устойчивым к развитию сервиса, систему не пишут один раз под одну конкретную задачу. А в 128 кб уверен влезло 10050 if, вызовов goto и регулярных переключений указателей памяти и ее очистки.
Мы используем текстовый формат для общения двух частей одной программы внутри одного процессора.
Простите моё невежество, но как мы к такому пришли? Я из мира промавтоматики, я не понимаю, как можно просто так забить на ресурсы и гонять джейсоны, когда у вас общая память. Почему не shared memory?
Если ваше приложение заикается на бюджетном Android-смартфоне
Расскажите это Яндексу, сберу, а заодно авторам иных мессенджеров, которые не умеют с малыми ресурсами делать великое дело - ждать прихода сообщения часами, и не высаживать на это энергию Братской ГЭС!
Вы бы купили автомобиль с тысячей колес, 125 дверями и 18 рулями? Нет. Потому что это очевидный абсурд. А в софте можно закопать абсурд так, что его не видно. Назвать всё преждевременной оптимизацией и сделать квадратичным поиском, тупым копированием, через подключение монстер-фреймворка, фабрики молотков и т.п. «Когда надо будет - перепишем». Ага.
Судей нет. Потому что судья должен быть экспертом, а экспертом быть непросто. Можно для начала на каждой веб страничке нарисовать счетчик съеденных тактов, памяти и трафика. Популяризировать в массах рейтинг и антирейтинг. И, возможно, откровенные поделия в стиле херак-херак начнут всплывать. Вернее, тонуть.
Вы бы купили автомобиль с тысячей колес, 125 дверями и 18 рулями? Нет.
А если он дешевле, и уже существует? А идеальный ждать несколько лет, а ездить надо еще вчера?
Можно для начала на каждой веб страничке нарисовать счетчик съеденных тактов, памяти и трафика.
И? Зачем автору странички оно надо?
Популяризировать в массах рейтинг и антирейтинг
На ту страничку люди не ради тактов ходят.
Извечный вопрос последних нескольких десятилетий - что сложнее: штамповать процессоры и память как горячие пирожки на конвейерных линиях или писать руками опытных (более-менее) людей уникальный код, в каждом случае для какой-то своей уникальной цели?
Оказалось, что массовое "железо" делать дешевле, чем писать код, который вынужден быть уникальным исходя из того, что каждый бухгальтер по своему трактует требования МинФина или ЦБР или какого-либо другого надзорного органа, например.
Время ускоряется, люди хотят успеть, быть не хуже конкурентов. Сейчас это решается только переиспользованием, декораторами, абстракциями. Делать простой и быстрый код хорошо, но пока есть ресурсы никому не нужно. Нет бизнес модели, которая это хотя бы окупит.
Оно-то конечно всё верно. Раньше в 128 КБ могли вместить много чего. Да впрочем и сейчас есть специалисты. Которые и список контактов вам сделают плавно открывающимся. Но только во сколько оно всё обойдётся, такая роскошь? Сколько стоит рабочее время джуна, который вам напишет строчку на JS, и сколько стоит рабочее время профи, который будет ещё возиться незнамо сколько?
Вы в курсе, сколько там надо было копаться с ассемблером, чтобы создать весь софт для Бурана. И какие математики нужны были? Современные JS джуны им в подмётки не годятся.
Смартфон с ценой как у Бурана мало кто купит. Даже если там вместо проца attiny 13.
Софт для Бурана делали на "Драконе". Вернее, разработчики рисовали на "Драконе", а потом передавали кодерам, чтобы те закодировали. А математику делали математики. Никаких сверхчеловеческих усилий от каждого отдельного специалиста не требовалось.
И уровень сложности собственно программирования был, как справедливо написали выше - "формулку запрогать".
Проблема в том, что всем (99.9%) в компаниях занимающихся разработкой ПО пофигу на производительность.
Я когда-то любил заморочиться с производительностью, считал миллисекунды, потраченные килобайты памяти, радовался как мой проект на самописном фреймворке с кучей логики и запросов в базу отдает ответ на http-запрос за 20 мс, а симфони которая считается топ-фреймворком в пхп только собирается за 60-100 мс, не говоря уже об обработке запроса.
Но все продолжат пилить проекты на симфони и доктрите, получая ответ по 500-1000 мс. Потому что пофигу на производительность.
Поколение JSON: цена удобных абстракций и упадок культуры ресурсов