Почему боятся ООП?

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

Сложность там определяется свойствами программируемой системы

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

Джава с ГЦ в ядре нахрен не нужна

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

а без ГЦ тоже не нужна, потому что неэффективна

Да откуда вы такие берётесь? Причём тут синтаксис джавы, вообще и ООП в частности? Неэффективен SDK и/или компилятор преобразующий джава код в машинные коды, а не ООП.

надо его проверять вручную (границы массивов и проч.),

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

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

А это ещё что за хрень? ООП на уровне джавы тебе опять что-то не даёт по системе? Через ООП ты можешь хоть на уровень 0 и 1 опуститься, назови класс Zero и One и получай хоть какие знания по системе.

А это ещё что за хрень? ООП на уровне джавы тебе опять что-то не даёт по системе?

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

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

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

зачем наследование - когда есть встраивание

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

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

зачем полиморфизм если есть опять же утка-типность и опять же интерфейс уженный как потребно

крч

от о.о.п. если есть чё полезное - так это преобщенние масс к пониманию важности структур данных и методов к ним - ой да эт же АТД

так что да - ооп нужно - особенно если малограмотны

Это всё признаки не понимания сути ООП. То, что ты перечислил это недоООП.

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

При этом структуры можно отставить, иногда нужно просто хранить данные. В джаве, например, структуры сейчас в процессе добавления. Назвали их примитивные классы (или value class? уже запутался, там они кучу раз всё переделывали), которые в своей структуре не хранят тип класса, а поля иммутабельны.

ага - свет Великой Истины понятен не только лишь всем

уж лучше так - чем отказ теми кто понял - вот кто еретики ооп:

Я не про легаси. А про современный ИТ продукт. Если сегодня ты начнёшь писать новый Линукс (редокс и вот эти все) на сях и прочих ржавых с недоООП, то ты не сделаешь конкурентный продукт. Но при использовании ООП (хотя бы на уровне джавы, я уже не говорю об изобретении новых ЯП с лучшим ООП) у тебя появляется шанс написать конкурентный продукт и вытеснить тот же Линукс или тот же Хром.

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

