Немного новостей из мира Rust

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

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

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

Ну и еще Джейсон Стейтем говорил, что цитатам в инторнете верить нельзя

неважно каким языком ты пользуешься, но все они НЕВЕРНО реализовали ООП

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

Остальные концепции ООП, кажется, что легко реализуемы за исключением полиморфизма

Рад за вас. Но ООП только ради полиморфизма и нужно.

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

Не понял, а это-то как противоречит полиморфизму? Или речь о том, что нет утиной типизации как в цпп?

Таким образом С++ тянет иерархию наследования, но может надо будет меньше чуток писать. А в Rust больше ручками пошевелить, но все проблемы с наследованием исчезают.

а что за проблемы с «наследованием» в классических OOП гуях??? там их просто нет. потому эти гуи и есть.

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

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

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

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

Нормальные разрабы не ноют, а пишут код.

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

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

Тем не менее ты не привел аргументов, что с ООП все хорошо =)

Это ты должен аргументы приводить)

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

во-первых, спорно, что можно красиво и компактно.

во-вторых, «если оно крякает, то оно - утка». то есть, если вы сделали «как в опп», без ооп, то это и есть ооп, только корявое.

Раскрой что ты понимаешь под ООП, мамкин программист. Знаю я таких, обкурятся этими своими GoFами, а потом:

Ехал визитор через фактори,

Видит визитор, в фактори листенер.

Сунул визитер листенер в декоратор,

StackOverflowExeption цап.

Рад за вас. Но ООП только ради полиморфизма и нужно.

И в чем проблема?! На ООП мир сошелся и ничего больше не существует?! =)

Если вернуться к расту, в котором нет ООП похожего на С++, то там есть статическая\динамическая диспетчеризация, мощные generic’и и enum’ы. Конечно, зависит от задачи, но у меня есть ощущение, что то как люди в 90% случаев используют полиморфизм, можно заменить просто Enum’ами в расте.

«нам ваше ооп не надо, мы почти все такое же можем сделать и без ооп».

спокойно и даже лучше: https://www.youtube.com/watch?v=OjgzmIGRJUk

Тогда почему твой ООП обсирают все кому не лень?))

А есть что-то, что не обсирают?

но все они НЕВЕРНО реализовали ООП

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

тут как раз Microsoft решила вложиться в раст и сделать его языком №1 в своей шарашкиной конторе

С каких пор микрософт стал индикатором правильности решений?

Там то дядьки наверное лучше умеют сравнивать языки чем мужики с лора с непонятными достижениями =)

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

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

видосы не смотрю, лениво, лучше текстики давай.

На ООП мир сошелся и ничего больше не существует?!

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

В каком именно ООП все отлично, которое от Алана Кэя или весь тот набор костылей из мира C++ и Java?

Тогда почему твой ООП обсирают все кому не лень?))

Люди и обсирают, и обсираются. Это обычное явление. Плюсы от раст-а в этом моменте не отличаются. Найдутся адепты и одного, и другого.

Холивар (ООП vs недоООП, Наследование vs Композиция) не стоит потраченных на него душевных сил.

Не понял, а это-то как противоречит полиморфизму? Или речь о том, что нет утиной типизации как в цпп?

Я на плюсах писал чуток и что такое утиная типизация не знаю. НО, по-научному это тоже полиморфизм, но тут часто разрабы отказываются в это верить =)

Ехал визитор через фактори, Видит визитор, в фактори листенер.

это не ооп. это некие архитектурные принципы поверх ооп. придумай свои.

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

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

Ну это джавопараша типичная. Такое можно созерцать только в C#, Java и… внезапно PHP. Я вообще никогда не задумывался какой паттерн и где мне применить, ну, наверное, потому что подходы применяемые в джаве не нужны в питоне, js, ruby и тд

с каким там ООП борются эти противники ооп? вот с тем и отлично.

глубина наследования вообще не играет никакой роли, да будь она хоть 100.

Вообще-то играет и достаточно сильно:

• Проблема хрупкости базовых классов (изменения в базовых классах ломают наследников)
• Нарушение принципов SOLID ведущих к повышенной связанности
• Проблема ослабления инкапсуляции
• Проблемы с тестированием
• Сопровождение (вытекает из сильной связанности)

Ну собственно, это тоже самое что и случилось с ADA

