Серия видео по Rust для начинающих

Почему монополисты так решили? Разве им не выгодно использовать языки получше?

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

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

Нет,

а похоже что да

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

а ты сколько ядер на расте написал? Или других каких полезных и известных программ?

А я что, программист ядра писать или другие полезные и известные программы? Ну и аргумент из серии «сночала свои работы покажи», так что я на твоём месте выложил пароль, как настоящий самурай.

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

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

у меня профильный диплом есть )

Почему монополисты так решили? Разве им не выгодно использовать языки получше?

Очевидно, те кто решает, не опускаются до такого низкого уровня. Если ты условно руководитель стройки века, с чего бы тебе вникать в детали уровня - «А каким инструментом работают мои рабы» ?

Конечно в общих чертах всё это как-то прослеживается, но в то же время не является целью, лишь средством к достижению целей.

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

неплохая, хорошая шутка.

Почему монополисты так решили?

потому что так выгодно лично им. А все эти сказки для придурков про прогресс слушать просто смешно.

Google, Oracle, Amazon - это зло. Например одно зло в виде оракула наехало на другое зло в виде гугла по теме жабы, мол «торговая марка и все такое». гуглу надо обходить эту мину это повлияет на технические решения.

Я молчу про Microsoft у которой любое решение - это хишнический мотив захвата рынка, недобросовестная конкуренция. Мелкомягим надо продавать окошки, офис и иксбокс - это 51% выручки(если верить открытым исходникам). Фиг когда они сделают свободными хотя бы часть своего API.

Взять хотя бы тот же MFC. Как я с заказчиком с ним намучался в 2019 году.

Благодарю, вопросов больше нет

Ахахаха, все сотка. То же самое наблюдаю

т.е. у тебя его нету?

Ну это хорошо, что хоть кому-то весело. Значит всё не так плохо:)

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

у тебя тоже, значит, нету

Растодиплом?) До какой главы Растбук дочитал до пятёрки?) Нотариально заверенный скриншот в тред ахаха!

Бесконечно можно делать три вещи: смотреть на пылающий огонь, текущую воду и полуподорванных дидов в растотредах ахах

есть, но шутка все еще смешная, градус абсурда всё выше и выше.

Ок, твой уровень владения материалом ты определил одним комментом.

не мой а ваш;) вы посмотрите на типичный растовский код, в котором сотни методов и структур на файл и попробуйте мысленно сопоставить с кодом на си или даже имплементаций cpp. Вот эта помойка методов и структур и называется процедурным кодом, особенно если там указатель на контекст надо передавать в явном виде как аргумент метода. Именно поэтому у многих сомнения даже в оопшности крестов или пейтона, т.е. оно там конечно есть, но костылями.

MFC

в 2019 году

Ого.

&self - это как this в СПП или всегда явный self в Петоне. Не вижу тут особенных инноваций. Причём хотя бы в Раст есть разница между ассоциированными функциями, мутабельными по отношению к ассоциированному классу, меняющими объект на нечто совершенно иное или просто предоставляющими немодифицирующий доступ. Хотя бы лишние 50 ключевых слов не нужны, как в более других языках.

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

мутабельными по отношению к ассоциированному классу, меняющими объект

для модификаторов доступа есть умолчания, а это выглядит как костыль

Из более-менее адекватного, что помнится, это заявления первых лиц toyota о том, что нет смысла выпускать электроавтомобили, так как для них всё равно используется сгораемое топливо. Но сместят и их, и toyota запоёт общую для всех песню

Для тех, кто вылез из танка: с 2008 года по сей день в мире происходит вялотекущий экономический кризис, который на самом деле начался еще где-то в начале нулевых, но в 2008 дал какие-то ощутимые для простых субъектов экономики эффекты. А эффекты такие, что ниши сокращаются, количество производителей автомобилей сокращаются, старые заводы объединяются в гигантов, вроде Renault–Nissan–Mitsubishi, PSA, VAG, Hyundai-Kia, Fiat-Chrysler. Аналогичные процессы, на самом деле, наблюдаются во многих сфера, в том числе IT, которое всё больше напоминает цивилизацию дикарей-собирателей, построенную на руинах древнего мегаполиса.

