От си уже поздно отказываться.

То что ты называешь контекст - это состояние машины.

Разупоритесь, юноша. Я такого не говорил.

Проблема объекта в том, что он «знает как себя отрисовать»

У объекта нет никаких проблем. Проблемы в вашей голове.

Расскажи это фанатам функциональных языков программирования :-) Удалённо, конечно. Не в баре… Покажи хоть один функциональный ЯП где нет классов

но при этом ему надо передать информацию о внешнем мире. Что в принципе противоречие.

Задача ООпринципа в абстракции построить кучу когерентных объектов с low coupling и high cohession (плохо на русский переводится), а не один большой объект, который и является противоречием для большой системы

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

В нормальном, отрефакторином коде, а пока будет индусстриальное программирование, нам это не светит. Про коллбеки и замену его паттерном Observer не слышал ?

Ну и что? Есть ещё event loop. Есть polling. Всё это нужно и полезно.

В первый раз ты ошибся с неизвестностью ООП в момент начала разработки ядра

Опять же, не ошибся.

теперь пытаешься что-то доказать цитатой, не имеющей никакого отношения к теме

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

Об этом говорилось вот в этом видео, например: https://www.youtube.com/watch?v=V6VP-2aIcSc

В видео показывается то, что в итоге получилось после замены объектов на функции?

Там последовательность другая. Сначала делают фигнятесты вместо того что предполагалось, а потом фигню под фигнятесты.

проработка архитектуры в неявном виде => проблемы, если нет привычки все недостающее в уме прокручивать.

На подавляющем большинстве задач прописывание и проверка data flow избавляет от кучи приключений.

low coupling и high cohession (плохо на русский переводится)

Таки скажи, если перевести на русский, получиться противоречие.

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

ядра начиналась как вполне несложный проект

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

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

Более простой пример извращения в программировании - TDD

На самом деле, сам Кент Бек в своей книжке говорит, что не уверен, что его методика приемлема везде. Кроме того, у него были удобные инструменты для такого стиля разработки. И с этими инструментами всё выглядит заманчиво. Но я, например, не видел таких удобных инструментов для C++.

Если весь код зависит от побочных эффектов (ввод-вывод, отрисовка GUI, шевеление какой-то механикой), то вы всё будете подстраивать под мок-объекты и, соответственно, тесты будут проверять работу этих мок-объектов, а не реального ПО. Хотя при определённых условиях и это может быть временным вариантом.

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

Я мимокрокодил, и на свои скрипты тесты не пишу. Но как в том числе бизнес аналитик - клянусь, что всё нужно начинать с датафлоу.

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

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

Расскажи это фанатам функциональных языков программирования :-)

В функциональных языках есть понятие замыкания. Функция замыкает контекст. Т.е. если в области видимости, где функция определена, есть свободные переменные, то она может использовать их - это и будет контекст.

В чистом ООП, все эти переменные надо будет передать в конструктор класса.

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

на момент старта разработки ядра ООП было хорошо известно.

А на g++ без слёз смотреть нельзя было, и ваще он был текстовым препроцессором. Не на лиспе жи было minix переписывать.

И как можно тупее.

global в питоне - наше всё. Естественно, с умом.

В функциональных языках есть понятие замыкания.

Вспомнил замыкания JS как лайфхак для локального контекста - вздрогнул.

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

Кстати, вопрос к любителям тестов. Есть классический пример. Например, у нас функция на Питоне, которая принимает длины трёх сторон треугольника и возвращает тип треугольника: разносторонний, равнобедренный или равносторонний. Сколько нужно тестов для проверки корректности работы этой функции?

Почему в голове автора нельзя одновременно НЕ_игнорировать архитектуру модели данных и при этом хранить всё в объектах без потери производительности при кодировании и не создавая бестолковых вещей?

Это ж надо две мысли в голове держать, или блокнотик завести если память подводит. Трындец как сложно.

Главное в том, что меня, в отличие от многих специально учили проектировать архитектуру по. Да с использованием паттернов и других практик. И пофиг, что я никогда их не использовала и половину уже забыла.

Сколько нужно тестов для проверки корректности работы этой функции?

3*мощность(континуум)

Кстати, вопрос к любителям тестов. Есть классический пример. Например, у нас функция на Питоне, которая принимает длины трёх сторон треугольника и возвращает тип треугольника: разносторонний, равнобедренный или равносторонний. Сколько нужно тестов для проверки корректности работы этой функции?

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

