Исправление byko3y, (текущая версия) :
он не мог развиваться кем попало, потому что кто попало не осилит даже конфигур, мейк, мейк инсталл
В чем проблема? Секретарша прочитает пару глав книги по сишке, в stackoverflow посмотрит, как собирать ядро, и поправит пару строчек, и отправит пул реквест. Ее код примут, конечно же, потому что никому не помешают лишние руки. И такие проекты есть на гибхабах, там половину женских лиц в разработчиках.
если нет объектов, вся сложность размазывается прямо в коде, методы обрастают десятками аргументов, которые не всегда надо передавать все, появляется миллион мусорных структур данных, для хранения всяких промежуточных состояний, проверок на целостность и валидность данных внутри методов
когда у тебя бизнесовые модели с нескольким десятком свойств и разными ветвлениями обобщений и конкретизаций и проект постоянно их развивает, процедурный код становится помойкой в которую страшно лазить и которую можно только наращивать дальше добавляя свое говнецо скраешку или переписывать без конца
У меня нескромный вопрос: ты писал когда-нибудь программы? У меня после твоих фраз сложилось впечатление, что ты их мне копипастишь отрывками откуда-то из книжек — настолько они канонично-абстрактны. ну то есть отрывочно куски некоторые понимаю, понимаю откуда они взялись, но не понимаю, какая здесь твоя мысль. Может быть ты спешишь куда-то, может быть считаешь излишним пояснять причинно-следственные связи, но понимать такой текст очень тяжело — в 26 минут я закончил свой предыдущий ответ, сейчас 43-я минута, а я до сих пор до конца не вкурил, какой смысл этого абзаца.
Смотрим код ядра линукс — где там десятки аргументов, миллион мусорных структур данных? Нет их. Так зачем ты о них пишешь?
проверок на целостность и валидность данных внутри методов и все это либо не имеет контрактов, т.е. типобезопасности для ссылочных типов
А при чем тут обсуждение процедурного программирования? В паскале контракты есть, даже в старом, который без классов. По сути ты называешь недостатки одного конкретного языка Си здесь, а также в тезисе
когда у тебя бизнесовые модели с нескольким десятком свойств и разными ветвлениями обобщений и конкретизаций и проект постоянно их развивает
А вот если говорить про
процедурный код становится помойкой в которую страшно лазить и которую можно только наращивать дальше добавляя свое говнецо скраешку или переписывать без конца
То по факту 99% проектов на классическом класс-ориентированном программировании, вроде какого-нибудь Qt или стандартной жавы представляет собой именно наращивание, добавление говенца сбоку, поскольку единственной альтернативой является переписывание — именно это и сделал Qt или Unreal Engine, которые переписали с нуля стандартную либу, поскольку это является единственным способом расширения онной.
Исходная версия byko3y, :
он не мог развиваться кем попало, потому что кто попало не осилит даже конфигур, мейк, мейк инсталл
В чем проблема? Секретарша прочитаешь пару глав книги по сишке, в stackoverflow посмотрит, как собирать ядро, и поправит пару строчек, и отправит пул реквест. Ее код примут, конечно же, потому что никому не помешают лишние руки. И такие проекты есть на гибхабах, там половину женских лиц в разработчиках.
если нет объектов, вся сложность размазывается прямо в коде, методы обрастают десятками аргументов, которые не всегда надо передавать все, появляется миллион мусорных структур данных, для хранения всяких промежуточных состояний, проверок на целостность и валидность данных внутри методов
когда у тебя бизнесовые модели с нескольким десятком свойств и разными ветвлениями обобщений и конкретизаций и проект постоянно их развивает, процедурный код становится помойкой в которую страшно лазить и которую можно только наращивать дальше добавляя свое говнецо скраешку или переписывать без конца
У меня нескромный вопрос: ты писал когда-нибудь программы? У меня после твоих фраз сложилось впечатление, что ты их мне копипастишь отрывками откуда-то из книжек — настолько они канонично-абстрактны. ну то есть отрывочно куски некоторые понимаю, понимаю откуда они взялись, но не понимаю, какая здесь твоя мысль. Может быть ты спешишь куда-то, может быть считаешь излишним пояснять причинно-следственные связи, но понимать такой текст очень тяжело — в 26 минут я закончил свой предыдущий ответ, сейчас 43-я минута, а я до сих пор до конца не вкурил, какой смысл этого абзаца.
Смотрим код ядра линукс — где там десятки аргументов, миллион мусорных структур данных? Нет их. Так зачем ты о них пишешь?
проверок на целостность и валидность данных внутри методов и все это либо не имеет контрактов, т.е. типобезопасности для ссылочных типов
А при чем тут обсуждение процедурного программирования? В паскале контракты есть, даже в старом, который без классов. По сути ты называешь недостатки одного конкретного языка Си здесь, а также в тезисе
когда у тебя бизнесовые модели с нескольким десятком свойств и разными ветвлениями обобщений и конкретизаций и проект постоянно их развивает
А вот если говорить про
процедурный код становится помойкой в которую страшно лазить и которую можно только наращивать дальше добавляя свое говнецо скраешку или переписывать без конца
То по факту 99% проектов на классическом класс-ориентированном программировании, вроде какого-нибудь Qt или стандартной жавы представляет собой именно наращивание, добавление говенца сбоку, поскольку единственной альтернативой является переписывание — именно это и сделал Qt или Unreal Engine, которые переписали с нуля стандартную либу, поскольку это является единственным способом расширения онной.