Я не буду загадывать на будущее, но я уверен, что это надолго. Потому что прошлая цивилизация строилась на эмиссии доллара, и борьбе за то, чтобы оказаться к этой эмиссии ближе, и накоплении долгов, стимуляции бессмысленного спроса на вещи, главным образом у тех, кто ближе к этой эмиссии, то есть, у жителей США. Когда нет бессмысленного избыточного спроса, то исчезают узкие ниши, и тогда мировая экономика скатывается к «советскому застою», который на самом деле является достаточно здоровым и стабильным состоянием экономики.

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

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

в том, что такой процедурный дизайн языка был устаревшим уже 30 лет назад

Я что-то пропустил. Разве линь не процедурный? И что же у нас прогрессивно-передовое?

Стоимость разработки даже простейших веб приложений за последние лет 10 возросла в несколько раз просто из-за используемых «современных» фреймворков и языков, не давая при этом чего-то нового и полезного

Не соглашусь. Простые странички можно по-прежнему писать довольно быстро и просто. В том числе даже на какому-нибудь банальном HTML с минимумом JS на фронте, и минимальным количеством динамики на бэке. Да, фич в браузерах стало больше, но грамотный разраб веба, как и грамотный разраб C++, не будет использовать большую часть фич. Например, панели по четырем сторонам (священный грааль) нынче прекрасно делаются на flexbox-ах и css-таблицах, хотя 10 лет назад верстальщики (фронтендщики) на стенки лезли от этой проблемы. В общем-то, почти всё прекрасно делается на flexbox-ах и css-таблицах — все остальные инструменты не нужны и их можно не изучать.

Тот же windows 10 тормозит на примерно половине ноутов и ПК

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

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

Ну вот гугль лажанул с WebComponents. Кто поднялся? Проблема заключается в том, что нужные всем технологии естественным образом приходят в open source, но в open source действует принцип «лебедь, рак, и щука». То есть, даже если кому-то качество опенсорса и не безразлично, то толка все равно получается мало. В итоге приходит какой-нибудь Facebook, Google, или Microsoft, выкатывает собственный продукт, который нужен главным образом им самим — и это все хавают.

С питоном лажа полнейшая вышла, но гугл его поддержал, гугл выкатил готовые решения под питон — все хавают питон, хотя даже сам гугл пытается уйти от питона. И какая «мелкая контора» поднялась на этом? Да кому это нужно? Только очень крупная контора может позволить себе потратить миллионы долларов на разработку чего-то, что она потом просто выложит в опенсорс.

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

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

А что тебе еще не понятно в этой сфере? Я могу пояснить, если что.

Помню, я читал LKML по поводу race condition в epoll. Меня просто убил комментарий к исправлению, вроде «после этого патча шанс возникновения гонок если не исчезает, то становится ничтожно малым». То есть, «авось заработает». Справедливости ради, в Rust нет совершенно никаких инструментов для упрощения разработки подобных фич, потому что это lock-free алгоритмы, в которые Rust не умеет совсем никак. Потому для разработки ОС для многоядерных процессоров Rust не подходит — эксперимент можно даже не пытаться проводить. На всякий случай я напомню, что помимо многоядер в классической ОС неизбежно присутствуют прерывания, которые в любом раскладе требуют lock-free алгоритмов, потому что альтернативой этому является только чудовищное снижение производительности или отзывчивости ОС. Защищенный режим в классических ОС и так вносит солидные накладные расходы, к которым мы просто привыкли, но на этом фоне ОС на расте и им даст прикурить — будет примерно как в классических микроядрах, которые в большинстве своем сдохли так никуда и не взлетев.

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

Блин, я помню, как мне 12 лет назад один програмист-мигрант в мурику мне отвечал на мои претензии по поводу «много жрет» в духе «вот в моей молодости был мегабайт памяти за бешенные деньги, а сейчас гигабайт ничего не стоит — чего его экономить».

Просто так решили монополисты, так решил бизнес - следовать за волной, так решили программисты - хавать хайп и подстраиваться

Так решило 98% людей земли — хавать хайп и подстраиваться. В большинстве своей эти людей не имеют отношения к IT. Дальше всё уже естественно получается само собой.

