Технический долг — один из самых популярных сегодня терминов. Люди говорят: «Мы быстро развиваем свой MVP, минимизируя технический долг!» Они говорят о техническом долге, чтобы звучать круто или выделиться.
А я просто смеюсь, ведь всё рано или поздно превращается в технический долг.
Вся моя карьера теперь стала техническим долгом или кодом, который перестали поддерживать.
И если вы не верите, что вся ваша карьера — это технический долг, то, возможно, поймёте это после прочтения статьи. Я расскажу о том, что изменилось за мою двадцатилетнюю карьеру.
▍ Сначала это был Basic…
Я начал свою карьеру как разработчик на Visual Basic 6. С 1999 по 2003 год я создал множество разных приложений. Думаю, можно с уверенностью сказать, что всё, написанное на Visual Basic 6, по современным стандартам стало техническим долгом или уже давно было заменено. Да здравствует «on error resume next!»
Долгое время я занимался разработкой классических active server pages (ASP). Немного я побыл специалистом по разработке веб-сайтов, работавших в Internet Explorer 6 и Netscape Navigator. И в моём резюме эта информация больше не имеет никакого веса!
Visual Basic, ASP, IE6 и Netscape — это уже давно забытые технологии.
▍ Старые языки: Perl, Delphi, Fortran, FoxPro, ColdFusion
Кроме Visual Basic 6, есть множество языков программирования, которые за двадцать с лишним лет впали в немилость. Есть большая вероятность того, что если вы писали на одном из этих языков, то кто-то уже пытается разобраться, как переписать этот код, потому что для этих языков сложно найти программистов: Perl, Delphi, Fortran, FoxPro, ColdFusion.
Существуют ли всё ещё на них приложения? Да. Можно ли нанять людей, чтобы разрабатывать их? Это сложно. В большинстве случаев, такие компании вынуждены модернизироваться и избавляться от старых приложений.
В начале 2000-х люди думали, что Adobe ColdFusion находится на пике популярности. Помните его небольшой скачок к звёздному статусу?
Ruby on Rails находится в опасности попадания в этот список. Он утерял популярность и для него сложно найти разработчиков. То, что когда-то сделало его уникальным, теперь есть в других языках.
Языки программирования приходят и уходят. Разработчики не хотят осваивать навыки, не имеющие спроса. Вопрос всегда заключается в равновесии спроса и предложения!
Разработчики быстро бегут с тонущего корабля и всегда стремятся указать в своём резюме новую популярную технологию.
▍ Что произошло с ActiveX, апплетами Java, Flash и Silverlight?
Одно из первых моих приложений использовало элементы управления ActiveX в Internet Explorer 6. В то время они требовались для выполнения печати и других небезопасных программных трюков. В те времена PDF были не так распространены, и печать из браузера сама по себе превращалась в отдельный кошмар.
Апплеты Java тоже когда-то были громкой технологией. Они были медленными, а для установки на компьютер подходящей версии Java всегда приходилось потрудиться. Я никогда не забуду кошмаров работы с сетевыми файрволлами, требовавшими апплетов Java. Я не скучаю по этим кошмарам и рад, что они ушли в прошлое.
И, разумеется, все мы помним Macromedia/Adobe Flash! Когда-то он был любимцем всего Интернета. Появлялись бесчисленные игры на Flash, множество ПО создавалось во Flash на ActionScript. Сегодня продукт под названием CheerpX позволяет запускать старые Flash-приложения при помощи WebAssembly.
Microsoft выпустила конкурента Flash под названием Silverlight. На самом деле, это потрясающий фреймворк для разработчиков на C#. Моя компания разработала несколько удивительных продуктов на основе Silverlight.
Но как мы все знаем, Apple покончила с Flash и Silverlight, отказавшись от их поддержки в своих браузерах.
Вот скриншот финансового калькулятора, который мы разрабатывали на Silverlight в VinSolutions более десяти лет назад. Silverlight уже давно в прошлом, и компания переписала весь код на JavaScript, но он по-прежнему такой же крутой, как и старая версия!
▍ Моё первое мобильное приложение
В 2004 году я создал мобильное приложение. Это время уже вспоминается с трудом, тогда ещё не существовало ни iPhone, ни Android. Я разработал приложение для инвентаризации автосалонов под КПК Compaq. Оно было написано на C# для .NET Compact Framework для работы в Windows CE.
У этого КПК была камера на один мегапиксель. При облачной погоде, когда не было сильного блеска, фотографии даже получались умеренно ужасными. Как же изменились технологии! В 2005 году это приложение было на передовом рубеже технологий, а теперь давно уже покоится на кладбище.
▍ Лучше перейти на Swift
Swift — ещё один превосходный пример того, как быстро меняются инструменты разработки. После выпуска компанией Apple языка Swift стало сложно найти причины дальше писать на Objective C. Я уверен, что есть случаи, когда он по-прежнему нужен. Но на Swift гораздо проще вести разработку и он стал серьёзным эволюционным шагом вперёд.
Я бы сказал, что все написанные на Objective C приложения, скорее всего, стали теперь техническим долгом.
▍ WebForms
После написания безумных встроенных скриптов для сборки веб-приложений я с радостью начал использовать новые веб-формы ASP.NET. Их управление на стороне сервера существенно облегчило разработку. Их задача заключалась в том, чтобы максимально упростить разработку веб-приложений на Visual Basic 6. И по большей части это удалось! Можно было создавать многократно используемые компоненты UI на стороне браузера для рендеринга в браузере. Точно так же, как мы это сегодня делаем на стопроцентном JavaScript.
WebForms не были идеальными, но стали существенным улучшением. Они отлично развивались, пока не появился Ruby on Rails и не популяризировал фреймворки MVC (Model-View-Controller) для разработки веб-приложений.
MVC быстро превратили все разработанные нами на WebForms приложения в устаревший код. С уверенностью можно сказать, что всё, написанное на WebForms, превратилось в технический долг. (Однако та же идея возвращается к нам в виде Blazor.)
▍ MVC — чемпион! (на какое-то время)
И прежде чем мы успели спохватиться, каждый язык программирования начал поддерживать фреймворки MVC. Мы начали писать всё новое на ASP.NET MVC. Он был везде, в том числе в Django, Laravel, Symfony, Spring и так далее.
Перенесёмся в настоящее: с тех пор MVC вышел из моды. Сегодня всё пишется на React, Angular, Vue и других фреймворках.
А до них у нас были другие Javascript-фреймворки. Наша компания Stackify использовала достаточно популярный фронтенд-фреймворк Knockout.
Помните ли вы хотя бы один из этих фреймворков? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars…
Если вы работали с какими-то из них, то могу поспорить, что теперь этот код считается техническим долгом и попал в немилость. Первое поколение фронтенд-фреймворков проиграло React и Angular.
▍ Angular JS
В 2015 году на сцену ворвался созданный Google фреймворк Angular. Он быстро стал самым популярным фронтенд-фреймворком.
В 2016 году произошёл крупный апгрейд Angular, который утерял обратную совместимость.
Понимаете, что это значит? Всё, написанное на оригинальной версии, теперь стало техническим долгом. В нашей компании у меня есть проекты на старой версии Angular, которые превратились в крупный технический долг, требующий обновления.
▍ Старые грязные SOAP и WCF
До того, как REST API и JSON стали стандартами де-факто, одной из альтернатив был SOAP (simple object access protocol). Он упрощал вызов веб-сервисов и автоматически кодогенерировал прокси-классы для корректного вызова сервисов. В основном он использовался Windows Communication Framework (WCF) поверх XML.
Он работал потрясающе… до определённого момента. Одна из самых трудных проблем в моей карьере заключалась в том, чтобы понять, как использовать сертификаты безопасности между моей компанией и другим поставщиком по WCF и SOAP. SOAP и WCF давали большие обещания, но со временем их поддержка превращалась в кошмар.
О SOAP и WCF я совершенно не грущу. Microsoft решила больше не поддерживать WCF в .NET Core. Теперь предпочтительны технологии наподобие REST, gRPC и GraphQL. Однако проект сообщества создал CoreWCF, чтобы обеспечить его работу.
Со временем типы технологий для вызова веб-сервисов изменились. Старые способы по-прежнему работают, однако большинство разработчиков, скорее всего, предпочтёт отправить их на пенсию.
▍ Основные версии языков
Ещё одна распространённая проблема заключается в изменениях основных версий языков, будь то Ruby, PHP, .NET или другие. Обычно они требуют больших изменений в коде или даже его переписывания.
Когда вышел .NET Core, он стал более новой, легковесной и быстрой версией .NET, спроектированной для работы в Linux. Простой код на C# портировался на него довольно легко, но в реальных приложениях никто не использует только простой код.
Однако в сложных корпоративных приложениях при движении по пути апгрейда возникает множество потенциальных проблем. Это становится крупным техническим долгом, который необходимо устранить. В противном случае вы окажетесь привязанными к древней версии языка.
Такие апгрейды основных версий со временем становятся большими проектами по устранению технического долга.
▍ Привязка к старой внешней зависимости
Одна из самых больших трудностей нашей компании Stackify заключалась в том, что мы оказались привязаны к старой версии Elasticsearch.
В какой-то момент разработчики этой системы внесли существенные изменения в способ её работы, которые были не полностью обратно совместимы. Мы активно использовали эту систему, и вся работа по апгрейду превратилась в крупномасштабный проект по устранению технического долга.
Нам постоянно приходилось идти против течения, и в результате мы остались далеко позади. Это ещё один пример того, как реальные проекты с техническим долгом могут наносить огромный ущерб компаниям.
▍ Из-за опенсорсной альтернативы мой код перестал быть актуальным
Наша компания создавала собственные библиотеки трассировки/профилирования для шести языков программирования. Для их реализации приходилось выполнять невероятный объём работы.
Что ж, теперь появилась OpenTelemetry, сделав всю нашу работу бесполезной.
Зачем поддерживать собственную библиотеку, если можно воспользоваться опенсорсным продуктом, ставшим стандартом отрасли? Наша компания постепенно работает над тем, чтобы прекратить поддержку профилировщика .NET, в разработке которого я участвовал.
▍ Весь код устаревает или оказывается заменённым
С течением времени вы видите, как почти всё созданное вами умирает и заменяется по различным причинам. В противном случае ваша работа будет основана на устаревшей технологии.
Множество приложений, которые я создал на ранних этапах моей карьеры, было убито, потому что разрабатывавшие их компании кто-то купил или они решили использовать совершенно другую технологию.
Срок жизни большинства ПО ограничен, и он гораздо меньше, чем вы предполагаете. Весь код постепенно становится техническим долгом, который все хотят переписать более современным образом. Или же существенно меняются потребности бизнеса.
Разумеется, в корпоративном мире выше вероятность того, что какие-то внутренние приложения будут использоваться практически бесконечно. Управляющая железными дорогами компания или банк по сорок лет используют одно и то же ПО, работающее на мейнфреймах.
Я предположу, что WebAssembly постепенно захватит весь современный мир фронтенд-разработки, и мир ПО эволюционным образом превратится в совершенно иной.
▍ Реальность технического долга
При разработке новых проектов людей всегда волнует минимизация технического долга. И я это понимаю. Есть баланс между работающей программой и стремлением к её совершенствованию.
Однако ничто не является техническим долгом только потому, что оно неидеально. Нет ничего идеального. Со временем то, что было идеально сегодня, перестанет им быть в будущем. Учитесь соглашаться на нечто меньше, чем идеал.
Другая сторона технического долга заключается в том, что теперь всё постепенно портится со временем. Или ПО имеет существенные проблемы с апгрейдом до последних версий языка, или технология теряет популярность, потому что появились новые способы реализации. Удачи вам с наймом людей под старые технологические стеки.
Всё со временем превращается в технический долг или проекты клонятся к своему закату. Если вам сильно повезёт, то ваш код выживает достаточно долго, чтобы стать техническим долгом кого-то другого.
По прошествии достаточного количества времени весь ваш код будет удалён.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (123)
vacoo
29.05.2023 14:02+4Не думаю что это плохо. Ведь развитие это хорошо. В конце концов ни что не вечно под луной
Nichls
29.05.2023 14:02+5Так-то оно возможно и есть.
Тем не менее Delphi до сих порт используется.
Есть проекты, которые по ряду причин, назовём их "политическими", не переписываются и продолжаются сопровождаться. Хотя руки порой и чешутся ...
IRS
29.05.2023 14:02+1эта политическая причина называется "зачем трогать то что и так работает". В некоторых ситуациях это правильный подход, в некоторых нет. Приводит рано или поздно к тому что с рынка исчезает железо и ОС на котором старое работало :)
AntoineLarine
29.05.2023 14:02+18С учётом того, что Delphi работает поверх WinAPI, то там обратная совместимость о которой остальные могут только мечтать. Приложения на Delphi до сих пор прекрасно работают на всех версиях Windows, как на старье XP, так на Windows 11, если, конечно, у программистов руки прямые. Естественно, за исключением случаев, когда в приложении используется какая-либо возможность, не предусмотренная в более ранних версиях ОС.
Хотя, конечно, сама среда уходит в историю.
sim31r
29.05.2023 14:02Вполне себе поддерживается и развивается и бесплатна стала для небольших компаний (до 100к прибыли). И под Андроид компилируется. Но не знаю ни одной компании или продукта сделанного на Delphi, возможно Альтиум дизайнер специфический для электронщиков и еще некоторые подобные.
Совместимость есть, .NET или Java могут быть привязаны к версии, а тут 32 битные приложение работают как есть от Windows XP до Windows 11.
И исходный код "защищен" компилятором, до исходников не добраться, кому-то это плюс.
alan008
29.05.2023 14:02+2Новые версии RAD Studio для Delphi и C++ Builder выпускаются по сей день. И да, там есть интересные возможности.
AntoineLarine
29.05.2023 14:02+3Да, но насколько они популярны? Имхо, сейчас это очень нишевый продукт
Alexey2005
29.05.2023 14:02+4Сейчас сама по себе разработка десктопных приложений стала очень нишевой. Всё ушло в облака.
Dr_Faksov
29.05.2023 14:02рынка исчезает железо и ОС на котором старое работало
Вы не поверите, иногда дешевле разработанность и заказать мелкую, ~ 10 000 шт, партию железных эмуляторов старого железа, чем переделывать систему.
Лично видел переходник с "толстого" Ethernet (если кто помнит такого зверя) на витую пару.
ErshoffPeter
29.05.2023 14:02+4Да, были времена - разрабатывали мы на Delphi + Transact-SQL АБС...
...но в результате разработали:
систему управлений версиями (начало двухтысячных),
некое подобие методики управления требованиями,
некое подобие Agile со спринтами в календарный месяц.
А результат - примерно тот же, что и в статье описан...
Thomas_Hanniball
29.05.2023 14:02+2Средний срок жизни IT-проекта после его внедрения составляет, как правило, 5-7 лет. Иногда срок может доходить до 10 лет. За это время сильно меняются как потребности бизнеса, так и актуальный стек технологий.
Людям тоже свойственно менять работу, поэтому за 10 лет в компании может полностью поменяться вся команда разработки или эксплуатации. Новым людям будет неинтересно поддерживать чей-то старый сервис, особенно если по нему почти нет никакой документации. Им будет проще создать свой собственный сервис на замену старому, но на актуальном технологическом стеке.
Kahelman
29.05.2023 14:02+15Вы это копаниям расскажите, что им надо все базы данных и приложения каждые 5 лет выкидывать. Кроме того, автору посоветовал бы на C/C++ писать чтобы все не переписывать при смене моды :)
sim31r
29.05.2023 14:02+1Я с SAP работаю, биллинг специфический. Я работаю 3 года и по впечатлениям освоил 10% от нужного объема знаний как программист и как консультант. У нас много сотрудников что более 10 лет лет работают, статус у них старший эксперт. Первые записи в БД в 2007 году и иногда код правишь, а там комментарий 2008 года, типа это временная заглушка, потом надо переделать и оно так и работает в каком-нибудь отчете по наше время ))
Переписывать код не планируется, огромный объем работы вложен в ПО и в обучение пользователей.
Смена команды в такой сложной области нежелательна.
Аналогично и про игровые движки слышал мнение, 3-5 лет нужно чтобы просто понять как работает движок, чтобы уверенно работать с ним.
mapron
29.05.2023 14:02+12C/C++ писать чтобы все не переписывать
Ага, устроиться в 2023 на проект на С+С++, который писался в 80-90-е годы. И который "ура, не надо переписывать". Мечта, а не работа просто!
(если кто-то грезит "ура новые стандарты, ща отрефакторим" - nope, в таких проектах обычно все будет продолжать собираться тем самым gcc 2.95 или Turbo C, и сейчас, и спустя еще 20 лет).
IMnEpaTOP
29.05.2023 14:02+2Иногда достаточно большие проекты всё же делают эти переходы, например 1С так делает.
xcs9
29.05.2023 14:02В чем проблема? Что не практикуешь новые стандарты? Так это твоя проблема. Или не в состоянии разобраться в "старом" С++, который будет работать еще много-много лет? И да, случалось, всплывал контроллер, в котором boost не компилировался ) Это жизнь..
mapron
29.05.2023 14:02И да, случалось, всплывал контроллер, в котором boost не компилировался
я делал порт буста на кастомный форк gcc 2.95 под no-mmu желязку с каким-то непонятным форком арма (где часть инструкций отсутствовала). По молодости один раз прикольно, но спустя какое-то время и опыт хочется "просто спокойно работать над решением проблем бизнеса а не ебаться с тулчейнами и багами железа/ОС". тупо не моё. Если вам по фану и в кайф - очень рад за вас.
Если вы из моего коммента думаете что я смузихлеб который ниже С++23 ни на чем не готов писать и боится трудностей - вы ошибаетесь. Просто есть разница между быть готовым к трудностям и мазохизмом для меня) работа должна приносить хоть какую-то радость)
Alexey2005
29.05.2023 14:02Боюсь, через 10 лет всё же придётся заняться переписыванием на Rust. Популярность стека C/C++ постепенно падает.
dunkelfalke
29.05.2023 14:02Им будет проще создать свой собственный сервис на замену старому, но на актуальном технологическом стеке.
Классический синдром неприятия чужой разработки. Поэтому гугл уже 20 с лишним мессенджеров написал.
stitrace
29.05.2023 14:02Слышал другую версию. Если все вокруг пользуются одним и тем же инструментом, то они не имеют преимуществ перед друг другом, а успех в преимуществе.
Wesha
29.05.2023 14:02+1Если все вокруг пользуются одним и тем же инструментом, то они не имеют преимуществ перед друг другом
Если все вокруг пользуются одним и тем же инструментом, то они имеет преимущество тот, кто пользовался им дольше (= начал пользоваться им раньше).
А по большому счёту преимущество имеет тот, кто смог уболтать начальство, что именно его инструмент самый кошерный.
Thomas_Hanniball
29.05.2023 14:02+2Вся моя карьера теперь стала техническим долгом или кодом, который перестали поддерживать.
Так как технологии в IT быстро развиваются, то для карьеры важен лишь актуальный опыт работы за последние 5 лет. Если там ничего интересного нет, то работодатель ещё может посмотреть на последние 10 лет. Опыт старше 10 лет, как правило, никому не интересен, поэтому нет большого смысла на нём акцентировать внимание в своём резюме и на собеседовании.
Areso
29.05.2023 14:02+6Позволю себе заметить, что опыт старше 10 лет мало интересен с технологической точки зрения, но вполне себе ревалентен в смежных:
1) предметная область. Если вы 10 лет назад работали писали АБС в банке (хоть на мейнфрейме\дельфи, в зависимости от размера банка), то вы и сегодня сможете писать АБС -- на современных инструментах, естественно. Раньше, когда людей было действительно много, компании искали разработчиков с опытом не только на актуальном для них стеке, но и в актуальной предметной области. Сегодня, с развитием микросервисной архитектуры, всем пофиг на предметную область.
2) опыт разработки "под ключ", его тоже не пропьёшь, и скорее наоборот. Пусть, скажем, 1 проект занимает 2,5 года, то за 10 лет -- всего 4 проекта. Пока аджайл коучи учат других считать бурнаут таски, взрослые люди тихо радуются тому, что их навыки сбора требований, подготовки нормальных техзаданий на дорогие системы, и тому подобные навыки не обесцениваются выпускниками курсов.
3) архитектура. Это примерно как пункт 2, но с поправкой на то, что архитектура современных приложений постоянно усложняется (иногда без особой нужды). Но человек с опытом в 5-7 лет, что он успел там увидеть?) Учитывая, что часть плохих архитектурных решений становится видна не сразу.
aborouhin
29.05.2023 14:02+21Что-то я не понял, о чём сокрушается автор. Он успел освоить множество разных технологий, что где-то даёт ему более глубокое понимание проблемы, где-то позволяет предложить нестандартное решение (иногда новое - это хорошо забытое старое). В любом случае навыки понимания ТЗ и потребностей бизнеса, проектирования систем, организации работы и т.д и т.п. прокачались независимо от технологий. Да и, в конце концов, постоянная смена технологий позволяет быстрее осваивать новые и в будущем. Плохо всё это, что ли?.. Вроде, хорошо.
OlegZH
29.05.2023 14:02+4Просто, если бы удалось как-то удачно что-то разработано в прошлом, то не надо было изобретать, что то новое и заменять им старое, старое работало бы, как часы. И чей-то код продолжал бы работать. А так... имеет то, что имеем. Код, который всегда однажды умирает. А вложено было сил, времени, никому не нужных авралов, недосыпов и беготни...
aborouhin
29.05.2023 14:02+15Ну если автор рассчитывал, что его код, как сонеты Шекспира, восхищённые потомки будут использовать и перечитывать через пятьсот лет... тогда да, обидно :)
sim31r
29.05.2023 14:02В своё время авралы были нужны. И многое из разработанного в прошлом работает и в наше время, например финансовый код на Cobol в США или SAP в ЕС.
event1
29.05.2023 14:02мне кажется, что автор не сокрушается, а скорее делится опытом: не надо зацикливаться на текущей задаче/приложении. Через 5-10 лет никто не вспомнит не только о них, а и об языке на котором они написаны.
VladimirFarshatov
29.05.2023 14:02+24Как-то странно автор трактует понятие техдолг, как нечто устаревшее и только поэтому требующее переписывания, явно нарушая принцип YAGNI, в его варианте "работает? Не трожь!".
Разработка Ассемблер-реассемблер для Д3-28, 1985г. Проработал в НИИПГ до 2001г. И умер с последним рабочим экземпляром. Это тоже "техдолг"?
Разработка (частичная, бросил, ибо петпроект как теперь это зовётся) синтаксического анализатора языка Ада, диспетчера параллельных процессов, сетевого драйвера, системы межзадачного общения (привет каналам go!) .. 1986..1994, где-то там.. да этот "техдолг" дал мне такое понимание работы компиляторов, оптимизаторов и параллельного исполнения! Полезно по сию и чем дальше, тем чаще..
Фортран.. технические расчеты, математика, тензорные вычисления и пр. Число дробилки.. применяется по сию пору, как выяснял недавно.. техдолг, точно? 1979..1983. Как мне это знание потом помогало в игровой разработке!
Конечные автоматы.. освоенные, угу на Паскале, ещё ДВК.. очень пригодились позже в соревнованиях сына на Ардуино-гонках.. 13-9-6 секунд на круг, при правиле что машинка может простоять до .. 15 секунд, а проиграл тот кто врезался.. 2018Робофест.. победитель въезжает в стоящую на трассе колымагу и .. выбывает из соревнований .. 6 (шесть!) сек. на круг, Карл.. тормозной путь больше чем расстояние обнаружения препятствия.. одна из причин, почему это был последний год такого направления.. надеюсь внёс и свою лепту .. техдолг, теперь вся эта разработка, вкупе с целочисленным просчетом флоат, аки децимал? Не думаю.
Компания ведёт свое ПО.. зенд 1.7.8 передовое слово.. и? Ушел в лету, всё, техдолг? Да щазз, протяжно. Форкнули репу и .. живёт то ПО по сию пору.. работает - не трожь! В то же время, и там же, есть и второй зенд и симфони и Юй как первый так и второй, с ларавелем впридачу и даже чистый Пых 7.2 .. 8... Что мешает?
Кстати, по соседству нормально уживались и Парадокс с МС Дос и Дельфи и Аксесс 97 и Мускуль от 5.1 до Марии..
Может не надо считать техдолгом то, что уже работает? А создавать новое можно и с применением "последних достижений", которые, по мере освоения всё чаще напоминают забытое старое, или даже деградацию подходов к разработке, особенно когда вижу "от гугля".. :(
Кмк, техдолг, это всё же нечто недоделанное, что требует допиливания, а не переделок, только потому что устарело. Может поэтому у крупняка оно и пашет по сорок лет, что они бабки умеют считать, а не кидаться в погоню за модным?
foxweb
29.05.2023 14:02Кажется вы с автором про разное. Ваш опыт максимально крут, спору нет. Респект и уважуха. Только непонятно, а что вы собственно опревергаете?
Было? Было.
Прошло? Прошло.
Плохо штоль? Хорошо.VladimirFarshatov
29.05.2023 14:02+1Ну так автор как раз и сетует что "плохо-плохо", что устаревание ПО - это "техдолг". Тут ниже ответили лучше и точнее про то что стоит считать техдолгом. Свой опыт привел исключительно как пример устаревания ПО, о котором ни разу не жалею. Ушло и ушло. Любой разработчик, с возрастом за 50+ расскажет Вам не меньшую кучу таких разработок, что точно также "канули в Лету".. не исключение, да и ничего шибко заумного у меня нет, типовые истории на ночь. ;)
Ну и .. отдельный раздел с МС ДОС (DR DOS 6.1) выделен по сию пору, но .. уже года три как туда не лазил.. ;)
Keeper9
29.05.2023 14:02+45
Писать надо уметь.
AdrianAlexandrov
29.05.2023 14:02Странный скриншот. Ken Thompson написал Grep на ассемблере под PDP-11.
А вот GNU Grep написан Mike Haertel на С. Версия 1.0 вышла в 1988.
s-a-u-r-o-n
29.05.2023 14:02Статья про grep в целом, а карточка программы про GNU Grep. По идее, это две разные сущности, но писать про них 2 разные статьи глупо.
Nipheris
29.05.2023 14:02+15Я предположу, что WebAssembly постепенно захватит весь современный мир фронтенд-разработки, и мир ПО эволюционным образом превратится в совершенно иной.
Когда это наконец случится, я смогу спокойно умереть. Компилировать статически типизированные языки в динамический только ради возможности доставить логику пользователю - это победа техники над здравым смыслом. Как и вообще необходимость переписывать половину кода в мире только ради того, чтобы засунуть это в браузер. Зачем вообще засовывать приложение в браузер? Зачем делать из браузера операционную систему?
Это как плохой сон, но ты никак не можешь проснуться.
Hardcoin
29.05.2023 14:02+9Зачем вообще засовывать приложение в браузер?
Ради песочницы. Ставить все подряд приложения далеко не каждому по вкусу, да и не безопасно. Пользователям нужна песочница для выполнения приложений без ритуала скачивания, установки и без риска. Какая это будет песочница - без разницы. В телеграм тоже приложения есть (боты), но функционал беднее.
Nipheris
29.05.2023 14:02+10Пользователям нужна песочница для выполнения приложений без ритуала скачивания, установки и без риска.
Вот именно! Нужна песочница и очень простая доставка и выполнение логики на машине клиента. В каком месте из этого следует, что нужно переписать приложение на динамический язык? Ну или на статический, который был создан только ради того, чтобы можно было потом без гемора и кучи прослоек скомпилироваться в динамический? Я вот не могу найти ответы.
Сколько виртуальных машин с разными свойствами люди успели напридумать за это время. Наконец-то хоть одна (WebAssembly) подошла.Hardcoin
29.05.2023 14:02+1В каком месте из этого следует, что нужно переписать приложение на динамический язык?
В том месте, где у пользователя одна песочница, удовлетворяющая условиям - браузер. Другой у пользователя нет и разработчик приложения не может на это повлиять.
Разумеется, Гугл может добавить в свою песочницу статический язык, но это совершенно другой вопрос. Более близкий к реальности - почему Гугл (и мозилла) не добавляет поддержку статического языка. Но тут ответить сложнее, если кратко - пытаются. TypeScript тому пример.
youngmysteriouslight
29.05.2023 14:02+2У пользователя уже есть ОС и это её (или входящих в дистрибутив системных приложений) задача обеспечивать пользователя новой песочницей по требованию и нужными мерами изоляции — cgroup там всякие и иже с ним. Осталось обеспечить пользователя удобными инструментами, которые позволят «выполнять приложения без ритуала скачивания, установки и без риска». ИМХО, в связи с этим Docker обрёл популярность.
Мне тоже кажется странным использовать JS в качестве низкоуровневого языка виртуальной машины, на котором запускаются пользовательские приложения, к которым предъявляются требования надёжности (пишутся тесты), стандартизации (код транспилируется под конкретный стандарт), изоляции (Worker, WASM) и т.п. JS разрабатывался совсем для других нужд (низкие требования к коду, некая совместимость с нестандартными реализациями, отложенное падение программ, выживание любой ценой) и сейчас это выглядит как натягивание совы на глобус.
Hardcoin
29.05.2023 14:02её задача обеспечивать пользователя новой песочницей по требованию
Когда эта задача будет решена, прикладные программисты конечно будут пользоваться. А сейчас пользуются тем, что есть. Им же надо как-то доставлять свой код пользователю.
inkelyad
29.05.2023 14:02Насчет будут - есть вопросы. В Java есть целый страшный раздел, которым пользоваться мог практически никто. Который про конфигурирование Java машины на счет того, что приложению можно трогать, а что нельзя, какой код можно запускать, какой нельзя. Как раз нужная песочница. Даже средство доставки было придумано, которое Java Web Start. Но не осилили.
Nipheris
29.05.2023 14:02+1Другой у пользователя нет и разработчик приложения не может на это повлиять.
В статье как раз перечислены всякие песочницы, которые были, и которые просто не выстрелили. Ну или уже отслужили своё, как Flash.
Собственно и браузер не стал бы такой замечательной песочницей, если б работал без всякой магии вроде угадывания классов (см. комментарии ниже). Просто Гугл вложил огромное количество сил в оптимизацию движка, и по сути захватил Веб как платформу, и навязал её всем остальным. Раньше ещё можно было с этим спорить, но сейчас Веб - это Гугл, ибо Хромиум. Firefox остался единственной альтернативной реализацией, и кажется лет через 10 он к сожалению сдохнет.
Гугол вполне себе победил всех в плане экосистемы для приложений, чистый бизнес. Нет никакого "веба", когда код браузера и спеки настолько сложны, что уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания приложений. Чем это лучше какого-нибудь WinAPI с точки зрения отсутствия vendor-lock?Areso
29.05.2023 14:02+1Нет никакого "веба", когда код браузера и спеки настолько сложны, что
уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания
приложений.Разработчики мобильного Сафари смеются веб-разработчикам в лицо.
PuerteMuerte
29.05.2023 14:02А его что, с нуля писали, разве не адаптировали готовый движок от десктопного Сафари, который сделан на вебките, который произошёл от конкьерора, и который мутировал в блинк, вокруг которого лепят хромиум?
mixsture
29.05.2023 14:02+2Кроме песочницы я бы еще отметил визуальный и интерактивный компонент с большими возможностями. На который у человечества уже натренированы миллионы верстальщиков.
А также кроссплатформенность с очень большим числом поддерживаемых платформ. Думаю, превышающем существующие платформы виртуализации.
0xd34df00d
29.05.2023 14:02Обычный язык ассемблера так-то тоже не очень типизированный, что не мешает в него компилировать тот же раст или вообще хаскель какой.
youngmysteriouslight
29.05.2023 14:02+1Как бы да, но «это другое» (с).
Язык ассемблера или байткод какой-нибудь виртуальной машины выполняется непосредственно на машине. В случае с JS вычислительная среда (движок браузера) пытается угадать/восстановить типизацию переменных и контекста для более эффективной компиляции в байткод перед исполнением (как пример, выявление скрытых классов).
В итоге получается, что программист пишет, скажем, на TypeScript, PureScript или Idris свой код (типы проставлены и согласованы), который компилируется в JavaScript (типы стираются), после чего движок пытается угадать, какие типы использовались. Логично же?
Nipheris
29.05.2023 14:02Да-да-да, вот с этого у меня бомбит больше всего. Из-за того, что в качестве целевого языка компиляции мы используем динамический язык, мы сначала теряем кучу полезной информации о типах, о структуре объектов и т.п., а потом V8 сотоварищи начинает это всё угадывать обратно с использованием всякой магии и статистики. И при этом продвинутому разработчику нужно ЗНАТЬ хотя бы в общих чертах, как это происходит, иначе его код свалится в deopt и внезапно начнёт работать в 50 раз медленнее. Отличная абстракция, которую мы заслужили.
Приятно видеть, что хоть кто-то ещё обращает внимание на абсурдность ситуации.
0xd34df00d
29.05.2023 14:02Так там речь вроде не про JS, а про wasm, а он типизированный не меньше ассемблера, насколько я знаю, разве нет?
youngmysteriouslight
29.05.2023 14:02Я контекст обсуждения понял таким образом: вместо нативных компилируемых приложений пишут веб-приложения или на JS, или на чём-то компилируемом в JS.
Wasm не курил, но это вроде как обычный байткод. Если я правильно представляю, концептуально wasm ничем не отличается от других виртуальных машин. Беглый гуглёж сообщил, что есть LLVM IR → wasm. Мне представляется, что сам по себе wasm не даёт ничего принципиально нового в сравнении с другими VM. @Nipherisвроде такого же мнения. Но за слова не отвечаю.
Nipheris
29.05.2023 14:02Язык ассемблера вполне себе типизирован - его типы совпадают с типами целевой машины. Вместо всяких enum-ов, классов и union-ов высокоуровневых языков у вас байты, машинные слова и производные от них (какие-нибудь значения с плав. точкой в MMX регистрах). Более того, для машинных инструкций всегда точно специфицируется, что она будет делать с данными и какого они размера.
0xd34df00d
29.05.2023 14:02Есть сильно разные системы типов по выразительности, и «размеры элементов» — одна из наиболее невыразительных систем.
Да и никто не мешает положить в какой-нибудь xmm1 вектор двухбайтовых целочисленных значений, а потом с ним работать как с вектором флоатов.
Keeper9
29.05.2023 14:02float Q_rsqrt( float number ) { long i; float x2, y; const float threehalfs = 1.5F; x2 = number * 0.5F; y = number; i = * ( long * ) &y; // evil floating point bit level hacking i = 0x5f3759df - ( i >> 1 ); // what the fuck? y = * ( float * ) &i; y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration // y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed return y; }
Format-X22
29.05.2023 14:02+3А браузер изначально не был предназначен для приложений, но все захотели через интернет вместо текста тонкие клиенты ставить пользователю, костыль поверх технологии. Вот и едем на этом.
И браузер медленно мутирует в виртуалку/ОС со своими правилами. И есть хорошие - работает примерно одинаково везде, на всех ОС включая мобильные и не нужно задумываться об особых нюансах, безопасно для пользователя, можно гонять контент от просто текста до полноценного 3Д, отлажено десятилетиями и всё это доступно в один клик. Универсальнее платформы не существует вообще в принципе.
Но увы - легаси просмоторщика текста в XML формате - всё ещё с нами. Что поделать, люди избрали это - новым миром. Возможно web assembly уровняет все проблемы.
VladimirFarshatov
29.05.2023 14:02помнится авторам HTML 1.0 предлагалось за основу взять что-то типа "упрощенный интерпретатор с языка Си" .. отказались шведы, однако: "Это нафиг никогда не понадобится, Латех-а достаточно" .. как-то таким был ответ. ;)
PuerteMuerte
29.05.2023 14:02+72Автор в статье путает технический долг и легаси. Технический долг, это про другое. Это не устаревшие технологии, не вышедшие из моды языки. Технический долг, это недоделки в ПО, оставленные по принципу "сейчас несущественно, потом перепишем как надо, когда появится больше свободного времени", которого на самом деле потом не появится, и эти "перепишем как надо" накапливаются и накапливаются.
MiraclePtr
29.05.2023 14:02+1This.
Этот коммент надо закрепить самым первым, странно что выше никто подобное не написал.
nronnie
29.05.2023 14:02-2Автор в статье путает технический долг и легаси.
Я сразу хотел это написать, только поленился :))
atil
29.05.2023 14:02Точно! Я бы только еще добавил, что технический, как и финансовый долг, не есть что-то абсолютно плохое, если его правильно обслуживать и адекватно оценивать риски. А еще его, как и занятые деньги, не всегда приходится отдавать - разные бывают "сценарии будущего"...
Yuriy_75
29.05.2023 14:02+2Верно, но не автор один. В корпоративном мире как раз есть такое явление, когда проводится знак равенства между устаревшей технологией и техническим долгом. И даже более того - техническим долгом называется все, не соответствующее некоему новому корпоративному стандарту.
Был свидетелем, когда хранимые процедуры на SQL были объявлены техдолгом, ибо "бизнес логику на хранимках не пишут". То есть тут уже вкусовщина в чистом виде. Конкретно этому начальнику так не нравится - вот и техдолг.
vadim_bv
29.05.2023 14:02Да, техдолг — это отчасти вкусовщина. Точнее, что-то вполне работающее может противоречить (новой?) архитектуре. Как хранимки: например, потому, что монолит, а мода пришла всё делать на микросервисах и REST.
0xd34df00d
29.05.2023 14:02+1Технический долг — это проблемы с поддерживаемостью и развитием ПО. Недоделки ли, отсутствие тестов/типов ли, или же непопулярный сегодня стек, на который не найдёшь программистов — вопрос десятый.
DenisPantushev
29.05.2023 14:02+10Автор не понимает смысла термина https://ru.wikipedia.org/wiki/Технический_долг.
Это раз. Во-вторых, если автор не пишет сейчас на Delphi, это не значит, что систем на Delphi сейчас нет. Полно. Программистов на Delphi найти - раз плюнуть, если предложить им зарплату, которую они сейчас получают, работая на Джаве. С удовольствием пойдут, даже если меньше дадите процентов на 15 (если вы понимаете почему, ха-ха).
vvbob
29.05.2023 14:02+2По прошествии достаточного количества времени весь ваш код будет удалён.
Это одна из самых демотивирующих сторон нашей профессии. Причем ладно что будет удален, в конце-концов в этом мире мало что живет дольше сотни-другой лет, самое болезненное, что удален он скорее всего будет довольно скоро.
Помню свои ощущения, когда я работал в начале нулевых в одной фирме - админоодинсникомпрограммистомипрочее написал за несколько лет кучу всякого софта на 1С, Делфи, С, автоматизировал там все, настроил и поддерживал в порядке сетку, выжал из имевшегося (довольно старого и дохлого) железа все на что оно было способно, у меня даже на 150-х пеньках крутилась 1С в терминале, и при этом всё сносно работало.. Потом фирма обанкротилась, все железо было списано и продано за копейки, все эти мои наработки просто стерли.. Это как строить дом много лет, а потом наблюдать как его уничтожает пожар за пол часа, ощущения не из приятных.
badstarosta
29.05.2023 14:02Меня мысль об эфемерности кода наоборот как-то освобождает. Приходит понимание того, что нет смысла вылизывать каждую строчку, рефакторить под SOLID, применять самые модные практики и фреймворки. Если твой код будет просто нормальным, его перепишут через 5 лет. Если идеальным - ну, через 7-8. Просто доставь заказчику то, что он хочет здесь и сейчас, всё равно это вскоре отправится в мусорку.
VladimirFarshatov
29.05.2023 14:02+1Каждая программа обладает существенным недостатком, часто не устранимым: она написана не тобой.
-
Каждый программист, натыкаясь на свой собственный код по прошествии времени попадает в бинарную логику:
а) Какой дурак это писал?
б) Как круто, надо взять на вооружение..
режим КЭП выключен. ;)
vvbob
29.05.2023 14:02+1а) Какой дурак это писал?
"Сейчас гляну в гите.. А, так это я! Нуууу... в принципе-то код не так и плох..." :)
VladimirFarshatov
29.05.2023 14:02Нуу.. писал где-то тут уже байку из своего опыта: через какое-то время полез в код, обнаружил странность, п.2, вариант "б". ;) Да ладно, ща поправлю!
Во как надо .. упс, так не то что хотелось, ну ок, тогда вот так - фигушки, полез в "гит" .. нашел: писано мною и стоит коммент (удален кем-то позже): "не трогать! это работает только так!" ;) Деталей уже не помню..
Wesha
29.05.2023 14:02+1Приходит понимание того, что нет смысла вылизывать каждую строчку
Лови крудошлёпа!!!
vvbob
29.05.2023 14:02А мне это как-то большую часть удовольствия от работы портит. Стараешься, голову ломаешь как сделать код надежнее, красивее, удобнее для поддержки, а потом через пол года смотришь - а твой модуль либо вовсе выпилили за ненадобностью, либо над ним так надругались что хочется удалить из гита все записи о том что его изначально создавал я.
event1
29.05.2023 14:02Чтобы делать вечное, надо строить пирамиды из тяжёлых каменных блоков. Остальное преходяще.
Если программа приносит пользу, то это хорошо и надо радоваться. То что, пройдёт пять лет и пользователю понадобится новая программа — просто банальная правда жизни.
zloddey
29.05.2023 14:02Можно подумать, без оптимизации фирма бы дошла до банкротства медленнее?
vvbob
29.05.2023 14:02Да мне как-то на фирму наплевать, та еще конторка была, обанкротилась вполне заслуженно (мутили всякие мутные схемы на околооткатах, не то что-бы совсем воровством занимались, но нечестная конкуренция была налицо). Мне свой труд жалко, который просто был одним "вжухом" спущен в унитаз.
R0bur
29.05.2023 14:02+7А ведь задачи, которые решались "старыми технологиями" никуда не исчезли. Есть малый бизнес и индивидуальные предприниматели, которым достаточно того, что умел FoxPro - приложения с локальной базой данных. В нынешнем мире я не вижу инструмента, настолько пригодного для описанной сферы. Может быть, ближе всего к нему 1С, что и обусловило популярность этой среды. Возможно, подобное можно делать средствами Java - насколько понимаю, там есть локальная СУБД. Но насколько же просто в FoxPro for DOS было делать экранные формочки! Прототип приложения (БД + интерфейс) можно было набросать за несколько часов! Не редки случаи, когда полноценные системы учёта разрабатывались и сопровождались одним программистом. Причём те, что я видел, было совсем нетрудно поддерживать и вносить в них изменения при необходимости: понятная архитектура, инструкции для пользователя - прямо на форме ввода данных. Возможно, это просто привычка, и современные средства не хуже?
Areso
29.05.2023 14:02+1Visual Basic / Delphi позволяли делать то же самое, с нужными компонентами.
R0bur
29.05.2023 14:02В общем-то да, но порог вхождения, на мой взгляд, был немного выше. Ну и всё-таки это системы разработки приложений с графическим интерфейсом пользователя, которому, как ни крути, надо уделять больше внимания, чем текстовому интерфейсу. Что касается поддержки баз данных MDB - она была то ли интегрирована в операционную Windows, то ли требовала установки небольшого компонента - уже не помню. С ними можно было даже на Visual Basic Script работать.
event1
29.05.2023 14:02А потом этот один компьютер ломался, один программист попадал под автобус и "малый бизнес и индивидуальные предприниматели" оставались у разбитого корыта.
R0bur
29.05.2023 14:02+1В те времена (начало 2000-х) программистов на FoxPro было примерно столько же, сколько сейчас на 1С. Да и FoxPro этот был не такой чтобы уж совсем универсальный язык программирования, а скорее фреймворк для файловых БД. Так что разобраться в коде большого труда не составляло. Сам язык - не сложнее структурного Бейсика.
iig
29.05.2023 14:02Но насколько же просто в FoxPro for DOS было делать экранные формочки!
Книга по FoxPro, няп, была размером с обычную настольную библию ;) 3 пальца в толщину.
Возможно, это просто привычка
Эффект утенка ;)
R0bur
29.05.2023 14:02Я учился только по встроенной справочной системе. Этого было более чем достаточно. По всем операторам и функциям - подробное описание с примерами использования. Вот только не пользовался конструкторами форм, отчётов и запросов. При некотором опыте всё записывалось намного проще прямо в коде.
А экранные формы делать в условиях, когда у тебя всегда поле 80x25 символов, а не окно непредсказуемой геометрии, - одно удовольствие! Опять же, это ограничение стимулирует к тому, чтобы не перегружать интерфейс. При необходимости можно было создавать многоэкранные формы, которые работали по принципу современных "мастеров" (wizards).
belch84
29.05.2023 14:02+2А ведь задачи, которые решались «старыми технологиями» никуда не исчезли. Есть малый бизнес и индивидуальные предприниматели, которым достаточно того, что умел FoxPro — приложения с локальной базой данных
Согласен.
Вот система, изначально написанная на FoxPro 2.0 for DOS и работающая уже более 30-лет. Данные в ней сохранялись и сохраняются в файлах DBF и (частично) — в MS SQL Server достаточно древней версии. Отдельные приложения системы были переписаны на Visual Foxpro 9.0, другие так и существуют в досовском варианте. При этом некоторые из приложений существуют параллельно в досовской и визуальной, т.е. версии для Windows, с теми же самыми данными. Несколько раз систему пытались переписать на что-нибудь новое, руководство было обеспокоено её древностью (а также bus-фактором, очень близким к единице), но не получилось (кстати, именно руководство для повседневной работы использует досовскую версию — им так привычно). Иногда приходится даже добавлять новые фичи — в более современную версию (если они нужны пользователю — нужно использовать визуальную версию, нет — можно оставаться на досовской).
Эта система предназначена для оперативного учета. Мне очень интересно — что такого нового в учете появилось за эти 30 лет? По-прежнему нужно учитывать приход и расход, и следить за тем, чтобы ничего не терялось. Точно так же — что принципиально отличает интерфейс досовского FoxPro от современного? Да, он текстовый, но вполне себе поддерживает окна и работу с мышью (про легкость создания форм в FoxPro for DOS — чистая правда).Windows-окно основного приложения с четырьмя формами
То же приложение в DOS
Что касается размеров этого бизнеса — в лучшие годы в системе создавалось более 100 тысяч выходных документов в год, а число одновременно работающих пользователей превышало 150. Сейчас, конечно, бизнес сильно сузился, возможно, на порядок.
Еще хочу отметить, что эта система с самого начала задумывалась не как тиражируемая, точнее, при разработке очень быстро стало ясно, что удовлетворить основным требованиям и требованию тиражируемости будет невозможно.
vadim_bv
29.05.2023 14:02+1Формально, MS Access ещё жив. И там тоже можно делать формочки :)
R0bur
29.05.2023 14:02+1Ну, формально жив даже dBASE - пожалуй, наиболее близкий аналог FoxPro for DOS. И неизвестно, насколько эта система была бы сейчас востребована, если бы не $99 за непонятную лицензию. То, что он "для DOS", не может служить причиной отказа, потому что в эмуляторе DosBox тот же FoxPro работает не хуже, чем на аппаратной платформе. А эмулятор этот портирован даже на мобильные устройства.
vadim_bv
29.05.2023 14:02+1dBase, емнип, это что-то даже до FoxPro. Потому что перед FoxPro был FoxBase (и Clipper?), на примере которого отец меня учил слову "browse" ещё лет за 5-7 до того, как в дом проник Интернет :)
R0bur
29.05.2023 14:02+1Да, можно сказать, что все перечисленные продукты используют язык программирования dBASE и базы данных DBF. Clipper - это компилятор языка, остальные - интерпретаторы и интегрированные среды разработки/исполнения. А "browse" - один из аргументов, почему надо было использовать эти продукты, а не, например, Turbo Pascal.
ri_gilfanov
29.05.2023 14:02Стандартная библиотека Python во многом состоит из legacy (букв. наследия) 1990-х и 2000-х годов. Причём, как правило, из legacy хорошо документированного, хорошо отлаженного, многими используемого и официально поддерживаемого.
Elena24Kov
29.05.2023 14:02С появлением ChatGPT ваш технический долг превращается в ваше техническое богатство: кусок кода написанный на любом из ваших древних языков за 2 секунды будет переведён на тот язык, который нужен заказчику. И можете смело писать в резюме любой новомодный язык - считайте, что вы его уже знаете! Кстати, в Котлине с версии 2.0 будет GPT библиотека, которая такие задачи решает без проблем
mickvav
29.05.2023 14:02+1Оптимистично. У ChatGPT большие проблемы с построением "mental models" - для сложных вещей, не валяющихся в базах типовых задач, по которым это чучело учится, оно спотыкается только в лет. Так что простые вещи, типа CRUD-ов к БД оно перепишет запросто, а сложные - не всегда. Другое дело, что сложные вещи покрытые тестами уже доработать напильником обозримо сложно и не адски скучно, это да.
lotse8
29.05.2023 14:02Оптимистичная для программистов статья. Софт не только пишется, но и постоянно переписывается, т.е. работы хватит всем и на все времена.
Gradiens
29.05.2023 14:02Всё со временем превращается в технический долг или проекты клонятся к своему закату
Это нормально.
Гораздо обиднее работать над мертворожденным проектом, который хоронят, не успев выпустить.
Darkhon
29.05.2023 14:02+1Помните ли вы хотя бы один из этих фреймворков? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars…
Dylan Beattie - We're Gonna Build a Framework
cross_join
29.05.2023 14:02Переписывание со старого шила на новое мыло касается в основном небольших и относительно простых приложений. Остальные системы живут десятилетиями и "умирают" разве что из-за прекращения поддержки/ухода разработчиков.
mickvav
29.05.2023 14:02У любого ПО есть "что" написано и "как/на чем" написано - в этом смысле пример с grep-ом - шикарен. Понимание "что" - какой именно инструмент нужен и что он будет делать, ну никуда с 70-х не делось. Да, на C переписали. Ну можно на golang или rust переписать, если очень хочется и от этого есть какая-то польза. И формально исходники на C или на ассемблере PDP-11 (не к ночи будь помянут!) - можно в этом случае похоронить. Но "что" в этом месте не денется никуда особо, и "long live the king".
Zhuikoff
Это называется "в поисках панацеи", лекарства от всех болезней. Недостижимый идеал, к которому нужно стремиться. Но часто новый движок или фрейм на модном языке облепленном тоннами синтаксического сахара оказывается слабее проверенных временем решений. Но чтобы это понять, нужно пройти весь этот путь.. И начать заново...
saboteur_kiev
Главное чтобы эти проверенные временем решения, продолжали развиваться и при этом оставались достаточно стабильными и современными (успевали понимать какие новые платформы или требования стоят к решениям).
Флеш вот не смог нормально в безопасность.
PuerteMuerte
Я в принципе не верю, что не было возможности сделать безопасной коробочку с мультиками. Просто… она им нафиг не нужна была.
javalin
Как-то вы недооцениваете возможности флеша (
begin_end
Это на западе от Flash отказались — но это не весь мир. А так потенциально Flash может пользоваться более миллиарда человек. Как и технологией ActiveX вообще.
И не просто легаси, многое современное китайское железо имеет панели управления на этом.
Про безопасность, когда им надо — взяли и сделали.
Alexey2005
Как будто современная браузерная песочница может лучше. Посмотрите, сколько дыр в безопасности затыкается с каждым обновлением браузеров.
Флеш не смог в мобильные устройства — его там чисто физически было невозможно запустить без того, чтоб смартфоны попросту расплавились от перегрева, заодно полностью ушатав аккумулятор чрезмерными нагрузками. И именно мобильные устройства убили Флеш — кому нужна технология, которую вы не можете комфортно юзать на вашем смартфоне/планшете?
Сейчас мощности смартфонов наконец-то стали достаточными, чтоб Флеш там мог работать, вот только он уже успел помереть. Но, возможно, родится какая-то замена. Вероятно, на базе Unity.
p07a1330
Для смартфонов поддержка флеш была, в том числе - через условно стандартные браузеры.
Puffin'ом пользуюсь до сих пор
saboteur_kiev
Флеш убила внутренний хаос разработки.
Техдолг просто не позволял разработчикам нормально внедрять новые технические фичи и поддержку технологий, поэтому он и был таким тормознутым.