Вот, многие сетуют, дескать программы стали просто огромными, уже не килобайты а мегабайты места занимают. А работать стали ещё хуже. В принципе, отвечу почему и кто виноват.
Виновато, как ни странно, ООП (объектно-ориентированное программирование). Когда программирование было "линейным", с функциями в подгружаемых модулях, это было ещё пол-беды. Но с ООП пришла полная феерия. В том смысле, что написанный чертзнакогда и чертзнакем модуль, становится центром всей структуры, иерархически.
Объясню на простом примере типа "Кнопка", класс "TButton". У кнопки есть собственные свойства, функции и обработчики событий, мыши в частности. Допустим, ты решил, что простой кнопки тебе недостаточно и ты решил создать класс-потомок, с определёнными параметрами. Ну и отсебятины чуть добавить в обработчик события onClick. Нет проблем.
Если ты хочешь просто "украсить" кнопку, то не получится. Придётся просто наследовать от более глубокого класса, "TWindow", у которого в отличие от кнопки есть Canvas, рисуй на здоровье. Только события мыши обрабатывать (перерисовывать) надо будет самостоятельно. А лень.
Потом ещё кто-то хочет унаследовать не оригинальную "TButton", а твою кнопку, чтобы добавить ещё отсебятины... Вот в этом-то весь и вопрос (самая засада). Если в твоём потомке будет какая-либо ошибка, то её повторят все потомки твоего класса. Не говоря уже об увеличении размера кода.
В частности, о размере: Известно-ли вам, что компилируемая программа включает в себя все, так или иначе задействованные библиотеки? За исключением конечно тех, которые ты сам выносишь за пределы исполняемого файла и подключаешь как внешние? Вот как-то так. Плюс прибамбасы с иконками и свистелками, туда-же складываются, если внешними библиотеками не озаботиться.
Ну и напоследок, даже стоит отдельной темы, наши доморощенные бухгалтерские приложения. Это вообще просто песня. Недавно вдруг подобное произведение искусства программирования из налоговой отказалось работать. Выдавая совершенно невнятную ошибку, правда с кодом. Погуглил. Оказалось, этой фигне не понравился модуль Excel устаревший. Понятно, что там программисты продвинутые, используют Excel последней версии. А я куда его на старенький двухядерник с гигом памяти запихну?!
А не подскажешь? Мне как аттестованному мастеру сварочного производства второго уровня, всегда было интересно знать. Зачем же все-таки нужен горячий проход сварного шва при использовании электродов с основным видом покрытия.
Я все же к тому, что тема поста очень специфичная. И ее как-то не просто изложить так, чтобы стало понятно всем и вся. Либо в беседки что ли, либо на тематических форумах. Либо уж излагать так, чтобы любой понял её.
Размещено через приложение ЯПлакалъ
Причина говнокода современных программ, ТС, в том, что время программиста стоит дорого, а железо дешево, вот и все. Проще указать в системных требованиях 100500 гигов оперативки, чем оптимизировать код, этим практически никто, кроме микроконтроллерщиков не занимается, щас даже на тестирование забивают, автотесты прогнали и норм.
Большинство программ любимых из детства которые приводят в пример типа вот как надо и работает и весит килобайты. сделаны на библиотеках классов mfc и vcl. Ещё с 90х.
Программы большие больше из-за того что сейчас никто не парится мегабайтами, надо одну функцию вместо того чтобы включить ее код, подключаем целую библиотеку. Надо в степень возвести, вместо своей функции в три строчки кода. Подключаем библиотеку матана. В которой есть все чтобы вывести на орбиту ракету итд. Надо новую кнопочку подключаем библиотеку в которой 100500 компонентов с 4к контентом в ресурсах
Да потому, что оплачивают за колличество строк когда, появился индийский гавнокод, где много ненужные строк кода, на работу не влияет, а платят больше. Вот вам и причина!
Размещено через приложение ЯПлакалъ
Виновато, как ни странно, ООП (обьектно-ориентированное программирование). Когда программирование было "линейным", с функциями в подгружаемых модулях, это было ещё пол-беды. Но с ООП пришла полная жопа. В том смысле, что написанный хрензнакогда и хрензнакем модуль, становится центром всей структуры, иерархически.
ООП придумано как раз для того, что бы улучшить структуру программы, разделить на модули, сделать её более понятной(что в результате приводит к меньшему числу ошибок).
За счёт ООП можно применить шаблоны проектирования, значительно упростить работу в команде.
Линейное программирование годится только для мелких программ.
Непральна, ТС. Ща не пишут, ща из шаблонов набирают под нужный результат. Совместимость - похуй, сначала наберем, потом костылями залепим - железо позволяет. Вот и все.
Размещено через приложение ЯПлакалъ
Да потому, что оплачивают за колличество строк когда, появился индийский гавнокод, где много ненужные строк кода, на работу не влияет, а платят больше. Вот вам и причина!
За объёмы кода давно уже не платят. Сейчас оплачиваються жопочасы.
На самом деле, причин этому больше: 1. Возросшие мощности железа отучили мороки с оптимизацией. Гиг туда, гиг сюда - кому какое дело, железо тянет. 2. Сломанные процессы разработки. Мода на всякие аджайлы создает монстров. И в самом аджайле нет ничего плохого, просто многие считают, что если они делают стендапы утром и у них есть доска с стикерами- у них аджайл. Плюс это приводит к аду с требованиями. Изначально задумывали сделать автомобиль, потом решили, что он ещё должен уметь ездить под водой, а в конце его вообще переделали в самолёт. В результате у самолёта есть перископ, АБС и багажник сзади.
оооо. еще оказывается существуют дельфисты. охренеть. ))) проблема не в ООП, а в рукожопости. если быть более точным в пофигистичности. вот кто сейчас во всяких бюстгалтерских программах будет заниматься оптимизацией? эту проблему давно взвалили на железо. главное скорость реализации.
оооо. еще оказывается существуют дельфисты. охренеть. ))) проблема не в ООП, а в рукожопости. если быть более точным в пофигистичности. вот кто сейчас во всяких бюстгалтерских программах будет заниматься оптимизацией? эту проблему давно взвалили на железо. главное скорость реализации.
А при чём тут дельфисты? Можно подумать, в VC++ или в Qt классы сильно названиями отличаются. Да и Lasarus вроде ещё не сдох.
Не нравится ООП - не используй. ХЗ только чего ты там напишешь, используя линейный подход)
Да, сейчас для рисования одной кнопки подключается тысячи библиотек и выполняется куча ненужного кода. Зато и кнопку можно на форму вывести щелчком мыши, а потому софт становится в разы доступнее и любая гламурная блядь имеет возможность демонстрировать свои сиськи! А не будь ООП, кучи библиотек и терабайт быдлокода, софт остался бы доступен только крупным корпорациям.
Это сообщение отредактировал Admin1C - 17 июн 2020 в 06:04
Ды ты ламер! Обвинить ООП в тупизме и деградации кодеров - это сильно! ООП принципам уже 50 лет! И еще 20 лет назад не было гиговых апликух с элементарной базой функционала. Почему? Потому что, блять, не было тысяч ебучих пустых библиотек, импортируемых ради одной ебаной трехстрочной функции! Как же, сука, бесит, когда тупой еблан, прочитавший статью на хабре, добавляет 30 метровую библиотеку гуаву ради ебучего предикат-чека, когда у тебя 99% кода покрыто арг-чеком апачи-ланг3. Сука, ебать их анально без смазки! А самый пезедец творится на стэковерфлоу. Последние 10 лет там рекомендуют библиотеки вместо инлайна 10-строковой функции. Конвертировать ргб в смик? вот вам либа, конвертирующая все блять известные форматы, включая пдф док и растр на 50 метров и там есть ебаная функция на 10 строк. надо обязательно эту либу подгрузить всю... Пидорги, мнящие себя лидами после года гугления хуеты и копипасты, продвигаемые эффективными долбоманагерами - вот корень зла. Манагеры тупы до одури и им похуй на матчасть. Лиды нихуя не знают сами кроме громких слов с хабра. Как итог - 1000 строчное сочинения таких вот ебланов весит гиг. ГИГ! ебать их в сраку!!!! PS: Вот жеж у меня подгорело !
А не подскажешь? Мне как аттестованному мастеру сварочного производства второго уровня, всегда было интересно знать. Зачем же все-таки нужен горячий проход сварного шва при использовании электродов с основным видом покрытия.
Я все же к тому, что тема поста очень специфичная. И ее как-то не просто изложить так, чтобы стало понятно всем и вся. Либо в беседки что ли, либо на тематических форумах. Либо уж излагать так, чтобы любой понял её.
ну прикинь, если ты этот же шов сделаешь не в один проход, нужным электродом. а в пять, вдоль, поперек, зигзагом и елочкой, а потом еще раз вдоль. да разными электродами. и что в итоге получится?
Это сообщение отредактировал МимоПроходил - 17 июн 2020 в 06:15
Ну и напоследок, даже стоит отдельной темы, наши доморощенные бухгалтерские приложения. Это вообще просто песня. Недавно вдруг подобное произведение искусства программирования из налоговой отказалось работать. Выдавая совершенно невнятную ошибку, правда с кодом. Погуглил. Оказалось, этой хуйне не понравился модуль Excel устаревший. Понятно, что там программисты продвинутые, используют Excel последней версии. А я куда его на старенький двухядерник с гигом памяти запихну, вашу мать?..
Это ты еще не игрался в игру под названием 1с. Когда ссука каждая отдельная конфигурация - и каждый дрочит как хочет.
Там некоторые вещи даже не поддаются логике. Вот смотри - есть функционал "Вести раздельный учет партнеров и контрагентов" призван он чтобы можно было для одного Партнера указывать несколько Юридических лиц, потому что партнера как бы один, а контор многа. И все бы заебись было если бы не одно интересное но... Если ты галочку эту снимаешь, то у тебя скрывается справочник контрагентов, но не перестает использоваться в куче документов - например кассовых и банковских. Но что-то сделать с контрагентом ты не сможешь, поскольку он создается через хуй пойми какую жопу фоном и недоступен для редактирования, но доступен для выбора в документе. При попытке открытия формы контрагента, открывается кто? правильно - партнер, совершенно отдельный объект.
Это сообщение отредактировал Барабульк - 17 июн 2020 в 06:17
А вообще автор путает теплое с мягким. Объем кода если он качественный никому не мешает. Тем более пишет этот объем автодополнение. :) Навигация по нему тоже за счёт ide. По одной кнопке. А вот в бинарник весь этот дополнительный объем не идет. В бинарнике это если грубо набор функций(если не грубо то набор условий и переходов ) и ООП это все также набор этих функций и куча красивого кода для человека и ide ,а не для компилятора, который откинет все эти обертки на этапе компиляции.
имея 10 классов различающихся одним методом в бинарнике мы получим 10х объем метода + 1 объем класса вместо 10х( объем метода + объем класса). С учётом того что можно вызывать базовые методы, на практике ещё меньше.
Это теплое, а теперь почему оно не мягкое. Допустим выпиливаем нафиг все богомерзкие ООП. Берём чистый православный С и винапи безо всякого мфц и корячим в нее твой екселевский компонент. Как библиотеку или будем общаться с ним через сообщения не важно хоть через веб, программа будет в пару сотен строчек кода только для того чтобы показать одно окно, белое даже без серого фона :) в которой стопицот строчек кода захардкоденых сообщений для общения с конкретной версией библиотеки экселя потому как список того чего можно дёрнуть из либы и не выводится в ошибку напрямую зависит от версии этой либы.
. Да бинарник будет скорее всего меньше на пару килобайт но это не точно, и вот вопрос: как все это уменьшит размер библиотеки от экселя. И привязку к конкретной версии?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
Обвинить ООП в тупизме и деградации кодеров - это сильно!
yaplakal.com