Comments / Profile of Lekret / Habr

Леонид Карих @Lekret

User

ООП: худшее, что случалось с программированием

Я то конечно согласен с утверждением, что ООП не единственная и не самая лучшая парадигма на свете, и далеко не всегда её применяют уместно. Люди начитываются клинкодов и книжек по паттернам и начинают писать по догмам, это всё понятно.

Не совсем только понятен момент по ФП. Вы специально ввели свою терминологию, где описали ФП как структуры + функции. Замечательно, то есть сюда помимо канонично функциональных языков программирования (Haskell, F#, Scala и т.д.) подходят как минимум C, Odin, Zig, наверное ещё Rust, а также в зависимости от стиля JS/TS, Python, C++, Go и многие другие языки.

Вы приводите пример с row polymorphism:

const getDisplayName = (user: {firstName: string, lastName?: string, middleName?: string} | null | undefined) => { ... }

Если что данной фичи нет в большинстве языков, которые я привёл. Так умеет только TS, а также JS и Python (из-за типизации). Почему это свойство приписывается к ФП (в вашем понимании), не совсем понятно.

Затем вы приводите пример с union:

type Shape = Circle | Rectangle

Тут лучше, хотя даже здесь я могу выделить C, C++ и Go, которые на уровне языка tagged unions не поддерживают. И всё ещё непонятно, почему данный способ приводиться как универсальный и заведомо лучший. Zig и Odin оба поддерживают tagged unions на уровне языка, но достаточно открыть реализацию структуры Allocator стандартной библиотеки для каждого из них и вот что мы увидим:

// Odin
procedure: Allocator_Proc,
data:      rawptr,

// Zig
ptr: *anyopaque,
vtable: *const VTable,

Ого, это ООП или ещё нет? По-моему вполне себе попытка эмулировать ООП, причём очень успешная, потому что люди заходят создавать свои аллокаторы, а не юзать юнион из 5 которые предоставляет std/core.

Потом вы называете методы мусором:

// Rust
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

// Zig
const Door = struct {
    is_open: bool,
    pub fn open(door: *Door) void {
        door.is_open = true;
    }
    pub fn open_can_be_null(door: ?*Door) void {
        door.?.is_open = true;
    }
    // Door.open(door)
    // door.open_can_be_null()
};

А это можно называть методами? Думаю да. Языки ООП в привычном понимании? Вообщем-то нет, я бы оба отнёс к процедурным.

В целом непонятна эта неприязнь к методам, ведь как я уже сказал, если вы в условном C мы напишем глобальную функцию принимающую конкретную структуру, то никакого магического ducktyping по полям там не случится и переиспользовать эту логику для чего-то ещё не выйдет. Метод это обычная глобальная функция, где как вы сами сказали, есть неявный (а иногда и явный) this/self, и удобный вызов через точку. Тут нет никаких кардинальных отличий, и в некоторых языках это отлично видно. Тоже самое можно сказать про class/struct/type, зачастую это просто синтаксис, и разница видна только в конкретных языках в конкретных кейсах.

При всём этом вы приводите Go как язык, который вот уже почти подобрался к званию идеального, ведь там нет классов, но создатели таки оставили методы. Странно, потому что Go вроде как считается классическим ООП языком, там тебе и методы, и интерфейсы, и облегчённое наследование через включение полей структур, и инкапсуляция через camelCase.

Это уже не говоря о попытке показать инкапсуляцию для "ФП", когда мы используем замыкания, которых нет в части языков, которые я привёл, а в некоторых нет даже лямбд, и не во всех из них можно свободно и удобно кастить указатели на функции. Зато в Rust, Zig, а также частично в Odin, откуда-то взялись "pub" или "(private)". Скрыть поля или логику можно даже в C через opaque/incomplete types или static.

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

Статья выглядит больше как реклама TypeScript на фоне Java/C#, либо даже как реклама классического ФП (не в вашем понимании), но никак не как успешная попытка столкнуть между собой две парадигмы. Запинать ООП или тот же C# можно было бы гораздо изящнее.