Цитата: Ещё один инженер от 24.06.2020 04:37:43А на ассемблере - еще ровнее, угу.
Вы не понимаете, что все эти технологические софтовые навороты - ООП, далее везде - они направлены на то, чтобы справляться со сложностью.
Все эти технологические софтовые навороты - ООП, далее везде - они направлены на то, чтобы печатать каждый год толстенные книжки об одном и том же, и этим самым кормиться. Все эти фаулеры, шилдты, александрески и прочие авторы *надцатых изданий одной и той же книжки – это верхушка огромной секты адептов ООП.
Тезис о том, что ООП позвоялет справляться со сложностью, уже лет двадцать как, если не более, подвергается сомнению теми, кто разрабатывает действительно сложные системы – компиляторы и операционные системы.
Мало того, ООП ликвидирует возможность развития программного продукта, намертво приколачивая гвоздями
крышку гроба ошибки начального проектирования иерархии классов. Основные принципы современного ООП – класс, объект, абстракция данных, инкапсуляция, наследование и полиморфизм подтипов были изобретены еще в 60-х и в конце концов от последних трех из них почти отказались из-за того, что при их использовании оказалось невозможным исправлять ошибки проектирования, а также из-за крайне неэффективной реализации парадигмы ООП на чисто императивной архитектуре набора процессорных инструкций. Многие из нас имеют дело с вордпроцессорами – одни с мсо, другие с ло. Это сложные программные системы, разработанные с использованием принципов ООП. Мало того, в основу современных форматов и того и другого положены именно три последних принципа ООП – инкапсуляция, наследование и полиморфизм подтипов. В результате развитите как одного вордпроцессора, так и другого было фактически заморожено на уровне функционала вместе со всеми ошибками начального проектирования.
Есть такой термин – рефакторинг. Это способ, позволяющий "починить" веточку иерархии классов, когда выясняется, что результат настолько убог, что пользоваться им невозможно. Так вот весь жизненный цикл программного продукта, разработанного в полном соответствии с заветами борзопишущих членов секты ООП, представляет собой наполовину рефакторинг, а вторая половина – написание никому ненужного кода в реализациях классов на всякий случай.
Libreoffice – яркий пример того, как ошибки начального этапа проектирования кочуют из мажора в мажор и так будет продолжаться, пока не будет полностью переработана архитектура всех основных базовых классов. А поскольку они как раз отражены в формате odf, то совместимости на уровне документов настанет капец.
Цитата:
Ещё один инженер от 24.06.2020 05:37:43Цитата: Ещё один инженер от 24.06.2020 04:37:43Контроль типов вам не нужен? Классы не нужны? Ну и напишите код хотя бы в полмега двоичного исполняемого, и добейтесь, чтобы работало.
Контроль типов присутствует во всех языках ВУ и нет исключений.
Во-вторых, класс, как написано в стандарте 14882 – это тип. Есть встроенные типы, есть конструируемые. Методы конструирования могут быть любыми. Кому нравится арбуз, а кому — свиной хрящик. Лично мне – и тот и другой.
Приходилось участвовать в написании такого софта, и оно таки работало. И не полмега, а гораздо больше – размер оверлеев в сумме превышал 12 мегабайт. Никакого ООП – чистый си и фортран. Технологическая база данных с нуля.
Полмега современного двоичного исполняемого чуть менее, чем полностью, состоит из вызовов функций, которые проверяют уже проверенное или то, что проверять бессмыссленно, и опять вызывают такие же функции во фреймворке/билиотеке, которые ниже, и так несколько раз, прежде чем дойдут до вызова функции из ран-тайм библиотеки. При этом они гоняют параметры туда-сюда по стеку. Я отвечаю – код, который работает с tiff-файлом через библиотеку libtiff и код, который работает с ним же через буст, кюти и прочий оперсиви, короче более, чем в сто раз, памяти он использует в несколько раз меньше, а что касается функциональности, то, по крайней мере, не крэшится, если формат пикселя отличен от 8 бит, число каналов, например, двенадцать, а размер изображения в пикселях в десятки раз больше размера оперативной памяти.