Но при использовании ООП (хотя бы на уровне джавы

Это вы про ту джаву для приложений которой может потребоваться более другая версия jre? А потом возможно ещё более другая... а потом ещё... Или про ту которая жрет как не в себя?

я уже не говорю об изобретении новых ЯП с лучшим ООП

Нет спасибо, мы ещё от джавы неотошли.

Причина банальна. ООП снижается уровень входа

Входа куда?

и сложность кода

Сферично да. Согласен полностью.

ага - свет Великой Истины понятен не только лишь всем

А что поделаешь, если нет желания развиваться и изучать новое? Топик как раз по этой теме, только выяснилось, что и сам автор далек от понимания ООП.

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

У вас точно какой-то NiH синдром.

Новые разрабы чураются лезть в это болото

Новые разрабы это те которые вчера вылупились и сразу с NiH синдромом?

Вытеснение Линукса системой с ООП подходом лишь вопрос времени.

Вот когда... тогда и поговорим.

Входа куда?

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

Новые разрабы это те которые вчера вылупились и сразу с NiH синдромом?

Про старение мейнтейнеров ядра Linux

https://habr.com/ru/news/779090/#:~:text=%D0%9F%D1%80%D0%BE%20%D1%81%D1%82%D0%B0%D1%80%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%BC%D0%B5%D0%B9%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2%20%D1%8F%D0%B4%D1%80%D0%B0%20Linux

«Ах баба́, как устарел ваш хевиметал, в наш ПРОСВЕЩЁННый XXI век»

Но вот с чтением грамотно спроектированного ООП проекта справится любой надмозг.

Также как и с любым грамотно спроектированным проектом без ООП.

Когда у тебя есть класс, есть методы определяющие его поведение и интерфейсы для взаимодействиями с другими классами всё становится проще.

Ну да. На структурах у меня есть server.h, protocol.h и connect.h (с функциями соединения). На классах мне приходится либо соединение делать неотъемлемой частью сервера или протокола, либо делать «класс» Connection, у которого нет никаких полей, но есть метод connect. А если у функции больше двух аргументов, то поиск, в каком классе её искать становится ещё более занимательным.

И в 1С у меня есть функция ЗаполнитьЗначенияСвойств(Приёмник, Источник), которая из источника в приёмник копирует значения полей, у которых совпадают имена. На ООП о такой функции даже подумать нельзя.

https://habr.com/ru/news/779090/#:~:text=Про старение мейнтейнеров ядра Linux

Переведено ИИ. «Rust на самом деле не показал себя как следующая великая вещь» стало последней каплей, дальше неосиил.

«класс» Connection, у которого нет никаких полей, но есть метод connect

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

ЗаполнитьЗначенияСвойств(Приёмник, Источник)

Используй статические методы Reflection.Field.copy(destination, source, ::[Reflection.Field::name, String::equals])

Используй статические методы

То есть функции.

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

Да, плохой пример, соединение ведь завершать потом надо.

Вот хороший: метод print() должен быть у принтера или у печатаемого документа? Или у класса Printing, объект которого создаётся только для вызова функции print? Или статический метод (функция) с двумя параметрами?

либо делать «класс» Connection, у которого нет никаких полей, но есть метод connect.

да запросто! В любом коде таких классов полно, если имплементация тривиальная

# base
abstract class BaseConnection
{
    abstract fun connect(): Session
}

abstract class HttpConnection: BaseConnection (
    protected val httpClient: HttpClient
)


# impl

class LocalConnection: BaseConnection {
    
    fun connect(): LocalSession {
       return LocalSession()
    }
}


class UserPasswordConnection(private val httpClient: HttpClient,
    private val user: String,
    private val password: String
): HttpConnection(httpClient)  {
  fun connect(): HttpSession {
      val session = httpClient.startSession()
      session.authorize(user, password)
      return session
}
}

Вот хороший: метод print() должен быть у принтера или у печатаемого документа?

метод debug() должен быть у объекта класса Logger

Вот хороший: метод print() должен быть у принтера или у печатаемого документа? Или у класса Printing, объект которого создаётся только для вызова функции print? Или статический метод (функция) с двумя параметрами?

у вас пропадут вопросы, когда вы начнете думать абстрактыми типами. В том месте, где вы вызываете print(), совершенно не важно куда именно будет напринтано - в файл, на консоль, или на устройство. Не должен ваш код в этом месте знать, что имеено стоит за этим принтом. Для вас имеет значение, что в функцию, класс или модуль передали объект, который умеет делать print(). Реализаций этого контракта (то есть объектов, которые умеют делать принт) может быть хоть миллион.

И чем эта гирлянда лучше, чем простая функция UserPasswordConnect ?

Вот хуже она тем, что глядя на UserPasswordConnection::connect надо пройти в базовый класс и убедиться, что он абстрактный и никаких дополнительных действий не делает. То есть, при чтении кода, лишняя потеря времени.

И чем эта гирлянда лучше, чем простая функция UserPasswordConnect ?

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

совершенно не важно куда именно будет напринтано - в файл, на консоль, или на устройство

Ну как же? В зависимости от того, куда выведено, должен исполняться разный код. Если документ печатается в файл, то пишем данные в некотором формате (причём, в зависимости от формата может быть разное разбиение на страницы, например), если на принтер, то, опять же, надо подготовить изображение по характеристикам принтера.

объект, который умеет делать print()

Каждый объект должен уметь делать print() куда угодно?

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

Вот все эти штуки и инкапсулируют конкретные импленентации

Каждый объект должен уметь делать print() куда угодно?

Каждый объект должен уметь вызывать метод принт у переданного в него объекта с интерфейсом IPrintable, больше ему ничего знать не надо

UserPasswordConnection::connect надо пройти в базовый класс и убедиться, что он абстрактный и никаких дополнительных действий не делает.

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

И в 1С у меня есть функция ЗаполнитьЗначенияСвойств(Приёмник, Источник), которая из источника в приёмник копирует значения полей, у которых совпадают имена. На ООП о такой функции даже подумать нельзя.

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

class Foo:
    
    def __init__(self):
        self.a = 1
        self.b = 2
        
class Bar:
    
    def __init__(self):
        self.a = 10
        self.c = 20
        
        
def copy_attributes(source, target):
    for attr in dir(source):
        if not attr.startswith("__"):
            if hasattr(target, attr):
                setattr(target, attr, getattr(source, attr))
                
foo = Foo()
bar = Bar()
copy_attributes(foo, bar)
print(bar.a, bar.c)

из источника в приёмник копирует значения полей, у которых совпадают имена. На ООП о такой функции даже подумать нельзя

Ну почему, рефлекшон можно расчехлить (и затормозить всё в несколько раз) %)

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

