nickita startcev (nicka_startcev) wrote,
nickita startcev
nicka_startcev

Category:

про программирование

Давным-давно программы были маленькими и относительно простыми.

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

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

Первый очевидный переход - от ассемблеров к ЯВУ типа фортрана-бэйсика-паскаля-си.
теперь программист мыслит не на уровне 'переложить значение из регистра Ъ8 в регистр Ъ3, а потом умножить на содержимое регистра Ё6' а на уровне арифметических выражений. Это реальный шаг вперед, теперь программист может удержать в голове намного более крупную конструкцию.

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

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

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

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

Во всех этих наследованиях встает проблема поиска по всей этой каше того места, где сидит логика работы, поиск мест, где ее можно исправить, дикий адский поиск всех мест, где это изменение даст побочные эффекты. При декларированном реиспользовании кода, какой-нибудь strdup/strcmp оказывается реализован независимо чуть ли не в каждом файле кода проекта. Иногда по глупости, иногда из-за невозможност найти нужный функционал в уже написанном, а иногда по причине неподходящести уже написанного или нежелания/невозможности отслеживать все побочки от использования уже написанного кода.

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

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

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

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

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 9 comments