По стоимости я сужу сугубо по своему опыту и опыту коллег и заказчиков, с которыми общаюсь. Да, сделать можно недорого, если будут нормальные разработчики, выбирающие только то, что необходимо. Но зачастую мало кто парится и сразу берут какой-то наработанный пакет компонентов за последние пару лет на одном из распоследних фреймворков и делают на этом даже простейший сайт. В итоге не то что какая-нибудь gis, а элементарный сайт с общей информацией о компании тянет за собой пол интернета и как минимум 3х разработчиков. Вот совсем недавно сотрудничали с конторой, которая делала gis для автодорожников и прочих подрядчиков. Всё по последнему слову техники с точки зрения тенденций React. Но беда была в том, что у них компонент для отрисовки одной сущности(ну там может быть машина, может быть знак, может быть дырка в асфальте и тд) был настолько тяжёл, что даже при отображении пары сотен таких сущностей возникали тормоза, а при паре тысячах всё вставало колом на любом компьютере. Смеялись мы долго, но суть в том что допиливали они это нереально долго и оно до сих пор шевелится лишь чуть лучше. Ну и конечно речь про трудозатраты, они просто гигансткие. Были бы адекватные разработчики и правильно подобранные инструменты - проблемы не было бы вообще.

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

Просто ты лошара. У меня под боком есть контора, которая промышляет именно тем, что ты описываешь. Как сказал мне её директор «делать нужно так, чтобы работа всегда оставалась». Парадокс в том, что некоторые конторы на полном серьезе повторяют эти приемы, мол «та контора успешная, она использует эти методы разработки, мы повторим эти методы и тоже будем успешные» — и применяет «эти методы» для разработки решения для себя, и в результате софтина, которая должна была делаться два месяца, делается два года.

Это примерно как запланированное устаревание, когда производитель не может в открытую сокращать срок эксплуатации — ему нужно оправдание плана «эта фича экономит целых 3% топлива, пусть и сокращает срок службы автомобиля в каких-то 3 раза». Или купил игровую консоль, а потом узнал, что игры к ней стоят в разы больше, чем эта консоль. То есть, заглотив эту наживку ты не сможешь доработать решение на реакте так, чтобы из него получилась конфетка — доработка в любом случае будет долгой и трудоемкой.

Единственный по-настоящему правильный путь — это продать тот автомобиль/игровую консоль, и купить что-то не вытягивающее бесконечно из тебя деньги. Конечно, к сожалению, в вашем случае «продать бэушную систему» у вас не получится. Лично я при разработке SPA по возможности предпочитаю использовать чистый JS. Я уверен, что я бы смог заставить ваш проект летать на тысячах значков именно таким путем — выкинув стандартный react.js, реализовав вместо него кастомный алгоритм обновления DOM плюс немного адаптировав под него компоненты. Конечно, если там нечитаемая лапша, то не поможет вообще ничего, только переписывание почти с нуля.

Кстати, так как вы в итоге сделали эти значки? Или просто забросили этот проект?

это lock-free алгоритмы, в которые Rust не умеет совсем никак

в каком смысле? Вот, например, такие штуки делают как-то:

https://docs.rs/lockfree/0.5.1/lockfree/

С десяток программистов денно и ночно перепиливали движок, отвечающий за эти самые «entities». Стало работать, лучше, перестало вставать колом, но всё ещё тормозит. Мы прекратили с ними сотрудничество несколько раньше из-за слишком большой траты времени на митинги и по другим причинам. Митинги бывали аж по 2а часа, а иногда и каждый день. На нас висела только часть работы, подрядчиков там было много, но в итоге выгоднее было отказаться, чем продолжать работать и тратить своё время. Но опыт был интересным:)

И да, там не лапша, а современный код, когда за один элементарный компонент, умещающийся в 300 строк нормального кода, причём даже в стиле React, там было по 10 файлов разной херни, реактивщина там, где она ну вообще в крайне нужна и много чего ещё интересного:) Переписывание этого добра возможно, но как всегда в таких случая - бюджет получается приличным, проще терпеть:)

рякт это и есть кастомный алгоритм обновления dom, инновацией он не был уже 5-7 лет назад. Сфера применения - паразитирование на постоянным переписывании между его ormами (flux/reflux, redux, mobix, context, saga/thunk и что там еще) и конвеер вины для работорговли программистами, т.к. там все сделано на антипаттернах и ты пишешь либо не правильно с точки зрения методологий разработки ПО, либо пишешь правильно, но оно не совсем работает в рякте. Быстрым алгоритм обновления dom быть не может принципиально потому, что это джаваскриптовый рантайм, который после всех хитрых программных диффов все равно проходит стадии браузерного рендеринга

