25.05.2025 09:00
artstesh 58 7800 Источник

Введение: Программисты, где ваша вольница? Или как парадигмы превратили нас из ковбоев в архитекторов

Представьте: вы — инженер-программист из 60-х. Ваш код — это дикие прерии, где goto прыгает через функции как ковбой через барную стойку, а память — ваше личное ранчо. Вас внезапно переносят в 2023 год. Вас окружают фразы вроде «SOLID», «иммутабельность», «реактивные потоки». Вы пытаетесь написать пару строк на Python, но слышите: «Стоп. Мутировать переменные? В 2023-то? Это же грех!».

Что случилось с нашей свободой?

За последние 70 лет программирование из искусства постепенно превращалось в ремесло со своими жёсткими требованиями и правилами. Мы больше не взламываем реальность — мы строим мосты по ГОСТу.

  • Раньше: код писали на салфетках, а ошибки исправляли тяжелыми предметами, как тот "клюквенный" русский космонавт в фильме "Армагеддон".

  • Сейчас: парадигмы диктуют, как дышать. ООП? Обязательно. Функциональщина? Без вариантов. Мутации? Только шепотом, иначе код-ревью соберет совет конгрегации священной канцелярии на предмет вашего сожжения на очистительном огне.

Почему это важно? Потому что сегодня ваш код управляет не калькулятором, а:

  • Ракетами, которые садятся на плавучие платформы,

  • Банками, где один null — это чей-то дом, проданный за долги,

  • Умными холодильниками, которые внезапно решают, что вы веган и переводят вас на спаржу с одуванчиками.

Эта статья — манифест потерянной свободы. Мы пройдём через:

  • Кладбище оператора goto, где покоятся мечты о спагетти-коде,

  • Тюрьму ООП, где данные охраняют как форт Нокс,

  • Лабораторию функциональщиков, где даже циклы — вне закона,

  • Суд общественного мнения, где хайп — главный судья,

  • Будущее, где ваш код, возможно, напишет ИИ, пока вы пьёте кофе.

1. Процедурное программирование: Похороны эры «goto»

Когда код был диким

1960-е. Эпоха Assembler и COBOL.
Программирование тогда напоминало стройку без архитектора: вы могли вручную управлять памятью, прыгать между метками, и вообще чувствовать себя демиургом, создающим новые миры и насаждающим им свою непреложную волю. Но эта свобода, на поверку, оказывалась кредитом из ларька микрозаймов за углом. Код превращался в лабиринт из goto, где даже автор через месяц не мог найти выход, и вчерашний демиург ползал по канализационным трубам своего эпохального града в пойсках вентиля включения воды...

Что потеряли: Свободу или анархию?

Раньше goto был космическим кораблём с warp-движком: скакали куда хотели, не спрашивая разрешения. Но именно он превращал код в спагетти-монстра. Проблема не в самом операторе, а в том, как его использовали:

// Типичный код 70-х: куда прыгнем сегодня?
if (error) goto cleanup;
goto calculate;
...
cleanup:
    // 100 строк хаоса
calculate:
    goto validate;

Эдсгер Дейкстра в 1968-м вынес приговор: «Goto considered harmful». Развести **ач в комментариях тогда не могли, потому нагрузка на почтовые отделения сильно выросла - все ринулись активно выражать свои мнения/возмущения и одобрения по этому поводу. Это привело сообщество к ключевому вопросу: можно ли писать код без хаоса(goto)?

Что выиграли: Правила вместо Дикого Запада

Процедурное программирование дало нам:

  • Функции вместо меток.

  • Циклы и ветвления вместо лабиринта переходов

  • Локальные переменные — наконец-то приватность для данных

Раньше вы ездили по городу без ПДД, игнорируя здравый смысл и законы физики, попадая в аварии и застревая в пробках из-за каких-то идиотов, попавших в аварию. Но вдруг по всему городу появились светофоры, разметка и суровые дядьки в форме дорожной полиции. Да, нельзя лихачить, зато теперь не надо на всякий случай писать завещание перед поездкой за продуктами.

Почему это было необходимо?

Эпоха, где код стоил дороже жизни

В 1960-х программирование напоминало русскую рулетку. Ошибка в одной строке могла:

  • Уничтожить космический зонд (Mariner-1, 1962: пропущенный дефис → отклонение траектории → десятки миллионов в мусоропровод),

  • Обрушить экономику (первые банковские системы теряли млн/час из-за goto в транзакциях),

  • Убить пациентов (Therac-25, 1985: race condition в коде 60-х → смертельные дозы радиации).

Лозунг эпохи: «Программист — это сапёр, который не знает, где мина, но если рванёт, виноват будет он».

Кризис профессии: Безумие как норма

  • Требования к разработчикам:

    • Знание ассемблера, машинных кодов и физического устройства ЭВМ,

    • Способность держать в голове 10 000+ строк кода,

    • Готовность работать 90 часов в неделю за право называться «избранным».

  • Реальность:

    • 85% проектов ВПК США выходили за бюджет и сроки,

    • Средняя цена ошибки в финансовом ПО перевалила за 2 млн. долларов,

    • множество программистов бросали профессию из-за нервных срывов.

2. ООП: Диктатура абстракций

Контекст: Когда данные потребовали тюремной охраны