Путаете теплое с мягким. Есть реализации рефлекшена путём предварительной генерации кода (и последующей его компиляции) с прямым получением/установкой значений на полях переданных объектов. Есть кривые реализации с установкой значений в рантайме путём поиска по таблице нужных имён полей. Не используйте кривые реализации и у вас будет летать.

Вот хороший: метод print() должен быть у принтера или у печатаемого документа?

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

То есть функции.

Да. Ещё можете использовать структуры, если у вас нет поведения и просто нужно хранить данные. Мы здесь про реальную разработку, а не про поехавших элитариев с идеальным ООП.

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

Вот таких людей тоже стоит избегать. Это у них фабрики фабриками погоняют.

У принтера. Документу не нужно знать как его будут печатать, это не его область ответственности.

Учитывая, что имя до точки — это просто неявный первый аргумент функции, называемой методом, обычно доступный в нём по имени this или типа того (a.foo(b) === foo(a, b)), то, видимо, есть огромная разница между print(printer, document) и print(document, printer).

Правда, размеры (и тру энтерпрайзность) этой разницы, как всегда, ускользнули от моего внимания %)

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

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

У принтера. Документу не нужно знать как его будут печатать

И да, программа — это инструкции вычислителю, что делать и с какими данными. Printer.print(document) навевает жёсткий вайб послеполуденных игр в песочнице. Мой экскаватор закопал твоего солдатика! Ррряяя, нет, это мой солдатик расстрелял твой экскаватыр!11 Схватка идёт не на жызнь, а на смерть. Всё предельно серьёзно.

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

Кто кем был в этой притче — догадывайтесь сами.

Избегай, сделай милость

Ах да, ах да, как я мог забыть — в мейнстримных ООП-недоязычках полиморфизм приколочен гвоздями к типу первого аргумента. Отсюда ваши фейспалмы, господа? %) Тогда они не по адресу.

Языков с мультидиспатчем вообще мало, и вопрос, на сколько он там к месту. Вот в Джулии есть мультидиспатч, а её ради замены фортрано-матлабов разработали. Вопрос: многие ли разработчики числодробильни нуждаются в мультидиспатче?

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

вы же путаете ООП со статической типизацией

Нет. Я про то, что для копирования не используется метод, а используется функция.

def copy_attributes(source, target):

По ООП-шному должно было бы быть что-то типа source.copy_to(target). Или target.copy_from(source).

Вопрос: многие ли разработчики числодробильни нуждаются в мультидиспатче?

Они и в полиморфизме вообще вряд ли нуждаются, а в ООП так и тем более.

У принтера. Документу не нужно знать как его будут печатать, это не его область ответственности.

А принтеру надо знать, как печатать все виды документов?

То есть всё равно будут функции и этот аргумент не работает:

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

И без ООП тоже никто не мешает сложить структуру и функции для работы с ней в один модуль.

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

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

По ООП-шному должно было бы быть что-то типа source.copy_to(target). Или target.copy_from(source).

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

А принтеру надо знать, как печатать все виды документов?

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

когда типизированная функция хочет конкретный тип А

дальше можем не продолжать, с нетипизированными функциями - это вам к другому кому-то