процедурный монолитный линукс жиф только потому, что Лайнус сказал: «так я тут за всех все решаю и мержу все говнокоды сам» и 20 лет так и делал, а иначе разработка бы захлебнулась или выродилась в функции с 50ью аргументами и перемалывание одних хешмапов в другие. Ну есть еще конечно особенность в том, что ядро оперирует скорее байтиками и прочими семафорчиками, нежели разными высокоуровневыми сущностями. Уровень абстракций какой-нибудь БеОСи или даже plan9 линуксом никак не достигнут, а все пользуют потому, что работает и альтернатив доступных и качественных нет. И помимо голых сей проекты, если смотреть не только в ядро, зачастую имеют какого-нибудь костыль-монстра типа gobject, vala или своего фреймворка работы с памятью.

это lock-free алгоритмы, в которые Rust не умеет совсем никак

в каком смысле? Вот, например, такие штуки делают как-то:
https://docs.rs/lockfree/0.5.1/lockfree/

Это либа плана «черный ящик», которая с таким же успехом могла быть написана на Си. Стандартная же библиотека у раста никак не адаптирована под lock-free — она приколочена гвоздями к доступу через блокировки, вплоть до автоматических трейтов Sync/Send в компиляторе.

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

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

рякт это и есть кастомный алгоритм обновления dom, инновацией он не был уже 5-7 лет назад

Это обновление DOM общего назначения, без учета специфики конкретной задачи. Главный парадокс заключается в том, что react.js нельзя использовать для SPA с сильно динамичным содержимым.

паразитирование на постоянным переписывании между его ormами (flux/reflux, redux, mobix, context, saga/thunk и что там еще)

При чем тут ORM к redux и mobix?

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

В последних версиях реакта «пишешь правильно» стало штатным способом написания. Это я про хуки для реализации состояний, уход от компонентов в сторону чистых функций, и, самое главное, уход от миксинов, которые Дан Абрамов ругал еще много лет назад.

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

Там очень много разных моментов. Во-первых, генерирование и сравнение достаточно большого виртуального дерева, в котором почти ничего не изменилось — это весьма ресурсоемкий процесс. Сократи его — получишь солидный буст. Конечно, это при условии, что изменений настойщих свойств в DOM получается мало. Во-вторых, изменения свойств в DOM бывают разные, и если говнокодеры отлюбись дергают всякие getClientRects/getBoundingClientRect, то исправив эту проблему можно, опять же, сильно ускорить работу приложухи. Не говоря уже о том, что зачастую большая часть функции render просчитывает свойства, которые не менялись, то есть, делает бесполезную работу даже не доходя до виртуального DOM.

процедурный монолитный линукс жиф только потому, что Лайнус сказал: «так я тут за всех все решаю и мержу все говнокоды сам» и 20 лет так и делал, а иначе разработка бы захлебнулась или выродилась в функции с 50ью аргументами и перемалывание одних хешмапов в другие

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

И помимо голых сей проекты, если смотреть не только в ядро, зачастую имеют какого-нибудь костыль-монстра типа gobject, vala или своего фреймворка работы с памятью

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

В последних версиях реакта «пишешь правильно» стало штатным способом написания. Это я про хуки для реализации состояний, уход от компонентов в сторону чистых функций, и, самое главное, уход от миксинов, которые Дан Абрамов ругал еще много лет назад.

нет, чистые функции там не чистые как раз из-за хуков, которые являются внешними ссылками из контекста функции, абраможулье (на самом деле там конечно f-шня) просто выкинуло ооп, чтобы у лемингов-хайпожоров и прочих неопытных никогда не могло получиться поддерживаемого расширяемого ПО, сколько бы они не переписывали с редукса на мобикс, а получался кривой харкод, который сложно отладить и невозможно отрефакторить

Там очень много разных моментов. Во-первых, генерирование и сравнение достаточно большого виртуального дерева, в котором почти ничего не изменилось — это весьма ресурсоемкий процесс.

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

то есть, проект не развивался кем попало.

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

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

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