1990-е. Эпоха Java и C++.
Программисты устали от того, что процедурный код превращался в груду не связанных между собой функций. Представьте: вы управляете банком, где деньги лежат в открытых ящиках, а любой может их взять без спроса. Именно так чувствовали себя разработчики, пока ООП не навело порядок.

// Раньше: глобальные данные — как общественный туалет
float accountBalance = 1000.0;

void withdraw(float amount) {
   if (amount > accountBalance) {
      ...
   }
   accountBalance -= amount;
}

Что потеряли: Право на прямой доступ

Раньше данные были общими и беззащитными. Теперь инкапсуляция диктует:

  • Поля — приватные,

  • Методы — ваши единственные посредники,

  • Наследование — как династия, где дети обязаны слушаться родителей.

Даже простое действие вроде «получить имя пользователя» превратилось в ритуал:

public class User {
   private string _name; // Данные под замком

   // Хотите имя? Вот вам геттер
   public string GetName() {
       return _name.ToUpper(); // А тут еще и мутация!
   }
}

«ООП — это как общение с чиновничьим аппаратом: чтобы получить паспорт, вы подпишете кипу документов, побегав с кучей справок по разным кабинетам до появлявления румянца на щеках и желания убивать в глазах. Удобно? Нет. Зато теперь на вас уже нельзя взять кредит, просто назвав имя».

Что выиграли: Империя вместо деревни

  • Переиспользуемость кода: Наследование и полиморфизм позволили клонировать логику.

  • SOLID-архитектура: Мы перестали бояться изменений. Добавить новую фичу? Не надо переписывать 1000 строк.

  • Моделирование реальности: Объекты — как цифровые двойники:  Car,  User,  Payment живут по законам бизнес-логики и реального мира.

ООП — это IKEA для разработчиков. Все детали стандартны, из них можно собрать хоть космический корабль.

Почему это было необходимо? ООП как ответ на цифровой апокалипсис 70-х

Кризис, который изменил всё

К 1980-м миру грозила цифровая инфляция:

  • Программы для Boeing 777 содержали 3.5 млн строк кода — в 10 раз больше, чем Apollo 11

  • 70% IT-проектов проваливались

  • Ошибка в одной функции могла обрушить систему управления АЭС

Революция графических интерфейсов: Когда кнопки потребовали цивилизации

Xerox Alto (1973) — первый ПК с GUI — стал триггером:

  • Каждый элемент интерфейса (окно, кнопка) требовал:

    • Состояния (цвет, позиция)

    • Поведения (клик, анимация)

    • Иерархии (меню внутри окна)

Решение: Smalltalk (1980) — первый чистый ООП-язык. Один из его создателей Алан Кэй сравнил объекты с биологическими клетками: «Каждая знает свою роль и взаимодействует через чёткие интерфейсы».

Цена прогресса

К 1995-му (рождение Java) ООП стало индустриальным стандартом не из-за моды, а по необходимости:

  • Windows 95 содержала миллионы строк кода, без классов это был бы цифровой Вавилон

  • Финансовые системы обрабатывали сотни миллиардов долларов в день, прямой доступ к данным == риск хакерских атак и критических потерь от каждого бага

Хотите почувствовать себя программистом 60-х? Напишите обработчик платежей на чистом ассемблере с goto. Если через час вы не захотите сжечь компьютер — вы или гений, или ваша программа уже всё сломала

Вывод:

ООП дало нам инструменты для масштабных работ. Мы потеряли анархию прямого доступа, но получили власть над сложностью. И да, иерархии абстракций иногда напоминают бюрократию, но без них мы до сих пор копались бы в спагетти-коде.

P.S. Если вам кажется, что наследование — это перебор, вспомните, как вы в последний раз копипастили код. Классы хотя бы делают это элегантно.

3. Функциональное программирование: Тирания иммутабельности

Контекст: Когда данные объявили войну человеческой лени

1958. Рождение Lisp — языка, который перевернул всё.
Пока мир утопал в goto и глобальных переменных, Джон Маккарти создал язык, где функции стали гражданами первого сорта. Это не было прихотью: первые задачи вроде искусственного интеллекта и автоматического доказательства теорем требовали математической чистоты, а не адреналина прыжков по меткам.

; Lisp-код 1960-х: рекурсия и чистота
(defun factorial (n)
  (if (<= n 1)
      1
      (* n (factorial (- n 1)))))

Что потеряли: Право распоряжаться данными

Раньше программист был владельцем данных, теперь ФП диктует:

  • Иммутабельность — данные нельзя менять, только создавать заново.

  • Чистые функции — никаких побочных эффектов.

  • Рекурсия вместо циклов — потому что for — это слишком «грязно».

// Было (императивный стиль):
const arr = [1, 2, 3];
for (let i = 0; i < arr.length; i++) {
    arr[i] *= 2; // Мутация? Да кто её заметит!
}

// Стало (функциональный стиль):
const doubled = arr.map((num) => num * 2); // Исходный массив остался нетронутым.

«ФП — это как воспитание ребёнка: вы не можете заставить его слушаться, но можете создать среду, где он сам захочет вести себя правильно. Удобно! Только если вы не контроль-фрик».

Что выиграли: Мост между 60-ми и эрой Big Data

1960–1980: Истоки для гениев

  • Lisp стал языком ИИ-лабораторий MIT.

  • ML автоматизировал доказательство теорем — без чистых функций это было бы невозможно.

  • Haskell довёл идеи до догмы: «Если код компилируется — он уже работает».

2020-е: Ренессанс через века