Вы же почему-то подумали

Потому что:

слишком старый проект

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

Елси ты не это имел ввиду, то объясни какое отношение к теме имеет возрастная характеристика.

Ну так не пейте токсические спирты включая этанол.

Ты скачешь с темы на тему быстрее, чем самая популярная в борделе шалава по херам…

Думаю, этого вопроса в принципе не стояло.

И раз уже об это заговорили, разве на тот момент плюсы уже победили Objective-C? Стали бы на них смотреть в первую очередь?

Держать в голове «чтобы можно было написать тест если понадобится» - достаточно. Покрытие от задач зависит. У меня есть библиотеки, где без 99-100% покрытия себе дороже. И есть приложения где совсем по вершкам.

Но как в том числе бизнес аналитик - клянусь, что всё нужно начинать с датафлоу.

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

Например:

• По таймеру (эвент) с частотой килогерц читаем из порта - плохо.
• Поток данных из порта (с частотой килогерц) - хорошо.

Если не надо валидировать параметры

Ок, можно предположить, что некое внешнее устройство ограничивает ввод нулей или отрицательных параметров. Но, например, проверка на ввод 1, 2, 10 явно должна быть внутри функции.

Елси ты не это имел ввиду, то объясни какое отношение к теме имеет возрастная характеристика.

Проект: создание операционной системы, как думаете, проще его писать для поддержки железа типа 386 процессора или <имя любого современного десктопного процессора>?

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

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

По таймеру (эвент) с частотой килогерц читаем из порта - плохо.

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

А вот не помню. Тыкал Objective-C только в контексте WindowMaker-а. Не думаю, что в gcc был готов.
И в школе я много слышал про c++ (90-92 гг), а про Objective-C - ничего.

сможет ли она его сварить?

А зачем собаке варить пиво? Миллионы людей пользуются компьютером и не могут его ни собрать ни починить. И это люди из ит-области.

Собаку можно научить…

А человека? Или это завуалированное сравнение человка с собакой?

Ок, логика ясна.

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

Вопрос про ядро изначально неверно стоял, отчего и ответ звучит неубедительно. Тут скорее встаёт ответный вопрос: а точно ли в ядре нужно ООП?

при этом ему надо передать информацию о внешнем мире.

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

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

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

Я это к тому, что от заучивания до действительного понимания есть несколько ступеней.

А научить можно и глупостям.

Вопрос в знании методологи. На самом деле, там полтора правила, которые любой осилит за пару часов. Просто про них надо знать, ну или чтобы кто-то сказал.

от заучивания до действительного понимания есть несколько ступеней.

«Если крякает, как утка, плавает как утка, то это утка». Если собака приносит пиво, когда просишь, то не все ли равно, умеет она варить или нет?

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

Неполезно увлекаться пресловутыми серебрянными пулями.

А ОО-идеи рождались не в научной, а в инженерной среде.

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

Один генеративный (property-based) тест.

эволюция ушла в другую сторону

пиво варить умеют столько же людей, сколько и собак, в пределах статистической погрешности.

Ну потратил ты 10 лет на прохождения этих ступеней для понимания. А завтра все уже пишут на раст++, где твои знания нафиг не нужны.

Если бы это было необходимым навыком, умело бы большинство. Замени это заваркой чая из пакетика, если тебе больше нравится. Для собак это уже околоневыполнимая задача.

Просто добавится ещё один язык к 5-7 другим (от уровня «хорошо знаю» до уровня «могу с гуглом нахерачить»). Язык после пары-тройки ступеней не так уж важен.

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

Старинный фармакалогический справочник

Препараты не из одного только спирта:

Spiritus vini 95°.
Spiritus vini 90°.
Spiritus vini 70°.
Spiritus vini 40°.

Обладает антимикробным, наркотическим и местным раздражающим действием.

Слабые растворы (1–2%) несколько усиливают действие пепсина.

Всякая технология, стиль программирования - хороши на своём месте.

До 3 версии в php небыло толкового ООП. Причины: не хотели удлинять время сборки скриптов. Но я всё равно умудрялся писать в стиле ооп используя case swith. И я рад что оно там появилось.

Да наследование «КАК ПРАВИЛО!!! с исключениями» приносит трудно находимые ошибки, и можно его избежать, так пускай оно всё таки будет.

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

Шутка на

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

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