кстати, отличный пример как отсутствие ооп вредит линуксу это непортируемость всевозможных дбасов, удевов, системдов, у каждой nix-подобной ОС свой набор этого барахла и очень мало переиспользования и много воровства и кулибинства. 100% такая же история происходит в мире популярных фронтенд фреймворков.

чистые функции там не чистые как раз из-за хуков, которые являются внешними ссылками из контекста функции

Какими еще внешними ссылками? Хуки разве позволяют получить доступ к данным вне контекста функции, то есть, к чему-то помимо самих хуков (являющихся контекстом)?

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

А тут ты уже переизобретаешь Vue. Но мне кажется, что ты не осознаешь проблем такого подхода — как ты собрался узнавать, что тебе нужно обновлять, а что — нет? React принимает это решение именно на уровне виртуального DOM. Vue тоже применяет виртуальный DOM для принятия окончательного решения внутри компонента, а между компонентов решение об обновлении принимается на основании срабатывания хуков в модели.

А тот же Svelte v3 ссылки на компоненты в DOM уже не держит — доступа к состоянию из DOM там вообще нету, оно наглухо инкапсулировано.

Вот присвоил ты DOM элементу данные, потом изменил их — что дальше твое приложение будет делать? Какие DOM элементы после этого обновлять? В hello world-е, конечно, ты будешь обновлять один элемент, но в более сложных приложениях неизбежно возникают связи между соседними элементами, глобальные состояния — как ты будешь реагировать на изменения таких состояний? И, самое главное, как потом поддерживать этот код?

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

В чем проблема? Секретарша прочитает пару глав книги по сишке, в stackoverflow посмотрит, как собирать ядро, и поправит пару строчек, и отправит пул реквест. Ее код примут, конечно же, потому что никому не помешают лишние руки. И такие проекты есть на гибхабах, там половину женских лиц в разработчиках.

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

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

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

Смотрим код ядра линукс — где там десятки аргументов, миллион мусорных структур данных? Нет их. Так зачем ты о них пишешь?

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

А при чем тут обсуждение процедурного программирования? В паскале контракты есть, даже в старом, который без классов. По сути ты называешь недостатки одного конкретного языка Си здесь, а также в тезисе

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

А вот если говорить про

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

То по факту 99% проектов на классическом класс-ориентированном программировании, вроде какого-нибудь Qt или стандартной жавы представляет собой именно наращивание, добавление говенца сбоку, поскольку единственной альтернативой является переписывание — именно это и сделал Qt или Unreal Engine, которые переписали с нуля стандартную либу, поскольку это является единственным способом расширения онной.

Блин, я помню, как мне 12 лет назад один програмист-мигрант в мурику мне отвечал на мои претензии по поводу «много жрет» в духе «вот в моей молодости был мегабайт памяти за бешенные деньги, а сейчас гигабайт ничего не стоит — чего его экономить».

И я сейчас такое слышу иногда. Даже здесь.

отличный пример как отсутствие ооп вредит линуксу это непортируемость всевозможных дбасов, удевов, системдов, у каждой nix-подобной ОС свой набор этого барахла

DBus прекрасно портируется. Udev намертво приколочен гвоздями к конкретному механизму netlink в ядре линукс. В случае systemd нет каких-то серьезных причин для того, чтобы он не был хотя бы частично портируем, но это настолько гигантский монолит, что неизбежно обречен быть непортируемым. И при чем тут тогда вопрос ООП?

Увы, часто сталкиваюсь с таким. Сам больше предпочитаю чисто письменное общение и планирование хотя бы на пару недель-месяц вперёд. Скорее всего тебе ещё не приходилось сталкиваться с agile во весь рост так сказать. Притом митинги в нормальных конторах или на контрактах(как в нашем случае) также оплачиваются, то есть это рабочее время. Самое прикольное, это когда митинги междукомандные, естественно международные. Хрен кто приходит вовремя и всё это растягивается не то что на два часа, а на неделю по два часа в день, если кроится архитектура или ещё чего важное решается:) Мы стараемся держаться подальше таких проектов, но иногда берёмся. Иногда потому что интересные проекты реальной экономики, иногда потому что деньги хорошие.

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

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

Скажи Торвальдсу, что модулей в ядре у него быть не может.

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