Те же принципы стали основой:

  • Распределённых систем (Apache Spark): Нет мутаций → нет конфликтов в кластере.

  • Машинного обучения (TensorFlow): Чистые преобразования данных → воспроизводимость экспериментов.

  • Фронтенда (React): Иммутабельность стейта → предсказуемый рендеринг.

Почему это было необходимо? Потому что мир стал сложнее

Аполлон-11 vs. Big Data

  • 1969: Код Apollo написан на ассемблере — 145 000 строк, каждая критична.

  • 2020-е: Google обрабатывает эксабайты данных ежедневно.

Параллелизм: ФП с его отсутствием состояния позволил масштабироваться без deadlock’ов.

От теорем к нейросетям

  • 1970-е: ML доказывал теоремы в Isabelle.

  • 2020-е: Тот же подход — в обучении GPT-4:

    • Данные → чистые функции → предсказания.

    • Никаких сайд-эффектов → можно обучать на кластерах из 10 000 GPU.

Ирония судьбы: Даже Java, королева ООП, добавила лямбды и Stream API. Мир понял: будущее — за гибридом, где функции и объекты живут в гармонии.

Вывод:

Функциональное программирование дало нам язык для выживания в эпоху мегасистем. Мы потеряли право на анархию, но получили код, который: масштабируется и даже спустя годы не вызывает вопросов в духе: «Что хотел сказать автор?».

4. Общественное мнение: Почему мы молимся на «правильные» парадигмы?

Контекст: Когда хайп стал новой религией

2020-е. Эпоха фреймворков, холиваров и слепой веры в «best practices».
Программисты больше не спорят о том, как решить задачу — они спорят о том, какая парадигма «более священна». ООП? Функциональщина? Или, прости господи, процедурный код? Сообщество превратилось в совет кардиналов, где еретиков сжигают на костре code review.

// Диалог из 2020-х:
— Почему ты выбрал ООП для этого микросервиса?
— Ну... потому что все так делают?
— Правильный ответ. Одобряем.

Что потеряли: Право на здравый смысл

Раньше парадигмы были инструментами. Теперь они — догмы:

  • Культ ООП: «Если в коде нет классов — ты лузер».

  • Фанатизм ФП: «Мутации — грех, даже если это let i = 0 в цикле».

  • Мода на реактивность: «RxJS? Обязательно! А зачем? Неважно».

В стартапе, где я консультировал, команда потратила 2 недели на внедрение Redux в приложение из 3 экранов. Аргумент: «Так делают в Enterprise». Результат: 200 строк кода для управления состоянием кнопки «Отправить».

Некоторые современные разработчики похожи на обезьян с гранатой: бросают  useEffect  и Dependency Injection куда попало, потому что «так в интернете написано».

Что выиграли: Стадный иммунитет

  • Стандартизация: Новый разработчик быстрее входит в проект — шаблоны-то знакомы.

  • Карьерный рост: Сертификаты в резюме вроде «React Certified Developer» звучат солидно.

  • Иллюзию контроля: «Мы следуем best practices — значит, всё под контролем».

Сообщество — как большой оркестр. Да, все играют по нотам, но хоть иногда хочется, чтобы заиграл драйвовый рок, а не вот это вот всё...

Почему это было необходимо?

1980-е: Кризис «велосипедов» и вавилонское столпотворение

К началу 80-х программирование напоминало стройплощадку, где каждый изобретал свой бетономешалку:

  • сотни языков (от Forth до Prolog), но ни одного стандарта

  • 90% кода нельзя было передать другой команде без недельного брифинга

В книге «Мифический человеко-месяц» (1975) Фредерик Брукс писал: «Добавление программистов в горящий проект только замедляет его. Нужны не люди — нужны правила".

Рождение «религий»: Как best practices спасли индустрию от распада

Кризис 80-х требовал универсального языка коммуникации. Им стали парадигмы:

  • ООП как латынь для enterprise-разработки,

  • Структурное программирование — Библия для NASA и Boeing,

  • ФП — мантра для математиков и криптографов.

Механизм выживания:

  • Компании стали требовать SOLID/DRY/YAGNI — чтобы код жил дольше авторов,

  • Университеты преподавали парадигмы как догмы — чтобы выпускники понимали друг друга,

  • Сообщества (как OMG для CORBA) превратили мнения в стандарты.

Результат: К 2000-м время адаптации нового разработчика в проекте сократилось с 6 месяцев до 2 недель.

Почему это было необходимо? Потому что код стал социальным явлением

  • Масштаб: От одиночек в гаражах — до миллионов разработчиков в наше время.

  • Скорость: Если в 1980-х проект длился 5 лет, то сегодня — 5 спринтов.

  • Ответственность: Код управляет беспилотниками, биржами и ИИ — ошибка == катастрофа.

Вывод:

Общественное мнение превратило парадигмы в мемы — легко тиражируемые, но не всегда осмысленные. Мы потеряли гибкость, но получили:

  • Возможность работать в командах из 1000+ человек

  • Единый язык для дискуссий (даже если они сводятся к «ООП vs ФП»)

  • Ощущение принадлежности к «крутому клубу» (React, SOLID, TDD — как значки на куртке)

  • Возможность сменить парадигму, когда старая выходит из моды (привет, jQuery!)

  • Гарантию, что ваш код поймут даже через 20 лет

P.S. Если вы вдруг захотите написать код без парадигм — назовите это «мультипарадигменным подходом». Прокатит.

