Время от времени я пользуюсь одним сервисом: мне нужно загрузить файлы в какое-то место (название сервиса не имеет роли, потому что, откровенно говоря, все они одинаковы). По сути, я просто указываю папку на своём жёстком диске, после чего её содержимое копируется на удалённый сервер, на котором, вероятно, происходит что-то связанное с базами данных — этим файлам присваиваются имена и выполняются проверки того, кто их скачивает.
Сервисом владеет большая компания, поэтому её процессы масштабны; вероятно, её часто пытаются взломать, поэтому требуется какая-то защита, а также проверка того, что файлы никто не модифицировал в промежутке между загрузкой с моего компьютера и получением на сервере. Всё это я понимаю.
… но по сути, речь идёт о том, что нужно зарегистрировать несколько файлов, считать их, загрузить, а затем закрыть соединение и записать в файл лога, всё ли прошло успешно, а если нет, то что именно случилось. В этом нет ничего сложного, и даже я писал с нуля подобный код при помощи Wininet API и PHP на сервере, общающемся с моей базой данных MySQL. Наверно, моя система была не такой надёжной, как системы уровня энтерпрайза, однако поддерживала сотни тысяч загруженных файлов, их верификацию, скачивание и логирование. Наверно, это работа для одного кодера на две-три недели?
Специальный инструмент загрузки на сервер, которым я пользуюсь сегодня, суммарно имеет 230 МБ клиентских файлов и задействует 2,7 тысяч файлов для управления этим процессом.
Возможно, вы подумаете, что это опечатка, однако ошибки здесь нет: две тысячи семьсот файлов и 237 МБ исполняемых и поддерживающих файлов для копирования нескольких файлов с клиента на сервер. Это уже не bloatware и не оверинжиниринг, а абсолютное, совершенное, очевидное, наглядное безумие.
Проблема в том, что, скорее всего, этот аплоадер не отличается ни от одного подобного современного ПО, созданного любой другой крупной компанией. А, кстати, он выдаёт сообщения об ошибках и на текущий момент не работает.
Я видел кодеров, которые занимаются подобным. Я знаю, как это происходит. Это происходит не только потому, что кодеры не пишут низкоуровневого эффективного кода для достижения своей цели: они просто никогда не видели низкоуровневого эффективного, хорошо написанного кода. Как можно ожидать от них создания чего-то более качественного, если они даже не понимают, что это возможно?
Вы можете написать программу, которая загружает файлы на сервер надёжно, быстро и безопасно, и для этого потребуется двенадцатая часть от этого количества кода. Это может быть один файл, просто единственный маленький
.exe. Ему не нужны сотни и сотни DLL. Это не только возможно, это легко, и такое решение будет более надёжным, эффективным и удобным в отладке, к тому же (подчеркну) оно на самом деле будет работать.Можно подумать, что на разбухание кода жалуются старые программисты за пятьдесят (вроде меня), потому что они старые и ворчливые. И я осознаю это. Но старые и ворчливые жалуются на код, который работает на 50% медленнее, чем нужно, или на код, который на 50% больше нужного. Однако ситуация вышла далеко за эти рамки. Мы достигли черты, после которой, как мне искренне кажется, 99,9% кода в файлах на наших PC абсолютно бесполезны и даже, чёрт побери, никогда не исполняются. Код просто лежит в пакете из 65 DLL, просто потому, что кодер хотел сделать что-то тривиальное, например, сохранить битовое изображение и *понятия не имел, насколько это просто*, поэтому импортировал целую кучу bloatware, чтобы решить задачу.
Как я и говорил, на самом деле мне не стоит сердиться за это на молодых программистов. Именно так их и учили. Они понятия не имеют, что такое высокая производительность или разработка с учётом ограничений. Если скажешь им, что в первой Elite была огромная галактика, космические бои в 3D, система развития карьеры, торговля и тысячи исследуемых планет, и при этом игра умещалась в 64 КБ, то они услышат вас, но не осознают пропасть между этим и тем, что мы имеем сегодня.
Почему для меня это важно?
Меня волнует это по множеству причин, и не в последнюю очередь потому, что если для выполнения задачи вам нужно в две тысячи раз больше кода, то он хотя бы должен работать. Но более важно то, что я осознаю: 99,9% процессорного времени моего огромного мощнейшего PC совершенно бесполезны. Он выполняет миллиарды операций в секунду, просто чтобы простаивать. Поэтому сейчас он должен находиться в сверхнизком режиме энергопотребления, все вентиляторы должны молчать, потому что всё, что я делаю — это занимаюсь проверкой орфографии, вводя текст в WordPress.
Ха. WordPress.
Сегодня компьютеры настолько быстры, что мы должны были бы воспринимать их как абсолютную магию. Всё, что бы вы ни могли представить, должно успевать происходить за 1/60 секунды. Тем не менее, когда я нажимаю на значок громкости ноутбука Microsoft Surface, то вижу задержку: машина постепенно создаёт новый элемент интерфейса пользователя, разбирается, какие значки отрисовывать, а затем они появляются и становятся интерактивными. На это уходит время. Кажется, около половины секунды, что в масштабах времени процессора близко к миллиарду лет.
Если сейчас (по консервативным оценкам) 99% ресурсов наших PC тратится впустую, мы впустую тратим и 99% потребляемой компьютером энергии. Это абсолютно преступно. И для чего же эти траты? Понятия не имею, но если взглянуть в диспетчер задач, то можно увидеть тонну разбухшей программной ерунды, которая бог знает чем занимается. Я всего лишь печатаю этот пост для блога. В Windows запущено 102 фоновых процесса. Моей графической карте NVIDIA в настоящий момент принадлежат 6 из них, а некоторые из них имеют подзадачи. Чтобы делать что? У меня не запущена игра, я пользуюсь практически тем же набором функций драйвера видеокарты, что и двадцать лет назад, но зачем-то необходимы 6 процессов.
Web View Microsoft Edge тоже нужны 6 процессов, как и самому Microsoft Edge. И я даже не пользуюсь Microsoft Edge. Кажется, я открывал вчера файл SVG, и вот пожалуйста — 12 бесполезных кусков кода впустую занимают память и, наверно, к тому же опрашивают ЦП.
Это совершеннейшее, совершеннейшее безумие. Именно из-за этого ничего не работает, всё медленное, нужно покупать новый телефон каждый год и новый телевизор для скачивания этих раздутых приложений для стриминга, в котором тоже прячется столь же плохой код.
Лично я думаю, что дальше всё будет только хуже, потому что крупные тупые, бесполезные технологические компании наподобие Facebook, Twitter, Reddit и т. п. — наихудшие примеры этой тенденции. Скоро каждый из тысяч работающих в этих компаниях «программистов» будет использовать машинное обучение для копипейста раздутого, забагованного, расползающегося фуфла с Github в свой код. Просто для того, чтобы сложить два числа, понадобится 32 DLL, 16 служб Windows и миллиард строк кода.
У Twitter две тысячи разработчиков. Tweetdeck иногда отказывается загружать столбец пользователей. Это происходит уже четыре года. Уверен, что никто из кодеров не представляет, почему это происходит, а код в его основе — это просто куча раздутого скопипащенного навоза.
Предлагая название темы по тексту ссылки, Reddit не может справиться с амперсандом, точкой с запятой и символом фунта. На дворе 2022 год. Вероятно, у компании тоже две тысячи разработчиков. Очевидно, ни один из них не способен заставить правильно работать парсер текста. За что платят всем этим людям?
Когда-то был золотой век программирования, когда у нас были ограничения на память и ЦП. Сегодня мы живём в яме неэффективности и огромной траты ресурсов. Это очень печально.
Комментарии (615)
Breathe_the_pressure
24.06.2022 14:14+14Специальный инструмент загрузки на сервер, которым я пользуюсь сегодня, суммарно имеет 230 МБ клиентских файлов и задействует 2,7 тысяч файлов для управления этим процессом.Проблема есть, но все вовлечены в процесс раздувания, разворота не видно. Сами работодатели всех заточили на фреймворки, спрашивают и там и тут. Там из этих 230 мб, можно целый CRM наверное сваять.
Ну и условно всех учат собрать Теслу из выданных компонентов, а реальные задачи от работодателя, это собрать из этих компонентов - фонарик.
antonblockchain
24.06.2022 15:18+13230 мегабайт это больше чем windows 2000 или windows 98.
это целая операционная система 32 и 16 битная одновременно.
еще 20 лет назад.
с тех пор ничего не поменялось в пользовательском опыте работы.
(не игр)
navferty
24.06.2022 16:17+15Всё-таки Вы слишком категоричны в "ничего не поменялось в пользовательском опыте". Поменялось очень многое, начиная от более удобных и интуитивно понятных интерфейсов, не требующих чтения учебных пособий по ним, заканчивая возросшей функциональностью программ.
Я не отрицаю проблему, которую поднял ТС, и сам солидарен с его позицией. Но это цена за то, что разработка становится дешевле, а значит у пользователя появляется намного больший выбор ПО, которое он может использовать. Можно писать программу максимально близко к железу и упарываться по производительности, иногда это оправдано. Но тут приходит какая-нибудь фирма, и говорит "сколько стоит написать сайтик корпоративный? 50 тыс. руб.?? а что так дорого?!" и разрабочик берёт готовый фреймворк (раздутый потому что универсальный) и быстро пишет на нём этот сайт.
AlexeyK77
24.06.2022 16:52разработка точно не становится дешевле, и тем более чем 20 лет назад.
Hisoka
24.06.2022 19:30+4Ох, если всё время придумывать новый способ организации данных (виндовс, машем ручкой всем твоим разновидностям диалогов, некоторые до сих пор из 98/nt4. Кстати, это эталонная помойка, за которую часто любят ругать линуксовые смешивания kde/gnome приложений).
Хороший пример "удорожания" разработки - 20 лет назад приходилось брать 3D модель, делать развёртку и рисовать в каком-нибудь фотошопе текстуру по этой развёртке. Сейчас, в том же блендере можно взять картинку и тупо рисовать частью этой картинки в текстуру, используя проекцию окна. Это просто фантастика для 2000 года. Я уже молчу про перевод из фоток в 3D в каком-нибудь Meshroom. Да, там надо редактировать и делать по сути новую сетку, но! это уже очень легко делается по готовым поверхностям в пространстве. 3D скульптинг - тоже "магия", когда с планшета просто "рисуешь", а не кропотливо решётку с нуля фигачить.
Ded_Banzai
24.06.2022 21:49+8Но смысл изначально был в другом. У вас новый функционал, полезный и разнообразный. Хоть и раздутый код для его реализации. Я не знаю, может быть в фотошопе это оправдано, но калькулятор, который раньше ел меньше мегабайта, а сейчас за раз отъедает за 150 мегабайт оперативной памяти при таком же функционале - это действительно просто неприлично уже. В посте это и рассматривается, что крохотная приложенька делала то же самое, что и 200+ мегабайт и 2700 файлов.
denis-isaev
25.06.2022 01:27+1Калькулятору 20-летней давности не приходилось думать о hidpi, 4k, мультимониторных конфигурациях, тач-управлении, поддержке десятка тем интерфейса, синхронизации в облако, подгрузке из интернета курсов валют и еще вагону функционала, который отдельному пользователю может и не нужен, но нужен другим пользователям, а писать 100500 версий под каждого юзера нерентабельно.
DrPass
25.06.2022 01:36+12Дело в том, что современному калькулятору тоже не приходится об этом думать. Все эти темы/тачи/hidpi и иже с ними — всё это разруливают библиотеки операционной системы. А в плане функционала он не слишком ушёл от калькулятора 20-летней давности, зато жрёт ресурсов примерно как AutoCAD или MathLab 20-летней давности
denis-isaev
25.06.2022 03:02Вот именно этими библиотеками, входящими в состав калькулятора, и набираются те мегабайты, которые в этой теме хейтят.
Ded_Banzai
25.06.2022 18:52Они же в составе ОС, зачем они отдельно? Да и крайне сомнительно, что поддержка тача увеличит код на 40-50 мегабайт
cepera_ang
25.06.2022 18:57+2Это характерное мышление некоторых современных программистов, оправдание раздутости невероятной сложностью: «все эти тачи/hidpi/unicode» — это просто мантра для остановки размышления. «Ты что! Не лезь! Сложно же, там тач, хайдипиай, конверсия валют и другие какие-то штуки важные»
denis-isaev
25.06.2022 21:20+1Давайте посмотрим на ваш код. В нем вы юзаете огромный
telegram.extтолько радиUpdaterиCommandHandler.
Почему не написали свою обвязку? Это же пара сетевых вызовов, ради которых вы инклюдите в проект большую библу, функционал которой на 99% не используете.
В соседнем файле для парсинга даты фиксированного формата вы юзаетеdateutil.parser. Это вместо того, чтобы написать простой regexp. А ради парсинга пары аргументов запуска, юзаетеargparseв котором еще тонна ненужного вашему софту функционала.
Вы когда этот код писали, вам кто на ухо мантры для остановки размышления начитывал? :)
cepera_ang
25.06.2022 21:28Когда я этот код писал (форкал, на самом деле), то даже и не думал, что буду хоть кем-то называться “программистом” восемь лет спустя. :)
denis-isaev
25.06.2022 21:38+1А кто-то из посетителей этого поста запускает ваш бот и причитает, что автор раздул свой софт на ровном месте и заюзал большие библы там, где не стоило и поэтому оно теперь жрет много памяти и диска :)
Репа, кстати, не форкнута :)
cepera_ang
25.06.2022 21:50Репа, кстати, не форкнута :)
Ибо я тогда и не умел особо, скопировал себе, потом запушил. Или что-то такое. А может и вообще просто из примеров накидал, не помню.
Если у этого кода есть хоть один пользователь, то я буду очень удивлён :) А вот когда такой же код встречается в проектах, которыми пользуется миллиард пользователей — это уже беда.
denis-isaev
25.06.2022 21:54Хотите сказать, что если этот ваш проект начнет использоваться некоторым количеством человек, то вы вложите в него свои ресурсы (финансовые и временные), чтобы все переписать без зависимостей?
cepera_ang
25.06.2022 22:28Хочу сказать, что если я буду делать проект для значительного количества пользователей, то я буду вкладывать в него свои финансовые и временные ресурсы :)
Где пошла речь про переписывание без зависимостей я не заметил. Обсуждаемый бот имеет самую большую зависимость — интерпретатор питона, запускается на любом тостере и жрёт практически ноль процессора, потому что ограничен скоростью опроса API (что-то типа раз в минуту было в то время допустимо).
Mingun
25.06.2022 22:09Я понимаю, сторонние пакеты, но чем вам
argparse-то не угодил? Он же в стандартной библиотеке, так что по-любому есть всегда и нисколько не увеличивает конечный объём приложения — глупо отказываться от предоставляемого им функционала даже «ради парсинга пары аргументов запуска».
denis-isaev
25.06.2022 22:21+1А какая разница стандартная или нет? Если представить, что мы собираем дистриб для распространения, то в него будет включено только то, что мы заюзали, а не всё, что с питоном прилетело. В рантайме аналогично — оперативу есть будет только то, что мы подключили, а не все, что есть в стандартной библе.
Если отложить в сторону рантайм, а распространять скриптом/исходником, а не инсталлером/дистрибом, исходя из того, что питон (со стандартной библой) есть на целевой тачке, тогда ваше замечание в тему, но такое распространение — это частный случай. Ну и тут больше про win приложения, кмк, топят. Ну и весь мой коммент был не более, чем примером на скорую руку, но надеюсь суть я донес :)
cepera_ang
25.06.2022 22:33Если бы я делал сейчас, то бахнул бы на Rust’e, вкомплил бы всё в один бинарь с LTO и использовал бы реально минимум. Но это сейчас, потому что я как раз и прошёл путь от «могу накидать скрипт на питоне и мне пофиг на ресурсы» до «специально изучил новые инструменты, чтобы снизить оверхед из-за того, что это моя ценность как разработчика».
На практике никакой разницы бы не было — минимальная тачка на AWS t1.micro была бы пустой не на 99%, а на 99.9%, но всё равно было бы приятно. И скорость разработки бы ничуть не пострадала.
denis-isaev
25.06.2022 22:37Покажите ваш современный коммерческий код :) Пошаримся в нем на предмет сторонних библов :) Уверен, что найдем оч много :)
denis-isaev
25.06.2022 22:47С вашего коммента.
Вы где грань проводите что еще можно, а что уже нельзя? К примеру, если telegram.ext можно, а qt нельзя, то как этому прийти?
cepera_ang
25.06.2022 23:10Из коммента не следует, что сторонних зависимостей не должно быть, из него только следует, что нельзя сходу оправдывать многократный рост размеров тем, что приложение содержит что-то, что считается «сложным» в разработке. Тут в комментариях уже много вариантов такого «сложного» мелькало, кому то парсинг форматов кажется магией («ты что! Там тыщи типов файлов поддерживаются, сам будешь писать — там уязвимости будут, вот на их закрытие и уходят мегабайты»), кому-то якобы юникод раздувает, кому-то кажется, что поддержка нескольких мониторов должна быть сложной, или рендер шрифтов в терминале.
А на практике, libpng — это не то, что раздувает код. А поддержка webgpu и джойстиков, родная для хрома, который электрон, который нужен для запуска текстового чатика :)
Использование telegram.ext вместо собственной логики запросов к телеграму добавило килобайт 100 кода на питоне. Не думаю, что это bloat. А вот распространять такой проект в каком-нибудь докере внутри virtualbox’a — уже да. И я так говорю, потому что такой софт есть.
denis-isaev
26.06.2022 02:09Вам показалось сложной в разработке реализация запросов к серверам телеги и вы взяли telegram.ext. Кому-то показалось сложной в реализации аналогичная штука — запросы к биржам за курсами валют для калькулятора и он взял готовую библу биржи. Еще кому-то показалась сложной своя реализация поддержки hidpi и он переехал на qt.
При этом свой кейс вы оправдываете, а про остальные язвительно пишете "«Ты что! Не лезь! Сложно же, там тач, хайдипиай, конверсия валют и другие какие-то штуки важные»", удобряя это заключениями об остановке размышления современных программистов.
cepera_ang
26.06.2022 11:08Именно так, себя восьмилетней давности я бы не называл программистом вообще. Тем более хорошим. Даёт это мне право называть делающих также плохо — плохими программистами? :)
denis-isaev
26.06.2022 17:52Вы покажите ваш сегодняшний код и тогда будет понятно :) Я уверен, что в нем вы не пишете свою реализацию гуёв, а берёте тяжелый qt. А ваши олдовые пользователи жалуются, что раньше гуи столько не жрали :)
Mingun
25.06.2022 22:36А разве при распространении дистрибутивом стандартная библиотека режется? По-моему, она просто рядышком вся упаковывается, вот и всё.
denis-isaev
25.06.2022 22:44Это, наверное, смотря как паковать. Я не настоящий питонист, но кажется мне, что возможность не паковать всю stdlib в нем должна быть. Там ведь каждый модуль в отдельном файле. Просто оставить нужные, вроде, ничего не мешает.
denis-isaev
25.06.2022 21:07Если мы говорим про рантайм, то пофиг где лежит библа на диске (в составе ОС или не в составе), она будет в памяти процесса и будет увеличивать размер занимаемой оперативки.
Если мы говорим про размер дистриба, то чтобы ваша софтина поддерживала нужные фичи, вам придется заюзать какой-ить qt и прочие .net-ы, что увеличит размер дистриба.
Ну или можете написать все это сами.
vconst
25.06.2022 10:05+2Только что запустил виндовый калькулятор — 5,6 мегов в оперативке занял
Откуда 150?
Static_electro
25.06.2022 10:22+3Безотносительно потребления памяти - но я отчётливо помню как "новый" калькулятор в вин8 меня поразил в самую пятку, когда при запуске показал крутилочку пока загружался UI. Честно признаюсь, память не замерял
ss-nopol
24.06.2022 17:16+13Поменялось очень многое, начиная от более удобных и интуитивно понятных интерфейсов
По-моему интуитивной понятности стало меньше. Но это, конечно, моя субъективная оценка.
antonblockchain
24.06.2022 18:21+12В пользовательском опыте ничего не поменялось.
Графический интерфейс.
Все офисные программы в графике.
Мышка все дела.
Броузер тоже уже был и там все работало.
По работе обычного офисного планктона ничего не поменялось.
разработка иде тоже была и вполне работала.
автоподстановка тоже была.
весь Delphi7 весил меньше чем сейчас один голый редактор.
именно пользовательский опыт рабочего места специалиста не изменился.
тот же 1с его дизайн сейчас в 2022 хуже чем был в 2002 когда вышла 8 версия.
тоже графический)
Alex_ME
24.06.2022 18:32+1На Делфи не писал. Но самое простое и юзабельно в плане разработки GUI, с чем я сталкивался - это VB6. IDE, маленький бинарь. Потом я перекатился на C#, и там уже все тянет за собой целый .NET, и Qt, который тоже немаленький.
Еще был (есть) C++ Builder, в котором был и редактор форм, и целая хренова туча виджетов, втч всяких сложных. И еще помню были всякие пакеты компонетов для C++ Builder. Эх, времена.
Что касается GUI, то чем более новая технология, тем она сложнее и выше порог входа.
AHOHNMYC
26.06.2022 06:19VB6. IDE, маленький бинарь. Потом я перекатился на C#, и там уже все тянет за собой целый .NET
Бинарь маленький, но не самодостаточный. А .NET встраивается в винды начиная с версии XP. Обе технологии используют виртуальные машины (интерпретирующие P-код и CIL, соответственно) и обе же требуют сред исполнения.
Alex_ME
26.06.2022 07:14Посыпаю голову пеплом.
А .NET встраивается в винды начиная с версии XP
Насколько я помню, там либо не было .NET, либо был очень-очень старый (чуть ли не 1.0)
denis-isaev
25.06.2022 01:53+2Во времена до появления usb флешек любили хаять Delphi[1-2-3] за большой размер exe-шника, который не влазил на дискету. Олды плевались от vcl и говорили, что ванильный winAPI рулит :) Теперь Delphi7 — ориентир для отсчета :)
DrPass
25.06.2022 02:09+1У Delphi 4 пустое приложение весило килобайт 350, если мне память не изменяет, и очень хорошо архивировалось. Ну т.е. на дискету много чего было можно всунуть :)
denis-isaev
25.06.2022 03:13За пустое приложение зачет не поставят :) А еще ресурсов напихать надо! Но архивировалась эта балалайка хорошо, да!
V1RuS
24.06.2022 18:31+5Чтобы сделать хороший "интуитивно понятный интерфейс", надо уметь делать хорошие интерфейсы. Это почти никак не связано с кодом.
JordanCpp
25.06.2022 14:02+1Почему бы не совместить быструю разработку и адекватный по ресурсам фреймворк? Фреймворк это абстракция над ниже лежащим уровнем. Ситуация больше похожа на строительство абстракций над абстракциями. К примеру CMake генерирующий текста для разных билд систем. С каждой версией становится больше и сложнее и не удивлюсь если скоро выйдет новая тулза, которая генерирует текст для CMake, так как это проще, чем юзать сам CMake. Сама по себе задача, по сборке программ не изменилась, собрать программу, ну ок дополнительные телодвижения по интеграции, прогонов тестов(если они есть:))
cepera_ang
24.06.2022 17:47+8При этом rclone, который умеет загружать и синхронизировать файлы на все возможные облака (включая то, куда льёт автор с вероятностью 99%), а так же на всякие виртуальные/шифрованные/сжатые таргеты — весит 13мбайт. И то, только потому что написан на Go, который компилит всё в «гигантский» статический бинарь.
grishkaa
24.06.2022 14:21+32В последнее время developer experience считается едва ли не самым важным. Типа, код красивый, писать мало/удобно, вот это всё. А то, что оно тащит за собой грёбаный браузер, и вообще, писать полноценные приложения на макросах для гипертекста не может быть адекватной идеей, никого не останавливает. Продукт побочен и вторичен, важен исключительно сам процесс.
Прикиньте если бы почти все популярные клиенты мгновенных сообщений были написаны на макросах word, на бейские, и поставлялись бы с копией ворда. Электрон — это вот настолько же нелепо.
IvanSTV
24.06.2022 15:25+2Пользователю глубоко пофигу, на чем написано, лишь бы работало. А с копией ворда есть немало плюсов взаимной интеграции. Можно отправку сообщений из ворда автоматизировать не через гребанный API, а напрямую, например. Можно дорабатывать клиент под требования бизнес-процессов.
grishkaa
24.06.2022 15:34+22Так оно и работает, только херово. У пользователей планка качества просто уже под землю ушла, поэтому они когда видят что-то, что работает быстро даже на старом железе и не занимает под сотню мегабайт, реально удивляются.
IvanSTV
24.06.2022 16:06+3тут цепная реакция - новое ПО наращивает объем кода, пользователю приходится наращивать железо, как правило, с излишком от требований ПО. Новое ПО закладывается под излищки - нефиг оптимизировать, если ресурса и так полно, и на какой-то этапе ресурс исчерпывают, пользователь покупает новое железо.
А если не покупает и сидит на старых версиях - то начинают лезть вопросы совместимости форматов, сценариев, обязательно требуют для просмотра/проигрывания файла прикрутить свистоперделку, которую или не поставишь на старое железо\ОС, или жрет ресурс как не в себя.
TerrorDroid
24.06.2022 18:04+4А на деле даже в 2022 году сам Microsoft продаёт типа современные ноутбуки Surface Go, которые начинаются с 4 ГБ оперативной памяти, ставишь туда такие Slack, Discord и прочие шедевры и всё - приехали.
grishkaa
24.06.2022 18:48+6У меня оперативки 64, но дискордом всё равно пользуюсь в браузере. Отличий от отдельного приложения вообще никаких, UX такой же бесячий, но хотя бы не обновляется по 5 минут с 3 перезапусками без возможности отключить обновления.
DistortNeo
24.06.2022 18:51+9Меня больше бесит Teams, который суть — обёртка над браузером.
Но если аналогичные сервисы Google прекрасно работают из браузера, в т.ч. и из Firefox, то Teams не работает и требует запуска через приложение. Пусть горят в аду.zv347
25.06.2022 10:06В смысле «не работает»?
Собственно, в браузере он мне нравится больше, чем стэндэлон.
P.S. При открытии ссылки на конференцию Zoom тоже требует скачать программу без вариантов. Если обновить страницу, появляются варианты. Может, и тут так же.DistortNeo
25.06.2022 11:51В смысле: нельзя устроить аудио/видеоконференцию.
Zoom — нативный клиент, а Teams — Electron, поэтому ограничения кажутся искусственными.zv347
25.06.2022 12:01-1Несмотря на то, что у Zoom нативный клиент, отличий в UX в браузерной версии я не нашел. Допускаю, что они есть, не суть.
Я, видимо, чего-то не понимаю, но... в браузерной версии Teams, точно как в десктопной, назначаю встречу, присоединяюсь и провожу видеоконференцию. С демонстрацией экрана.
encyclopedist
26.06.2022 01:02Микрософт тупо проверяет User Agent. Если подставить юзер агент от хрома, то звонки магически начинают работать. Я сейчас точно не помню, я так делал примерно 2 года назад, но кажется проблемы были только с расшариванием экрана.
DistortNeo
26.06.2022 11:43Вот это и отвратительно. Поменял User Agent — и действительно, стало лучше. К слову, по неведомой причине, родной клиент Teams в Linux позволяет шарить только весь экран, а браузер — отдельные окна.
TerrorDroid
24.06.2022 18:02+4Насколько я помню, клиент электронной почты Outlook до сих пор рендерит html в письмах с помощью движка Word. Такие дела.
yokotoka
24.06.2022 22:05+5Видимо браузер, в итоге, оказался лучшим решениям для построения кроссплатформенных приложений. Что там конкурирует?
Мёртвые Adobe Flash/JavaFX?
Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год? Да так, что уже видно что это тенденция и не хочется инвестировать время в то, что через год закопают. Сколько их было и есть? Silverlight, WinForms, XAML, Xamarin, Avalonia, вот сейчас всех на MAUI перетягивают. Ждём следующую MS THE CURRENT THING, которая, конечно, опять будет лучше и на которую надо будет всем переползать, выбросив в мусор инвестиции своего времени в изучение всех предыдущих THING. Уверен, что забыл ещё с десяток "вот теперь точно последних кросс-платформенных фреймворков для создания приложений" от одних только MS. Они там вообще ку-ку?
Qt с их неудобными и дорогими лицензиями? И в целом есть ощущение, что проект перестал развиваться.
Гуггловый Flutter? Похоже, единственный адекватный вариант на замену электрону. Только за чей счёт будут переписываться тонны того, что кодеры сейчас ставят из npm - большой вопрос.
grishkaa
24.06.2022 22:11+7А не надо делать кроссплатформенные графические интерфейсы. Меня за такое, может, и заминусуют, но я считаю, что либо нативно, либо никак, а кроссплатформенных графических интерфейсов — таких, которые сами рисуют контролы и реализуют поведения — существовать просто не должно. Они всегда выглядят и работают достаточно чрезжопно. Зато, конечно, да, разработчикам время экономят, а пользователи страдают, но кого это волнует. Разработчики же важнее пользователей.
Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год?
Конкретно под винду — WinAPI работает и будет работать всегда. Тут как я с андроидом: все бесятся и носятся и обожают все эти гугловые абстракции и прочие jetpack compose, а я просто беру и использую всё системное.yokotoka
24.06.2022 23:18+9Вы считаете так. А те, кто платят деньги за разработку, чтобы зацепить как можно больше пользователей и не имеют столько же бабла, сколько Uber или Facebook - считают иначе. :) Заплатить один раз на условном Unity/Flutter/Adaptive Web или заплатить много раз на iOS, Android, Win, Mac, Web - хм, что же выбрать?
WinApi работает. Но работает только на винде. Вопрос "только на винде" не стоит, потому что в мире существует не только винда. И ещё вопрос - зачем тогда Microsoft ТАК мечется? Есть же WinApi.
DevilDimon
25.06.2022 03:46-8Вы считаете так
Да нет, все считают так. В мире приложений почти все ходовые приложения - нативные. Уже даже стартапы сразу пишут нативные приложения, потому что их потом при росте не нужно будет переписывать на нативные (а пользователи и разработчики обязательно попросят). Самые известные примеры - AirBnb (выкинули React Native) и Slack (переписали с Electron целиком).
В мире игр вообще кроссплатформенности почти нет. На моем маке могу запустить только 10% библиотеки Steam. Если "все считают", что кроссплатформенность нужна, то где версия под мак? Или под линукс без Proton?
yokotoka
25.06.2022 04:37+9Вы только что привели пример Slack, которые изначально писался как раз на Electron, чтобы писать код только один раз - для Web, а потом использовать его везде. Потом они заработали бабла и смогли себе позволить нативные приложения. Это уже опровергает тезис, что «все считают так». Именно Slack считал, что пока бабла нет, его надо экономить.
Не знаю насчёт AirBnb, они стартовали с React Native, или пытались удешевиться и ускориться за счёт него. Если пытались удешевиться и ускориться - значит всё не так прекрасно с нейтивами? А если же стартовали - это, опять же, опровергает тезис что «все считают так». Именно, что «все» (если не брать уже богатые компании или стартапы с бесконечным финансированием) сначала экономят деньги. А потом, когда денег становится много - пишут нэйтивы. Собственно, пример со слаком именно об этом. Насчёт AirBnb не возьмусь судить, не знаю истории.
Тут ещё вспоминается ClubHouse, который изначально был под iOS только. И много других iOS-only приложений, которые потом заходят на Android. И не пишут сразу на обе платформы, потому что денег делать одно и то же по 2 раза, наступать и исправлять двойные грабли (а в случае когда надо много платформ - многократные) просто нет.
grishkaa
25.06.2022 07:23Slack (переписали с Electron целиком).
Разве его переписали на натив? Я помню, что читал, что да, они его переписали, но всё на том же чёртовом веб-стеке. Типа, вместо 2 гигов оперативки он теперь жрёт 500 мегабайт. Офигеть достижение для клиента мгновенных сообщений.
mapnik
25.06.2022 01:37+6Это всё прекрасные рассуждения, но ответьте: сколько будет стоить в описанном вами случае разработка одного приложения, которое должно работать как минимум под Linux, MacOS и Windows? А если оно же должно работать ещё и под Android? Как в этом случае помогает факт всегдашней работы WinAPI?
VEG
25.06.2022 00:33+7Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год? Да так, что уже видно что это тенденция и не хочется инвестировать время в то, что через год закопают. Сколько их было и есть? Silverlight, WinForms, XAML, Xamarin, Avalonia, вот сейчас всех на MAUI перетягивают.
Silverlight — не предназначался для разработки настольных приложений, это плагин для браузера, его закопали вместе с другими плагинами для браузеров.
WinForms — уже 20 лет живёт и развивается, но он никогда не был кроссплатформенным, это изначально обёртка над классическим WinAPI.
Xamarin — для мобил, переродился в виде MAUI с поддержкой десктопа.
XAML — это язык разметки, который до сих пор используется в том же MAUI.
Avalonia — не имеет отношения к Microsoft.
zetroot
25.06.2022 00:58+1Ну и надо не забывать что WPF жив здоров, хотя и не особенно приятен, но черт возьми, его пережил только winforms.
yokotoka
25.06.2022 04:45+1А зачем MS столько много всего для, по сути, одного и того же?
VEG
25.06.2022 09:02+5Интересный вопрос. А зачем насоздавали столько фреймворков для JS за последние 20 лет? Даёшь jQuery во все поля!
Нет, их создавали не для одного и того же. WinForms был тонкой обёрткой над WinAPI. Оно было создано во времена, когда у всех была одна и та же плотность пикселей, и справлялось плохо с нестандартными DPI. Классические API не позволяли вытворять всякие безумные вещи типа вращения контролов, ну назрела проблема с поддержкой нестандартных DPI, поэтому запилили WPF на базе DirectX. В WPF первая буква от слова Windows, оно тоже не планировалось кросс-платформенным (хотя это и осуществимо). UWP был (провалившейся) попыткой сделать новые нативные API и подсистему для Windows с системой прав как в Android и iOS, а не так, что всем приложениям сразу доступно почти всё. WinUI — библиотека новых нативных для Windows контролов, здесь опять ничего про поддержку других платформ.
Xamarin был разработан не в Microsoft, его купили и сделали бесплатным, когда Microsoft изменила курс на кроссплатформенность, но он был только для iOS и Android, и там надо было отдельно дизайнить приложение под разные платформы с использованием нативных контролов (самый правильный подход, ИМХО), только внутренняя логика приложения могла быть общей. На основе Xamarin был создан Xamarin.Forms для тех, кто не хотел отдельно дизайнить интерфейсы под iOS и Android. Этот проект оброс поддержкой десктопных платформ и переродился в виде MAUI — это первая разработка от Microsoft с заявленной кроссплатформенностью в том числе и для десктопных платформ. На Windows MAUI использует WinUI 3 для отображения контролов.
Кстати, Electron тоже принадлежит и разрабатывается в Microsoft, хоть и был изначально создан вне её. Microsoft достаточно большая, чтобы поддерживать и развивать сразу несколько технологий для кроссплатформенного GUI.
yokotoka
25.06.2022 04:44Спасибо за ликбез! Может есть ещё какие-то кросс-платформенные попытки от MS для десктопа?
В любом случае, судя по всеобщему огорчению, что много софта на электроне, электрон пока лидирует в деле кросс-платформенных десктопов... И на то есть причины, которые не решают другие фреймворки.
denis-isaev
26.06.2022 02:26Про Silverlight Microsoft с вами не согласен docs.microsoft.com/en-us/archive/msdn-magazine/2009/june/building-an-out-of-browser-client-with-silverlight-3
VEG
26.06.2022 08:32Как и Flash, можно было запускать вне браузера, но это не было основным предназначением. Если кому надо было десктопное приложение, брали полноценный WPF или WinForms.
Ну и поддерживался Silverlight аж до октября 2021 года, то есть 14 лет. Правда, последние обновления с новыми фичами были в 2012, а потом только обновления с фиксами багов. Я сам рассматривал испольлзование Silverlight для админки CMS в 2010 году, но уже тогда было понятно, что он не жилец (как и Flash), поэтому мы взяли за основу популярный тогда Ext JS.denis-isaev
26.06.2022 17:43Если кому надо было десктопное приложение, брали полноценный WPF или WinForms.
А если кому надо было мультиплатформенное, то им предлагали Silverlight. Поэтому некорректно утверждать, что Silverlight не предназначался для разработки настольных приложений. Он пытался стать электроном своего времени :) Правда, даже flash больше преуспел. Ну так в том и претензия в комменте yokotoka была, что MS бросает развитие кучи своих продуктов.VEG
26.06.2022 18:39Запуск вне браузера для Silverlight никогда не было основной фичей. Эта функция даже появилась только в Silverlight 3 в 2009 году. Да и Linux оно не поддерживало. Был неофициальный Moonlight на базе Mono, но он еле работал.
Ну так в том и претензия в комменте yokotoka была, что MS бросает развитие кучи своих продуктов.
А смысл развивать объективно ненужные продукты типа Silverlight? Он был изначально мертворожденным. Тут Microsoft сильно просчиталась. 5 лет вливала деньги в совершенно бесперспективную технологию (упорные!), и потом ещё 9 лет латали в ней дыры.
По-вашему она должна была закрыть глаза на реальность, что Silverlight провалился, что его почти никто не использовал даже после 5 лет вливаний денег? Они должны были не замечать, что что разработчики браузеров взяли курс на отказ от сторонних плагинов типа Flash и Silverlight, и упорно развивать технологию, которая вскоре просто не сможет выполнять свою основную функцию? Зачем? Чтобы оно работало только в IE на Windows?denis-isaev
26.06.2022 18:48Падажжите! :) Разговор вообще в сторону ушел. Суть в том, что Silverlight был не просто плагином к браузеру, а костылем для кросс-платформенной разработки тоже. Почему он там не взлетел и т.п. — оффтопик.
kekekeks
25.06.2022 02:56+7Avalonia
Эцсамое, мы не Microsoft, мы сами по себе. Вот прям совсем отдельно, в порочащих связях с корпорациями замечены не были, беспощадны к врагам опенсорса. Не надо нас в очередь на кладбище проектов со всеми остальными ставить.
yokotoka
25.06.2022 04:41Прошу прощения, не знал, что Avalonia без MS. Тут пожелаю проекту только долгой и яркой жизни, развития и всех благ! Разделяю убеждение, что кросс-платформенный инструмент не имеет права быть не опенсорсным и принадлежать корпорациям.
Massacre
26.06.2022 03:30Для построения кроссплатформенных приложений лучше взять не интерпретируемый язык программирования и компилировать под каждую платформу нативный код. И да, интерфейс под каждую платформу должен быть тоже нативным. Телеграм ведь как-то справляется…
AnthonyMikh
26.06.2022 22:57Телеграм ведь как-то справляется…
У Telegram ни разу не нативный интерфейс.
Massacre
26.06.2022 23:09По желанию можно конечно включить что-то типа use system window frame и частично станет «нативным», но таки да… много своего нарисовали.
turone
24.06.2022 14:32да сейчас почти везде когда что либо пишешь, то подтягиваешь для 1-2 функций еще либу либо модуль либо фреймворк, даже тот же вордпресс автора на лишнего кода 90% никогда не используемого фунционала.
В плане программирования мне нравится подход @MarcusAurelius - пишет чистый код, без кучи хлама. Основная мысль - часто чтобы разобраться с какой либо либой, по времени дольше, чем самому написать 1-2 функции, которые тебе нужны.Hisoka
24.06.2022 19:49+4Бывают случаи оправданного раздутия, я как реверсер(с написанием оперсорсного аналога) это могу сказать. Оригинал - exe игры на 1мбайт, но там код по сути С, с самодельным ООП. После реверса, переноса частей на С++ и std контейнеры - код в exe раздулся мегабайт до трёх(из-за шаблонов и дублирования кода под реализации). А вот мультиплатформенность добавляет ещё 100+ мб dll'ок, т.к. вместе с портирование добавилась возможность использования ресурсов в различных форматах(ffmpeg, sdl_image), а не только пары как в оригинале, да и уже установлены в систему пользователя(dshow кодеки в системе, d3d/ddraw тоже). Конечно можно было оставить только форматы оригинальных изображений и разделить код - под никсы ffmpeg, opengl, openal, sdl, а под win - d3d, dsound, dshow, но это добавит больше проблем, в виде ещё кода абстракций и возможно тормозных решений по конвертации данных под платформу. Поэтому была ориентация на никс-стек, как более универсальный, а вин-сборки, да, толстые.
0xd34df00d
24.06.2022 22:09+2из-за шаблонов и дублирования кода под реализации
А как это было сделано в сишной реализации изначально? Касты через
void*, или как-то ещё?
DungeonLords
25.06.2022 00:42В продолжение темы - статья Абстракции и наследование в Си — стреляем по ногам красиво
JordanCpp
25.06.2022 14:17Согласен, но! Это огромные монолитные библиотеки. К примеру ffmpeg тянет +100500 форматов видео и аудио. А вам нужен один для видео и музыки. SDL_Image та же ситуация. Если это возможно скомпилить статически игру только с нужным функционалом, получится небольшой бинарник, только с тем, что реально юзается.
Hisoka
25.06.2022 17:28Не, там смысл ещё как раз в том, чтоб добавить возможностей модерам, а не запирать в устаревших форматах.
ATwn
25.06.2022 22:59Такой подход предпочтительнее ещё по одной причине. Притягивая функционал из раздутых фреймворков, программисты вряд ли задумывались о том, что придётся их постоянно обновлять при обнаружении уязвимостей. Тем более если фреймворки с открытым кодом.
Возникает вопрос, действительно ли компания так беспокоиться о безопасности сервиса?
В таком случае, я думаю, стремились бы как-то сократить базу кода. На деле же, как это часто бывает, потребность показать дейтельность и привнести фунционал наверняка решалась кратчайшим способом в лоб
citius
24.06.2022 14:38+2Все верно, но все это жуткое нагромождение абстракций - цена скорости прогресса.
Именно потому, что практически каждому так или иначе доступно написать код, создать какой-то MVP даже и из чужих компонентов, мы и имеем всякие фаанги, приложения для телефона и телевизора, миллиард криптовалют и так далее.
А этот прогресс, как мне кажется, и толкает в свою очередь вперед прочие отрасли, вроде разработки новых лекарств на основе анализа молекул с помощью ИИ.
Волнует ли больного что тот ИИ является нагромождением программного кода и собранных по всем возможным сусекам данных, и не факт что его разработчики до конца понимают как это все работает? Думаю совершенно не волнует.
DrPass
24.06.2022 14:56+18Все верно, но все это жуткое нагромождение абстракций — цена скорости прогресса.
Нет. Это цена непрофессионального отношения к работе. 20 лет назад я точно так же мог склепать за короткий срок на коленке MVP из чужих компонентов, который делал бы всё то же самое, что делают современные MVP. Только весил бы он 5 мегабайт, а не 200. Продуктивность программистов за это время не выросла. Всего лишь упало качество библиотек.citius
24.06.2022 15:00+1О том и речь. Талантливых и высокопрофесииональных людей меньше чем вообще людей с идеями.
janvarev
24.06.2022 15:17+9> я точно так же мог склепать за короткий срок на коленке MVP из чужих компонентов, который делал бы всё то же самое, что делают современные MVP.
Нет! У вас бы не было вжух-вжух и красивых градиентных кнопочек со скругленными краями!
/sarcasmgrishkaa
24.06.2022 15:31+5Так градиентных кнопочек сейчас почти ни у кого нет, потому что «не модно». А тогда были!
ihouser
24.06.2022 17:18+3Но. Весь мусорный код этих кнопочек в библиотеках остался. И есть подозрение, что выполняется -> проверяется что это уже не модно -> перерисовывается как модно.
Dolios
25.06.2022 00:36+9И очень плохо, что нет. Раньше кнопка выглядела, как кнопка. А теперь тыкаешь во все что можно пытаясь понять, где тут кнопка, а где просто модный прямоугольник..
grishkaa
24.06.2022 15:30+8Скорее, появилось наплевательское отношение ко всему. Лично я считаю, что нельзя добавлять в проект библиотеку без хотя бы базового понимания её внутренностей. Проблема в том, что мало кто с этим согласен. Очень часто происходит так, что кто-то ради какой-то одной элементарной функции, которую можно было бы просто скопипастить, тянет библиотеку с пятью зависимостями. Люди не просто не понимают абстракции, они осознанно не желают их понимать. Нет этой пытливости и любопытства, есть лишь желание чтобы начальник отстал как можно скорее. Операционные системы и браузеры для них сделаны из магии.
UalikhanJ
25.06.2022 08:41Если не копи-пастить, а пользоваться библиотекой, то любое изменение надо отдельно тестировать и адаптировать свой код. А так автор библиотеки развивая проект тестирует и этим обеспечивает работоспособность использующих её программ. Ну или делает это в идеальном мире.
cepera_ang
25.06.2022 09:37Автор библиотеки развивая проект тестирует то, что ему там нужно и вовсе не заботится о вашем конкретном коде, который легко может сломаться или затупить. И поэтому в больших проектах либо все версии запинены (и это не сильно отличается тогда от копи-паста), либо половина времени уходит на обновление зависимостей.
Alexey2005
24.06.2022 17:15+15И оно бы запускалось на Windows, Linux, macOS, iOS и Android? И на любом железе — ARM, под M1, под x86/64?
Все эти абстракции приходится городить именно потому, что у нас в IT-индустрии фактически нет никаких стандартов, полная анархия. И сделать за приемлемое время софт, который бы хоть как-то работал на всей этой сборной солянке, невероятно сложно. Фреймворки просто перекладывают цену этой разработки на самого же пользователя, вынуждая его оплачивать работу многочисленных слоёв абстракций.
Сам как-то столкнулся с ситуацией, когда надо было уже готовую обученную нейронку распространять в качестве автономного приложения. И вдруг оказалось, что никаких кроссплатформенных решений для этого не существует, кроме… да, вы угадали, Electron! Да, нейронка. На Javascript (фреймворк tensorflow.js). Звучит как безумие, но сделано за три дня и работает везде, тогда как попытка сделать это нативно под весь набор платформ потребовала бы не менее трёх месяцев. А потом ещё кучу времени на отлов багов, связанных с проблемами совместимости, которые разработчики Electron решили за нас.DrPass
24.06.2022 17:25+3И оно бы запускалось на Windows, Linux, macOS, iOS и Android? И на любом железе — ARM, под M1, под x86/64?
Да, само собой. Если бы мне нужно было не слишком производительное, но кросс-платформенное решение 20 лет назад, я бы взял Java или Qt. Это лучше, чем Electron, чесслово. Даже сегодня.
SNNikitin
24.06.2022 17:53+11Qt - просто дорого, да и спецов мало, итого - ТТМ стремится к бесконечности
Java - может, и хорошо, пока не начинаются пляски с версиями JVM (известно многим разработчикам, сидящим на М1), да и специалисты недешевые...
Electron - осилит любой джун+ на JS, итого - дешево и минимальный ТТМ
Просто миром разработки давно рулит маркетинг, все остальное - лишь следствия
darthmaul
24.06.2022 19:03Но виноваты то не программисты, а сам бизнес. Вот чем определяется рыночная ценность сотрудника и его шанс полпасть на денежную вакансию? Эффективностью кода? Да ни разу. Знание списка модных фреймворков и библиотек решает всё. Чем больше модных технологий - тем больше ЗП. Без того же докера Вас и джуном никуда не возьмут. Самые продвинутые ещё на "читабельность" кода смотрят - но и её возвели в ранг культа. Оптимизация и читабельность - зачастую взаимоисключающие явления. Да и "не говнокодить" в наше время нереально - на действительно детальное изучение всего требуемого стека жизни не хватит.
eyudkin
24.06.2022 19:51+3Тогда уж не бизнес, а потребители. Логика бизнеса простая и определяется законами рынка, бизнес делает то, что приводит к продажам и росту.
Здесь должен быть мем (сходу не удалось нагуглить, извините) про двух программистов, один из которых сразу программировал хорошо, а второй наговнокодил, быстро выпустил первую версию, собрал отзывы, выпустил вторую, в итоге заработал денег/получил инвестиции и нанял первого программиста рефакторить его говнокод ;)
Так что я бысказал, что пока пользователям наплевать на качество и подход "быстро загнать тяп-ляп mvp" работает, то ничего не изменится, в конце концов пользователи голосуют рублём за бизнесы, а уже эти бизнесы определяют стиль работы программистов. Программисты тут в конце цепочки и особо ничего не решают.
cepera_ang
24.06.2022 20:19+2А потребители не знают границ возможного и не понимают, что продукт, который им предлагают — плохой, потому что не видели хорошего. Но если у них есть возможность сравнить — выберут конечно быстрый и надёжный вариант. Вот такой замкнутый круг.
И в этой цепочке у программистов единственных есть понимание того, каким может быть продукт. Это мы знаем, что современные компьютеры обладают запасом мощности в десятки раз для выполнения всех обычных бытовых задач и что любой софт мог бы запускаться за долю секунды, заботься об этом разработчики. И нам нужно продвигать эти ценности среди бизнеса и пользователей.
cepera_ang
24.06.2022 20:25+1Правда большая проблема в том, что программисты тоже не знаю границ возможного (вон в соседней теме про «базу» обсуждают, нужно ли разработчику знать как работает процессор в компьютере для которого он разрабатывает) и к тому же им всё «сложно», поэтому нужно использовать готовые решения, которые всю эту «сложность» решили за тебя.
altervision
25.06.2022 09:45+5Пользователи НЕ выберут быстрый и надёжный вариант. Они выбирают тот вариант, у которого сильнее маркетинг. И как итог, минимальные вложения в ПО и максимальные в маркетинг дают засилие говнокода везде.
Red_Nose
25.06.2022 08:40-1Ой ли ? 20 лет назад ? Оки, пример разбора строки (математического выражения) на С++ меня удовлетворит :)
Static_electro
25.06.2022 09:41вы сомневаетесь, что это возможно? Или что итоговый бинарник будет весить меньше 10 мб?
nikolas78
24.06.2022 16:45+1Так проблема даже не в тоннах кода — это кстати понятно и почти нормально (что бы там не думал автор), а в том, что это невозможно отладить!
Сейчас эра безоглядного (и бездумного) переиспользования чужого кода, надеюсь она скоро закончиться.
PereslavlFoto
24.06.2022 22:52+1Погодите минуточку. Какое же безоглядное переиспользование, если код закрыт?
nikolas78
24.06.2022 23:33+1Имелось в виду библиотеки, фреймворки и т.д. Их часто используют не потому что «будет хорошо», а потому что «другое еще хуже».
RC_Cat
25.06.2022 09:54Если каждый будет писать одно и тоже получится как с прошивками роутеров у каждого одинаковые баги с одной стороны и openwrt с другой.
HiLander
24.06.2022 14:47+5Ну и вишенкой на торте ВЕБ разработка где без докера нынче вообще ловить нечего. Любой фреймворк тащит на себе 100500 депенденсов большая часть которых давно устарела и не соберется заново ни при каких условиях...
Это типа музыкант пишет песню, которую можно прослушать только в магнитоле из окна автомобиля определенной модели...
aik
24.06.2022 14:56+4Да, я долго держался, но в конце прошлого года пришлось таки с докером связаться.
Слишком много софта стало идти в виде «ставь контейнер либо вот тебе тар.гз с исходниками без документации по сборке, раз такой умный»
nin-jin
24.06.2022 15:20+1Любой фреймворк тащит на себе 100500 депенденсов большая часть которых давно устарела и не соберется заново ни при каких условиях...
Не любой, $mol не тащит, например.
extempl
25.06.2022 06:53Как там у вас с bus-factor'ом? Я как-то использовал в продакшене подающий надежды фреймворк famo.us. С громкими презентациями, оффлайн конференциями, светлым будущим. Который закрыли через год. И хотя он был в опенсорсе - последователь пожелающий возродить былое нашёлся аж один (infamous, ныне lume). И хотя проект вроде бы активный - он (меинтейнер) всё ещё один.
nin-jin
25.06.2022 08:09+1Примерно так:
AngularJS: был похоронен не дожив до 6 лет. Всем, кто на него подсел, предложили переписать код на другой фреймворк с похожим названием, в котором лишь через 5 лет вылечили детские болезни.
$mol: почти 7 лет не то устаревать не думает, а наоборот - продолжает внедрять инновации.
А басфактор повышается пользователями, так как разработка фреймворка ничем не отличается от его использования.
Dr_Faksov
24.06.2022 14:48+3Всё просто - в 99.999% программист не несёт ответственности (материальной и юридической) за результат своего труда. Но хочет за свою работу немалых денег.
mixsture
24.06.2022 15:04+11Он может, я думаю. Но стоимости такого решения будут астрономические — думаю, в ПО для космоса именно так. Но бизнес выбрал фичи вместо стабильности (в сущности это выбрали конечные потребители софта). Жаль, но за стабильность мало кто хочет платить.
nin-jin
24.06.2022 15:23+6Не, на самом деле вместо "быстро и качественно" бизнес выбрал "медленно и дорого". Ибо своей экспертизы не хватает, а у исполнителей иная материальная мотивация.
DrPass
24.06.2022 15:34+21Вот только хотел сказать. Не так давно участвовал в совещании с заказчиком, где мы — субконтрактор. В совещании участвовал наш менеджер, наш тимлид, менеджер заказчика, менеджер собссно контрактора и продакт оунер заказчика. Мы час обсуждали добавление четырех полей на форму, чисто текстовых, без какой-то бизнес-логики. Срок на задачу поставили неделю. Я не знаю, сколько за неё контрактор возьмёт. Мы выставим наше время участия в совещании, время на оформление тасков, часы разработчика, часы тестера. Но контрактор стесняться не будет, он там удвоит и рейт, и расчасовку. Клиент заплатит и глазом не моргнёт, потому что ему там пару штук евро тоже ни на что в бизнесе не влияет.
А по факту, можно было просто добавить эти четыре поля ещё в то время, пока совещание шло, и это бы решило проблему. И так везде. Мы делаем и медленно, и дорого. Потому что так нам выгоднее, а заказчик готов платить.
sainomori
24.06.2022 18:37+12А заказчик готов платить не потому что это 4 поля, а потому что труд разработчика это карнавал масштабирования.
Представляете, если бы у вас был токарный станок, который мог бы обслуживать (почти) неограниченное количество токарей одновременно? Сколько бы вы не посадили за него специалистов - все бы они были заняты, не мешали друг другу и единственное бутылочное горлышко которое в у вас было бы - отгрузка готовых деталей! Сколько бы вы были готовы заплатить за такой станок или за добавление лампочки на нём?
А с программными продуктами такое работает - маленькая CRM написаная на коленке и раскрученная на "Малинке" может занять работой целый стадион продаванов! Только подноси списки телефонных номеров и выгружай лидов из воронки! Гипотетически, убер может прямо завтра открыться в 10 странах сразу! Потому "пара штук евро" действительно "ни на что в бизнесе не влияет"
При этом я не оправдываю то, что творится в разработке. Более того, когда мне попадаются случайные заказы на поддержку старых продуктов - я только радуюсь - они простые и понятные! Да - местами надо добавить очистку пользовательского ввода, да - местами надо перестать хранить пароли в открытом виде, да - с газзлом гораздо удобнее делать запросы к сторонним API чем руками. Но это маленькие поправки - бизнес работает и без них уже очень продолжительное время!
А когда я вижу магию middleware в Laravel я начинаю чесаться в самых нескромных местах!
Mayurifag
26.06.2022 04:26Вам, возможно, платят так же и за решения не добавлять бесполезный функционал, либо реализовать его в другом виде, либо заполнять поля в базе автоматически, используя какую-нибудь инфу. Клиент заплатил за то, чтобы вы проанализировали все варианты и действительно увидели, мол, ага, без полей никак.
Ещё клиент заплатил за UI/UX, — то, где будут поля находиться, какого цвета, какие валидации (фронт/бек) и так далее и так далее.
DrPass
26.06.2022 23:26Нет. Нам платят просто за добавление полей. «Проанализировали все варианты» — это термин больше из менеджерских комментариев к счёту, которые впишет подрядчик, выставляя клиенту круглую сумму. По факту оптимальное решение в таких «линейных» задачах, как автоматизация бизнес-процессов, чаще видно сразу в процессе обсуждения, по крайней мере, если вы эту систему увидели не недавно, а уже сопровождаете длительное время.
DrPass
24.06.2022 15:07+11В 99.999% случаев никакой работник не несёт материальной и тем более юридической ответственности. Чтобы он работал качественно, необходимо и достаточно не карать его материально, а всего лишь обучить и просить переделать, если налажал.
Dr_Faksov
25.06.2022 04:39Почему -"просить"?. Из этого "просить" и растут проблемы.
Если у вас обнаружится дефект тормозной системы вашего автомобиля - (ошиблись при разработке, с кем не бывает) то вы будете "просить" чтобы починили и ездить с дефектом? Или "требовать" немедленного ремонта?
0x131315
25.06.2022 09:00Ты не учитываешь, что программист ни за что не отвечает, потому что ему никто этой ответственности не даёт - всё решают за него, и до него, ответственность у вышестоящих лиц, сам он лишь мелкий винтик в современной индустрии. Ему дают задачу и время, и главное - уложиться в отведенный срок, а результат не особо важен.
vikarti
25.06.2022 10:57+3В следующий раз (или в этот — если получится сделать юридически) получите огромный счет. А также — ограничения на то как это можно использовать вида "так, установка ЛЮБОГО обновление не протестированного разработчиком — лишает гарантии, то что какая то там MS орет что это срочный патч и отменить установку невозможно — ваши проблемы. Наличие на компьютере ПО которое меняет стандартный функционал ОС и/или перехватывает системные вызовы — лишает гарантии, то что вы хотите Касперского поставить или там AdGuard или там FRAPS'а — ваши проблемы. Неработа интернет-канала до указанных в приложении №1 сетей и dns-имен с характеристиками не менее таких то — лишает гарантии, роскомнадзоры это ваши проблемы. Поддерживаются процессоры Intel Core 4-го поколения (если хотите другие — с вас отдельные деньги). Для запуска в виртуальной среди разрешается использовать только согласованный с разработчиком гипервизор конкретной версии а иначе лишение гарантии.
Мобильная версия разрабатывалась под Apple iOS 14.5 на iPhone SE 2-го поколения. Использование другого железа или другой версии ОС — лишает гарантии, то что у вас iOS сама обновилась — это ваши проблемы, новую версию приложения выпустим скоро, да — обновление не будет бесплатным если у вас подписки нет"
И так далее.
А то ишь — моду развели — ставят на все начиная с WinXP до Win11 кучи разных версий (это я еще линукса не касаются — flatpak и snap совсем не на пустом месте родились), на черт знает какое железо и требуют чтобы работало.
Jian
25.06.2022 09:48+9в 99.999% программист не несёт ответственности (материальной и юридической) за результат своего труда
А с чего это за все косяки начальства решившего экономить и на рефакторинге и на тестировании должен статья козлом отпущения именно программист?
Но хочет за свою работу немалых денег
Именно, начальство решившее экономить и на рефакторинге и на тестировании получает больше всего денег, а то что получает программист это, так крошки с барского стола.
PS судя по тому, что ты считаешь, что программисты должны работать за еду будучи козлами отпущения за чужие косяки, ты @Dr_Faksovи есть тот самый менеджер, считающий что и рефакторинг и тестирование - "напрасная трата времени".
RedJabber
26.06.2022 20:43TDD? DDD? Мы решаем нашими инструментами проблемы тех кто нам платит и несем ответственность за это перед клиентом и перед коллегами программистами, которые это будут дорабатывать после нас.
Ты/Вы сам выбрал эту компанию и это начальство и за эти деньги продолжаешь делать то-то делаешь - это все твой выбор, не отмазывайся.
Ты сам либо делаешь качественно - через тесты и поддерживаемый код, либо сам идешь на компромиссы и предоставляешь на выбор "плохо и БЫСТРО" или "поддерживаемо и ДОЛЬШЕ в начале" - твое начальство не разбирается в твоей работе, оно разбирается в сроки,бабки,клиенты,зарплату вовремя - дай 1 срок за который сделаешь достаточно качественно для поставленной задачи и не принимай его занижений.
Если нужно сделать прототип - то он должен быть таким чтобы выбросить сразу после принятия решения о доработке.
Не браться за чужие прототипы или не ныть.
Бери ответственность не за код, а за решение задачи/кейса клиента и будет тебе счастье.
...и я не вижу проблемы сменить работодателя, если не сошлись по принципиальным моментам.
aik
24.06.2022 14:54+8Если сейчас (по консервативным оценкам) 99% ресурсов наших PC тратится впустую, мы впустую тратим и 99% потребляемой компьютером энергии. Это абсолютно преступно. И для чего же эти траты?
Эти траты нужны для понижения порога вхождения в отрасль написания программ, ускорения разработки, обеспечения работоспособности всего написанного и т.п.
Не хочется — не тратьте, выбор есть. От вас не требуют использовать эдж, вордпресс и т.п. Баш, нано, линкс…
На велосипеде тоже можно ехать. Как и пешком ходить. Но люди в массе почему-то предпочитают машины и самолёты, хотя их надо обслуживать, заправлять, искать место для парковки и т.п. И на тех, кто ездит на велосипеде от Москвы до Владивостока, смотрят с непониманием.DrPass
24.06.2022 15:01+7Эти траты нужны для понижения порога вхождения в отрасль написания программ, ускорения разработки, обеспечения работоспособности всего написанного и т.п.
Нет. Эти траты имеют одно-единственное происхождение. Кто-то когда-то написал код для библиотеки, потом к нему добавился ещё код, потом ещё, потом ещё. Старый уже легаси, про который все забыли, но он там сидит, а каждый год к нему ещё докидывают, и так далее. Потом библиотека подтягивает к себе зависимости из других, точно так же растущих библиотек… и вот так оно годами наслаивается и растёт в геометрической прогрессии. Никакой положительной корреляции с ускорением разработки, снижением порога и т.д. оно не имеет. Наоборот, имеет некоторую отрицательную корреляцию, т.к. тяжёлые и сложные библиотеки имеют под капотом и недокументированные «особенности» и побочные эффекты, и просто становятся сложны для изучения.aik
24.06.2022 15:09+5Так это и есть снижение порога. Не нужно тратить время на рефакторинг, приписал новую функцию сбоку — и в продакшн. Ресурсы условно не ограничены, производители железа об этом заботятся — им тоже надо каждый год впарить вам новый ноут или телефон.
DrPass
24.06.2022 15:11+3Так это и есть снижение порога. Не нужно тратить время на рефакторинг, приписал новую функцию сбоку — и в продакшн
Ну это же не бесплатно. Сегодня мы приписали новую функцию сбоку, завтра с другого боку, а послезавтра мы тратим неделю на то, чтобы отрефакторить всё это разом, потому что третьего бока уже не нашлось.aik
24.06.2022 15:41+3Послезавтра ставим костыль, иначе сроки сорвём.
Конечно, рано или поздно эта система костылей и подпорок развалится, но это уже будет не при нас. Наверное.
arheops
24.06.2022 22:06Да, но в большинстве случаев система не доживает до этапа, когда это становится дорого. А если доживает — есть деньги на рефакторинг.
singerfox
24.06.2022 16:05+4Все верно - порог входа снижается, соответственно снижается квалификация программистов (в среднем), на выходе имеет такой говнокодинг.
О чем собственно и статья.
inkelyad
24.06.2022 20:56Кто-то когда-то написал код для библиотеки, потом к нему добавился ещё код, потом ещё, потом ещё. Старый уже легаси, про который все забыли, но он там сидит, а каждый год к нему ещё докидывают, и так далее. Потом библиотека подтягивает к себе зависимости из других, точно так же растущих библиотек… и вот так оно годами наслаивается и растёт в геометрической прогрессии.
Ну так тут описан Open–closed principle. Убрать слои абстракций и выкинуть лишнее - нельзя как можно. Сломается же что-нибудь. Причем, действительно, скорее всего сломается - принцип не на пустом месте возник.
mikleh
24.06.2022 16:39+12Порог вхождения сейчас выше чем в 2000. Нет, ну серьезно, вы думаете, что разобраться в каком-нибудь ангуляре проще чем в php 4? Про десктопные приложухи я вообще молчу.
edogs
24.06.2022 22:29+2вы думаете, что разобраться в каком-нибудь ангуляре проще чем в php 4?
А написать на php4 что-то, что займет пару дней на ангуляре (при нулевых знаниях там и там) сколько дней займет?mikleh
24.06.2022 22:47Я слабо представляю, что осмысленное можно написать на ангуляре за пару дней при нулевых знаниях в нем. Хелло ворд? Ну минут 30 наверное на пхп с перекуром.
edogs
24.06.2022 22:59+3что осмысленное можно написать на ангуляре за пару дней при нулевых знаниях в нем
Много чего можно. С нулевыми знаниями же в ангуляре, а не в программировании как таковом.Хелло ворд? Ну минут 30 наверное на пхп с перекуром.
Мультиплатформенный и симпатично выглядящий хелло-ворлд на пхп4 за 30 минут? Удачи:)
mixsture
24.06.2022 14:57+19Есть один плюс, который часто упускают из вида. Это требования к кроссплатформенности. Чтобы этот код запускался на куче непохожих друг на друга архитектур, в такой же куче непохожих друг на друга окружений, работал с языками, которых разработчик даже в глаза не видел (юникод), а еще бы был многопоточным, чтобы использовать многоядерные архитектуры. В старом софте этих требований не было и поэтому можно было использовать что-то специфичное для одной архитектуры, но эффективное.
Ну и вторая большая часть проблемы — мы умеем распространять код крупноблочно — библиотеками/фреймворками, а вот как выдернуть отсюда нужную функцию с десятком зависимых, а все остальное не подключать — это нерешенная пока что проблема. И даже в идеале еще глубже — вот есть функция, вместе с зависимыми функциями она поддерживает 3 фичи, из них вам нужна 1, а остальные вы точно знаете, что не будут использоваться никогда — вот как выкинуть поддержку этих 2х фич и подключить только нужный код для 1й фичи — это пока невозможно.DrPass
24.06.2022 15:06-2Есть один плюс, который часто упускают из вида. Это требования к кроссплатформенности
Ну вот смотрите: есть кросс-платформенные приложения на .NET Core, относительно молодом фреймворке, и есть кросс-платформенные приложения на Java, на старом фреймворке. По функциональности они сходные, но вторые значительно «тяжелее». А есть ещё веб-приложения, которые вообще некорректно называть кросс-платформенными, т.к. их платформа — три браузера и нодежс, которые более-менее придерживаются одного стандарта исполняющей среды, и которые вообще на порядки тяжелее.mixsture
24.06.2022 15:40Да, в том или ином виде все языки верхнего уровня хотели достичь кроссплатформенности. Даже С. Но «веб-технологиям» удалось это лучше всего пока что (имхо). Естественно, ценой производительности.
panteleymonov
24.06.2022 16:01То что, к примеру, я пишу на С для одной ОС и потом переписываю для другой не делает конечную библиотеку больше.
Если взять тот же Qt с требованиями "разработать с использованием QML", прицепить базу данных и использовать сервисы ОС (погода, положение, и тд) - это будет гиговый дистрибутив в отдельном каталоге не считая библиотек операционной системы. Но при статической линковке это всего лишь 12 мегабайт. А если взять весь функционал напрямую из ОС то приложение будет не больше метра.
Не будем также забывать про существование KolibriOS.
aml
24.06.2022 19:52+4Всего. Лишь. 12. Мегабайт.
DungeonLords
25.06.2022 01:08Я может не умею собирать Qt, но у меня получается где-то 16-35 MB занимает один исполняемый файл простенького проекта.
DistortNeo
24.06.2022 15:12+2В .NET Core, кстати, при публикации приложения есть опция выбросить из dll заведомо неиспользуемый код. Программа худеет раза в два.
MrPomidor
24.06.2022 16:13+1Стоит отметить что при работе с рефлексией могут быть нюансы и такой код нужно дополнительно "помечать", но в целом вы правы. Вот бы еще этой опцией люди начали пользоваться)
d_ilyich
26.06.2022 20:07+1Это, конечно, здорово. Но вот я собрал win10-x64 self-contained консольное приложение (.NET6) с единственной строчкой «return;» Получилось ~19Мб (single-file ~11Мб). Смотрю на получившийся ворох dll-ок и недоумеваю — неужели они все действительно нужны для приложения, которое ничего не должно делать?
DistortNeo
26.06.2022 20:34Большая часть этих файлов — рантайм, нативный код.
Непосредственно .NET код — 2 мегабайта. Не всё так плохо.
iddi
24.06.2022 15:14+2по второму вопросу - static linking умел это еще во времена DOS, а вот это вот все - dll
nin-jin
24.06.2022 15:27+1mixsture
24.06.2022 15:46+1Да, оптимизация у компиляторов есть, в том числе и удаление неиспользуемого кода. И все это хорошо работает пока не вышло за код вашей программы. Вот нужно вам из openCV подключить 2 функции, а ваш проект на java и варианты «не тащить лишнее» как-то сразу исчезают.
nin-jin
24.06.2022 15:49-4Хороший повод не писать на Java?
siarheiblr
24.06.2022 17:41+3Т.е. ради одной фичи переписываем весь проект? Э - эффективность.
nin-jin
24.06.2022 17:47-5Хороший повод сразу писать на нормальных языках?
siarheiblr
24.06.2022 17:53+2Неа. У вас уже есть готовый проект. Неважно на чем, хоть на языке Ада или на Фортране.
К счастью в мире больше одного языка программирования.
nin-jin
24.06.2022 18:12-7У меня нет проектов на яве.
hyperwolf
24.06.2022 20:39+1А у других - есть. И часто это проект бизнеса, а не ваш. И бизнес не будет менять технологический стек без крайней на то нужды
nin-jin
24.06.2022 21:03-3Хороший повод поменять техдира, что выбрал такой стек.
hyperwolf
25.06.2022 02:21+1Почему? Наш условный проект на Java существует, приносит прибыль. Разработчиков найти можно для работы с ним. Все еще не вижу проблемы.
nin-jin
25.06.2022 08:15+1Потом приходит конкурент, которому хватает 1 сервера вместо 10, 1 разраба вместо 10, 1 дня на разработку вместо 10, за счёт чего демпингует по цене, и вы разоряетесь.
randomsimplenumber
25.06.2022 09:32И разраба этого зовут Исаак Ньютон;)
Вылизывание кода требует человеко-часов. "1 разраба вместо 10, 1 дня на разработку вместо 10" - так не выйдет. Выйдет наоборот. .
nin-jin
25.06.2022 09:37+1Вылизывание архитектуры требует человеко-дней. Разгребание последствий кривой архитектуры в коде требуется человеко-лет.
cepera_ang
25.06.2022 09:42+2Вот из за подобных дурацких максим у нас и есть куча проблем. Когда ценности разработчика «главное быстрее дать результат, потому что бизнесу надо», «работающее не трогать», «не изобретай велосипед, надо брать готовое» и «
преждевременнаяоптимизация зло», то удивляться, что у нас состояние дел описанное в статье — не стоит.
dakuan
25.06.2022 11:24Хороший повод сразу писать на нормальных языках?
Например?
nin-jin
25.06.2022 11:42Начать можно отсюда: https://llvm.org/ProjectsWithLLVM/#LDC
dakuan
25.06.2022 12:37Тогда почему вы пишите на JS/TS (судя по профилю)?
nin-jin
25.06.2022 13:07Я много на чём пишу. Но для браузера толковых альтернатив пока нет.
dakuan
25.06.2022 13:19Ну вот в том и проблема, что далеко не всегда есть возможность выбрать тот язык, который нравится. Зачастую выбор обусловлен ограничениями платформы и/или наличием легаси кода, который никто не будет переписывать ради того, чтобы внедрить одну новую фичу правильным путем.
nin-jin
25.06.2022 13:22За пределами браузера ограничений практически нет, кроме инертности мышления.
dakuan
25.06.2022 13:37+2За пределами браузера ограничений практически нет, кроме инертности мышления.
Вы можете выбрать любой стек, который позволит решить текущую задачу оптимальным способом. Но через N спринтов, когда уже написаны сотни тысяч строк кода, у приложения появилась куча активных пользователей, к вам внезапно прибежит заказчик с горящими глазами и заявит, что ему кровь из носа нужно интегрировать в приложение, ну хотя бы, тот же OpenCV, не суть важно. Тут и возникает два варианта: угробить еще тысячи часов и кучу денег на переписывание кода и миграцию, либо раздуть дистрибутив на лишних 100 Мб. Как думаете, что выберет бизнес?
nin-jin
25.06.2022 14:12Ох уж эта выученная беспомощность. Тут мы возвращаемся к исходному тезису. Не берите "любой язык", берите тот, что не создаёт вам проблем на "тысячи часов".
dakuan
25.06.2022 14:17Тогда и я возвращаюсь к исходному вопросу: какой брать?
Потому что любой из известных мне языков, не дает гарантий, что подобной ситуации не произойдет.
cepera_ang
25.06.2022 14:23Но некоторые дают гарантию, что вы стартуете сразу с толстого и медленного языка. Питон/руби/etc — заложено в природе языка быть таким. JVM-based — можно попотеть и сделать более-менее быстро, но культура языка не располагает к этому (лучше читаемость, чем скорость, тысяча классов с миллионом слоёв как пример «хорошей» декомпозиции и т.д.). Go/Rust — сразу с заделом на производительность и безопасность. С/С++ — если хочется страданий.
dakuan
25.06.2022 14:47+1Да тут дело не столько в производительности. Вы можете выбрать, скажем, Go или Rust и запросто влететь в такую же проблему через какое-то время. Тут даже не столько в языке дело, сколько в современных методологиях разработки, которые подразумевают работу с очень маленьким горизонтом планирования. Когда вы начинаете создавать MVP, вы имеете весьма расплывчатое представление о том, что с ним будет через год или два.
nin-jin
25.06.2022 14:32И тут мы возвращаемся к исходному ответу на исходный вопрос. Так и будем кругами ходить?
Cerberuser
25.06.2022 14:55Проблему возникновения требований, которые на этом языке не решаются без возникновения вышеупомянутой дилеммы.
dakuan
25.06.2022 14:59Какую проблему не решает язык, на который я дал ссылку?
Что там подразумевается? D конкретно или LLVM в общем?
Вот потребуется вам, например, в проект интегрировать какую-нибудь существующую Java-библиотеку. Как D решит эту проблему?
dakuan
25.06.2022 15:16Потому что нужная вам библиотека есть только на Java, и времени портировать ее на нужный язык нет. И это пример не с потолка взят. Мне как-то на заре карьеры пришлось интегрировать Scala-библиотеку, реализующую алгоритм PLSA, в C++ проект. Тот кошмар с JNI до сих вспоминается, но это был самый быстрый способ из доступных.
dakuan
25.06.2022 20:23Любопытно. Надо бы поиграться на досуге. Хотя у меня сейчас нет JVM проектов.
nin-jin
25.06.2022 15:24Использование альтернативы на компилируемом языке / Портирование / транспиляция / поднятие JVM в воркере.
dakuan
25.06.2022 15:40Альтернативы есть не всегда. А портировать - это долго и дорого. Никто не будет с ним заморачиваться, если есть возможность сделать пусть немного криво, но быстро и, что важнее всего, дешево. Исключение - достаточно крупные игроки, которые могут себе позволить потратить кучу человеко-часов на качественное решение.
Cerberuser
25.06.2022 14:23+1А есть ли вообще такой язык, который при любом изменении требований не создаст "проблем на тысячи часов"? И может ли он существовать хотя бы теоретически, или для любого наперёд заданного языка может найтись требование заказчика, которое поставит разработчиков раком?
nikolas78
25.06.2022 17:26Или: существуют ли отдельные предметные области, где создание таких ЯП возможно?
GavriKos
24.06.2022 15:51+1Посыл в том, что проблему решить можно. Не всегда и не во всех условиях - но можно. А вы заявили безаппеляционно "это пока невозможно.".
Есть еще и другие варианты - самый простой это OpenSource. И хоть на джаве оно все будет - можно все порезать.mixsture
24.06.2022 16:23+2Посыл в том, что проблему решить можно. Не всегда и не во всех условиях — но можно. А вы заявили безаппеляционно «это пока невозможно.».
И пока придерживаюсь этой точки зрения. Я бы сказал наоборот — проблема в целом не решена (*для всех языков нет стандартного решения и с разумными затратами времени), но где-то в частных случаях можно (где-то вам поможет компилятор, где-то разработчики предусмотрительно на блоки по функционалу разбили).Есть еще и другие варианты — самый простой это OpenSource. И хоть на джаве оно все будет — можно все порезать.
Вот ваш стэк, допустим, java. А opencv на c++, вы развернете окружение для сборки, сделаете форк и вырежете лишнее на незнакомом для вас языке? Боюсь, это может занять времени больше, чем само ваше приложение целиком.randomsimplenumber
25.06.2022 08:23+1А потом, когда из обновленного opencv захочется применить какой то важный багфикс - пройти этот квест ещё раз.
Gryphon88
24.06.2022 15:51По поводу кроссплатформенности меня расстраивает вот какая ситуация: много софта, у которой установка по умолчанию через веб-инсталлер. Почему в этот инсталлер не встроить что-то типа CPU-Z/GPU-Z и собрать (если такой сборки ещё нет на сервере компании) со всеми ключами, чтобы шустро работало именно на моей машине? CI/CL уже не диковина, билд-сервера жирные... Скорость растет, размер, в том числе за счет dead code elimination, падает, пользователь доволен, для производителя затраты не очень высокие. Видимо, я чего-то не понимаю.
lair
24.06.2022 16:39+4Вы хотите иметь на своем компьютере сборку, которую производитель никак не тестировал?
(а то, что билд-сервера жирные — ну это когда как, некоторые продукты до сих пор минут 40 собираются, вы готовы добавить это время ко времени установки?)
Gryphon88
24.06.2022 17:09Вы хотите иметь на своем компьютере сборку, которую производитель никак не тестировал?
Лично мне для развлекательной программы автотестов хватит, для остального телеметрии и крашрепортов хватит, зря их встраивают в таком количестве, что ли? Пусть я не думаю, что -march может что-то сломать, но вдруг, а как падают тесты на разнице -Os, -O0 и -O2 видел, поучительно, кстати. Небольшой оффтоп: в статьях про VLIW пишут, что для того, чтобы шустро работало, надо фактически переписать программу. Дык и чтобы старая программа шустро работала на новых процах, используя их возможности (avx, sse, интрисики) её тоже очень мощно перелопатить нужно, но это игнорируется.
некоторые продукты до сих пор минут 40 собираются, вы готовы добавить это время ко времени установки?
Я - готов. Но вполне разумен сценарий, когда тот же браузер через час-день-неделю вешает попап "Псст, мы собрали версию, идеально подходящую под твоё железо. Хочешь установить?".
lair
24.06.2022 17:57+1Лично мне для развлекательной программы автотестов хватит
Вот только чтобы запустить автотесты, нужно такое же железо, как у вас. Откуда оно у производителя?
И это еще не считая того, что автотесты, вообще-то, легко превращают затраты производителя из "невысоких" в "что-то уже пожалуй не буду".
Gryphon88
24.06.2022 18:31чтобы запустить автотесты, нужно такое же железо, как у вас. Откуда оно у производителя?
Хотел сказать про QEMU, но так правда получается дорого + баги эмулятора. С другой стороны, разработчики мобильных приложений как-то же тестируют хотя бы на самых популярных моделях смартов?..
автотесты, вообще-то, легко превращают затраты производителя из "невысоких" в "что-то уже пожалуй не буду"
Странно, считал, что иметь автотесты хороший тон, хотя бы под каждую поддерживаемую платформу. Ну не лапками же тыкать, дорого, долго и ненадежно.
lair
24.06.2022 20:17С другой стороны, разработчики мобильных приложений как-то же тестируют хотя бы на самых популярных моделях смартов?..
Ну так они тестируют либо общую версию, либо версии, собранные для этих смартов. То есть оно уже собрано.
А вы хотите версию, собранную под ваше железо.
Странно, считал, что иметь автотесты хороший тон, хотя бы под каждую поддерживаемую платформу.
Иметь автотесты — да. А вот прогонять их каждый раз когда пользователь себе что-то устанавливает — уже дороговато.
hyperwolf
25.06.2022 02:25Мобильщики, которых я видел и знаю, держат парк в 2-3 десятка основных смарфонов и тестируют на них.
iShrimp
24.06.2022 18:49Псст, мы собрали версию, идеально подходящую под твоё железо
Удачно сделал Гугл, перейдя с APK на AAB (что позволяет сразу выкинуть неиспользуемые ассеты) и внедрив Android Runtime c компиляцией байт-кода непосредственно под целевую платформу.
Но гугловская модель имеет недостаток - приложения слишком изолированы друг от друга и не могут использовать общий код. Если 10 вашим приложениям нужен OpenCV, то у вас на устройстве окажется 10 копий этой библиотеки, причём самых разных версий и без возможности обновления. Поэтому обязательно необходим менеджер пакетов, как в настольных линуксах.
Alex_ME
24.06.2022 19:57+2А менеджер пакетов, как в настольных линуксах, приводит к тому, что требуются мейнтейнеры, которые разруливают зависимости, чтобы всё в репозитории зависело от одних и тех же версий библиотек. Что приводит к хорошо известным проблемам: трудности с обновлением на более новые версии, кучу работы мейнтейнеров и вообще превращение всего дистрибутива и репозиториев под него в огромный монолит.
К сожалению, в 2022 году настольные линуксы плохо умеют в решение DLL hell
0xd34df00d
24.06.2022 22:10Что приводит к хорошо известным проблемам: трудности с обновлением на более новые версии
В чём эти трудности наблюдаются и как я, как пользователь такого маргинального дистрибутива, как gentoo, могу их наблюдать?
кучу работы мейнтейнеров и вообще превращение всего дистрибутива и репозиториев под него в огромный монолит.
Эти проблемы на мою жизнь особо не влияют, почему нужно о них задумываться?
Alex_ME
24.06.2022 23:11Gentoo не использовал, поэтому не знаю, как оно там. У Gentoo там есть еще механизм слотов, возможно, там все совсем хорошо.
Как пользовтаель Arch не испытываю проблем с обновлениями, потому что роллинг и репозиторий оперативно обновляется на свежие версии. Хотя суть остается - использование разных версий зависимостей в системе - боль.
Эти проблемы на мою жизнь особо не влияют, почему нужно о них задумываться?
Это из разряда рассуждений о вечном и прекрасном :)
0xd34df00d
24.06.2022 23:25Хотя суть остается — использование разных версий зависимостей в системе — боль.
Так если вы пользователь, то это вас не сильно волнует, мейнтейнеры за этим следят.
Если вы разработчик на чём-то, что обычно наличествует в системном менеджере пакетов (вроде плюсов и так далее), то да, это неприятно. Но на винде это ещё более неприятно.
maxwolf
24.06.2022 20:10+1Проблемы, по большей части, не в ключах оптимизирующему компилятору, а в архитектуре и подходе к разработке приложений. Ущербные решения в этой области несут на порядки большие издержки, с которыми уже не всегда справляется экспоненциальный рост производительности.
cepera_ang
24.06.2022 17:53И много софта, который реально хорошо работает будучи разработанным вот так кроссплатформенно? Прям берёшь и одно и тоже запускаешь и на винде и на айпаде и на распбери пай?
На практике весь нормальный софт для каждой платформы отдельно и существует, а кроссплатформенные только какие-нибудь мессенджеры, которые ничего толком с платформы и не используют (текстики и картинки переслать сейчас на чём угодно можно).
Massacre
26.06.2022 03:51Вообще, есть нормальный софт, работающий на десктопах с разными ОС, это, в основном, опенсорс, вот только не на мобилках. Впрочем и у мессенджеров для мобилок совершенно отдельные нативные приложения.
Woodroof
24.06.2022 23:50+1как выдернуть отсюда нужную функцию с десятком зависимых, а все остальное не подключать — это нерешенная пока что проблема
Статическая линковка и LTO. Вот вторая проблема куда сложнее, для этого библиотеки надо специально для этого проектировать, а так мало кто делает.
Eugeeny
24.06.2022 15:57+12То же нытье, что и 5, 10, 20 и 30 лет назад.
DrPass
24.06.2022 16:01+5Сейчас оно куда более обоснованное. Потому что 20 лет назад к росту софта ещё и новые фичи прилагались в соответствующем объеме.
nin-jin
24.06.2022 16:12+2А сейчас фичи только выпиливают, а те, что остаются - страшно глючат.
MentalBlood
24.06.2022 18:09Движение в произвольную сторону проще подать как прогресс. В крайнем случае можно начать убирать/исправлять глюки
vitaly_il1
24.06.2022 16:32+3Что-то в этом есть...
"Обленилась молодежь - не хочет в машинных кодах писать, Ассемблер им подавай!"
yoz
24.06.2022 16:03+2Вспомнились некоторые вещи из фантастики далекого будущего. Насколько мы далеко сможем забраться в высокоуровневых абстракциях? Уже сейчас специалисты, которые помнят-знают-умеют в низкий уровень, являются штучным раритетом в мире.
TheMrWhite
24.06.2022 16:26+8Потому что они и нужны в штучных экземплярах. Рыночек порешал, как обычно. Когда появится высокий спрос на низкоуровневых программистов, такие специалисты начнут появляться всё больше и больше. Бизнесу, который создаёт спрос и платит разработчику зарплату, не нужно 100500 операционных систем, а вот интернет-магазинов, мобильных приложений и прочего нужно как раз 100500.
harios
24.06.2022 16:09+3Вы можете написать программу, которая загружает файлы на сервер надёжно,
быстро и безопасно, и для этого потребуется двенадцатая часть от этого
количества кода. Это может быть один файл, просто единственный маленький.exe.
Ему не нужны сотни и сотни DLL. Это не только возможно, это легко, и
такое решение будет более надёжным, эффективным и удобным в отладке, к
тому же (подчеркну) оно на самом деле будет работать.Как же сильно пахнет Delphi. :)
siarheiblr
24.06.2022 17:47+3Я бы сказал, тут пахнет старопердунизмом :)
Даже интересно, насколько низко автор предлагает спуститься. Использовать FTP? Упороться и сделать свой более лутший протокол? Там чем ниже, тем больше будет все более и более интересных вопросов возникать, про которые раздуватели кода даже и понятия не имеют.
Но да, зато быстро. Наверное.
legolegs
24.06.2022 22:45+3Использовать FTP?
А почему нет? Бизнесу надо чтобы быстро, дёшево и работало. FTP работает, все инструменты уже есть (нулевые трудозатраты на их создание) и свободные (нулевая цена). Ну ладно, надо ещё гуй к клиентской части сляпать. Хотя на самом деле надо просто как сетевую папку примонтировать и обойтись без гуя вообще (для ftp такие решения тоже есть). Ой, но тогда негде фирменный логотип показать, вот беда.
harios
25.06.2022 01:12Ой, но тогда негде фирменный логотип показать, вот беда.
Команду лепил занять нечем, пускай пилят пока веб морду на новом фреймворке, как до беты дойдет там уже пожирнее фреймворк выйдет, будут сразу на него переписывать.
splatt
25.06.2022 06:44+7А почему нет?
Потому что FTP не безопасный, и если вы хотите что бы ваши файлы не перехватил сидящий со сниффером кулхацкер, нужно как минимум SFTP. Сами вы реализацию TLS не напишете (в лучшем случае будет дырявое решето), поэтому придется добавлять OpenSSL.
Реализацитю FTP сами будете писать? Уверены что напишете в соответствии с RFC? А все кейсы учтете или для 5% пользователей ваша реализация не будет работать? Ага, подключаем ftplibpp...
А что там со сжатием, или будет заливать на 30% медленнее чем у конкурента? Ага, подключаем zlib...
И это мы даже не дошли до интерфейса.
Проблема не в том что "разработчики плохие". Проблема в том что задача менеджмента зависимостей и дублирования библиотек сегодня не решена для десктопного да и любого ПО. Мобильные ОС решают чуть-чуть лучше.
legolegs
25.06.2022 18:01-2Реализации ftp с TLS уже давно написаны, о чём вы?
Сжатие популярным форматам файлов не особо надо.
На самом деле я вот сейчас зашёл в яндекс.диск через webdav. Просто нажал на закладку в файловом менеджере и всё открылось. Без специального гуя, без клиентского софта от яндекса, только используя инструменты общего назначения, реализующие общепринятые стандарты. Это возможно. Никакой проблемы нет. Просто надо делать по-человечески.
andreymal
25.06.2022 18:34Не по теме поста, но — попробуйте теперь через этот webdav залить в яндекс файл размером пару гигабайт :)
legolegs
25.06.2022 21:06Яндекс доступ через webdav всячески троттлит и ущемляет. Потому что им хочется, чтобы я их троянца поставил. Но это не техническая проблема, а бизнесовая. Технически и webdav и ftp работают.
Massacre
26.06.2022 17:07К счастью, пока что можно и без троянца, просто через браузер, там не тротлит…
Mingun
25.06.2022 19:21Тут выше приводили притчу про двух программистов, но почему-то, когда защищается принцип, что можно делать быстро и экономно, про нее забывают… и все подавай уже сразу
doctorw
25.06.2022 23:16Почему бы не завернуть обращение к FTP в VPN?
cepera_ang
25.06.2022 23:24Нормальный подход, кстати. Более того, при грамотной реализации (см. tailscale) можно на сетевой уровень и авторизацию/аутентификацию свесить. Когда у каждого пользователя уникальный ключик для доступа к сети, дающий привязанный к нему айпи, то можно на уровне приложений не городить ни шифрование, ни аутентификацию, кайф.
siarheiblr
26.06.2022 12:07Мы все ещё рассчитываем обойтись без раздутых либ :)?
doctorw
27.06.2022 00:52VPN не обязательно встраивать в приложение, соответственно и библиотеки для этого в самом приложении не нужны.
Penguinus2008
24.06.2022 16:24+13Поворчать, это конечно весело. Но давайте спустимся на землю.
В реальном проекте, если бы я увидел, как кто-то пишет свой обход JS'овсвского объекта, вместо использования lodash - я бы немного РАССТРОИЛСЯ. И да, вроде как те же аргументы: обойти-то просто, из библиотеки нужно 2,5 функции. Только вот ты не один обычно над проектом работаешь. Один написал свой обход так, другой - эдак, третий - придумал еще что-то. В результате, у вас 100500 реализаций обхода объекта, чтобы просто получить значение свойства, причем каждый реализует по своему. А затем приходит еще один человек, он видит эти 100500 этих функций, в результате не понимая, чем они отличаются - делает свою и у вас 100501 функция.
И да, на истории про то, что у вас должны быть ревью, должна быть архитектура, диаграммки UML, четкая документация, чтобы все знали что уже есть, чего нет, как нам с этим работать, кто-то должен следить и т.д. Ну, да. Только вот как-то так получается, что в реальном мире - никто особо не хочет ревьюить чужой код, особенно, когда есть свои задачи; архитектура не успевает за хотелками; диаграмки - устаревают и никто их не поддерживает; документацию пишут недостаточную; вся информация о проекте в несколько миллионов строк не держится в голове; а нанять сертифицированного следителя за порядком - бизнес не хочет. А потому - нужно выбирать решения, которые стандартны, которые проверены и бить по рукам тех, кто будет без острой необходимости свое писать.SNNikitin
24.06.2022 17:59И, кстати, из lodash, вроде, deepEqual можно вытащить условно-отдельно ;)
nin-jin
24.06.2022 19:34+2Только зачем?
nin-jin
25.06.2022 00:17+10Вот, собственно, тут мы и наблюдаем причину всё увеличивающихся тормозов и раздувания. И она не в том, что скорость/размер софта меняется на скорость/надёжность разработки. И даже не в том, что нет времени искать лучшее решение. И даже не в том, что лучше найти не удаётся. А в том, что даже когда тычешь человека носом в тех анализ и бенчмарки, всё, что он может сделать - это дизлайк поставить, и идти говнокодить дальше.
emaxx
24.06.2022 16:52Так были же и альтернативы. Например, CppCms - быстрая и эффективная CMS, написанная на плюсах. Но проект сейчас заброшен - очевидно, оказался никому не нужным...
red_cell
24.06.2022 16:56+1Необходимо учитывать ещё непостоянные требования пользователей, которые реализуются в рамках проекта. А когда они становятся не нужны их просто хоронят в коде.
Вот, писали мы одно простое приложение, которое считавало адреса проводов со схемы и, по требованию пользователя, записывало их в таблицу Excel. Раз десять уточнили, точно ли они хотят именно файл Excel. Формат в ТЗ прописали. Дошли до сдачи проекта, а там требуется обычный текстовый файл с разметкой csv. Спрашивается, и на кой, мы обращались к Excel?
Естественно, код обращения к Excel удалять не стали, просто закомментировали. Потому что csv из Excel быстрее выгрузить.
И так, курочка по зернышку клюёт.
event1
24.06.2022 17:04+1Это естественный результат развития аппаратного обеспечения. Пока мы (были) на экспоненциальной части S-кривой ничего не изменится. Когда мы окажемся на логарифмической, вот тогда бережливые программисты будут нарасхват.
Junecat
24.06.2022 17:18+4<зануда mode> Не могу не отметить, что вообще то "этита" помещалась в 48 Kb памяти, причем ещё около 6 КБ из этих 48 были выделены под "экран", и, таким образом, не использовались для хранения кода.
А вообще - Синклер был прекрасной машинкой, которая - в то время - многому меня научила.
До сих пор проходят (под эгидой Яндекса, если что) соревнования по написанию игр для Синклера. Финал-в декабре! Ещё можно успеть...
HellWalk
24.06.2022 17:20+4Это уже не bloatware и не оверинжиниринг, а абсолютное, совершенное, очевидное, наглядное безумие.
Да, безумие, и всем плевать. Менеджменту плевать, потому что он очень далек от этого всего, а программистам просто западло озвучивать проблемы, потому что в современном мире говорить о проблемах это уже токсичность. А токсичность - это самый страшный современный грех. Пускай прод регулярно падает, пускай юзеры матерятся в техподдержке - главное чтобы внутри команды все было модно/молодежно/позитивно.
Меня поражают намного более приземленные вещи. Возьмем двух программистов:
Один программист пилит фичу 5 дней, потом в ней находят 2 бага, которые исправляются за 2 дня [7 дней суммарно]
Другой программист пилит фичу 2 дня, потом в течении года в ней находят 20 багов, которые он правит за 10 дней [12 дней суммарно]
Казалось бы, с точки зрения логики первый программист лучше - суммарно и времени потрачено меньше, и ошибок меньше - т.е. более довольные клиенты.
Но по факту, в компании за компанией я вижу ситуации, когда в пример ставят программистов второго типа, которые "быстро делают задачи" (как фичи, так и баги) а то, что можно потратить время на написание авто-тестов, и нормальный код, а потом ошибок будет в разы меньше - это вообще находится за гранью понимания.
SNNikitin
24.06.2022 18:01+5Это потому, что второй быстрее доносит Value до рынка, и бизнес быстрее начинает зарабатывать деньги на фиче :)
Миром разработки рулит маркетинг, это давно свершившийся факт
DrPass
24.06.2022 18:10+3Это потому, что второй быстрее доносит Value до рынка, и бизнес быстрее начинает зарабатывать деньги на фиче :)
Нет, это потому что менеджер второго быстрее получит премию за выполненную задачу. А для бизнеса по факту проблемная фича зачастую может и убытки приносить вместо прибыли.SNNikitin
24.06.2022 18:13+2Неверно :)
Фича выпускается только тогда, когда ее качество достаточно до донесения Value и, соответственно, получения прибыли
Терминальные случаи статистики не делают и быстро из оной выпадают :)
DrPass
24.06.2022 18:18+3Фича выпускается только тогда, когда ее качество достаточно до донесения Value и, соответственно, получения прибыли
Неа. Иногда, в некоторых компаниях — да. Но обычно менеджер имеет заявленные сроки и не имеет возможности достоверно оценить, достаточен ли уровень качества фичи для получения прибыли, или нет. Тем более что его KPI обычно завязано не на Value, а как раз на эти самые сроки.SNNikitin
24.06.2022 18:22Вы выпустили из внимания последнее предложение в моем предыдущем посте ;)
В целом, процессы планирования и, как следствие, выставления KPI, в частности - обычно, достаточно выстроены в любой нормальной компании
"Ненормальные" же - живут интересно, но недолго :)
DrPass
24.06.2022 18:27+1Вы выпустили из внимания последнее предложение в моем предыдущем посте ;)
Я ему не придал значения. Проблемный релиз — это не терминальный случай. Это обычный типовой кейс сейчас, на 100% соответствующий вышеописанной ситуации проОдин программист пилит фичу 5 дней, потом в ней находят 2 бага, которые исправляются за 2 дня [7 дней суммарно]
Другой программист пилит фичу 2 дня, потом в течении года в ней находят 20 багов, которые он правит за 10 дней [12 дней суммарно]
А что касается процессов планирования, ну, я много компаний повидал. В целом между качеством планирования и жизнью компании особой корреляции не могу проследить. Рынок ИТ сейчас такой, что прокормит кого угодно, даже полнейших бездарей, лишь бы у них отдел продаж работал.SNNikitin
24.06.2022 18:33Я ему не придал значения
А напрасно - это ключевой момент :)
Проблемный релиз — это не терминальный случай.
Проблемный релиз в проде - это именно терминальный случай
Это обычный типовой кейс сейчас, на 100% соответствующий вышеописанной ситуации про
Нет, не соответствующий :) Ибо в течение года компания получала профит, который, обычно, порядково превосходит затраты на фиксы
А что касается процессов планирования, ну, я много компаний повидал.
Ну, а я много где участвовал в этих процессах :)
В целом между качеством планирования и жизнью компании особой корреляции не могу проследить.
Мне остается только посочувствовать :)
Рынок ИТ сейчас такой, что прокормит кого угодно, даже полнейших бездарей, лишь бы у них отдел продаж работал.
Вы почти подтверждаете мой тезис :)
Если бездари производят то, что можно продать, а прибыль от продажи покрывает расходы - то это и есть то, о чем я говорю :)
DrPass
24.06.2022 18:44+1Если бездари производят то, что можно продать, а прибыль от продажи покрывает расходы — то это и есть то, о чем я говорю :)
Нет, речь не про это :) Продаётся продукт, а не релиз, не фича. Релиз может быть сколь угодно проблемный, фича может сколь угодно тянуть вниз расходами на поддержку и исправления. Речь про том, что сейчас это в порядке вещей, а менеджер все равно получит свою премию, а расходы на исправление проблем лягут в операционку, и никто там резкость наводить не будет.SNNikitin
24.06.2022 19:08Продаётся продукт, а не релиз, не фича
Фича - часть продукта
Даже бесплатная - может увеличить продажи
Это, в общем-то, азы, наверно, не надо их объяснять :)
Релиз может быть сколь угодно проблемный, фича может сколь угодно тянуть вниз расходами на поддержку и исправления.
Это те самые терминальные случаи, которые я предлагал не использовать как основу для статистики ;)
Речь про том, что сейчас это в порядке вещей,
Именно
Я ж так и сказал - разработкой рулит маркетинг, как и бизнесом в целом
Это теперь в порядке вещей
менеджер все равно получит свою премию
Не за выпуск релиза же, что вы )
За выполнение роадмапа, например
Или за рост DAU/WAU/MAU
Или за рост retention
Или за выполнение любого другого операционного показателя, который прямо связан с его KPI
расходы на исправление проблем лягут в операционку, и никто там резкость наводить не будет.
Это норма
Техдолг любого коммерческого проекта - история грустная. И, очень часто, весьма объёмная :)
DrPass
24.06.2022 19:12-1Это, в общем-то, азы, наверно, не надо их объяснять :)
Да, но я думал, для вас очевидно, что ещё фича может никак не повлиять на продажи (это, кстати, очень частый кейс), а может увеличить расходы, а может оттолкнуть пользователей своей реализацией. Фичи — они все разные, понимаете ли.Это те самые терминальные случаи
Терминальные случаи — это нечто, бывающее редко, и служащее надгробием какому-то процессу. Нечто весьма обыденное и проходящее бесследно, терминальным случаем не может быть по определению :)Это норма
Да. И это — отстой.
SNNikitin
26.06.2022 13:46+1Да, но я думал, для вас очевидно, что ещё фича может никак не повлиять на продажи (это, кстати, очень частый кейс), а может увеличить расходы, а может оттолкнуть пользователей своей реализацией.
Нет, не очевидно :)
Ибо реализация любой фичи - это затраты, которые должны окупаться, прямо или косвенно, а продажи - далеко не единственная метрика :)
Что же до "оттолкнуть пользователей" - это все благородно, но решит все MAU, а не недовольство отделных пользователей
Фичи — они все разные, понимаете ли.
Ваш намек на некую снисходительность в тоне выглядит забавно :)
Особенно, на фоне демонстрируемого понимания процессов, отличных от собственно разработки ;)
Фичи - они разные на вид, о реализация любой фичи имеет ту самую ценность, Value, ради которой и запускается ее разработка. Бизнес рассчитывает на тот или иной профит в результате ее реализации - иначе и быть не может
Терминальные случаи — это нечто, бывающее редко, и служащее надгробием какому-то процессу.
Вы преувеличиваете :)
Нечто весьма обыденное и проходящее бесследно, терминальным случаем не может быть по определению :)
Бесследно? Как легко вы списали затраты на разработку ;)
Да. И это — отстой.
Вообще, нет. "Отстой", как вы выразились, это как раз то, что вы называете отстоем ситуацию, в которой вам платят деньги за работу :)
Понимаете ли, любой наемный программист нанят не для самореализации и креатива, а для выполнения той работы, результат которой нужен заказчику и плательщику - это нормально и закономерно. Кто платит - тот и заказывает музыку :)
DrPass
26.06.2022 23:38-1Ибо реализация любой фичи — это затраты, которые должны окупаться, прямо или косвенно, а продажи — далеко не единственная метрика :)
Понимаете, я в этой отрасли очень давно, третье десятилетие как. Достаточно давно, чтобы не верить в рассказы по умных расчётливых менеджеров, которые прогнозируют экономический эффект от внедрения тех или иных фич, и на основании этого принимают решения об их реализации.
Ну т.е. вероятно в некоторых очень крупных компаниях они таки существуют. Но их как минимум, нет ни в одной из компаний, где я работал, и нет ни в одной партнёрской компании, с которыми я сотрудничал. И у меня нет оснований считать, что моя выборка недостаточно представительна.
Поэтому нет, бизнес обычно не рассчитывает на профит от внедрения тех или иных фич. Ну т.е. в общем случае он надеется на профит, но в реальности у него нет чёткого понимания, какой этот профит будет, и будет ли. И даже если есть бизнес-план, в нём всегда будет достаточное количество условных цифр, которые помножат на ноль точность планирования.Как легко вы списали затраты на разработку ;)
Эм. Легко, и тут я готов подписаться под каждым своим словом. В большинстве случаев в ИТ менеджмент спокойно засунет под коврик все свои ошибки. Это штатная ситуация, возникающая везде и регулярно. Да и не только в ИТ. Бизнес по определению имеет риски. И если бы всех наказывали за ошибки в бизнесе, никто бы в бизнес не шёл работать.Понимаете ли, любой наемный программист нанят не для самореализации и креатива, а для выполнения той работы, результат которой нужен заказчику и плательщику
Понимаете ли, я это понимаю, и ни разу в жизни не оспаривал, и нигде в моих вышестоящих комментариях не написано, что я в этом сомневаюсь :)
SNNikitin
27.06.2022 08:24Понимаете, я в этой отрасли очень давно, третье десятилетие как.
Ну так и я не первый десяток лет уже :)
Но их как минимум, нет ни в одной из компаний, где я работал, и нет ни в одной партнёрской компании, с которыми я сотрудничал.
У меня совершенно противоположный опыт - везде было именно так :)
у меня нет оснований считать, что моя выборка недостаточно представительна.
Ну, как минимум, есть моя выборка :)
И даже если есть бизнес-план, в нём всегда будет достаточное количество условных цифр, которые помножат на ноль точность планирования.
Как это "даже если есть"? Кто ж без бизнес-планов с роадмапами денег даст на разработку? :)
Это штатная ситуация, возникающая везде и регулярно.
Ну, вообще, это как раз НЕштатная ситуация :)
И, если она возникает регулярно - то гнать надо тех, кто занимается управлением в этой части
Бизнес по определению имеет риски.
Бизнес имеет как риски, так и риск-менеджмент, если он здоровый
Грамотное планирование и следование планам как раз один из инструментов, в частности, минимизации рисков
И если бы всех наказывали за ошибки в бизнесе, никто бы в бизнес не шёл работать.
Очень странный вывод
Во-первых, в бизнесе наказывают за ошибки :)
Во-вторых, причина "пойти в бизнес" - не в безнаказанности
DrPass
27.06.2022 11:08У меня совершенно противоположный опыт — везде было именно так :)
Ок, я принимаю, но своим глазам все равно верю больше, чем вашему опыту. Хотя бы вот на основе этого:Как это «даже если есть»? Кто ж без бизнес-планов с роадмапами денег даст на разработку? :)
… потому что вы не замечаете, что в подавляющем большинстве компаний, которые ведут какую-то ИТ-разработку, «даст денег» и «предлагает реализовать фичи» одно и то же лицо или группа лиц. Слона вы не заметили :)
В ИТ на одного отлаженного гиганта или вымуштрованного стартапа, который бегает питчить инвесторов, приходится сотня вот таких компаний.Бизнес имеет как риски, так и риск-менеджмент, если он здоровый
Да. И не имеет, если он обычныйГрамотное планирование и следование планам как раз один из инструментов, в частности, минимизации рисков
Да. И как любой инструмент, может применяться, а может не применяться. А ещё бизнес может работать в условиях недостатка информации для грамотного планирования.Во-первых, в бизнесе наказывают за ошибки :)
Вы забыли добавить слово «иногда», и тогда это не пойдёт в противоречие с моим тезисом.Во-вторых, причина «пойти в бизнес» — не в безнаказанности
… и это тоже ему не противоречит никак :)
SNNikitin
27.06.2022 11:31Ок, я принимаю, но своим глазам все равно верю больше, чем вашему опыту.
Ваше право, конечно :)
… потому что вы не замечаете, что в подавляющем большинстве компаний, которые ведут какую-то ИТ-разработку, «даст денег» и «предлагает реализовать фичи» одно и то же лицо или группа лиц. Слона вы не заметили :)
Эм. Очень интересно про слона :)
Вообще-то, я прямо писал, что деньги дает бизнес :) Соответственно, роадмапы и заказ фич - это именно то, что хочет и за что платит бизнес :)
Так что, еще вопрос, кто что не заметил ;)
В ИТ на одного отлаженного гиганта или вымуштрованного стартапа, который бегает питчить инвесторов, приходится сотня вот таких компаний.
Зачем приводить в пример нежизнеспособное? :)
Процессы продумываются не от излишка времени и денег, а для повышения эффективности и, как следствие, конкурентноспособности бизнеса
Выживет тот, кто эффективнее
Да. И не имеет, если он обычный
Тогда его ждут сюрпризы, чаще - неприятного характера :)
А ещё бизнес может работать в условиях недостатка информации для грамотного планирования
Бизнес - не может, в долгосрочной перспективе
"Бизнес" - возможно, останется жить
Вы забыли добавить слово «иногда», и тогда это не пойдёт в противоречие с моим тезисом.
Нет, не "иногда" :) Для бизнеса
А кавычки надо добавлять только вместе с окавычиванием "бизнеса" - тогда все будет похоже на правду :)
nikolas78
24.06.2022 19:52Просто когда создают технологии для разработчиков (яп, фреймворки, библиотеки и т.д.) думают примерно так: «дадим им все возможности, а там они сами разберутся», что на практике приводит к тому, что короткий путь — самый бажный, а надежный — самый длинный. А надо было думать так: «дадим им единственный путь, самый надежный», что привело бы к упрощению инструментария, а значит и к сокращению времени разработки. И тогда было бы и надежно и приемлемо быстро.
Nipheris
24.06.2022 17:29+4После прочтения таких статей, ради самоуспокоения всегда напоминаю себе о том, как возросли наши требования как пользователей:
все разучились управлять информацией. Никто больше не ценит простые инструменты, вроде иерархической файловой системы в целях создания порядка. Тех, кто раскладывает музыку во FLAC-е по сотням папочек, считают душными дедами. Все пользуются поиском на стриминговых сервисах.
ладно, не все разучились. Кто-то не умел с самого начала, и вряд ли бы научился. Ведь мы пригласили пользоваться информационными технологиями своих родителей, своих друзей. Им нужны более интуитивные интерфейсы, анимации, подсказки.
теперь мы рассчитываем на информационные технологии ГОРАЗДО сильнее, чем ранее. Многие уже забыли, что такое BSOD и фарш на файловой системе просто при наборе текста в Word. Согласитесь, даже ненавистная Винда сегодня куда более стабильная, чем её древние предки 95/98/Me.
многие вещи, вроде уже упомянутого Юникода, воспринимаются как должное. А за это тоже нужно платить сложностью. Тот же протокол TLS, который по меркам 90-х - супернавороченная вещь уровня дорогущего банковского ПО. А сейчас мы боимся даже картинку скачать по HTTP, вдруг куки/токены угонят.
Ну т.е. если подумать, у софта было достаточно причин стать сложнее.
Конечно, ситуация с JS, вебом и этими вашими Электронами - это другое (c). Это просто одна немаленькая корпорация выиграла битву за программную платформу, и мы пожинаем плоды этой победы. Надеюсь WebAssembly когда-нибудь свергнет JS с должности платформы, "под которую лучше писать по-умолчанию, чтобы дотянуться до максимального числа пользователей". Мне кажется, это самое большое легаси во всём IT на данный момент.
cepera_ang
24.06.2022 17:56Винда была единственной такой глючной системой в истории в течение 5 лет, не было это нормой 90% времени и на 90% систем.
Ndochp
25.06.2022 00:30+1Так винда стояла и стоит на 95% пользовательских машин. Значит то, что было на ней и было нормой.
cepera_ang
25.06.2022 09:55В те годы было гораздо меньше «пользовательских» машин. «Глючная» винда была нормой лет пять на небольшом количестве компьютеров, которое было тогда (маленький процент от всех машин в истории).
Ndochp
25.06.2022 12:53+1Всех машин в истории не надо смотреть, надо смотреть "машин, что видели люди в тот конкретный момент". А насколько я помню в те времена мейнфреймные терминалы отошли в прошлое, сервера большинством машин быть не могут, большинство домашних и офисных машин были персоналками. Если еще во времена винды 1-3.11 можно говорить, что под досом больше народу сидело, то 95-Ме уже ой.
В итоге, для массовых пользователей остаются вин, OS/2, НетВарь, никсы, дизайнерская экзотика (саны и маки).
Среди этого зоопарка кажется винда в абсолютном приоритете.cepera_ang
25.06.2022 14:18В исходном комментарии вы говорите, что многие уже забыли, что такое бсоды и фарш. Я просто хотел сказать, что многие и не знали, что такое бсоды и фарш, потому что рынок ПК в те краткие годы составлял дай бог сто миллионов машин. Сейчас в мире миллиарда 3 компьютеров и 15 миллиардов смартфонов (я уже и не говорю про сотни миллионов консолей и всяких смарт-телевизоров и даже автомобили) и всех их пользователи не видят, а многие и никогда не видели нестабильности подобной тому, что была в краткий миг доминирования 95-98 винды.
anka007
24.06.2022 18:46+1Добавлю что еще все думают об "обработке моего хорошего правильного файла" и совершенно забывают, что файл могут прислать хз какой. Как думаете сколько дыр и ошибок даже не появляется при использовании готовых библиотек? Все же готовые библиотеки раздуты еще и потому, что там стоит 100500 ifelse на проверки всяких условий корректности входящих данных, непропускания абракадабры, обработки всяких граничных условий и т.п.
Я как тестировщик только с какими "глупыми" ошибками не сталкивалась даже у очень опытных программистов. А какое разнообразие эффектов это дает!
Кому доверите написание своего софта: тому кто за год научился пользоваться готовыми библиотеками или тому, кто за два года научился писать что-то низкоуровневое и быстрое? Даже не зависимо от сроков и цены разработки. Главный критерий: программа стабильно корректно работает на среднепользовательском железе.
cepera_ang
24.06.2022 18:53+2Думаете 300 мегабайт хлама содержат меньше дыр, чем небольшой специализированный загрузчик? :) Почему-то кажется что наоборот.
siarheiblr
24.06.2022 20:02+4Вам кажется. Чем больше всяких штук надо учесть, тем больше шансов наделать неочевидных багов. А если вы собрались писать все сами и без либ, то учитывать придётся ну ОЧЕНЬ много всего.
eyudkin
24.06.2022 19:59+3Я боюсь, в итоге победит не webassembly, а мобилки. Уже сейчас у целой кучи бизнесов нет своего сайта или есть только простейший лендос, но зато в каждом сторе по полнофункциональному мобильному приложению.
Понятно, почему так произошло - веб очень плох и сильно запоздал и со стандартизацией, и с отображением на устройствах, но к чему это приведет, страшно даже гадать. Вместо единого протокола и единой среды, где можно качать/смотреть/делать что угодно, вам придется приседать и качать приложения, над которыми у вас нет никакой власти. Даже банально текст не сможете выделить и скопировать :) А ещё в разы вырастет (да уже выроста) власть владельцев сторов, потому что они на раз могут одним щелчком мышки заруинить любой бизнес просто удалив приложение из своего стора. Всё же с вебом такое было проделать куда сложнее.
janvarev
24.06.2022 22:53Делаю исключительно мобильную веб-версию, желающих предложить мне запилить под мой небольшой проект «мобильное приложение» шлю… Пока нормально.
Кстати, тот же Альфа банк был вынужден из-за удаления мобильного приложения из-за санкций перенести всё в веб. Вроде тоже пока норм.
В общем, если не давать пользователю выбора, нормально он будет работать с мобильным сайтом.
Massacre
26.06.2022 03:56Пользователи просто не смогут и не будут ставить по приложению для каждого веб-сайта, так что в этом плане не победит.
vconst
26.06.2022 13:21Да в жопу эти беспконечные мобильные приложения, 99% которых — тупо обертка вокруг вебвью.
К слову, ни одно приложение-маркет типа всяких озонов — не позволяет сделать «поиск по странице», как обычный браузер. Это просто навскидку
spirit1984
24.06.2022 17:43Автор так ворчал в 50 лет, а я так ворчал в 31 год https://habr.com/ru/post/379231/
PKav
24.06.2022 17:53+1Изменения будут только тогда, когда большой размер и тормоза будут вызывать общественное "фи!". Но как этого добиться я не знаю. Возможно, кто-то крупный должен демонстративно это показать. Ну или просто вводить для программистов телесные наказания за неоптимизированный или кривой код. С такими огромными зарплатами можно и требовать много, и наказывать за неисполнение качественно, чтоб неповадно было.
evtomax
24.06.2022 18:25+5Какими огромными зарплатами? Уже не раз обсуждалось, что в России у всех остальных профессий зарплаты ниже плинтуса, а не у программистов огромные.
Self_Perfection
26.06.2022 15:13Общественное фи будет, если общество будет уметь отличать качественный и быстрый софт от шлака.
Но как бы его научить?
Я раздумываю, что может стоит активнее следить за друзьями/знакомыми и чаще им демонстрировать: "Смотри, программа X, которой ты пользуешься для решения своей задачи, очень толстая и неповоротливая. Программа Y для этого же гораздо шустрее". Чтобы нарабатывался вообще навык, что можно требовать, чего ожидать. Кроме нас объяснить это некому. Что думаете?
PKav
26.06.2022 16:07+2Да достаточно просто кому-то популярному это продемонстрировать. К примеру, есть два популярных онлайн-магазина, конкурирующих между собой, у обоих сайты еле ворочаются. Но тут один вкладывается в переработку своего сайта, и его сайт начинает открываться за считанные десятые доли секунды, как обычные HTML-страницы. При примерно равных ценах покупатели подсознательно не захотят идти на тормозной сайт, а пойдут и купят там, где всё быстро. Тогда и конкурент вложится в оптимизацию, не забыв прорекламировать это, а дальше всё само пойдёт.
Cerberuser
26.06.2022 16:09Рискну предположить, что в 90% случаев ответ будет "да, она тормозит, но я ж, если на Y перейду, буду с ней десять лет учиться работать и не факт что вообще научусь, а X уже вдоль и поперёк знаю".
PKav
26.06.2022 20:40Если Y решает поставленные задачи и способен корректно открыть уже существующие файлы от X, то перейдут очень быстро.
Cerberuser
27.06.2022 04:58+1Но так не решает же. Нет, когда "умный компьютерщик" садится и показывает, то всё решает, конечно, а когда сами - тут кнопочка потерялась, которая в X была вот там, тут сообщение непонятное вылезло, и так далее и тому подобное и так далее. Может, конечно, у меня перекос восприятия из-за собственного опыта с "юзверями", может, это исключение, а не правило.
Dark_Purple
24.06.2022 17:54+18Идём на официальный сайт DELL, сапорт, драйвера, XPS 15 9520, Realtek Audio Driver, скачать. 428 MB (449,775,856 bytes). 400 всратых мегабайт на драйвер звуковой карты? Какого черта?
JordanCpp
25.06.2022 15:03Скорее всего, в драйвере множество драйверов для разных аудиокарт. Как пример драйвер nvidia или amd. Драйвер 1, но в нем большое количество дравйверов видеокарт выпущенных в течении 5-ти лет + поддержка разных версий windows 32 и 64.
Knightt
24.06.2022 17:54+1Несколько вопросов к вашему коду:
вирусы в файлах искать умеет?
конфигурировать какие типы(размеры) файлов можно какие нельзя умеет?
без проблем масштабируется на несколько дата-центров?
держит нагрузку в 100500 рпс?
поддерживает разграничение доступа?
может предоставить статистику по любым параметрам за любые сроки?
в случае проблем - умеет отсылать нотификации в различные мессенджеры?
тарификационная сетка на оплату есть?
ну и т.д. и т.п
Вы не представляете как около-сервисные навороты способны раздувать кодовую базу...
DrPass
24.06.2022 18:03+11Я вам более того скажу, ничем подобным и критикуемый автором клиент в принципе не обладает :)
baron9212
24.06.2022 18:02+3Все так и есть, уровни абстракции постоянно повышается.
~20 лет назад надо было долго изучать С или, упаси бог, ASM, набить кучу шишек и лет через 5, может быть, получится написать что-то достойное.
А сейчас нет этих 5-и лет, вот нету и все. Пока будешь писать идеальный код на чистом C, чтобы быстро работало и мало весило - школьник на питоне с 20-ю библиотеками решит поставленную задачу за пару дней. Вот и все. А то что варианту на C нужен калькулятор, а варианту школьника core i9 и 32 гига оперативы.. да кого это волнует сегодня? Бизнес, в большинстве случаев, не волнует - купить железо быстрее и дешевле, чем ждать супер-эффективный вариант на С и оплачивать его разработку. А если потом ни дай бог требования меняться начнут? А новые версии? То все, пиши пропало, конкуренция сожрет мгновенно.
Так что по сути, основная причина - сугубо экономическая, все остальное вытекает из этого.
Я не к тому что это все правильно. Меня тоже бесит, что современный софт занимает дохрена места, а электронные таблицы и текстовый редактор и в windows 3.11 не плохо работали, так то.
Но как есть. Какая то логика в текущем варианте развития тоже присутствует.DrPass
24.06.2022 18:05+4~20 лет назад надо было долго изучать С или, упаси бог, ASM, набить кучу шишек и лет через 5, может быть, получится написать что-то достойное.
~20 лет назад вам надо было изучать C#, Delphi, PHP или Java. Как и сейчас, с тем же порогом входа и с тем же сроком выхода на рынок. Ассемблер или С в нишевых решениях засели уже даже 30 лет назад :)
mikleh
24.06.2022 20:12+920 лет назад был 2000 год. Эпоха Delphi и PHP. Написать приложение на дельфях было проще, чем сделать формочку на электроне. Написать страничку на пэхапэ было проще, чем сейчас даже на какой-нить джанге.
Расскажите еще про экономические причины. Современный говнософт вредит не только экологии/здравому смыслу. Он и вашей любимой экономике вредит.baron9212
24.06.2022 22:56Почему экономика любимая? Я просто описал почему так случилось.
Спрос на разработку сильно вырос, а порог вхождения в профессию снизился.
В том числе за счет всех этих фреймворков, библиотек и прочего барахла которое тащит с собой любое приложение, а использует 1% от всего этого барахла. Но писать стало быстрее. Выигрывается время, а время - деньги, как известно.
С технической же точки зрения - это ппц, конечно.nikolas78
24.06.2022 23:41Так здесь и выпячен парадокс, что бизнес вроде как свои деньги считает, но мнение потребителей его почему-то не волнует.
mikleh
24.06.2022 23:59+3Так писать быстрее стало, или порог снизился? Потому что «все эти фреймворки, библиотеки и прочего барахло» не снижают порог вхождения, а вовсе даже наоборот безбожно задирают. Потому что в них во всех ну хоть чуть-чуть, а как-то надо разобраться.
А время то может и выигрывается, за счет кроссплатформенности, например. Но так это и не секрет, что принцип «тяп-ляп и в продакшн» всегда позволяет выиграть время в краткосрочной перспективе. И ничего плохого в этом нет, когда мы говорим о специализированных прикладных вещах — их так и нужно писать, чтобы успеть за требованиями бизнеса. Но вот библиотеки, то что повторно переиспользуется сто миллионов раз — вот это должно быть написано и оптимизированно хорошо. А не как сейчас, когда библиотеки тянут за собой библиотеки и это замкнутый круг.
AlchemistDark
25.06.2022 08:54Могу выразить только своё субъективное. С Delphi7 я разобрался за неделю. На Dart + Flutter + Android Studio у меня ушло сильно больше месяца. Тут, конечно, дело ещё и в том, что я не молодею, но всё же я не ощутил снижение порога входа…
cepera_ang
25.06.2022 10:50+3Порог входа раньше: запускаешь компьютер, а там сразу бейсик, написал, нажал F5, программа запущена.
Порог входа сейчас: попробуй просто запустить хелло ворлд на айфоне :)
DrPass
25.06.2022 12:04+3Ну, не совсем так. Delphi как инструмент весьма сложна и имеет много «уровней прохождения». Но архитектурно она действительно элегантнее современных фреймворков. Сейчас, например, чуть ли не индустриальным стандартом является реактивность. Это сложный механизм, который имеет один огромный недостаток: если не вы писали этот код, вы задолбаетесь разбирать, как он работает. Ну потому что нет прямой связи между тем, что происходит на форме и тем, что это вызвало. Вы видите текущее состояние, а какое действие вызвало переход в это состояние — идите, ищите. В Delphi же простая и сразу понятная событийная модель, вы сразу можете отследить всю цепочку действий, которая привела к текущему состоянию. Ещё плюс в том, что в Delphi практически нет многоуровневых зависимостей пакетов, причём это негласное правило соблюдалось всеми разработчиками пакетов. Каждый пакет является архитектурно автономной единицей, и зависит лишь от стандартной библиотеки или от соседних пакетов в том же наборе компонент, и не тянет за собой кучу другого барахла.
nin-jin
25.06.2022 12:13+1Не, это крайне простой механизм. Реактивность как раз таки позволяет снизить сложность, так как всё, что надо знать - это только текущее состояние, а не текущее состояние + то, как мы в него попали. А кто инициатор изменения состояния, если что, отслеживается обычный брейкпоинтом.
DrPass
25.06.2022 12:48Это самообман :) В бизнес-логике приложений не бывает такого, что нам нужно знать только текущее состояние. Нам обычно нужно знать и то, как мы в него попали, и лучше видеть это явно, чем не видеть.
nin-jin
25.06.2022 13:11+1Это 25 лет практики. Если для БЛ важно "как мы сюда попали", это должно быть отражено в текущем состоянии, а не быть размазано по стеку.
DrPass
25.06.2022 13:18-1В первую очередь, это ещё одна архитектурная фича, читабельность и логичность которой не заложена «by design», а перекладывается на разработчика. Это — плохо. Я тоже был когда-то молодым и задорным, и мне казалось крутым, что чёрный ящик делает свою работу, я вот тут модельку поменял, а там всё автоматически сработало. С опытом я понимаю, что реактивное программирование имеет достаточно узкие рамки применения, как правило это хорошо лишь в роли шаблонизатора для UI. В остальных случаях это просто технологичный способ сделать код нечитабельным и нелогичным.
nin-jin
25.06.2022 13:25То есть по ссылке вы не ходили, я правильно понимаю? Что именно в обычных объектах с мемоизированными методами нечитабельного и нелогичного?
DrPass
25.06.2022 13:29Простите, но меня не нужно учить правильно программировать, и тем более, понимать, как работает реактивность, мы этим пользовались ещё задолго до того, как появился такой термин. Мои претензии не про то, что я не знаю, как правильно программировать, а про то, что реактивный фреймворк легко даёт возможность забить на все best practices и написать нечитабельный и несопровождаемый код, чем многие успешно пользуются.
UPD. Вижу, вы дописали комментарий. Объясняю, что нечитабельного и нелогичного.
Вот пример условного императивного кода (на каком-то языке):this.Amount = getSomeAmount(); ... property Amount { set: (value) => { txtAmount.text = value; updateTotals(); } }
Вот пример реактивного кода:
какой-то шаблонstate.Amount = getSomeAmount(); state.TotalAmount = calculateTotalAmount(); setState(state); ...<amount>{Amount}</amount> <total>{TotalAmount}</total>
Разница в том, что в первом случае вы сделали действие и сразу видите, какие у него последствия — что оно меняет, на что влияет. Во втором случае у вас нет прямой связи между действием и его последствием. Вы установили состояние, а где-то там в шаблоне что-то произошло. Взять и просто отследить эту связь вы не можете, вам надо смотреть шаблон и искать, где же там изменённые вами атрибуты состояния используются.
nin-jin
25.06.2022 14:27Вот пример реактивного кода:
@mem Amount( next = 0 ) { return next } @mem Total() { return this.Amount() * this.Price() } @mem view() { return <> <amount>{ this.Amount() }</amount> <total>{ this.Total() }</total> </> }Любая IDE умеет в Find Usages, так что искать глазами нет необходимости.
А то, что вы написали - интерактивный код. По мере роста приложения он превращается в тормозное (из-за лишних апдейтов), глючное (из-за забытых апдейтов), нагромождение лапши (из-за условных апдейтов и множественных зависимостей).
Но не мне вас учить, да.
DrPass
25.06.2022 16:23-2А то, что вы написали — интерактивный код.
Интерактивный код — это редактор IDE с подсказками :) Парадигму программирования с таким названием не изобрели. Ну или может быть, вы сами её придумали, т.к. вы тоже активно статьи пишете. Но по крайней мере, она не распространилась дальше ваших материалов.
А то, что я написал — это такой точно реактивный код, как и ваш, просто с другим шаблонизатором. И да, именно так, абсолютно любой код по мере роста приложения может стать таким:тормозное (из-за лишних апдейтов), глючное (из-за забытых апдейтов), нагромождение лапши (из-за условных апдейтов и множественных зависимостей).
… но императивный код сохраняет цепочку действий, а реактивный — нет. И это значительно усложняет его сопровождение.
DrPass
25.06.2022 19:29-2Ок, понял, термин «интерактивный код» сказал другой автор в какой-то другой книжке. Ну в общем, он перепутал. Это — императивный код, а не интерактивный. Императивный, потому что действие передаётся явным указанием. А интерактивный — это редактор IDE с подсказками.
nin-jin
25.06.2022 20:09Ага, эти ребята тоже всё напутали: https://en.wikipedia.org/wiki/Interactive_computation
И интерактивный код, и реактивный являются императивными, так как описывают алгоритмы, а не результат.
DrPass
25.06.2022 20:21+2Эм…
interactive computation is a mathematical model for computation that involves input/output communication with the external world during computation.
А какое отношение это имеет к обсуждаемому нами вопросу, кроме того, что там слово «интерактивный» встречается? Если вы уж решили погуглить пример «интерактивного программирования», то не кидайтесь в меня первой попавшейся ссылкой, прочтите хотя бы что кидаете :)
И да, реактивный код не является императивным. Реактивный темплейт — это чистой воды декларативное программирование.
nin-jin
25.06.2022 23:47Никакого. Это имеет отношение к пробелам в вашем кругозоре, где интерактивным может быть только UI, а ничего другого "с таким названием не изобрели". С пониманием императивности/декларативности у вас тоже беда. Я бы предложил вам почитать, но вы ещё предыдущую статью не осилили. Продолжать терминологические споры мне не интересно.
DrPass
26.06.2022 00:44Ок, можно было и раньше прекратить. Я не знаю, послушаете ли вы моего совета, но…
а) Если вы хотите как-то аргументировать своему оппоненту, не кидайте ссылки на статьи и книги. Ваш оппонент не будет тратить время, выискивая в том тексте, что вы там конкретно имели в виду. Если вы что-то конкретное хотите сказать, дайте цитату из своего источника. Если цитаты нет, а вся суть вашего посыла «учите матчасть», лучше промолчите. Никакого аргумента — это в 100500 раз лучше, чем плохо завуалированная грубость. И
б) тем более не приводите в качестве аргументов свои собственные статьи. Если ваш собеседник сомневается в вашем знании «матчасти», вес ваших статей для него, знаете ли, by default околонулевой.
AlexBream
25.06.2022 08:3620 лет назад был 2002 год
Delphi - да, PHP - еще нет, как массовое явление статика на чистом голом HTML. PHP — это еще ~+5 на календаре, вторая половина нулевых
Экономике bloatware пока не вредит так, чтобы это было ощутимо в цифрах (и тезис "вредит" лучше все же доказывать, потому что аксиоматичность его под большим вопросом), потому процесс и продолжается
rtemchenko
24.06.2022 21:54+1Уверен, что никто из кодеров не представляет, почему это происходит, а
код в его основе — это просто куча раздутого скопипащенного навоза.Скорее всего кто-то представляет.
Проблема не в том, что код хреновый. Проблема в том, что на фиксы таких мелочей не выделяется время. Нужно деливерить фичи. Закончили одну фичу, тут же начинается следующая, потому что она была распланирована еще на позапрошлый месяц. Все некритичные проблемы, промахи и т.д. отправляется в категорию тех. долга. Если проблема становится критичной она фиксится. Иначе она существует годами до смерти фичи.
Это типичная история любой крупной компании, любого долгоиграющего проекта.
Это происходит не только потому, что кодеры не пишут низкоуровневого эффективного кода для достижения своей цели: они просто никогда не видели низкоуровневого эффективного, хорошо написанного кода.
Проблема более комплексная. ИМХО она вообще в другой плоскости. Я бы сформулировал так:
Подавляющее большинство программистов пишет тупой процедурный код. Говорят ООП, а на самом деле гоняют тупые ДТО между функциями. В таком коде сложно выделить абстракции, определить границы. Все связано со всем.
При увеличении требований и сложности продукта это приводит к экспоненциальному росту количества кода. Получается порочный круг. Код сложный для понимания - он обрастает костылями. Костыльный код становится сложнее понимать.
В такой системе низкоуровневый код невозможно поддерживать. Потому что он не отделен строгой границей. Его начинают копировать, подгонять под требования. И получаем проблему о которой говорил автор.
DrPass
24.06.2022 22:02+4Проблема в том, что на фиксы таких мелочей не выделяется время.
Слушайте, ну я не слишком ошибусь, если скажу, что в 95% проектов никто там за спиной у разрабов с таймером не стоит. Видишь что-то корявое, возьми и исправь по ходу дела, никто ругать не будет, а коллеги похвалят. А менеджер потраченное тобой время не моргнув глазом в счёт клиенту впишет, а клиент оплатит. Просто всем пофигу.rtemchenko
25.06.2022 00:36+1Я говорю больше о продуктовых компаниях. Тут свой набор проблем. Можно статью писать. Навскидку:
Фичи планируются на несколько месяцев вперед. Первая фича ломает весь график, и остальные уже делают в режиме "на вчера". И так до бесконечности. Планирование то делают не инженеры. Их только ставят перед фактом дедлайнов.
Даже небольшое изменение кода требует больших ресурсов на анализ и тестирование. Потому что код пишется с учетом существующих проблем. И фикс проблем создает новые проблемы. Гейтинг не панацея.
Промо культура требует импакта. Вот прям так. Получается, что выгодно сделать фичу побыстрее, набрать тех. долга, а другие разберутся. Плюс важно уметь продавать свои заслуги. Можно делать полнейшую фигню и получать повышения. А можно делать важные вещи, но не презентуя их правильно, получать отказы. Очень выгодно заделиверить фичу, набрать тех. долга, а остальные потом разберутся. И каждый разработчик думает "а чем я хуже", и круг продолжается.
Я тоже раньше читал статьи про ужасную культуру разработки в Гугле и прочих, и думал, что это все фигня, и зависит от команды. Попав в Калифорнийскую компанию, я понял, что, к сожалению, все реально так плохо.
Adjuster2004
24.06.2022 22:111С напомнило
lolipoka
24.06.2022 23:06Чем напомнило? БСП не нравится? Про Inversion of Control не слышали?
Это проблема прикладных разработчиков на местах, а не разработчиков БСП и типовых конфигураций. И проблема эта, по большей части, заключается в том, что большинство прикладных разработчиков на платформе 1С ничего, кроме Радченко и Хрусталёвой, не читали.
В мире 1С всё нормально. Для контраста можете пойти поработать в какого-нибудь интегратора на его внутренней самописной платформе на языках общего назначения с возможностями, по сути, такими же, как у платформы 1С, но без документации и с гораздо более низкой скоростью доставки новых фич. Отчёты на каком-нибудь JasperReports после СКД трудно воспринимать как что-то удобное в разработке.
Вот была хорошая статья на тему: https://habr.com/ru/post/480658/
greenkey
24.06.2022 22:55+2Очень много времени приходится тратить на изучение зависимостей, которые ты хочешь использовать в проекте. Сравнение доступных вариантов, изучение их истории, перспектив, в идеале состояние кода.
bsivko
24.06.2022 23:37Не понятно наличие картинок из Elite. Игра с процедурной генерацией вряд ли предполагает процедурную генерацию требуемого кода по запросу и некоторой экономии таким образом. Тут скорее бы подошёл какой нибудь пример из демосцены, где с ограничением по памяти умещают большой функционал и могут это просто показать.
Dr_Faksov
25.06.2022 05:30Когда-то были (а может и сейчас есть) соревнования по программированию в размере 1024 байта. Чего только туда люди не всовывали. Мне запомнился почтовый клиент и уровень от Castle Wolfenstein. Забыл сказать - исполняемый файл - COM, операционка - DOS.
nronnie
25.06.2022 00:39+2Несть числа раз видел, как много раз упомянутый выше "эффективный и талантливый" код приходилось полностью нах выкидывать и переписывать с нуля, потому что кроме его эффективного и талантливого автора (к тому времени уже свалившего в закат) в этом коде никто нихера не мог понять. Наверное все были просто недостаточно эффективны и талантливы для этого.
Dr_Faksov
25.06.2022 05:15+4Ну, если код работал ка надо, а вы не понимаете "как" значит ваш уровень ниже уровня автора кода. А люди обычно не любят (мягко выражаясь) тех, кто талантливей их.
А равняться по тупейшим - путь в никуда.
Dorval
25.06.2022 06:57+1Ваш комментарий поднимает старый вопрос: программирование - это искусство или ремесло? Если ремесло и автомобильный конвейер - ближайший аналог, то лучше выстраивать процесс, ориентируясь на добротного середнячка-исполнителя, именно он будет фиксить баги и точить новые фичи. И именно он будет читать код предыдущих программистов. У вас просто не будет столько гениев, чтобы заполнить конвейер (ну, если вы не Google, конечно).
i360u
25.06.2022 07:55Да нет тут никакого "или". Программирование может быть и искусством, и ремеслом и ими обоими одновременно. Все дело в контексте, и без него рассуждать на эту тему глупо. Программирование - оно про масштабирование процессов за счет автоматизации, и продать миллион раз код, написанный одним гением, может быть проще, чем продать один раз код, написанный миллионом бездарностей за конвеером. В определенном контексте, опять же.
cepera_ang
25.06.2022 11:01А с другой стороны: если автомобилестроение должно ориентироваться на слесаря-середничка, то как получить современный авто. напичканный процессорами? Слесарь на станке процессор не выточит.
Mitch
25.06.2022 11:59+2Вовсе не значит.
Понятный код писать сложнее, требуется выше квалификация.
Понятным код делают несколько вещей:Правильное разбиение на абстракции. Они должны быть максимально похожи на предметную область.
Сокрытие сложности. Инкапсуляция. Чтобы каждый кусок кода был не слишком сложным, и было понятно что происходит с теми обьектами что в нем используются.
Понятные названия. Сделать понятное название всегда более трудоемко, чем назвать x и y.
Плохо написанный код, где смешаны уровни абстракции, где недостаточная инкапсуляция, как попало названные переменные - может отлично работать. Но если там баг то найти его сложно, потому что понять что там вообще делается сложно.
FrolVII
25.06.2022 01:50+2Лично я думаю, что дальше всё будет только хуже <...> Просто для того, чтобы сложить два числа, понадобится 32 DLL, 16 служб Windows и миллиард строк кода
Проблема (хотя есть те, кто не считает это проблемой) может быть рассмотрена шире. Безудержное потребление - классика современного общества.
i360u
25.06.2022 07:47+2Есть большое количество нытиков, про то, что современные программисты уже не те. Однако, эти нытики, почему-то, не заваливают рынок своими сверхэффективными решениями, созданными за кратчайшие сроки... Напишите современную "элитку" в несколько килобайт, от которой глаз не будет дергаться... да вам памятник поставят! Но нет, тишина... К чему бы это? В целом, я согласен, проблема раздутости всего и вся, в современной разработке, имеется. Но причину стоит поискать в чем то еще, кроме вот этого "а я то, в советские времена, уууууууу!" Современное ПО, как и раньше, создается в условиях ограничений. Просто ограничения эти, давно вышли за пределы коротенького списка из процессора и памяти.
Helltraitor
25.06.2022 08:37640 КБ должно хватить всем
Как правильно заметили выше. Статья автора - сплошное нытье, ничем не отличающееся от нытья других людей до. Мне больше жаль переводчика, что он свое время потратил.
А если говорить ближе к сути, то количество зависимостей растет, а тенденции их отсекать, как садовник ухаживая за розами, - нет. Отсюда все эти многотонные программы, которые под капотом используют "проверенный годами" софт, который используюет старые библиотеки, которые... И так далее, с щепоткой утрирования
DrZliden
25.06.2022 08:38+1Вопрос что делать?
У нас контора сидит на аутсорсе. Приходит задача, надо сделать такую «пиндюрь», напишите соклько времени надо и делайете. Ок пишем время начинаем делать. Тут же прилетает со стороны заказчика, а чегойто так долго, а может вы возьмете вот эту либу? Нет не возьмем нам быстрей самим написать, чем разбираться с чужой. Ой да вы всё врете нам свой прогер сказал там всё просто(ага тока сам делать не стал). Давайте либу. Блин мы пока переписывались своё почти сделали. Вот и зря переходите на либу у неё 3.5 разработчика, и целое сообщество(9 человек). Ок переходим убедили. Тратится ещё неделя, хотя работы оставалось на день. Получам «пиндюрину» с левой либой, заказчик рад, ура вот как либа помогла, как наш «имярек» хорошо подсказал, а то бы вы ещё день писали код, а тут за неделю всё готово. Только смотрите тут вот хрен, тень не отбрасывает, добавьте хренотень. А выбраная вашим «имяреком» либа хренотень не поддерживает. Начинаем патчить левую либу под хренотень… А вы знаете тут вот ещё есть либа может она хренотень поддерживает, или её проще пропатчить, наш «имярек» говорит вроде проще(сам правда он этого не делает). По началу дико бесило. Но заказчик платит за хотелски, ну и пусть будет доволен. То что проект вы итоге из кучи непонятных либ, уже все давно пофиг. Идёт-едет, заказчик доволен, деньги платют. Я бы и рад по другому, но не дают. Стыдно стынд, но платют хорошо, а стыд я побороть смогу.
VentisStella
25.06.2022 08:38Вообще, насколько я знаю, эта проблема давным-давно известна. И имя ей - ООП. ООП - одна из форм добра, которое стало злом. Теперь его суют в каждую дырку без всякой надобности, просто потому, что по неизвестной причине у многих в голове сидит большой таракан с именем "ООП". И эти тараканы множатся с геометрической прогрессией. А любая самая простая процедура, являющаяся методом класса тащит за собой всю иерархию класса. И не понятно, почему компилятор не вырезает из кода всю неиспользуемую часть мусорного ДНК этого класса, оставляя только исполняемый код.
Например, в Дельфи пытались избавиться от дурной наследственности. ООП, создав KOL.
Static_electro
25.06.2022 09:45+1я вас уверяю, что 500 Мб современного текстового мессенджера - это не от иерархии наследования
nikolas78
25.06.2022 17:38Мне в этом смысле ближе множественное наследование только от абстрактных классов, каждый из которых сам-по-себе (ни родителей, ни абстрактных потомков).
JCD3nt0n
25.06.2022 08:38+1А есть ли "раздувание кода"? Конкретные проблемы, описанные в статье, касаются Windows, которой приходится тащить за собой кучу костылей. Другие системы (macOS/Linux) просто выбросили всё наследие ценой совместимости со старым ПО.
Если же смотреть реально, то мы ушли от якобы "оптимизированных" утилит, которые работали только на одной ОС с однобайтовой кодировкой, да ещё и с ограничением по объёму данных — тот же Outlook когда-то имел ограничение в 2ГБ для PST-файлов, потом оно выросло до 20ГБ, но кто-то всё равно упирался в это ограничение.
Так что объёмы данных растут. Увеличивается и размер самих файлов, так как они хранят больше информации, чтобы отображать содержимое качественно на современных средствах вывода. И не важно что это — текст, изображения, видео, аудио, etc.
Современные ресурсы позволяют получать приложения быстрее, а не ждать их годами. Тот core-функционал, что годами прорабатывали в старых приложениях, теперь обязателен в MVP, на который есть значительно меньше времени. Теперь не надо десятилетиями ждать версии для Linux или macOS, тот же FAR Manager сейчас всё ещё портируют под Linux, вот только кому он теперь нужен? Надо было вместе с версией для Windows выпускать.
А качество кода растёт. Я сейчас смотрю на внутренности старого продукта (который меньше ресурсов требует) и ужасаюсь. Новый требует на порядок больше ресурсов, но его возможности на голову выше, чем у старого, да и кодовая база там теперь приведена в порядок. За счёт этого продукт удалось за два года перевести на Linux (требование настоящего времени), а со старым такое не получится.
Оптимизация всегда имеет свою цену в виде зависимости от архитектуры процессора, версии ОС, библиотек, etc. Но самое главное — ограничения в расширениии функционала. Можете посмотреть на nginx и попытки реализации QUIC в нём. Продукт отличный, но рынок требует новых возможностей, в том числе для оптимизации объёмов трафика.
Massacre
26.06.2022 04:01+1Нет же. Основные проблемы не в обратной совместимости, а в том, что стали тащить веб-технологии на десктоп. Просто надо использовать технологии по назначению, иначе продукт в итоге будет одинаково негодным, что на Windows, что на Linux…
JCD3nt0n
27.06.2022 03:00Как раз в ней и проблема. Делать 100500 верий под разные API или его ревизии никто не будет. Особенно на общем тренде отказа от десктопов. Тот же SDK Apple позволяет быстро сделать версию для нескольких платформ, а теперь уже даже запустить нативную версию с iOS на macOS, поэтому на ней реже встречаются приложения на базе Electron. В основном страдают от этого подхода Windows и Linux. Первый, потому что у пользователей зоопарк версий ОС на устройствах, второй — потому что нет единого графического API. А так, в целом, софт очень даже оптимизируется. Firefox перестал адски жрать память после внедрения компонентов на Rust, да и Chrome'у тоже порезали аппетиты по ресурсам. Чудес, естественно, не будет, чтобы это работало на 2-4ГБ ОЗУ, да и не нужно, когда она достаточно дешёвая. Про 32-бита вообще пора бы забыть окончательно.
Ну и ещё один фактор — финансовый. Тот же Telegram старается, чтобы были нативные приложения, под какие-то платформы даже есть выбор из двух. Но что-то никто не побежал массово оплачивать премиум, чтобы отблагодарить разработчиков. Все хотят всё бесплатно, да ещё и чтобы под их хлам десятилетней давности что-то оптимизировали. Может пора начать платить за софт? Или обновить железо хотя бы?
Так что проблема "раздутости ПО" раздута. Да, есть такие приложения, но прям массовой проблемы нет. Софт сейчас вполне себе оптимизирован, особенно платный.
Watashiwa
25.06.2022 08:39-1Ну да, решил сейчас курсы пройти к примеру по тому же питону (да и все остальное) так там все "упрощенно" под стандартизацию. Возьмите для простоты понимания и создайте понятно названную переменную и запихните в нее значение и только тогда используйте одноразовую переменную, мол для более легкого понимания чтения вашего когда))) Оно конечно легче, но как представлю если бы на ассемблере все значения в регистры пихали бы да и переменные создавали чтобы один раз использовать))). И так почти во всем. Стараются сделать все настолько простым и универсальным, что оно просто увеличивает код и длительность его выполнения. Помню раньше такты считали и килобайты - сейчас такой фигней уже не страдают. Проще написать что-то новое за что заплатят, чем разобраться во всей этой здоровой мешанине. где никто ничего уже не понимает - ну да понятные переменные и названия функций - но вот логика работы же в них не описана. А описывать все значения, сравнения и прочее комментариями так никакого времени не хватит на код. А так найдут дырку в старом модуле - кое как исправят, а вот все остальное что было завязано на "правильной" работе модуля начинает иногда косячить))) Короче стало быстро писать но долго понимать доскональную работу. Впихнул всего и побольше - там функцию из того, там другую из этого и да получается как и написано в статье.
KL1
25.06.2022 08:39Раздувание ПО трогает только тех кто привык контролировать внутреннюю работу своих железок, знать что сколько ресурсов занимает, и скрупулезно следить за файлами и процессами.
Типичный современный пользователь об этом может вообще не знать, и когда сталкивается с отсутствием свободного места, проблема решается просто и относительно дешево - стереть лишнее или прикупить диск побольше. И то что новая железка (в купе с новой версией ПО) делает примерно тоже самое и примерно с той-же скоростью, для него не так важно. Зато это новая железка (в рекламе которой производитель показал лучшие цифры чем в прошлой) и новая программа (покрасивее, больше анимации и т. д.).
А с точки зрения бизнеса, все вообще хорошо, продажи растут, и надо продолжать в том же духе.
Static_electro
25.06.2022 09:52+3Типичный современный пользователь об этом может вообще не знать, и когда сталкивается с отсутствием свободного места, проблема решается просто и относительно дешево - стереть лишнее или прикупить диск побольше.
особенно пользователи смартфонов любят стирать лишнее и диски докупать. Особенно те, кто постарше. Так что не соглашусь. Типичный пользователь может не знать, что его трогает эта проблема, но это не значит, что она его не трогает на самом деле.
0x131315
25.06.2022 08:53+2Собственно это последствия мира команд и менеджмента.
Одиночка имеет больше ответственности, более целеустремлён, имеет контроль над кодом. В командах ответственность размазывается, контроль удержать сложно, как итог в код начинает проникать мусор и ошибки, и ресурсов этого избежать часто нет. Особенно плохо, если в команде есть слабые коллеги: за них их часть работы никто не сделает, ресурсов на это не дают, а их код ужасен, но так навсегда в проекте и останется, будет кое-как работать, порождать сотни ошибок.
С учётом того что современная разработка построена на максимальной экономии и руководит процессом менеджер, который в этом ничего не понимает, приходим к фичегонке: оказывается для проекта важнее наклепать тысячу ненужных фич, чем остановиться и привести в порядок хотя бы одну из уже сделанных. Та же ситуация с техдолгом и качеством кода: на это никогда нет времени, вечное завтра.
Вот и получается, что на выходе у одиночки компактный рабочий код - он его сам писал, один, сам за все в ответе, сам все проверил, и результат прямо соответствует ему опыту: у новичков он плохой, у опытных хороший.
А на выходе у компании - урод, внутрь которого лучше не заглядывать: раздутая смесь из грязного кода, ошибок и костылей, которая каким-то чудом но частично работает. Там тысячи фич, но работает из них лишь часть, и работает не особо хорошо.
Особенно таким грешат крупные компании, где софт для галочки: его просто нужно выпустить, а как - не важно. Менеджер на менеджере сидит и менеджером погоняет, важны только отчёты и расходы, а главное, сам результат, никого не интересует.
Чтобы результат был хорош, нужно давать разработчикам свободу. А это в основном некоторые продуктовые компании, которые сосредоточены на результате, где можно взять и пилить одну фичу до тех пор, пока она действительно не будет готова, или где если заметил ошибку или неоптимальный алгоритм, ты можешь его взять и поправить.
Javian
25.06.2022 08:56Столкнулся с тем, что на некоторых компьютерах бывает "аппаратно зарезервированной памяти" больше половины оперативной т.е. из 8 Гб половина занята непонятно чем. После удаления драйверов видеокарты Nvidia зарезервированная память уменьшается до 200 с небольшим.
JordanCpp
27.06.2022 10:41Да, столкнулся на ноуте с ryzen. При покупке в ноуте установлено 8 гб. GPU отъедается сразу 2 гб. В биосе поменять или уменьшить, данный объем возможности нет. Только добавлять память. Есть один слот.
thenonsense
25.06.2022 09:16На самом деле из текущего положения дел следуют огромные возможности по оптимизации по, ос и самого железа. Если начать всё делать по уму, а не ради прибыли, вращения потребления и накручивания технологий ради технологий. Раз есть среда, в которой живёт такое количество огромных неэффективных разожравшихся технологических динозавров - там же могут обитать куда более оптимальные компактные существа в каких-то неисчислимых количествах.
JordanCpp
25.06.2022 09:54-1Как же мне нравятся такие статьи. Да, да, да полностью согласен с автором. Все огромное и тормозит. Справедливости ради, скорее всего в архиве с программой какой нить qt + картинки + локализации и справочная документация. Или вообще электрон засунули.
vconst
25.06.2022 10:21когда я нажимаю на значок громкости ноутбука Microsoft Surface, то вижу задержку: машина постепенно создаёт новый элемент интерфейса пользователя, разбирается, какие значки отрисовывать, а затем они появляются и становятся интерактивными. На это уходит время. Кажется, около половины секунды, что в масштабах времени процессора близко к миллиарду лет
Кто-то пробовал проверять слова автора?
В данный момент сижу за относительно древненьким x260, нажимаю на кнопки изменения громкости и… все происходит МГНОВЕННО. Я не замечаю никакой задержки между нажатием и отрисовкой элемента на экране. Не только 0,5 секунды — а вообще нет задержки. Никакой, абсолютно
Тогда вопрос
Это я такой крутой виндо-юзер, что смог все круто настроить и оптимизировать?
Или просто автор жопорукий долболюб, который непонятно чем и как умудрился засрать свой комп до полной невозможности им пользоваться?
Может и нет никакой проблемы?JordanCpp
25.06.2022 10:30+1Думаю, что у вас ssd. А у автора hdd. Я столкнулся с таким поведением на hdd. Особенно это заметно когда переходишь по окнам настроек. Задержки и шуршание винта. Задача без ssd не решаема, раньше как то решалась, на древнем железе, ну к сейчас с 5нм уже проблемы.:)
vconst
25.06.2022 10:34-1Да ладно! Отрисовка ползунка громкости происходит с задержкой 0,5 секунды — из-за HDD?
Ни за что в это не поверюJordanCpp
25.06.2022 10:41Возможно до кеширования данного элемента, это происходит. Даже на ПК с ssd. Я это замечаю. Стоит windows 10. Но только один раз при загрузке ПК.
vconst
25.06.2022 10:42-2Ок, щяс перегружу комп и снова попробую
vconst
25.06.2022 10:46-4Короче — вранье это все
Только что ребутнул ноут и сразу после появления рабочего стола — попробовал регулировать громкость
Как и ожидалось — все происходит МГНОВЕННО.
Стоит задуматься, может и остальное автор тоже выдумал? Может не все — но многое или выдумано, или дико утрировано.JordanCpp
25.06.2022 10:59+4Ну ок. У меня не мгновенно. Значит и вы придумали? Понятно, что информацию нужно проверять. У меня так происходит на ноуте с ryzen 5 и hdd. И ПК athlon x4 640 и новенький ssd kingston.
iig
25.06.2022 10:45Кроме отрисовки, там ещё же и в реестре где-то обновленные параметры эквалайзера сохраняются. И ОС по всем окнам рассылает уведомление что параметры поменялись. Через слоев 100500 абстракций, конечно же. И где-то в этой цепочке что-то выгружается в swap.
vconst
25.06.2022 10:47-3Сову не жалко — пожалейте глобус.
Берется бритва Оккама и режется все под корень, если вместо попыток оправдать авторский бред — просто взять и подергать эту громкость самому.iig
25.06.2022 11:20+4просто взять и подергать эту громкость самому
У вас точно такая же нога но не болит? Рад за вас ;) Чтобы убедиться, что кто-то в интернетах
неправ, мне нужно найти такой же комп, взгромоздить на него тот же набор софта (с антивирусниками, кряками и кейгенами).. Воздержусь.ЗЫ: у меня воще
linuxлапки. :)vconst
25.06.2022 11:23-1Вот я и говорю — автор загадил свой комп до полной всратости — а потом стал пенять на разработчиков. Может у него в автозагрузке 100+ программ и три антивируса борются друг с другом с переменным успехом
cepera_ang
25.06.2022 11:36+2А может там при запуске читают десятимегабайтный файл по одному байту и парсят алгоритмом с O(n^2) или невидимые иконки ровняют по сетке
vconst
25.06.2022 11:40-1Или запускают рендер в режиме максимального приоритета, когда даже прорисовку курсора мыши можно чуть не по пикселю разглядеть
Вопщем, все очень натянуто и наброшено
Busla
25.06.2022 12:05Думаю, что у вас ssd. А у автора hdd.
ноутбук Microsoft Surface с hdd? - такие разве были?
irokezer58
26.06.2022 14:50Не знаю, что там у вас за х260, но, у меня Феном 2 х4 с 8 Гб ОЗУ и сразу после загрузки ОС, при первом нажатии правой кнопкой на любой папке на рабочем столе я ожидаю около 10-20 секунд. Да, что там папка? На рабочем столе правой кнопкой - то же самое.
Так что, я согласен с автором на все 100%. Считаю, что для продвинутых юзеров просто необходимо нормальное ПО, без всех вот этих вот наворотов в виде анимации и прочей бесполезной лабуды, с ГПИ на уровне 95 винды - как максимум, а как минимум - вообще без ГПИ, чисто на командной строке. А для остальных 95% юзеров пусть останется "плиточный 2д дизайн десятой винды", который ест ресурсов больше чем любая 3д игра из 2000 года.
Но, такого не будет никогда. Это только мечты.
cepera_ang
26.06.2022 17:17У вас на рабочем столе случайно не лежит тысяча файлов?
irokezer58
26.06.2022 18:04Нет.
cepera_ang
26.06.2022 18:06+1Может тогда экстеншн для проводника какой-нибудь? Добавляет пункты меню или ещё что-нибудь, при первом запуске долго инициализируется.
irokezer58
26.06.2022 22:57
Как-то так.
cepera_ang
26.06.2022 23:10Я бы грохнул это всё (каким-нибудь autoruns), особенно если не пользуетесь.
По-любому, это либо я.диск, который при запуске ещё не успел залогиниться/засинкать что-нибудь или антивирус, или sharepoint (тоже при включении что-нибудь в сети делает).
Ещё подозрительно, что иконки половины пунктов в «Создать» битые, как будто этот софт давно удалён или пути какие-нибудь кривые в реестре.
vconst
27.06.2022 08:29Только что ткнул правой кнопкой на десктопе, хотя не понимаю, зачем это надо, я десктоп практически никогда не вижу.
Все мгновенно, какие-то микросекунды на отрисовку эффекта плавного проявления меню — и все
x260 на мобильном i5, 16 гигов
ЧЯДНТ?irokezer58
27.06.2022 08:53Не знаю. Вы просили проверить слова автора - я проверил. Но, такая задержка у меня только после включения. После первого нажатия срабатывает быстрее, но не мгновенно. Иногда 1-2 секунды. Громкость работает так же.
vconst
27.06.2022 09:02Ну, значит есть таланты, которые умеют засрать систему до невменяемых тормозов. Только виновата в этом не система и раздутый софт, как пытается доказать автор статьи
irokezer58
27.06.2022 10:22Не спорю, система у меня засранная, и винда старая, я её устанавливал ещё году в 2013. То есть она уже лет 10 работает. И софта всякого разного стоит очень много.
Но, тем не менее, софт реально раздут. Например Windows XP требовала 1,5 Гб ПЗУ и 128 Мб ОЗУ, а десятка - уже 20 Гб и 4 Гб соответственно. А прошло всего 15 лет. Куда это годится?
Думаю, сейчас рынку просто необходима небольшая офисная ОС с минимумом функционала. Потому что код винды уже близок к технологической сингулярности.
JordanCpp
27.06.2022 10:51Как вариант кастомный Linux. К примеру есть Antix на старте где то 128 озу. + libre office 300 мб для запуска. Но юзать его очень неудобно(я особо не копал). Вариант сделать сейчас такой дистр на базе линукс есть. Даже самому. Поставить ubuntu и поменять DE. Правда он включает systemD, который не выпиливается.
JordanCpp
27.06.2022 10:45Перезагрузил, на глаз громкость с плавным выездом открывается за 0.5. Повторно примерно за 0.3.(Задержки уже нет) Это ко всем окнам относится. Wifi, настройки и т.д Но загрузка параметров экрана всегда одна секунда. Не мгновенно.
zkutch
25.06.2022 11:03"совершеннейшее, совершеннейшее безумие. Именно из-за этого ничего не работает, всё медленное, нужно покупать новый телефон каждый год и новый телевизор для скачивания этих раздутых приложений для стриминга, в котором тоже прячется столь же плохой код."
А может быть именно это следствие и есть причина? Если код вынуждает каждый год покупать и покупать дорогущие вещи, то может потому он и приветствуется? Безумие для програмиста, но вполне разумно для бизнеса.
JordanCpp
25.06.2022 11:17Да. Дёшево, быстро, чик чик и в прод. Как говорится а фигли нам бизнесменам:)
divanus
25.06.2022 11:29Все слои системы , которую я написал занимает порядка 250 кб + одна единственная Библиотека в 1 мб.
Предыдущий код , доставшийся в наследство занимал для этого же функционала около 150 Мб и десяток библиотек.
Вот думаю , а может ещё уменьшить ?????????
И я честное слово не считаю себя вообще программистом.
minusnaminus
25.06.2022 13:07+1Если бы программисты делали программы свои из реальных материалов, из дерева там, или металла, процесс конечно можно было бы замедлить. Посмотрите сколько в прочих отраслях стандартов всего. Дафигалион шурупов, винтов, марок стали, разъемов, сопряжений, оригиналов и аналогов, даже систем измерений две. Возможно в будущем случатся попытки как-то зафиксировать хотя бы часть этого программного зоопарка. Условный список "жизненно важных" (по аналогии с лекарствами) приложений, то есть, один редактор текста, один редактор изображений, базовый (гос) месенджер, стандартный браузер для "госуслуг" и т.д. С ежегодным фиксом багов и некоторым обновлением функционала раз в 10 лет. И все это под такой же стандартный ПК и смартфон. Учитывая торможения прогресса в этих областях, то подобной сборки хватит лет на 50, а следующей, может и на все 100. Мало что ли "древнего железа" до сих в работающего, а то ещё и производящегося? Либо же все само как-то коллапсирует до чего-то подобного. Как-то раз в компании любителей фантастики шутили, что космические просторы будут бороздить корабли, в недрах которых будет оборудование и код возрастом в столетия, а обслуживающий персонал будет, хочет он того или нет, напоминать вархамерровское техножречество :)
mbobka
25.06.2022 13:19Вообще обычно из этого огромного объёма 99% это не код, а графика. Хотите поменьше объём -- пользуйтесь утилитами командной строки, но вот тут уже 50% где-то будет занято кодами ошибок, которых вы никогда не увидите.
Aleksandr-JS-Developer
25.06.2022 17:32Ага, видал я функционал на больших проектах.
Помимо очевидного легаси, которое расширяется, всесто модифицирования, есть ещё один момент.
Аналитика и куча хотелок бизнеса. Вы просто загружаете файлы и понимаете, что они там где-то хранятся. На самом деле вы клиент. И ваши действия отслеживаются. Все возможные и нет. В каждой крупной компании есть десятки метрик для десятка сотрудников из разных сфер. От менеджеров и рекламщиков, до разработчиков и дизайнеров. Эти метрики нужно мониторить. Может быть - в реальном времени. Может, нужна возможность троттлить загрузку файлов в зависимости от загрузки кластера и уровня вашего пакета. Всё это уже многолетнее легаси на каком-нибудь паскале в перемешку с плюсами. И пока оно работает - никто не будет тратить невероятные ресурсы на рефакторинг. Это было и раньше и сейчас и будет в будущем, как бы печально не было.
vconst
25.06.2022 17:34А еще, я не заметил, чтобы автор упоминал дедупликацию. Хоть это и не побайтовое сравнение, но хэш все равно надо посчитать и сравнить.
cepera_ang
25.06.2022 19:16+3Так это всё часть того же крика — из-за зло***чей модели, что пользователь лох. с которого нужно драть сначала за основную функциональность, а потом ещё рекламой и телеметрией заполировать и ещё заполировать «поставляется as is», то в софте на компе пользователя, за деньги пользователя выполняются чьи угодно задачи, но не пользователя. Какую ценность мне несут эти долбанные метрики? Да никаких, только минусы, компания потом увидит, что какую-нибудь кнопочку нажимаю я один и выпилит её из следующей версии, потому что непопулярная фича.
Почему хотелки бизнеса важнее хотелок клиента? Только потому что бизнес может это делать без последствий.
Aleksandr-JS-Developer
26.06.2022 16:08Ну, это похоже на неконструктивное положение какого-то обиженного ребенка.
Бизнес зарабатывает деньги. Никто не станет тратить деньги на бесполезные метрики. А если они полезные, то никто их не выкинет. На самого клиента им срать, насколько это возможно. Бизнесу, чтобы выжить, нужно быть наглым и цепляться на всё, что возможно. Тут нечего обижаться - вам тоже на них срать, по большому счёту.
Если вы платите деньги и недовольны работой сервиса, есть отличное лекарство - написать им, что ты недоволен вот этим, 1: ..., 2: ... и валишь к конкурентам. И валить к конкурентам...
Да и вообще, какая вам разница, что происходит внутри, как клиент?
Более-менее подкованный пользователь может организовать почти анонимный сёрфинг у себя на домашнем ноуте без особого напряга и абсолютно бесплатно. Я понимаю, когда от перегруза страдает клиент (программа-интерфейс), тут да, но что происходит на серверах вам должно быть совсем по барабану.Это скорее крик программиста, которому этого монстра поддерживать (откуда тогда известна внутренняя кухня??). Тут да - без вопросов, парню (а скорее всей команде) не повезло)
cepera_ang
26.06.2022 17:20Деньги определяют не всё, у людей часто есть всякие ценности и принципы и выражать свое мнение об этом — одна из форм давления на тот же самый бизнес. Будет широкая кампания в поддержку чего-либо, бизнес будет туда двигаться, пусть и вяло.
Может быть подобные посты не приносят мгновенного результата, но если молчать — будет ещё меньше.
Aleksandr-JS-Developer
26.06.2022 21:16если молчать — будет ещё меньше
Молчать никогда не нужно. Но ценности и т. д. сходят на нет через два-три уровня бюрократии.
Как вариант (опять же, большой напряг для бизнеса и не подходит в сильно коррумпированных обществах) - законы. Уже есть целая система, которая огораживает народ от кучи неприятностей. Например, одно только обязательство печатать состав съедобной продукции на её упаковке - это уже достижение, которое, без преувеличения, спасло (в прямом смысле) кучу народу.
А по факту как всегда - где-то посередине
Silvestor
25.06.2022 19:19+2Опять очередное нытьё оторванное от реальности. Мальчик в песочнице, которому не понятно почему дом строится так долго в отличии от его песочного замка.
Есть такое суждение, хочешь проверить дуга дай ему денег в займы. Здесь также, хочешь понять почему, дай ему власть взаймы. Если бы данный персонаж имел свою фирму и попытался нанять команду , которая бы была в соответствии с его требованиями, то он бы быстрее поседел. А когда бы он потратил слишком много средств на проект, который в итоге не выстрелил, то его бы вовсе расстреляли.
JordanCpp
25.06.2022 21:05Вроде бы и понятно и не поспоришь. Но из года в год, та же история, бизнес, фичи, рыночек и т.д То есть проблема все таки в рынке, который диктует свои правила игры. Жручие и толстые программы лишь результат болезни.
cepera_ang
25.06.2022 21:07Рынок успешно выжимает из пользователей всё, что может. А программисты — бенефициары этого процесса, поэтому призывать к ним бесполезно, хотя они и валят всё на «менеджеров, продактов, бизнес».
JordanCpp
25.06.2022 21:21+1Для изменения правил, нужно менять систему. Сделать ветку, внести изменения и сделать коммит;)
Даёшь лёгкие программы.
Долой засилье электрона.
cepera_ang
25.06.2022 21:29-1Ну нет, между технокоммуняками и рыночными эксплуататорами я пожалуй выберу второе.
altmax
25.06.2022 20:12Хотелось бы поправить автора - первая Elite занимала не 64, а 48 килобайт, первые 16 кб - это было ПЗУ компьютера с неким аналогом операционной системы. И да, в 2004 году был у нас на работе Пентиум-3 533 МГц, и на нём прекрасно работала одна браузерная игрушка на Flash. Энтот самый flash-плейер имел нехорошую привычку обновляться пару-тройку раз в месяц, после каждого обновления он работал всё медленнее и медленнее, лет через 5 эта игра уже с трудом шла на 1700-м целероне.
И до сих пор интересно, как смогли уместить Elite в 48 килобайт?
VladGTN
26.06.2022 06:19Современные говнокодеры не понимают значения слова "оптимизация". Они считают, что если их божественный код не идёт на компе клиента - клиент должен поменять железо. Они никогда не пробовали что-нибудь написать на мк61. Про элиту отдельный разговор. Вот были программисты.
nmrulin
25.06.2022 23:51Вот примерно такая же тема. Я всё удивляюсь ,какие школьники пишут сохранения для игр , что они по 100 Мб занимают. При том что там максимум 1000-2000 параметров. Как-то сам опенсорсную игру писал. Там халтурное всё , и AI и графика и конечно же система сохранения. Но больше чем на 100 Кб всё равно они не занимали даже после нескольких часов игры(а по хорошему можно и в 10 Кб уместить). В общем как пишут сохранялки , чтобы они 100 Мб занимали, для меня так и осталось загадкой. Может быть просто дамп памяти сгружают в файл? Или надо ещё какой-то дзен познать, чтобы такие делать?
vconst
26.06.2022 13:25Ну если там мир разрушаемый и можно увидеть следы, оставленные первом первого уровня, два года назад? :)
nmrulin
26.06.2022 17:11Ну если разрушаемый, то да. Но я видел в Master of Orion 3 , там до 300мб сохранения. Хотя там 100 планет. Там максимум жителей 20, для каждого специализация - это байт. Ну ещё зданий 20, тип здания это ещё байт. Ну и всего параметров 100 максимум. Это 10 Кб. Ещё 10 Кб на флоты всех фракций.
В Total war Shogun где-то 15 Мб сохранение. В Thrones of Britania наняли уже студент и стало 7Мб , хотя информация для сохранения примерно такая же.
В шутере Quake 4 тоже 7Мб сохранение, я не помню, чтобы там особо был разрушаемые уровни.
PaulZi
26.06.2022 00:11+1Добавлю в копилку. Недавно был у нас проект, ничего экстра ординарного, несколько сущностей, UI в виде табличек, требований к дизайну особо не было. Совсем недавно всё это делалось одним человеком на Yii2+bootstrap3 за месяц максимум, и работало надёжно как лопата. Сейчас же всё это считается устаревшим, включая подходы к backend/frontend. Так вот, теперь такой проект пилили 4 месяца 2 отдельных front/back - программиста, всё по современному typescript/nestjs на бэке, spa/vue/quasar на фронте. Естественно всё это с кучей зависимостей, в докерах и т. д, напоминает супер-пупер навороченный мото-культиватор.
По итогу картошку лопатой выкопал один человек за день, а с мотокультиватором двое за четыре)
randomsimplenumber
26.06.2022 09:46-1Раньше можно было пойти в лес, поймать лису и сделать шубу бесплатно. А сейчас нужно подключить к созданию шубы кучу специалистов задорого. :)
Раз заказчик платит - значит, для него есть свои соображения, по каким технологиям создавать продукт. Или погонщики программистов таким образом подняли цену продукта. Должно быть рациональное объяснение.
vconst
26.06.2022 13:27Да-да, посмотрел бы я на вас, если бы вам выдали ружье, порох, вату на пыжи и кусок свинца на пули. Спички только в расширенном комплекте за донат. А потом отправили настрелять дцать лисиц, ибо из одной только шапка получится. Думаю, вы бы на третий день выползли к людям и стали просить еду :) Не подстрелив ни одной лисицы ))
egui
26.06.2022 06:19+1Сегодня оптимизация кода это что-то ругательное. Если уже мигание курсора нагружает цп на и задействует гпу. Потому что тестирование кода не на железе, которым будет пользоваться типичный юзер, а избыточно мощном. Плохо оптимизированный код на таком будет незаметен. https://habr.com/ru/post/402601/?ysclid=l4tq71gzl1147975540
maikuss
26.06.2022 06:19Я вот кино какое-то смотрел, там боевые машины восстали, а центральный взбунтовавшийся компьютер герои-люди так и не нашли. Потому что все было распределено по всем персоналкам в офисах . Вот так оно и есть. И во всех этих тысячах DLL, исходников которых живые люди не касались уже давно, и никто не помнит, кем и как они были написаны, располагается код SkyNet. Скоро бахнет )
IB2022
26.06.2022 09:24Каждый год 31 декабря мы ходим баню.Каждые полгода должна быть статья про нерациональное использование ресурсов: https://habr.com/ru/post/596517/Сам не кодер, но в универе было программирование. Грустно конечно.
Это тянет за собой такое же нерациональное использование материалов, из которых сделано железо, а многие из них редки и стоят недешево. Следующим вагоном сюда идет нерациональное использование труда по обслуживанию всего этого добра (софт, железо, генерация и поставка энергии). Ужас.
Есть тенденции не только в компьютерной техники. Набирают популярность различные универсальные блоки, функционал которых зависит от модели (лицензии), но при этом с технической стороны абсолютно идентичные.
netch80
26.06.2022 11:11+2> Каждые полгода должна быть статья про нерациональное использование ресурсов
И это хорошо. 1) Надо напоминать про эту проблему. 2) Надо напоминать на свежих примерах, чтобы не было «а что это за статья про необходимость сокращения на 5KB на RT-11?»
(Точно так же пишут новые детективы, чтобы не надо было переводить с языка Агаты Кристи или Эдгара По на современный.)IB2022
26.06.2022 12:26Именно поэтому во многом и появился этот комментарий)
Представьте, делается железка с производительностью на 10 функций, но в зависимости от того, куда ее запихнут или от оплаченной лицензии (не суть) будет выполнять меньшее количество функций. Такая практика с большой вероятностью может стать мейнстримом. С точки зрения разработчика такой железки это удобно. Покупатель все равно платит за всю железку + лицензию или внешний обвес. С точки зрения ресурсной базы и всем, что за эти тянется - беда.
JordanCpp
26.06.2022 12:35Это уже есть. Intel выкатила процы с возможностью разблокировки доп функционала при оплате. Думаю и другие компании со временем возьмут на вооружение.
netch80
26.06.2022 12:37А чего представлять-то? Практика давно известна и регулярно становилась мейнстримом в определённых суботраслях. Хакеры, правда, ломают эти ограничения, так что сейчас они работают в основном там, где разрешения регулярно подкачиваются из центра и авторизованы с подписями.
Но при этом вполне возможен вариант типа «купили фичу — качается библиотека её реализации»… не обязательно же всё сразу хранить.
(В железе — да, уже должно быть поставлено)
Ndochp
26.06.2022 19:33rigol ds1054z О нем пишете? Полоса пропускания вырастает вдвое после взлома, плюс куча демо обработчиков, доступных сутки, если память не изменяет. Понравился — оплати лицензию.
IB2022
27.06.2022 09:20В целом про ситуация. Можно поискать примеры, но особо смысла нет.
Мне кажется, что могут появится такого плана устройства, которые будут очень массовыми.
Ndochp
27.06.2022 09:31Так они уже есть. А если сделать шаг вниз — они есть массово и давно. Как только вы ставите универсальный процессор для того, чтобы "мигать лампочками" вы оказываетесь именно в этой ситуации. Правда цена у производителя обычно фиксированная.
Но это все равно именно то, о чем вы пишете. Просто микросхема очевидно дешевле рассыпухи, а универсальный процессор дешевле специализированной микросхемы. Так что ничего плохого я в этом не вижу.IB2022
27.06.2022 11:16Отчасти видимо так. Но изначально речь шла все-таки об устройствах, которые могут делать больше того, для чего используются фактически. Универсальность все-таки не совсем то и в где-то более, где-то менее, но эффективна.
JordanCpp
26.06.2022 12:46+1Я за. Больше статей, хороших и разных. Сам писал похожую статью. Потому, что накипело. Проблема есть и ее не скроешь.
TorVV
26.06.2022 20:43Наша ДНК так же накопила избыточный код. Практически все одинаково, сплошные аналогии по всем компетенциям этих проектов. Грех не воспользоваться опытом...
Brakomes
26.06.2022 20:43Предлагаю эту проблему назвать "Проблемой французских писарей". Есть легенда объясняющая, почему во французских словах в написании присутствует гораздо больше букв, чем произносится (иногда из 5ти букв произносится всего один звук) - в древности, когда грамотных было крайне мало, а бумажные документы уже были в обороте, писари брали с клиентов мзду за каждую букву. Так и накручивали неплохие суммы за написание простеньких текстов. Хитрожопые надутые индюки))). Это, конечно, лишь домыслы, но вполне логичные.
zkutch
26.06.2022 20:55Кстати, насколько помню, Дюма в д'артаньяне платили за количество строк (как некоторым програмистам) и появился у него Гримо. Слуга который мало говорил, но строчки рожал. А уже в десять лет спустя платить стали по количеству слов - и Гримо заговорил, но, может-быть у него это было возрастное. Так, что французский след подтверждается.
Можно, также, назвать синдромом Дюма.
ptr128
27.06.2022 00:48Если быть точнее, то оригинальная версия Elite занимала всего 22КБ. А вот ее версия для ZX Spectrum потолстела почти в два раза - до 40КБ. Но зато было добавлено множество разных звездолётов противников.
Infra_HDC
27.06.2022 00:59Тема довольно стара, но от этого не менее актуальна и сейчас.
Помнится, в конце 90-х ... начале 2000-х был подслушан разговор на одной из выставок, двух экспертов-программистов. Суть была в том, что в большинстве случаев, что на тот момент в объектах (ООП) не используются все свойства и методы, а именно используются в среднем всего несколько килобайт из тех сотен килобайт, которые есть у экземпляра класса.
Tarakanator
27.06.2022 08:48У меня есть пример покруче. Чтобы выключить подсветку видеокарты aorus (торговая марка gigabyte) нужно поставить 0.5гб софта. При чём его нельзя удалять т.к. при некорректном выключении компа подсветка опять включается.
JordanCpp
27.06.2022 10:47Забавно. А сколько весит установщик? И сколько занимает установленная утилита?
Tarakanator
27.06.2022 11:12Установшик RGBFusion2.0 253мб.
В установке и удалении программ пишет 170мб занимает.
Откуда я взял 0.5 гб не помню, там 2 варианта:
1)возможно оно писало это при установке.
2)На самом деле там нужны 2 утилиты, при чём 2-я раньше как я понял была отдельной, а потом стала плагином к первой. Возможно 0.5гб это с плагином или со 2-й утилитой или это суммарный объём установщиков.
Уже не помню точно, с документацией беда, ставил методом тыка разными способами.JordanCpp
27.06.2022 11:28Скачаю утилиту, распакую и посмотрю, что внутри. Отпишусь в тему.
Tarakanator
27.06.2022 11:37Насколько я помню правильная установка это когда ставишь утилиту, уже в ней пытаешься зайти в управление подсветкой видеокарты, и тогда она сама качает плагин для видеокарт.
milast
27.06.2022 10:24Может проблема ещё кроется в том, что бизнес требует работающего решения здесь и сейчас? И разработчику проще подключить готовую библиотеку, в которой нужна только 1 функция из 50, но это позволит уложиться в сроки.
JordanCpp
27.06.2022 10:55Не 1 из 50, а 1 из 5000. Условия рынка диктуют правила. Ответ, очевиден и возможно, безальтернативен. Если бы не рост производительности, было бы все намного экономичнее. И причем укладывались и в текущие сроки. Выработали инструменты, подходы и т.д
UtrobinMV
Переходи на Linux, в частности я работаю на xUbuntu 20.04. Там намного экономней расходуются ресурсы. Проблему, что вы описываете не так ощущается. На простеньком целерончике данная система работает вероятно быстрее и отзывчивее, чем Винда на мощном железе с внешней видеокартой!
Viacheslav01
Вполне проявляется, достаточно попробовать собрать любой опенсоурс проект, он тут же потянет к себе миллиарды таких же опенсорсных библиотек. Из которых многие нужны только ради одной двух функций.
А та же винда 10 у меня работает на 12 летнем деле и ей нормально )
UtrobinMV
Зачем собрать опенсорс проект, если все можно поставить из готовых пакетов?
"он тут же потянет к себе миллиарды таких же опенсорсных библиотек" давайте на примере разберем, что именно вы собираете, и что у вас там подтягиватся под Linux?
ST4NN
А в готовом пакете бинарники, простите, собраны из чего? Не из такого же сонма инклюдов, на уровне исходников, а в скомпилированном виде всё равно тянущие зависимости от внешних бинарников от прочих библиотек? И всё это прыгает по экспоненте сall-ов. Если бы не SSD, доступная оперативка, и аппаратные инструкции в процессорах и их многопоточность, работа компьютеров под управлением любой современной ОС была бы печальным зрелищем.
Woodroof
По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужна.
На других системах тот же ICU системный так просто не заиспользуешь, и люди тянут свой, а это 30 МиБ только ресурсов (можно собрать урезанные для части локалей, но всё же), не считая мегабайтов самого кода. Потом curl (полмегабайта), openssl (более мегабайта), libpng и прочие аналогичные, zlib, OpenAL...
И ведь всё это не будешь самостоятельно писать (и лучше и не надо, без того же ICU почти наверняка локализация будет неправильной).
SergeyMax
И сразу получаем DLL Hell в полный рост.
Woodroof
DLL hell — это всё же windows-специфичная проблема. Ад зависимостей может существовать и в linux'е, но для библиотек как правило всё хорошо. Да и разные мажорные версии утилит обычно могут быть установлены одновременно (тот же python).
iig
2 разные версии openssl, или libjpeg без танцев с бубном я бы не ставил.
Clock_Source
Прямо сейчас:
dev-libs/openssl-1.1.1o - для современных приложений
dev-libs/openssl-compat-1.0.2u-r2 для старья. после окончательного перехода старья на новые либы (или выпиливания оного в пользу более нового функционального аналога) compat версия с очередным обновлением будет выпилена из системы. C libjpeg чуть иначе, но в целом ровно то же самое.
Установка штатная, танцев с бубном не наблюдается, обновление централизованное и штатное. Посчитаем сколько версий libjpeg в венде, проследим как, когда и чем они обновляются?
netch80
А зачем сравнивать с виндой? Что будет, если libbuka захочет новую SSL, libzuka — старую, и потребуется слинковать приложение с обеими?
SergeyMax
Только из-за аббревиатуры DLL, а не из-за принципа работы.
vconst
Скажите это Каноникал, которая везде продвигает Snap
UtrobinMV
Если вам не нравится Snap. Дело буквально двух команд.
Вот статья.
https://losst.ru/kak-udalit-snap-paket
Лично я сам удаляю на слабых машинах.
В snap насамом деле есть и плюсы и минусы. С одной стороны это контейнеризация, примерно как в docker. С другой стороны большее потребление ресурсов в совокупности с накладными расходами.
Самое главное, что это как опция, хочешь пользушься, хочешь отключаешь.
vconst
Ну как сказать — опция. В современном гуи убунты это основной способ установки приложений. Конечно, никто не запрещает написать apt install, но встроенный менеджер приложений устанавливает именно через snap
Nasreddin_Hodja
Ну а что разработчики должны, вместо того чтобы использовать, например, libpng, писать свою собственную альтернативу этой библиотеки и юзать её? Так проблему это тоже не решит, просто вместо libpng будет свой велосипед.
Только у автора скорее проблема с bloated приложениями на фреймворках типа Electron, а не из-за dll'ок. Так-то это нормально использовать для определённой функции какую-то библиотеку, реализующую конкретную функцию.
PsyHaSTe
Миллиарды опенсорс библиотек это хорошо. Главное чтобы LTO работало.
Пусть в мире будет одна Идеальная Быстрая сортировка, Идеальный способ открыть файл, Идеальный способ отправить емейл через SMTP. И пусть этот идеальный способ экспортируется и распространяется как библиотека. Это приводит к тысячам библиотек? Да, и что плохого? Это неприятие велосипедов возведенное в абсолют. Это прекрасное будущее где ты создаешь только код который никто до тебя в мире ещё не написал, а потом им пользуются миллионы других разработчиков по всему миру.
Немного утопично, но это куда ближе к хорошему чем "если это реализовывать меньше 80 часов то напишем свой велосипед".
extempl
Для этого в опенсорсе должна быть модерация и голосование, какой пакет принять за основной. А потом основная библиотека перестаёт поддерживаться, появляются форки, и… ну вы поняли, было 11 стандартов, решили стандартизировать их все - теперь 12 стандартов.
А ещё основные библиотеки точно так же жиреют со временем в попытках сохранить обратную совместимость и вообще в экономии времени на оптимизацию, так что легковесные аналоги появляются и есть буквально для всего. И это не плохо, это, своего рода, конкуренция (хотя в опенсорсе… конкуренция?), но ни о каком "едином стандарте" речи быть не может.
А ещё мейнтейнерское "я так вижу, хотите свою фичу в моём пакете - делайте форк".
А ещё… продолжать можно долго.
Dorval
Идеальная Быстрая сортировка?
У вас может быть задача отсортировать данные, которые помещаются в память, а может быть задача про данные, которые не помещаются в память, надо тогда работать с диском или ещё с каким-то хранилищем. И вот у нас уже две Идеальные Быстрые сортировки.
PsyHaSTe
Данные которые не помещаются в паять не надо сортировать Быстрой, для этого есть другие способы. Так что это не проблема, да — кубики лего должны быть одинаковыми и хорошо сделанными.
netch80
Есть 100500 других особенностей. Где-то крайне дорог или невозможен обмен местами элементов. Где-то — очень дорогое сравнение, нельзя терять его результат, а конкретная реализация Идеальной Быстрой Сортировки проверяет только на <, а не на <=>. Где-то нужно уметь сортировать при наличии несравнимых элементов, несмотря на формальный запрет таковых (привет, float), где-то нет.
Говорить про пригодную для 99% случаев версию — ещё можно. Для всегда — нельзя.
PsyHaSTe
Быстрая сортировка без обмена элементов существовать не может — это заложенно в её основе. Сравнение с несравнимых элементов — это так же не быстрая сортировка а видимо что-то типа NullQuickSort которая сначала выполняет некоторую логику (сдвигает нуллы куда-то), а потом уже сортирует оставшуюся часть нашей Идеальной Быстрой Сортировкой.
Так что как раз получается, что по опредлению такой алгоритм будет единственным, и уже поверх него можно городить доп. логику. Это и есть задача программиста. Взять готовый кубик (рабочую сортировку на множестве с определенным сравнением), и навесить на него сортировку флоатов.
netch80
> Быстрая сортировка без обмена элементов существовать не может — это заложенно в её основе.
Любая сортировка может быть сделана без обмена созданием массива индексов/указателей и перестановкой этих указателей вместо самих элементов. И это не зависит от того, она «быстрая», пузырёк или что-то другое.
> Сравнение с несравнимых элементов — это так же не быстрая сортировка а видимо что-то типа NullQuickSort
Возьмите массив float'ов, заполните случайными значениями и растыкайте среди них, например, процентов 10 NaNʼов. Дальше отсортируйте разными алгоритмами и посмотрите на результат. Получаются весьма забавные зависимости от подхода. Некоторые реализации вообще крэшатся на этом, но все известные мне сортировки из стандартных библиотек C и C++ выживают.
А вот Rust просто откажется такое компилировать — трейт floatʼа не помечен как допускающий total order.
0xd34df00d
Да, это прекрасно.
А это — нет.
AnthonyMikh
0xd34df00d
Сразу ответственность какая-то, хотят что-то. Да ну нафиг, я попенсорс по фану пишу.
PsyHaSTe
Ну вот, опять докопался до формализма необходимости/достаточности :(
simafrus
А потом библиотека, подтягивающая другие библиотеки вместе с другой многоколенной библиотекой подтягиваются в сто пятую библиотеку. И вот уже экспоненциальный рост пожирания ресурсов обгоняет технологический прогресс, а еще чуть позже на неописуемой скорости врезается своей огромной массой в нерушимый потолок физических ограничений. Все, закон Мура не действует, производители больше не могут наращивать производительность на единицу процессорной площади. И придётся все переписывать заново, зато не изобретали велосипед
PsyHaSTe
У вас от библиотек производительность будет лучше, а не хуже. Попробуйте собрать любое раст приложение — там в реальной аппке на пару тыщ строк вероятон будет пара сотен транзитивных зависимостей. Попробуйте теперь сказать, что код получился медленным и раст тормозит.
JordanCpp
Для удаленки взял свой старый медиацентр. Что бы не занимать ноутбук. Athlon x4 640. Добил до 8гб + ssd. Поставил, windows 10 и lubuntu lts последнюю. Все же lubuntu побыстрее и меньший жор ОЗУ. И не так часто вижу в top'e загрузку проца под 100%. Серфинг одинаков на обоих осях.
sena
Я бы разбил проблему на части
Разделяемые библиотеки
Разделяемые библиотеки как раз и созданы для того чтобы избежать дублицирования кода, поэтому ничего плохого в их использовании нет. Но для того чтобы этот потенциал был реализован более полно, нужно чтобы (1) их лицензия позволяла программам в системе их использование и (2) программы были собраны именно с установленными в системе версиями библиотек, а не требовали другие версии. В случае дистрибутивов Линукса, казалось бы, эти условия выполняются чаще и лучше.
Но это преимущество имеет, правда, и свои негативные стороны. Например, когда в дистрибутиве десятки тысяч программных пакетов, обновление программы имеющей сотни зависимостей становится достаточно сложным, особенно для программ с несвободной лицензией. И чтобы решить эту проблему придумали всякие snap и flatpak, что полностью нивелирует преимущества разделяемых библиотек, то есть как раз в области, в которой дистрибутивы Линукс могут проявить себя лучше.
Умножение системных процессов.
В системах на основе Линукс, как и в Виндосе множатся и плодятся системные процессы. Причём почему-то с каждой новой версией они становятся всё более прожорливыми, пожирая память и процессор. Я уже смирился, что даже в Линуксе какой-то демон, ответственный за вывод звука иногда может есть процессорное время даже когда никакого звука в системе не проигрывается. Конечно, это пока это не дошло до крайностей, описанных в статье, но надо признать, тенденция в Линуксе такая же как и в Виндос.
Раздутые приложения-монстры
Некоторые приложения со временем растут, пока не превращаются в монстров которые содержат в себе ещё одну собственную операционную систему (иногда две или больше). Кажется что в конце-концов они должны погибнуть под тоннами собственного неподдерживаемого кода. Но они почему-то никак не погибают. Яркий пример - браузеры.
Приложения на электроне
Эта беда проникла как в Виндос, так и в Линукс и здесь Линукс ничем не отличается от Виндос. Это просто фабрика монстров.
Список можно продолжать. Но ясно что беда затронула и Виндос и Линукс.
JohnSelfiedarum
Господин не прав. Днесь пытался найти на ноутбук HP6110 с 32-разрядным процессором вменяемое ПО, при наличии 2-х гигов памяти. К удивлению своему - НИЧЕГО! Ничего, что бы вменяемо работало с Интернетом. Даже маленький Alpine - и тот уже не торт.
Пробовал множество линуксов.
Однако старая версия Runtu движется быстро и хорошо - прекрасна во всех отношениях - но не открывает современные сайты, и поэтому бесполезна...
Kekmefek
Мне кажется тут дело немножко в другом.
Попробуйте firefox + umatrix.
UtrobinMV
Вы про Alpine, а я про хUbuntu. У xUbuntu сообщество в сотни раз больше.
"Пробовал множество линуксов." Зачем пробовать, поставьте один вроде xUbuntu, и работайте. Хватит пробовать. Я вот запустил и работаю, уже лет 10
darthmaul
А чем Вам ОСь поможет то? Проблема в том, что сами сайты состоят из говнокода чуть более чем полностью и одна страница "весит" сотню мегабайт. Это на стороне сервера оптимизировать надо, иначе никак.
UtrobinMV
Потому что ОС, это основа всего. Если сама ОС вроде Виндовс, жрет памяти немеряно, то что останется на все остальное?
В Linux есть дистрибутивы например xUbuntu, которые очень легкие, и работают одинакого быстро и на простом железе и на хорошем.
hyperwolf
Еще раз. Если с сервера в браузер приезжает жирный js-код, который выполняется на вашем процессоре, то не очень принципиально, сколько ест система, обычно это единицы процентов ресурсов процессора.
speshuric
XUbuntu жрёт 600-1000 МБ просто загрузившись, для хоть какой-то работы ей надо 2 ГБ. WinNT Workstation запускалась и работала на 64 МБ, Win2K на 128, WinXP на 256. Ну, ОК, это не совсем честно, потому что NT/2K/XP были 32-битные, банально для CALL по полному адресу надо адрес 64-битный, но разница даже с WinXP в 8 раз. Справедливости ради - рабочая станция на Linux всё-таки больше условных 1-2 ГБ "сразу после загрузки" не съедает (тайловые ВМ - 0,5, голый KDE/xfce - 0,7-0,9, гном с навесами 1,2), а Win10/11 - запросто 3-4.
Ну и, да, согласен с @hyperwolf- основные ресурсы съедаются не голой машиной, а приложениями на ней. Браузер, IDEA, VSCode и куча других приложений съедают примерно одинаково (много) почти независимо от ОС. Да вот пример прямо в углу монитора у меня: Jetbrains Toolbox. Ёлы-палы, это же приложеньице для загрузки и обновления IDE. Оно съедает 200-500 МБ оперативной памяти. Штоа? Как это? Зачем? Ладно, у меня 48 ГБ в одной машине и 128 ГБ в другой и я почти смирился с тулбоксом, но всё-таки, я всё еще помню время, когда на сервере СУБД (СУБД, Карл!) в моей организации было меньше памяти, чем жрёт эта иконка в трее (то, что у тулбокса нет CLI раздражает больше).
andreymal
Ну, не совсем запросто
petuhov_k
Продукты JetBrains невероятно прожорливы. Ещё пару-тройку лет назад пересадили компанию на Rider при моем же участии. А на днях мне пришлось работать на докрымском ноуте. Райдер не смог. Он сожрал весь проц, разогрел его и дико тормозил на простом вводе текста. Запустил VisualStudio и на том же проекте смог комфортно работать. Был удивлен и много думал о том, стоит ли продлять лицензии.
DistortNeo
Rider — молодец, умеет в многопоточность. На мощных системах он работает гораздо шустрее студии.
vconst
Я ненастоящий программер, но мне кажется — что у JB наиболее адекватная автоподстановка, уровня «я бы сам почти так думал подставить»
petuhov_k
Так было. Мы сидели на решарпере, потом на райдере. Но время идёт, vs2022 просто дописывает всю строку кода за меня, невероятные подстановки. MS не стоит на месте, в отличие от. То, что предлагает райдер, в половине случаев приходится удалять. Ну и глюки эти вечные, при этом трудновоспроизводимые.
UtrobinMV
xUbuntu есть 400 мегабайт после старта!
"600-1000 МБ" Откуда вы такие цифры получили? И где вы нашли WinNT Workstation? Давайте с Windows 10 сравним, или с Windows 11.
"WinNT Workstation" - операционка которой уже больше 10 лет не существует, и на любом железе современном вы даже не запустите.
JordanCpp
В таком случае нужен дистр минимально потребляющий ОЗУ. Что бы по серфинг оставить максимальное возможное количество памяти из 2-ух гигов.
engine9
У меня mint (xfce) вполне норм работает на eeePC c 2 Gb и 900 МГц "целероне", тянет офис и браузер, даже ютубчик в низком качестве при желании можно посмотреть. Разумеется я им не пользуюсь в повседневной практике, нет смысла никакого. Но как читалка, компактная печатная машинка, аудиоплеер, вполне норм.
UtrobinMV
Вот если все это поставить на нормальный комп! Сколько экономии в ресурсах произойдет, по сравнению с перегруженными системами. У меня стоит xUbuntu с xfce, все летает, никаких тормозов. Софт по сути одинаков везде. На xUbuntu стоят все те же программы, только ресурсов больше свободных.
askharitonov
А какой был графический интерфейс? Я как-то разбирался, как ускорить работу Linux на старом компьютере, и обнаружил, что очень много ресурсов забирал на себя tracker, программа для индексации файлов. Причём вроде он работал даже если я использовал другое окружение рабочего стола. То есть, по сути компьютер работал бы быстрее, если бы я при установке просто убрал галочку напротив GNOME. Но, повторюсь, это касалось довольно старого компьютера, по логике вещей tracker нужен для того, чтобы ускорить работу (чтобы поиск был быстрее).
vconst
А ЗАЧЕМ на это старое говно пытаться что-то натянуть, как сову на глобус?
2005 год, простой Пентиум, да еще и М. Какие невероятные достоинства имеет конкретно этот ноут, чтобы пытаться им пользоваться? Его даже компактным не назвать, он весит почти ТРИ КИЛО, с отвратной TN-матрицей нижайшего разрешения. Его клавиатура тоже не представляет из себя — ничего особенного.
Практически по цене самовывоза можно найти ноут на Core2Duo и он будет отлично справляться с функциями пишушей машинки.
cepera_ang
Современный ноут будет где-то 50х быстрее по процу, 100х быстрее по видяхе, в бесконечность раз быстрее/экономичнее по всяким видеокодекам, в 100х быстрее чтение/запись по диску (а задержки в 10000х быстрее). Конечно современный софт будет тормозить, ведь никто не будет оптимизировать быстрее пусть будет 1/10 секунды на операцию на современном железе, что превратится на старом в 10 секунд :)
vconst
То есть — ничего удивительного в том, что оно все унылое и еле шевелится :)
cepera_ang
Но ведь девяносто восьмая винда на нём летала бы!
vconst
Так пускай запускает на нем 98ю винду :)
JordanCpp
Для эксперимента советую antix. Возможно взлетит.
vconst
Надо просто выкинуть это древнее говно, а не пытаться заниматься с ним роскомпозором. Ноут на Core2Duo можно купить тысяч за 5, который будет на порядки быстрее этого мрака мрачного на пне-м
JordanCpp
Возможно автору нравится копаться в старом железе. И пытаться их восстановить для текущих задач. Почему нет:)
vconst
Тогда бы он знал — чего ждать от этой рухляди и не жаловался бы тут ))
JordanCpp
Не такая уж и рухлядь. Смотрите на производительность одного ядра.
vconst
Толку от одного ядра, когда оно все в целом работает, включая hdd и 2 гига оперативки
В том ноуте проц вот такой: www.cpubenchmark.net/compare/Intel-Pentium-M-1.73GHz-vs-Intel-Core2-Duo-E8290/1160vs1790
Сравнил с типичным ноутным кор2дуо
JordanCpp
Не обратил внимание просто смотрел массовый проц core2duo. Производительность конечно всратенькая:)
cepera_ang
Это сравнение чего с чем? :)
vconst
Ноутный проц отсюда: habr.com/ru/post/673236/#comment_24468614
«ноутбук HP6110»
И моя рекомендация купить печатную машинку на c2d
cepera_ang
Так E5500 — это же и есть корка, да ещё и десктопная.
vconst
Но я то сравнивал ноут на старом пне, и к2д
Почитайте камент и посмотрите из чего тот ноут сделан
При чем тут райзен?
cepera_ang
Вот и я спрашиваю — чего JordanCpp с чем сравнивает :)
vconst
Я без понятия) Спросил его о том же)
JordanCpp
Перепутал я. Просто взял массовый проц core2duo. А нужно срравеивать с pentium m.
JordanCpp
Говорили о проце pentium m. Но если сравнивать с десктопным e5500 производительность вполне себе. Но для серфинга будет боль.
vconst
Надо сравнивать сравнимое. Средненький ноут на пентиум-м и средний ноут на к2д
Посыл то был в том, чтобы выкинуть эту рухлядь, дорогую как память — и купить б/у, но на к2д. Там совсем другая архитектура и она на порядки быстрее того старого пня, а всех делов — 5к деревянных
cepera_ang
А лучше конечно брать нормальный десятилетний ноут, если совсем уж не хватает на нормальный трёхлетний. Причём брать из топовой линейки, потому что старье всё одинаково стоит. Какой-нибудь x220 — он конечно уже напрягает (даже с 16гб памяти и ссд) по сравнению с современными ноутбуками, но для того, кому пентиум м хорош — будет просто бомба :)
vconst
Потому я выбрал х260, 16 памяти, ссд — очень приятственно работается. Если чисто серфинг, то 11 часов выдерживает, а еще есть увеличенный внешний акк в запасе. Еще и матрицу воткнул в него 1080
х220-40 довольно унылы, там заметно устаревшее железо, а 270 и выше — уже профанация, откровенно неудачные модели, сильно перегревающиеся и вообще не оптимальны. Убили такое приятное семейство, закачивая в него мощности больше, чем нужно.
cepera_ang
А я уже думаю отринуть любовь к старью и взять что-нибудь типа Asus Zenbook 13 OLED на 6800…
vconst
Вопрос целесообразности, мне не нужен мощный ноут.
Для фотошопа у меня десктоп есть и с покупкой ноута я его почти перестал включать. Разве что в пубг погоняться, развеяться
cepera_ang
Десктоп остался в далёкой России, кочевая жизнь требует мощности и лёгкости.
vconst
Ну, у меня пока так не получается…
DistortNeo
Не соглашусь насчёт экономного расходования ресурсов. Отличие Linux только в том, что там принято ставить зависимости общими пакетами, а не тащить их каждый раз с собой. Ну да, небольшая экономия места на диске, но память всё так же будет забиваться.
Также добавлю тенденцию пихать всё в snap и в docker.
UtrobinMV
Предлагаю сравнить скрины по количеству забитой и свободной памяти? На реальных примерах.
DistortNeo
На примерах чего именно?
Вообще, меня больше напрягает Telegram, который аж больше 1 гига жрёт.
UtrobinMV
Не знаю, что за дистрибутив а у меня вот так. И это xUbuntu. Сама ОС, практически ничего не ест, и отзывы мгновенные. Причем куча свободной памяти, и работает на Целероне
.
Hlad
Правильно ли я понял, что на экране мы видим 4 ядра и 8 гигов оперативы, как доказательство того, что «этот линукс летает даже на простеньком целерончике»?
UtrobinMV
Все верно. Легкий дистрибутив и куча свободных ресурсов. Не перегруженность графиков. Вот основа быстрой и оптимальной системы.
Hlad
Я могу в ответ скрин со своего компа скинуть. Там тоже будет куча свободных ресурсов и не перегруженность графиков. Получится, что Windows 10 — офигенно лёгкий дистрибутив.
Dolios
У меня i7, 32 оперативы и 2 ssd.На одном стоит минт с синнамоном, на втором в дуалбуте вин 10. Так вот, вин 10 по сравнению с линухом тормозит. Тормозит безбожно. После загрузки в нее минут 5 надо погулять, чтобы она там что-то себе пошуршала и начала, наконец, хоть как-то работать. Но даже после такой паузы работать в винде гораздо менее комфортно. Я даже не могу сказать что конкретно не так, просто какие-то раздражающие микрофризы, которые в целом создают ощущение, что "все тормозит" по сравнению с линухом. Например, запустил простую программу, а она не мгновенно запустилась, а через несколько секунд и т.д, Железо, я напоминаю, одно и тоже и совсем не слабое.
DistortNeo
Попробуйте отключить антивирус.
Dolios
Я не использую антивирусное ПО.
DrPass
Если вы ставили Windows 10, и не тюнинговали систему после установки, то используете :)
vconst
Снести винду и поставить все заново. Стандартный совет для таких вещей. Можно даже не обычную винду, а LTSC — оно и места меньше займет, и куче всяких украшалок крутить в фоне не будет
Но чисто отклик интерфейса — у линукс всегда будет лучше. Винда и Макос выглядят тормознутыми часто именно из-за микро-фризов интерфейса, а не самих программ.
cepera_ang
Только наоборот, это в линуксе постоянные микрофризы :)
vconst
Мой опыт показывает обратное. Отзывчивость интерфейса у линухов замечательная, винда и мсакось подлагивают. К этому привыкаешь, пока не пересаживаешься за линь и замечаешь разницу
cepera_ang
Ну вот, а мой опыт говорит обратное. Хотя может это как обычно был неправильный линукс (убунта). И помню эпический баттл каноникал за оптимизацию гнома, чтобы не было статтера хотя бы на быстрых машинах и как этому сопротивлялись мейнтейнеры, которым всё было норм, а тут пришёл какой-то корпорат и начал вливать непонятные патчи с оптимизациями.
vconst
Тоже убунта. Все чуть быстрее, отрисовка окошек, элементов интерфейса, тп
cepera_ang
Ну хз, может быть моей 1080ti сильно нехватало (фак нвидия, все дела), но даже при анимации стартового меню были затыки. А на винду вернулся и прям ощущение, как при отключении двойной буферизации в старых играх — лёгкая резиновость пропадает.
V1RuS
зависит от настроек ядра:
а еще, возможно, от оконного менеджера/композера и видеодрайверов.
cepera_ang
Да не, там было много интересного на горячем пути однопоточного рендерера плюс код, который оптимизировали локально, но над циклом отрисовки в целом никогда толком не задумывался и случалось всякое, когда код, который уложился бы во время кадра не начинал работу, а ждал лишний кадр и т.д.
0xd34df00d
Не могу ничего сказать, кроме «УМВР», что на ещё более старой 980, что на встройке у кастрированного U-шного скайлейка, что у какого-то 11-летнего core 2 (но я его последний раз года три назад включал).
Но да, не убунта и кеды вместо гнома.
Lapk
у нас десктоп на убунте/минте тормозит больше, чем на вин10. Астра на дебиане и флай дм - летает на том же железе
JordanCpp
Я от гнома отказался в самом начале перехода на linux. Мне нравится lxqt. Жручесть меньше. Скорость выше.
JordanCpp
Согласен. Жирный плюс, что можно поставить любую DE.
UtrobinMV
Микрофризы в Linux у тех, кто его запускается чтобы посмотреть через виртуальную машину из другой Операционной системы :)
Но даже если так. поставьте в виртулке xUbuntu. Даже в виртуалке думаю фризов вы не заметите. Что говорить, про реальную установку, космос!
Massacre
Если 7ка поддерживает то железо, можно для интереса сравнить и её :)
Ну а так, ниже правильно написали, если нужна 10ка, лучше взять LTSC — по дефолту там меньше всякого ненужного запущено. У винды ещё с XP была замечена тенденция по дефолту загружать разную блотварь, включая некоторые службы, но оно всё отключаемо.
kin4stat
У вас какой-то неправильный ssd видимо, или может ОЗУ. Тоже i7, тоже 2ssd, и тоже 32 гига озу. 17 секунд и уже можно пользоваться. Где вы 5 минут умудрились найти? У меня даже виртуальная машина образ которой на HDD стоит, грузится минуты 2.
xsevenbeta
У меня даже на старом, не самом быстром SSD всё летало - грузилось полминуты, а потому сразу в бой. 5 минут это только на старых HDD винда могла себя так вести.
UtrobinMV
Скиньте, мы посмотрим.
Chupaka
Там ещё аптайм чуть больше минуты — может, не всё прогрузилось :)
DistortNeo
Не, ну если я вместо KDE поставлю Xfce4, памяти тоже побольше свободной будет.
Но смысл?
UtrobinMV
Смысл примерно тот о чем пишут в статье. Компактный дистрибутив, компактное ПО, вот один из идеальных примеров, того как должен выглядеть софт, и прекрасно работать даже на слабом железе. Не потреблять излишнее количество ресурсов, память ГПУ и т.д.
DistortNeo
Ради интереса перегрузился в Xfce. Потребление оперативной памяти снизилось на полгига, потребление видеопамяти же, наоборот, выросло на полгига. Интересно, почему?
UtrobinMV
Скрин пришлите, из приложения nvtop? У меня xfce не расходует видеопамяти совсем. Там будет видно какие процессы едят видеопамять и сколько.
DistortNeo
Xfce: https://hsto.org/webt/2v/18/2u/2v182upjcjmxle5dkiiey450rqc.png
KDE: https://habrastorage.org/webt/hz/g9/s7/hzg9s7nfyi_twhjvcogwvy4qhpa.png
andreymal
Какой-то странный скриншот у вас, хотя бы один процесс Xorg обязательно должен быть. Это случайно не ноутбук со встройкой и оптимусом каким-нибудь?
Breathe_the_pressure
Thunderbird = 497 Мб, верните мой
2007The bat! :)Hlad
Outlook express из Windows 98 вполне закрывала все задачи электронной почты. Надо будет поставить на виртуалку, и проверить, насколько она актуальна сейчас…
DrPass
Угу, кроме безопасности.
gapsf
SSL/TLS.
Без шифрования ничего нынче не работает, хотя оно и нахрен не сдалось, ибо кому надо тевсе равно имеют доступ ко всему что передается и хранится.
Balling
Как раз к передается доступа нет.
UtrobinMV
Давайте я вам пример приведу, из той же категории. Claws Mail - легковесный почтовик. Не требует ресурсы. До сих пор поддерживается и обновляется, работает под Linux, и не только.
Balling
И как вы на нем будете открывать динамические письма с кнопками и анимацией?
Massacre
Вообще, выполнение скриптов в почте — не очень хорошо для безопасности…
randomsimplenumber
А в браузере можно?
vconst
В браузере — песочница
vladkorotnev
Кнопкой "Send to Trash", ибо ничего полезного в таких письмах по определению не приходит :-)
А вообще, он умеет в браузере HTML-письма открывать, что зачастую куда удобнее (и безопаснее), чем в почтовике.
Balling
А вы уверены, что браузер поддерживает динамические письма?
Cerberuser
А что в них может присутствовать, кроме тройки HTML+CSS+JS? Вопрос без подвоха, я действительно исходил из того, что тело письма - это всегда не более чем веб-страница.
Balling
Технология называется AMP for gmail.
MIME text-x-amphtml
https://amp.gmail.dev/playground/
Cerberuser
https://developers.google.com/gmail/ampemail/supported-platforms
Ну и, если уж на то пошло, кто может быть уверен, что почтовый клиент будет поддерживать ту или иную проприетарную технологию (если, конечно, это не клиент от владельцев технологии)?
DistortNeo
Не туда смотрите, 497М — это только shared mem, а есть ещё resident на 1082М.
И да, Thunderbird — это, по сути, браузер.
DrPass
А у меня Аутлук. Который не экспресс, а обычный, и более-менее современный, с календариками/планировщиками там всякими, хорошей интеграцией с другим софтом и т.д. Открыто два ящика на 5 гигов писем каждый, жрёт 65 метров памяти, 170 зарезервировано. Работает мгновенно. Старая школа :)
UtrobinMV
Предлагаю обмениваться не на словах, а прямо скринами с монитором ресурсов из вашей операционной системы, где в целом видно сколько памяти всего, сколько ест операционная система, сколько все остальное вроде Оутлуга. и будем сравнивать.
DrPass
У меня на компе работает Visual Studio, три мессенджера, три сотни вкладок браузера, две виртуальные машины с убунтами и докер, а, ещё недоигранный Cyberpunk 2077 свёрнутый в фоне лежит. Что вы у меня сравнить сможете?
С точки зрения быстродействия как раз интересуют конкретные приложения. Голая операционная система жрёт несущественно, даже Windows 11. Но как только вы к ней, или к вашей xUbuntu добавите банально браузер, всё сразу поменяется.
UtrobinMV
"несущественно, даже Windows 11" - это 3 гигабайта, несущественно? или сколько.
Вот xUbuntu ест 400 мегабайт после старта. А дальше навешиваются приложуши. Давайте сравним кто больше ресурсов ест.
Я предлагаю фактами обмениваться!
DrPass
Ну так в Win 11 из той пары-тройки гигабайт, которые она жрёт после старта, минимум половина — тоже необязательный софт. Выключите виджеты, антивирус, визуальные эффекты, всякие фоновые приложения, Teams, OneDrive и прочее барахло, и будет у вас ну не 400 метров, но под гигабайт вы её покромсаете. Больше — тоже можно, но уже ценой функциональности системы.
… но показывать вам я это не буду, потому что на это надо время тратить, а я не настолько хочу вас переспорить ;)
code07734
Это видимо ошибка какая-то. Наблюдал как память утекает в телеграм в Arch'е. В винде прямо сейчас - давно уже включенный телеграм 28mb занимает
andreymal
Виндовый диспетчер задач показывает какую-то странную память, по ощущениям сильно далёкую от «реальности». Возможно, лучше смотреть какой-нибудь «рабочий набор» (но не уверен, там всё сложно)
code07734
Действительно, посмотрел в Process Hacker. 160Mb при запуске. Сразу пошёл проверять размер exe - 112Mb)
Диспетчер может и что-то не то показывает, но по процентам стабильно после 85% занятой памяти всё начинает тормозить(Диск hdd, 4Гб RAM)
Хотя конечно понятно было что он что-то не так показывает. Память кончалась быстрее, т.е. занято было всегда больше чем сумма занятой памяти которую он показывал, причём ещё до того как приложение подгружало данные из сети. Т.е. например до токо как в той же телеге я нажимал что-либо вообще
Но в линуксе что-то странное с телеграмом, похоже на утечку памяти. Я там просто листал текстовые сообщения и у меня htop всё больше показывал(прям мегабайтами росло)
Так конечно просто если чат с картинками листать то тоже расти будет. Не удивительно что можно хоть до 1Гб догнать. Не знаю будет ли он со временем их сжимать и/или на диск скидывать
Проверил. Полистал огромный чат в том числе с картинками, рядом поставил Process Hacker. Занятая RAM растёт медленно, временами уменшаясь.
Похоже в линуксе таки у него утечка.
При прокрутке чата вполне ожидаемо появляется нагрузка I/O, так что телега вполне хорошо оптимизирована. Немного печально что ей при запуске тоже надо 160Mb
zaiats_2k
А вы ~~на шкаф~~ залезьте на пару десятков каналов с картинками и видосиками. Он не только памяти нажрётся, но и крашнуться может. ;)
Massacre
Если хочется узнать, что в действительности использует, надо отобразить Private working set.
tdemin
Специфика аллокатора в glibc, если верить этому. На других ОС такой проблемы нет.
Massacre
Интересные, конечно, утечки памяти у телеграма на линуксе, на винде у меня сейчас 80мб private working set и если не смотреть в нём видео, примерно так и будет, ну, может ещё на +100мб разрастётся в процессе (а видео добавляет ещё около 200 на время просмотра). Правда, не официальный клиент, а 64Gram.
netch80
> Вообще, меня больше напрягает Telegram, который аж больше 1 гига жрёт.
По которому из показателей?
DistortNeo
Как минимум, можно на RssAnon посмотреть.
hyperwolf
Ну давайте сравним. На 10 летнем десктопе дома win10 сильно меньше кушает. Прекратите верить, что десктопный линукс с гуями - это некое чудо, которое не есть ресурсы.
Nasreddin_Hodja
Это Гном небось 20ГБ отъел? У меня вон KDE Neon с двумя месяцами аптайма гораздо лучше себя чувствует, ресурсы отжирают в основном браузеры и кое какие проги на Electron. Сами кеды при этом потребляют вместе с системой где-то полгига всего.
UtrobinMV
Мне кажется вы тут, что то под шаманили )) Чтобы нам показать фейк. Список процессов бы показали и отсортировали по потреблению.
Вот как у меня на другой машине.
Это еще при условии, что у меня куча докер контейнеров уже запущено и работает.
hyperwolf
Вот, пожалуйста, старый добрый браузер. Там еще миникуб крутится где-то, докер, постгря, но браузеры нынче жутко жрущие до памяти. И да, тут не 100500 вкладок, но штук 30 будет.
andreymal
Ну и мой скриншот, чтоб коммент не был пустым
apro
А можно поподробнее раскрыть идею? Ведь если используется одна и та же разделяемая библиотека, то код ее и все константы будут разделяться между всеми приложениями, использующими эту библиотеку. То есть допустим у нас запущено 20 приложений KDE, каждое из которых используют 50 мегабайтный Qt с кучей плагинов, если бы каждое приложение использовало бы свою копию Qt на полную, то в результате у нас ~1ГБ оперативки ушел бы на всю эту фигню. А за счет того что Qt одна, страницы памяти разделяются и получаем экономию.
myaut12
Это не совсем так, so (shared objects) на то и shared, что переиспользуются в памяти между всеми процессами их загрузившими. Отсюда и большие значения в колонке SHR.
mpa4b
У меня есть подходящий пример по поводу 'простенького целерончика'. А именно, легендарный (в своё время) asus eeepc 900, с гигабайтом памяти (и апгрейдом до ssd накопителя).
OS - NetBSD, которая сильно легче линукса -- одно ядро раз в 10 меньше.
Сборка GCC -- не хватает гигабайта памяти и вываливается в своп немного.
То же самое, если попытаться ходить по интернету браузером palemoon (разновидность firefox) -- gmail, wiki, google -- уже тоже начинает из гигабайта вываливаться в своп и конечно же жутко тормозит. В остальном -- работает нормально (иксы, без DE и лёгкий WM типа fluxbox).
Так что нет, гигабайта памяти и скорости легких целерончиков уже совсем не хватает.
tzlom
я на eeepc 1015 веб разработкой занимался, хром + IDE, разумеется что-то свопилось, но в принципе это было весьма комфортно (если не принимать в рассчет не стандартное разрешение)
тогда правда и хром был по легче
Massacre
Для wiki и google (в смысле, именно поисковик) palemoon более 200-300мб памяти не будет жрать, вот с gmail, как и всё, что «веб-приложение» уже проблема, да.
netch80
Работаю сейчас над проектом, который запускается в Linux.
Основной бинарник первого компонента занимает 250 мегабайт. Бо́льшая часть из них там нафиг не нужна, это последствия включения нескольких толстых библиотек.
Ну и код написан так, что, например, чтобы собрать 3 параметра с кучи объектов, вся куча объектов пробегается по 1 разу на каждый параметр (с массой копирований...)
Но поскольку ресурсов хватает, это никого не волнует.
PS: Оно ещё и собирается и работает в докерах на основе древнего RHEL. Протестировать локально невозможно. Разработка замедляется на порядок. Зато стильно-модно-молодёжно-Linux.
PS[2]: я за Linux. Но я к тому, что убить преимущества можно у всего, и стандартные корпоративные подходы делают это влёгкую.
UtrobinMV
На Си пишешь и собираешь или на другом языке?
netch80
C++ (относительно низкоуровневый, смесь C-с-классами и 11).
tlittle
Поставьте на вашу убунту простенький Миднайт коммандер. Сколько пакетов он потянет за собой?
UtrobinMV
Совсем немного пакетов потянет. Midnight Commander - очень легкая, памяти почти не потребляет, регулярно пользуюсь, очень удобно.
tlittle
А вы проверяли, сколько он пакетов тянет с собой? Они действительно не нужны и не используются, но сколько их? Насколько я помню, он по-дефолту требует Xorg и кучу пакетов из гнома. Консольный файловый менеджер. И именно об этом говорит автор статьи. Неважно, винда у вас, линукс, полуконский полупес... В современных реалиях при установки любого программного пакета вы установите кучу ненужного хлама, который просто будет лежать и занимать место. Под виндой - больше (не факт), под линуксом - меньше, но этого хлама будут тонны.
Сколько занимает сейчас glibc? Вот вы делали 10 лет назад программу, которая использовала этот пакет. Функционал этот программы нисколько не изменился. Но при установке этой программы вы притянете к ней glibc, размер которого увеличился минимум в 10 раз. Вот это - проблема.
andreymal
На Ubuntu Server вот столько
andreymal@ubuntu:~$ sudo apt install mc
Следующие НОВЫЕ пакеты будут установлены:
libgpm2 libslang2 libssh2-1 mc mc-data
Обновлено 0 пакетов, установлено 5 новых пакетов, для удаления отмечено 0 пакетов, и 1 пакетов не обновлено.
Необходимо скачать 2 567 kB архивов.
После данной операции объём занятого дискового пространства возрастёт на 9 943 kB.
Хотите продолжить? [Д/н]
tlittle
это вы пробуете на своей конкретной системе (где уже установлено что-то). А на чисто ОС? Мне правда лень ковыряться в пакете, но раньше там было очень много зависимостей на гноме-окружение.
andreymal
Это чистый Ubuntu Server, никакого гнома на нём отродясь не было
khajiit
А чего в нем ковыряться, если можно просто взять и посмотреть зависимости через apt:
Все, что может потребовать иксов, находится даже не в Recommends.
denis-isaev
del
Massacre
Откуда у mc в требованиях xorg? Отлично работает на серверах, где вообще никогда не было иксов…
netch80
Есть GUI-сборки mc. Может, у него как раз такая.
tlittle
На самом деле, все проще. Я никогда не пользовался убунтой в повседневной работе, мне генту был ближе. А там все работает интересно - если в системном х.конф прописаны иксы, то миднайт ставит свои иксовые приблуды. При этом его даже не сильно волнует, что у меня настроено xfce - он ставит всякую гномовскую требуху.
ЗЫ. И, опять же, у меня данные сильно устаревшие, я уже лет 7 не пытаюсь использовать линуксы в качестве десктопных систем - корпоративными стандартами они не предусмотрены, а