В общем и целом, я хотел сказать что есть другие механизмы, которые отличны от того к чему ты привык. И далеко не факт что меньше кода всегда получается на С++, разве что в определенных сценариях. Можешь сам почитать критику ООП, особенно для С++, сравнить самостоятельно подходы\принцыпы разработки на расте и С++.

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

Тогда почему твой ООП обсирают все кому не лень?))

Либо ниасилили, либо попытались впихнуть туда, где не следует. Либо и то, и другое сразу (одно может запросто быть следствием другого).

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

А вот отсутствие оного выдавать за преимущество… Может вы еще и книги на старославянском при лучине читаете?

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

лучше, чем не иметь: когда нужен – используешь, когда не нужен – не используешь

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

А я про Rust особо и не пишу. Я пишу про ту чушь, которую тут на C++ пытаются навесить.

Ну и да, когда я смотрел на Rust, то не увидел там полноценного ООП в духе ООП для статически-типизированных языков (т.е. вся триада «наследование»/«инкапсуляция»/«полиморфизм», да еще статически проверяемая компилятором в компайл-тайм). Может что-то, конечно, поменялось, но сильно сомневаюсь.

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

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

Ну вот в D стандарта нет, но там хочешь использовать ООП – используешь. Не хочешь – не используешь.

Тогда как в Eiffel или Java не хочешь использовать ООП и… И используешь ООП.

Про стандарт C++ – это отдельная песТня. Но судя по стартовому сообщению этой темы, Rust-оманы хотят нажить себе такие же приключения :)

публикуется в научные журналы

Какие научные журналы? КАКИЕ В ЖОПУ НАУЧНЫЕ ЖУРНАЛЫ?
Наука - это, например, физика, и вот там чувак, который публикуется в журналах, потом разрабатывает графен, новые способы изготовления процов и крутейшие допустим светодиоды. И потом у нас везде солнечные батареи, обогреватели, дешевейшие быстрые холодные процы и огромные мониторы с отличной картинкой какого-нибудь невообразимо далекого космоса.
А эта вся сраная срань с «языками программирования» чем может похвастаться, покажи, пожалуйста, пальцем? «Утилизацией вычислительных мощностей»? «Быстрым выходом на рынок»? «Пологой кривой обучения хвостатых»? Сиреневыми волосами?

Лиспу их любимому вон лет 60 уже, просто напоминаю для полноты вброса.

Паттерны в джаве - это как костыли, потому как в ней везде классы, ты просто не можешь объявить где-нибудь в глобальной области видимости функцию или переменную… нет множественного наследования. Лень расписывать. Гофовские паттерны нах не нужны. Просто какой-нибудь EventEmitter заменяет и PubSub и Observer. Не нужны фабрики так как ты можешь просто сам класс как аргумент передавать, не нужны билдеры и тп. Есть специфические какие-то вещи типа декораторов, а итераторы - часть языка. Просто для общего развития прочитал и забыл

Ну это джавопараша типичная.

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

А теперь представь джавопарашу, но без средств ООП.

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

посмотри видос сравнения полиморфизма между rust и с++, у него ближе к концу таблица интересная

https://www.youtube.com/watch?v=wU8hQvU8aKM

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

Проблема хрупкости базовых классов (изменения в базовых классах ломают наследников)

это вообще не проблема. верней, это проблема не ооп, если она существует. приведите примеры.

Нарушение принципов SOLID ведущих к повышенной связанности

как раз solid без ооп не реализовать. SOLID это целиком про ооп. а уж на C++ это делается легко. гуглим «SOLID С++»

Проблема ослабления инкапсуляции

не проблема. в с++ вы можете инкапсулировать как угодно.

Проблемы с тестированием

какого рода.

Сопровождение (вытекает из сильной связанности)

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

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

Проблема хрупкости базовых классов (изменения в базовых классах ломают наследников)

А божечки, изменение фундамента ломает здание. Надо срочно всё переизобрести, а то как же так.

2. …

О, язык таки почти дорос до первого релиза

Ferrocene, наверное хотели бы иметь базовую спецификацию, от которой отталкиваться, а не писать своё.

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

Челики из ferrous уже свою успели сделать :))

Что-то мне кажется если бы они не сделали эту спеку то официальная команда бы не начала шевелится вообще в этом направлении. А то сейчас у них появился риск что спека от ferrous станет основной спекой и решили предотвратить такое)

посмотри видос сравнения полиморфизма между rust и с++