5. Куда мы движемся: Новые правила или возврат свободы?

Контекст: Когда ИИ стал соавтором, а код — потоком

2030-е? Уже сегодня.
Программирование больше не выглядит как монолог разработчика с компьютером. Это диалог: вы пишете строку, ИИ предлагает три варианта, фреймворк диктует архитектуру, а техлид требует «реактивности». Мы стоим на пороге эры, где парадигмы смешиваются, как краски в калейдоскопе — красиво, но непредсказуемо.

// Типичный код 2023 года: гибрид всего
class User extends Observable {
    private _name: string;

// Функциональный подход в ООП? Легко!
    readonly getName = () => this._name.toUpperCase();

// Реактивный поток данных
    name$ = this.pipe(
        map(user => user.getName()),
        filter(name => name !== 'ADMIN')
    );
}

Когда я впервые пробовал подключать AI к процессу разработки, он предложил мне написать нейросеть для валидации форм. Я отказался. Но через неделю осознал: ИИ не заменяет программистов — он стал новым «коллегой», который иногда советует странное, но чаще экономит часы рутины.

Тренды: Парадигмы будущего или прошлого?

  • Реактивное программирование (RxJS, Kotlin Flow):

    • Данные — это потоки, а код — набор труб и фильтров.

    • Плюсы: Идеально для реального времени.

    • Минусы: Дебажить потоки — как искать иголку в стоге сена... который тоже течёт.

  • Low-code/No-code:

    • «Программирование» без кода — только drag-and-drop.

    • Если вы собираете приложение из блоков как LEGO — вы программист или дизайнер?

  • ИИ-генерация кода (Copilot, ChatGPT):

    • ИИ пишет код, вы лишь редактируете.

Прогноз: Клетка станет просторнее?

  • Гибриды победят: TypeScript уже совмещает ООП и ФП, Rust — низкоуровневый контроль с безопасностью.

  • Декларативность как новая религия: «Опиши, что ты хочешь, а как — не твои проблемы».

  • Программист → Архитектор: Вы проектируете системы, а код пишут ИИ и шаблоны.

Будущее кода — как фастфуд: вы выбираете бургер (парадигму), а робот-повар (ИИ) собирает его из заготовок. Вкусно? Иногда. Полезно?..

Вопрос читателю:

«Готовы ли вы доверить 80% кода ИИ, чтобы сосредоточиться на архитектуре? Или для вас программирование — это священный ритуал, где каждая строка должна быть написана вручную?»

Вывод:

Мы движемся к миру, где свобода выбора парадигм станет новой клеткой. Можно будет собрать систему из кусочков ООП, ФП и реактивных потоков, но за это придётся платить:

  • Код превратится в «коллаж» из чужих решений,

  • Роль разработчика сместится в сторону редактора и архитектора,

  • Старые парадигмы станут «классикой», как виниловые пластинки — ностальгия есть, массово — уже нет.

Заключение: Свобода vs. Эффективность — вечный конфликт

Итог: Прогресс требует жертв, но даёт крылья

Если оглянуться на эволюцию парадигм, кажется, что мы прошли путь от диких ковбоев к архитекторам небоскрёбов. Каждое новое правило — от запрета goto до иммутабельности — забирало кусочек свободы, но взамен давало инструменты для покорения новых высот.

Что мы поняли:

  • Процедурное программирование научило нас структуре,

  • ООП подарило контроль над сложностью,

  • Функциональное — предсказуемость в хаосе параллелизма,

  • Общественное мнение превратило парадигмы в язык, на котором говорит индустрия,

  • Будущее ставит на гибриды и ИИ, где свобода — в выборе, а не в анархии.

Главный вопрос: Стоило ли оно того?

Программирование сегодня — это джаз: вы импровизируете, но в гармонии с паттернами. Можно ненавидеть SOLID, смеяться над монадами в JS или считать ИИ угрозой. Но именно в этом балансе между свободой и правилами рождаются проекты, которые:

  • Легко масштабируются,

  • Переживают смену команд,

  • И даже спустя годы вызывают не «Как это работает?», а «Как это элегантно!».

P.S. Если вы всё ещё сомневаетесь, вспомните: первые компьютеры занимали целые комнаты, а сейчас у каждого в кармане суперкомпьютер. Это произошло не вопреки парадигмам, а благодаря им.

Комментарии (58)


  1. rsashka
    25.05.2025 09:37
    #28350810

    можно ли писать код без хаоса(goto)?

    Э. Дейкстра писал не про отказ от оператора goto, а про улучшение стиля программного кода и автоматизации доказательства правильности программ за счет отказа от инструкций, меняющих ход алгоритма, и это не только goto, но и операторы присвоения: "Оператор goto позволяет нам посредством перехода назад повторить часть программы, тогда как оператор присвоения может создать необходимое различие в состоянии между последовательными повторениями."

    Вот только почему-то никто не предлагает отказаться от операторов присвоения (кроме промежуточного представления SSA), впрочем, как и goto использовать не прекратили :-).


    1. apevzner
      25.05.2025 09:37
      #28351966

      Стиль, одним из основателей которого был Дейкстра, называется "структурным программированием", потому что следование ему придаёт коду определенную структуру, состоящую из простых блоков (циклы, операторы ветвления, присваивания, вызовы процедур и т.п.). При этом разнообразие типов таких блоков невелико и блоки исполняются последовательно, имея одну входную и одну выходную точку.

      Это делает код пригодным для анализа, ручного и автоматизированного


      1. rsashka
        25.05.2025 09:37
        #28351988

        Это делает код пригодным для анализа, ручного и автоматизированного

        К сожалению, все немного не так: https://habr.com/ru/articles/784238/


        1. apevzner
          25.05.2025 09:37
          #28352088

          Не согласен. Ответил туда.


        1. WASD1
          25.05.2025 09:37
          #28352130

          Довольно очевидная вещь, которую сходу можно доказать минимум 2я способами (сверху и снизу).
          И если в качестве "исторической точности" ещё могут быть вопросы (ну типа они там доказали с большими дырками), то с точки зрения принципиальной возможности избавления - вообще не понятно в чём проблема.

          1.
          Частично-рекурсивные ф-ии <=> машине тьюринга.
          Частично-рекурсивные ф-ии можно реализовать при помощи "присваиваний-ветвлений-циклов".
          Доказано.

          2.
          В любом коде можно последовательно избавиться от:
          - рекурсии
          - exception.
          - на SSA-представлении нормализовать циклы (привести в каноническую форму) => избавиться от goto.
          (способ избавления а также что такое SSA-форма предоставляем как самостоятельное упражнение для любознательного читателя).

          Перевести в псевдо-процедурный язык.


  1. Evgeniy_Kuba
    25.05.2025 09:37
    #28350830

    Это еще что, люди раньше руками ели, а сейчас нас ограничивают всякими ложками и вилками :)


  1. apevzner
    25.05.2025 09:37
    #28350846

    Мы получили негласный запрет на goto, ООП, области видимости, строгую типизацию, immutable обекты, 100% тестовое покрытие, линтеры и статический анализ кода, встроенные прямо в компилятор, обязательные к исполнению code style guides, работу строго по таскам и обязательное code review.

    Чего мы так и не получили, это заметного улучшения качества софта в результате внедрения всех этих изнурительных ритуалов.


    1. e_Hector
      25.05.2025 09:37
      #28350882

      Но мы получили большое снижение требований к писателям софта


      1. victor_1212
        25.05.2025 09:37
        #28350996

        это вероятно следствие снижения требований к качеству sw, что стало в большой части ширпотребом, чего не было в те далекие времена, типа из ресторана сделали fast food, дешево и сердито, интересные проекты никуда не делись, но их на всех не хватает


      1. apevzner
        25.05.2025 09:37
        #28351038

        Ну, я не сказал бы. Следование всем этим ритуалам создаёт изрядную ментальную нагрузку, умение это делать - вполне себе требование, при том нетривиальное.

        Так что я не соглашусь, что требования снизились. Но характер их определенно изменился.


      1. isumix
        25.05.2025 09:37
        #28353972

        А следствием этого стало распухшее до гигабайтов ПО которое могло занимать килобайты. И еще одно следствие: железо становится мощнее а воспринимаемая скорость работы с компьютером, как и прежде, как из мема названия ПК "супертормоз 2000".


    1. victor_1212
      25.05.2025 09:37
      #28350906

      ритуалы сами по себе пустой звук, качество кода зависит от исполнителей, какой толк от разнообразного инструмента, если врач не умеет его использовать,

      начинал работать супер давно, могу сказать, что программисты точно были не глупее


      1. apevzner
        25.05.2025 09:37
        #28351048

        Корпорации очень хотят построить процесс, в котором стоимость разработки и качество результата не зависит от исполнителей.

        Смешно при этом то, что почти любой корпоративный продукт (исключения бывают, но они редки) состоит процентов на 80, если не больше, из открытого кода, взятого с гитхаба. Где его разрабатывали, следуя совсем другим процессам.


        1. victor_1212
          25.05.2025 09:37
          #28351162

          есть такое противоречие, привыкли считать людей типа мебелью, везде так где ширпотреб делают


          1. nv13
            25.05.2025 09:37
            #28352074

            Не мебелью. 1-м ресурсом. Или 0.5, а то и 0.125. Не встречал, правда, 0.666 - наверно пока ещё есть куда падать)


        1. Newbilius
          25.05.2025 09:37
          #28353452

          Довольно сильное заявление про 80 процентов открытого кода, взятого с гитхаба) Более того, "выложенный на гитхабе" != "разработан по другим процессам", т.к. там уйма открытого кода, написанного теми самыми корпорациями ;)


    1. Proscrito
      25.05.2025 09:37
      #28350932

      А как можно проверить, или хотя-бы измерить?


      1. apevzner
        25.05.2025 09:37
        #28351026

        Что именно проверить/измерить?


        1. gres_84
          25.05.2025 09:37
          #28359380

          Качество этого вашего софта.


    1. SadOcean
      25.05.2025 09:37
      #28351044

      Зато мы получили много софта.

      Это же классика - улучшением инструментов мы не начинаем работать меньше, мы начинаем выполнять больше работы.


      1. apevzner
        25.05.2025 09:37
        #28351058

        Зато мы получили много софта.

        Угу. А эти "много софта", они, конечно, сделали нашу жизнь отчасти удобнее, т.е., решили некоторое количество наших проблем. С этим не поспоришь.

        Интересно было бы задать вопрос, в каком отношении облегчение нашей жизни находится к количеству произведенного софта и к количеству усилий, потраченных на его разработку?


        1. victor_1212
          25.05.2025 09:37
          #28351506

          вопрос интересный - облегчение жизни и пр. это из области общественных интересов, изготовление sw теперь большей частью бизнес, side effect - кто знает, что более опасно CO2 или AI


          1. apevzner
            25.05.2025 09:37
            #28353848

            кто знает, что более опасно CO2 или AI

            Опасно то, что доступ к нефильтрованной информации стал очень простым и дешёвым. Вот она и засирает населению мозги. А AI там или википедия, особой разницы нет.

            При этом подчеркну, я не считаю интернет особо чем-то вредным. Но когда мы идем по улице и видим валяющийся на земле пирожок, нормальный же человек не подымет и не засунет в рот. А вот информационный пирожок, валяющийся в интернете, каждый примерно первый подымет и засунет себе в голову.


            1. victor_1212
              25.05.2025 09:37
              #28354804

              в основном согласен, но хочу обратить Ваше внимание, что обработка мозгов рекламой с начала ХХ века стала одним из двигателей экономики, как-то быстро сообразили, если тратить 30% доходов на рекламу, можно втюхать что угодно, и повышать качество не обязательно, за сотню лет это довели до совершенства,

              до появления smart phones, трудно было предположить такую степень зависимости какая появилась у людей, не уверен что есть достаточный запас прочности выдержать AI


            1. forever_live
              25.05.2025 09:37
              #28361018

              Разве википедия является источником "нефильтрованной информации"? Ровно наоборот. То же самое и с AI.


        1. SadOcean
          25.05.2025 09:37
          #28352294

          А?
          Я и не говорил, что это сделало или должно было сделать нашу жизнь лучше (хотя вероятно чуть сделало).
          Я говорю как этим инструментом воспользовались.


    1. dv0ich
      25.05.2025 09:37
      #28353736

      Чего мы так и не получили, это заметного улучшения качества софта

      Не соглашусь. Ещё в конце 2000-х баги и вылеты были скорее досадной нормой для софта, в том числе и системного, включая сами операционные системы. А сейчас кто и когда в последний раз видел BSOD на Винде или панику ядра на Линуксах?


      1. apevzner
        25.05.2025 09:37
        #28353816

        Я видел на линуксах такое, что видеодрайвер AMD попутал свою видеопамять с page cache и разнёс файловую систему. И это современное ядро на более-менее современном ноутбуке. Помогло выключить IOMMU, а до того регулярно разносил, и даже partition table один раз разнёс.

        И видел, как на некоторых ноутах отваливается тачпад потому, что когда от него приходит прерывание, то никто из драйверов не признаётся, что это евонное прерывание, и ядро его на всякий случай запрещает, как ничейное, и тачпад остаётся без прерываний и перестаёт работать. И даже хотфикс для этой проблемы написал (https://github.com/alexpevzner/hotfix-kvadra-touchpad) и в соответствующую ядерную почтовую группу рассылки жаловался, никто мне не ответил, так все, кому надо, до сих пор моим хотфиксом и пользуются.

        И много чего другого видел. На современных вполне линуксах.

        Вообще, на линуксе 15-летней давности uptime по году был вполне нормой. А сейчас, месяц продержался без перезагрузки, уже хорошо. Вон, иные сотовые телефоны с андроидом просто профилактически перегружаются ночью раз в сутки по расписанию.

        Насчет BSOD на венде не скажу, поскольку мои пересечения с вендой очень незначительны. Но замечу ехидно, что современный корпоративный стиль программирования заключается в том, чтобы assert-ы и прочие самопроверки, которые могут отправить программу в полёт, в релизных сборках принято выключать, и уговорить граждан так не делать очень сложно (типа, зачем ты тут программу убиваешь, она бы, глядишь, еще пожила, а у ней там пользовательские данные). Так что может потому и не вылетают, что самопроверки отключены мудрым менеджерским указанием.


  1. TechnoMag82
    25.05.2025 09:37
    #28351004

    Раньше код был более оптимизирован, не смотря на сумбурность. Используя классы, прикомпилируются полно проверок и информации о классах. По поводу суперкомпьютера в кармане. Если в начале развития Android, java-разработчики были против статиков, то сейчас их генерируют полно библиотек, приложения занимают много памяти и тормозят, но зато синтаксический сахар, ООПэ и всё такое.


    1. LAutour
      25.05.2025 09:37
      #28353822

      Большой размер кода не от самого ООП, а от способов его применения. Базовые объекты, не наследованные от кучи "предков" с еще большей кучей виртуальных методов должны компилироваться достаточно компактно.


    1. apevzner
      25.05.2025 09:37
      #28353882

      Раньше код был более оптимизирован, не смотря на сумбурность

      Небось процессор такой, сидит и думает "раньше меня кормили каким-то совершенно невнятным кодом с кучей переходов во все стороны, которых не предскажешь и которые срывают мой конвеер. И еще обижались, что дескать, позаботились обо мне, вручную заоптимизировани, а я почему-то всё равно торможу. А сейчас в коде команд хоть и побольше, но мой приятель-компилятор знает, как их расположить, чтобы мне удобно исполнять было, и в итоге получается побыстрее".


  1. temadiary
    25.05.2025 09:37
    #28351006

    странно, что никто не увидел, что это всё таки эволюция, развитие, изменения, а не разбор "почему гоу ту такой плохой" \хотя да сам факт события был тем самым pivot

    хорошо что есть кто фиксирует вехи развития


  1. php7
    25.05.2025 09:37
    #28351034

    А я не вижу ничего особо плохого в goto.
    Его даже сравнительно недавно добавил php.
    И тех проблем которые ранее с ним были сейчас нет.
    Плохо разве то, что не все IDE поддерживают переход к метке.
    goto добавляет слегка сложности. Но без него реализация не факт что была бы проще.
    Я обычно использую его чтобы пропустить какую-то часть кода. Например если в кеше нашли данные, то перепрыгнуть их получение из базы, чтобы if/else занимал меньше строк. Вернее чтобы else вообще не было.


    1. pnmv
      25.05.2025 09:37
      #28351914

      Когда-то давно, нас учили, что выход из цикла по break, это плохо и его необходимо избегать, но последнее время я всё реже об этом слышу.

      Нужен ли goto в современных языках программирования, сказать сложно. Мне очень давно не приходилось сталкиваться с необходимостью использования таких переходов.


      1. LAutour
        25.05.2025 09:37
        #28353856

        goto очень бывет хочется, когда нужно сделать общий выход из процедуры с освобождением выделенной в этой-же поцедуре памяти.


        1. amazingname
          25.05.2025 09:37
          #28356242

          Это задача для try-finally


        1. AnthonyMikh
          25.05.2025 09:37
          #28359054

          Используйте языки с RAII


  1. Dhwtj
    25.05.2025 09:37
    #28351206

    Короткую программу ака х-як и в продакшн можно писать как угодно.

    Но как только программу надо развивать, долго сопровождать, появляется командная работа то вот все жёсткие правила и появляются.

    После четверти текста читать бросил


  1. Dhwtj
    25.05.2025 09:37
    #28351218

    LLM статью написала? Или джун, страдающий резонерством (что одно и то же)

    Опять? Да блин!


  1. Inobelar
    25.05.2025 09:37
    #28351246

    Это ограничение только в голове у кодеров. У разработчиков и инженеров все средства хороши, особенно если нужно не абстракциями обмазываться а последний такт выжимать из железа, и последний байт.


    1. GospodinKolhoznik
      25.05.2025 09:37
      #28351824

      А вы себя к кому причисляете? К кодерам или разработчикам?


  1. vlad4kr7
    25.05.2025 09:37
    #28351402

    Эдсгер Дейкстра в 1968-м вынес приговор: «Goto considered harmful».

    А потом маркетологи такие - https://gotopia.tech/, а в IT уже и забыли, что goto в IT, это harmful и почти ругательство.


  1. senchik
    25.05.2025 09:37
    #28351494

    1. холивар про goto разводят только такие как автор, кому он нужен применяют и дальше...

    2. автор что курит когда обсуждает опечатки в коде? И причем тут ООП?

    3. не осилил этот бред, извините)


  1. Krasnoarmeec
    25.05.2025 09:37
    #28351720

    Про goto.
    Если уж отказываться от goto, то тогда надо убирать его и из ассемблера (jmp).

    Логично же... Или нет?

    И код, конечно же станет просто конфеткой! \s


    1. GospodinKolhoznik
      25.05.2025 09:37
      #28351832

      В машинных кодах по другому без jmp невозможно. А языки высокого уровня для того и нужны, чтобы освободиться от недостатков архитектуры Фон-Неймана.


      1. Krasnoarmeec
        25.05.2025 09:37
        #28356378

        Хотелось бы узнать почему в ассемблере без jmp не обойтись.

        Чисто по логике, как и в ЯВУ, jmp можно заменить на аналоги if-else (j** - ассемблере полно аналогов if-else). Теоретических ограничений я не вижу. Требую пояснений.


  1. pnmv
    25.05.2025 09:37
    #28351900

    От лабиринтов из goto, перешли к грудам процедур и функций, которые мутировали в хаос метедов и нагромождение классов с объектами.

    Кто-то говорит, что порог вхождения снизился, но это иллюзия. Написать свою первую программу стало очень легко, по побочной причине - из-за увеличения доступности техники, однако, что-либо серьезное написать всё ещё сложно, и эта сложность имеет тенденцию к росту. (см. вакансии джунов с километровыми списками требований)

    Передача проекта другой команде, всё ещё, может вызывать муки, трудно совместимые с жизнью, поскольку далеко не везде выделяют время, не только на ведение документации, но и на поддержку читабельности кода. Кроме того, у разных команд могут быть различные представления об этом, что частенько приводит к переписыванию половины всей системы (допустим, новые тимлиды решили, что проще написать с нуля, чем разбираться, но где-то споткнулись и бросили).


  1. TechnoMag82
    25.05.2025 09:37
    #28352410

    А насколько далеко ушли Android-разработчики, со своими паттернами, ООП, SOLID, coroutines, Compose от проблемы NPE и лавирования между жизненными циклами активностей и фрагментов для достижения ожидаемого певедения приложения?


  1. Kahelman
    25.05.2025 09:37
    #28352506

    «Я так и знал что дискуссии будут только по последнему вопросу»

    «Почему это важно? Потому что сегодня ваш код управляет не калькулятором, а:
    Ракетами, которые садятся на плавучие платформы,
    Банками, где один null — это чей-то дом, проданный за долги,
    Умными холодильниками, которые внезапно решают, что вы веган и переводят вас на спаржу с одуванчиками»

    Ваш код НЕ управляет ракетами и прочим. Программу для Аппалона писали в машинных кодах и смогли пропадчить за сотни тысяч километров от Земли.

    Большинство программ управления спутниками писались/пишуться на Fortran о котором у среднего посетителя Хабра нет ни малейшего представления ( автор комментария к ним тоже относится, но по крайней мере он о нем слышал)

    В банках, страховках компаниях тонны кода написанного на COBOL который работает до сих пор, поскольку скрипт Килли с JS +аджай не в состоянии даже понять половины финансовых расчётов

    По поводу торговых роботов на Basic- прочитайте про Investor’s Exchange /Isalnd/ Archopelag - как простой парень написал биржевой движок - кстати код опубликован, писал он по-моему на Foxpro. - для тех кто не в курсе, это практически Excel VBA.


    1. Kahelman
      25.05.2025 09:37
      #28352566

      О походу скрипт кидди набежали… давайте кто тут из отметившихся в комментариях написал код для управления спутником? Вы хоть рассчитать орбиту для запуска ракеты на Луну сможете?


      1. alex8079
        25.05.2025 09:37
        #28352640

        Да это веб-программисты.

        Если у некоторых ПХПшников (по слухам) случается нервный срыв от контакта с Битриксом...
        Фиг с ним, с Коболом, они от портянки, написанной на C в обморок падать будут пачками.

        "Банками, где один null — это чей-то дом, проданный за долги"
        Максимальный эффект от неожиданного null - это "при нажатии на кнопку ничего не происходит" или "при нажатии на кнопку вылезла мутная ошибка". Для того, чтобы совершилось какое-то качественное действие, это действие необходимо прописать.
        Хотя повсеместное распространние убогой реактивщины на фронтенде приблизило нас к опасной границе, после пересечения которой "фатальная ошибка" может возникнуть из-за того, что кто-то забыл, что какая-то часть стейта влияется где-то еще на что-то. Увеличение когнитивной сложности в веб-прогграммировании можно отрицать сколько угодно, но оно настигнет нас и больно укусит.

        И да, постепенный отказ от императивщины в финансовой сфере - это катастрофа. Эти "дети" все-таки сломают что-нибудь важное рано или поздно.
        Главное - это не подпускать их, с этими декларативно-реактивными подходами, к ядерным объектам .


        1. Kahelman
          25.05.2025 09:37
          #28352704

          На ядерных объектах фильтр стоит на входе: надо хотя бы слегка в. Физике/математики рубить


        1. Format-X22
          25.05.2025 09:37
          #28352730

          У гугла в интерфейсе со списком доменов для рекапчи кнопка под списком с текстом "Да" удаляла аккаунт. Баг пофиксили, но моему замешательству не было предела.

          В одной большой финансовой компании, услугами которой пользовались большинство читателей хабра, в интерфейсе иногда возникал баг, показывающий что у тебя на счету лишних полтора миллиона. Клиенты пытались вывести, процессинг конечно же не пропускал, но было забавно.

          А вот в другой компании, которой мало кто пользовался, баг отобразил исчезнувшие полтора миллиона евро и клиент натурально отъехал на скорой. И вроде реальных потерь нет, а вот здоровье и срок жизни немного уменьшился.


        1. VanishingPoint
          25.05.2025 09:37
          #28352810

          Реактивщина не увеличивает сложность а уменьшает.


        1. anshdo
          25.05.2025 09:37
          #28353234

          Учетная система британской почты, разорившая и отправившая под суд больше тысячи человек, и нескольких из них доведшая до самоубийства, была написана тогда, когда мамки этих ваших скрипт кидди ещё в девках ходили. Безо всякой реактивщины-декларативщины.


  1. VVBash
    25.05.2025 09:37
    #28352910

    Прочитал с интересом, ибо я вот тот самый программист, хоть не из 60-х, но из 2000-х. :) Так получилось, что все это время программировал "в одного", для себя и не принимал участия в программерских тусовках. Есть опыт использования и ассемблера, и даже машкода pdp-11, но последние четверть века это только c++(ардуино), php, js, mysql и, недавно, python.

    Так вот, к чему я: разумеется, я использую современные библиотеки и, порой, когда "что-то идет не так", лезу в исходный код и разбираюсь, как оно там работает. И, нередко, матерюсь от чрезмерной избыточности и, одновременно, бестолковости. Обновить бит в байте по последовательному интерфейсу (для 8 сегментного дисплея) - обновляем бит в буфере, буфер заливаем в интерфейс - ок, все правильно. Обновить одновременно 8 бит - проделываем то же самое 8 раз! И такое сплошь и рядом...

    Самое забавное: я читаю и понимаю код, в том числе современный. Но попытки читать статьи современных программистов (тут, на хабре) очень сложно - это какой то другой язык, другая терминология.

    "Старую собаку новым трюкам не обучить" - это, видимо, про меня. :) Программирование как было хобби, так и останется...


  1. Germanjon
    25.05.2025 09:37
    #28353070

    Как раз сегодня ехал на работу и думал, как хорошо было на дорогах в начале 1900-х, никто не диктует "как дышать" - едь с какой хочешь скоростью, проезжай перекрёстки как хочешь, разворачивайся как хочешь. А теперь никакой свободы, обязательно нужно учить странные правила "о 200 пунктах" и зачем-то их слушаться.


  1. Dovgaluk
    25.05.2025 09:37
    #28353992

    • 85% проектов ВПК США выходили за бюджет и сроки

    А в ВПК софт - это точно главная часть?