Посмотрел. У автора видоса специфическое восприятие термина «полиморфизм». Несколько ограниченное, как по мне.

В частности, вот такую схему его полиморфизм не подразумевает (если я правильно помню особенности traits в Rust-е):

class subscriber {
  virtual void cleanup() = 0;
public:
  virtual void subscribe() = 0;
  ...
};
...
class my_basic_subscriber : public subscriber {
  void subscribe() override {
    cleanup();
    some_actions();
  }
  ...
};
...
class specific_subscriber : public my_basic_subscriber {
  void cleanup() override { ... };

  void subscribe() override {
    my_basic_subscriber::subscribe(); // Тут будет вызван cleanup из specific_subscriber.
    additional_actions();
  }
  ...
};

Ну самое простое решение это не использовать такой паттерн потому что он нарушает инкапсуляцию :) Человек который писал класс my_basic_subscriber расчитывал что вызовет его метод cleanup а будет вызван совершенно другой метод который непонятно что сделает и может нарушить инварианты оригинального класса (например если дочерний cleanup не вызовет родительский cleanup). Или наоборот минимальные изменения в реализацию базового класса (например если мы уберем вызов cleanup в методе subscribe) могут поломать далекого наследника который в своей логике расчитывал что subscribe всегда вызовет cleanup. Это уже прямо явное нарушение инкапсуляции потому что приватная реализация базового класса не должна никак ломать сторонний код. Смотри википедию Fragile base class

Например в языке Kotlin который проектировали люди умнее меня и с большим опытом в ООП все классы по умолчанию final чтобы отказаться от этого патерна.

Я бы за такое на ревью поругал, но тут уже написали почему.

В частности, вот такую схему его полиморфизм не подразумевает (если я правильно помню особенности traits в Rust-е):

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

trait Subscriber {
    fn subscribe(&self) {
        println!("Хотя ты можешь иметь и общий код")
    }
}

struct MyBasicSubscriber;
struct SpecificSubscriber {
    basic_subscriber: MyBasicSubscriber,
}

impl Subscriber for MyBasicSubscriber {
    fn subscribe(&self) {
        println!("subscribed MyBasicSubscriber");
    }
}

impl Subscriber for SpecificSubscriber {
    fn subscribe(&self) {
        self.basic_subscriber.subscribe();
        println!("subscribed SpecificSubscriber");
    }
}

fn generic_subscribe<T: Subscriber>(t: T) {
    t.subscribe();
}

fn main() {
    let a = MyBasicSubscriber {};
    let b = SpecificSubscriber {
        basic_subscriber: MyBasicSubscriber {},
    };

    generic_subscribe(a);
    generic_subscribe(b);
}

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

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

и нет тут никакого «нарушения инапсуляции», все нормально инкапсулировано, просто инкапсулированное поведение внешней функции нарушило некий контракт.

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

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

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

А в случае когда мы разрешаем переопределять методы класса то контрактом является любая последовательность вызовов всех виртуальных методов этого класса. Как я уже приводил в пример что если убрать вызов cleanup из тела метода subscribe класса my_basic_subscriber то сломается класс specific_subscriber. Где описан этот контракт что метод subscribe обязан вызвать cleanup внутри? разве что в коментарии сверху или в документации на класс. Но это ведь внутренняя деталь реализации, почему это вдруг контрактом стало? Надо ли на все вызовы виртуальных функций писать контракт кто их будет вызывать и когда? Почему бы вместо этого не сделать отдельный интерфейс и описать контракт на него, а детали реалиции класса оставить скрытыми.

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

то есть в русте имя метода является контрактом, а в с++ - нет??? имя функции не есть контракт. в примерах про «хрупкие классы» оно не меняется.

Где описан этот контракт что метод subscribe обязан вызвать cleanup внутри?

у вас в рустовом коде где записан хоть какой-то контракт на семантику? таких контрактов нет ни в с++, ни в русте. заголовок функции строго говоря им не является и вообще разговор о другом.

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

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

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

Предложи альтернативу ООП для большого и сложного софта. Костылить недоООП самому, как гномеры?

В ГТК была проблема в том, что там вообще ничего не было, ни ООП, ни ФП, только ПП (процедурное программирование) — потому что сишечка. Взялись и реализовали самое модное на тот момент ООП. Наверняка посматривали на ядро, как пример — язычок тот же, проект сложный. Про композицию слыхом не слыхивали тогда в мэйнстриме.