Логика может быть в корне неверной. Язык, в котором нет ничего лишнего, лучше, чем в котором лишнее есть. Язык,в котором можно сделать что то только единственным способом - самым правильным, лучше, чем тот, в котором способов много [и все плохие].
Если кому то понадобиться тот бред, что вы перечислили, то пусть он и запрещает явно все эти базовые вещи. Но повторюсь, никому это нафиг никогда нужно не будет, поэтому по умолчанию все это должно быть.
Конкретно в Rust, добавление или отключение на итоговую производительность не влияют.
Если оно не влияет, и учитывая первый пункт про "по умолчанию должно быть", то это просто др***ево на пустом месте - результат непродуманности языка.
Вот это логика, а то что у вас это слабая попытка в логику.
азначение у языков разное и корректнее было бы сравнивать скажем с C17, C++20, C++23
Само по себе назначение не должно влиять вообще ни на что. Важно только можно так сделать или нет, и на что это фактически влияет.
можете вы в TypeScript для enum запретить сортировку элементов, запретить их сравнивать, запретить по ним итерироваться? Или комбинация: итерироваться можно, а сравнивать и сортировать нет.
Аналог троллейбуса из буханки, смешно))
но работает на максимуме возможностей из коробки
Вы хотите сказать что добавление таких возможностей замедлит код или что? Можно было так и написать. Вот только почему то я уверен, что это все можно реализовать вообще без доп нагрузки, было бы интересно послушать доводы.
Удивительно, как вот такой код просто для создания enum с самыми базовыми возможностями у кого то вызывает ощущение "мощности" языка:
#[repr(u8)]
#[derive(
Debug,
Clone,
Copy,
PartialEq, Eq, // Реализует операции ==, !=
PartialOrd, Ord, // Реализует остальные операции сравнения, в т.ч. используется при сортировке
TryFromPrimitive,
IntoPrimitive,
EnumIter, // Реализует Iter для enum
)]
pub enum Status {
Ready = 10,
Processing = 20,
Done = 30,
}
А у кого то ощущение непродуманности и невероятного оверинжиниринга.
В TypeScript у enum это все доступно из коробки, и намного удобней.
Практически вся коммерция на ФП сейчас. Клиентские (react, vue, redux, zustand и тп), серверные (go, nodejs express и тп). А это больше половины всех создаваемых программ.
Статья без примеров кода в каких случаях одна парадигма лучше другой, но при этом делающая какие то выводы в этом направлении - мусор. Научность статьи - нулевая.
Если нет ни одного примера кода, когда классическое ООП лучше чем ФП - значит оно никогда не лучше.
Для управленря загрузкой и кэшем при использовании redux советую рассмотреть react-redux-cache вместо RTK-Query. Поддерживает нормализацию, куда более производительный и менее оверинженеренный.
Ну супер, а потом сопостовлять стэйт и функции которые нужны?
Еще раз, никаких проблем ни с инкапсуляцией, ни с типами там нет. И можно реализовать и с замыканием, и в отдельном фале без замыканий, хоть в ПП, хоть в ФП.
нет вы облажались, потому что исходный инстансер работал со строками и в принципе у него другая логика работы была
вы в своём же примере накосячили
Посмотрите на мое сообщение что вы сами скинули - я как раз меняю тип с массива строк на массив чисел. Так что никаких косяков и проблем с типобезопасностью там нет вообще. Боитесь признать что в вашем любимом С++ такое невозможно сделать?)
полиморфизм в стиле ООП, который в TypeScript является основным вариантом полиморфизма, и довольствуетесь switch/case.
Ошибка, в статье привел полиморфизм аж трех видов, и в спорах с ООП-шниками привел пример вообще без switch / case, на обобщениях, когда пользователь библиотеки может спокойно добавлять новые инструменты, генерируя на лету.
И вы еще и ошибаетесь что switch / case не расширяем - оборачиваешь функцию другой, добавляешь новый тип, предоставляешь библиотеке новую функцию (разумеется автор предусмотрел если делал ее расширяемой). Правда в реальном коде, в коммерческой разработке, не припомню чтоб такое хоть раз требовалось. Union type используют в коде самого проекта, когда расширение делается самым простым способом - добавлением нового case. В остальных случаях лучше использовать обобщения.
В функциональных языках просто есть нормальные решения для полиморфизма на этот случай.
Отлично, может когда нибудь на Elixir начну писать, но пока на нем нет возможности делать мобилки / веб приложения и многое другое.
Вот только до сих пор никто так и не смог предоставить нерасширяемую, нерешаемую "задачку" даже на языке TS.
Бэкенд пишется на Go и NodeJS с его express, самое популярное ядро ОС - на С. Вы все динозавры, сидящие на своих древних, уродливых и непродуманных ООП языках.
import * as R from 'ramda';
const add = R.add(10); // Создаём функцию, которая прибавляет 10
console.log(add(5)); // 15
Круто, тащим всю библиотеку ради одной функции.
В целом статья из разряда "как сложить числа с помощью jquery", когда джуны тянут в код что то не потому что надо, а потому что могут.
Давно уже пора отказаться от подобных библиотек, стандартное апи очень даже неплохое, и только в редких случаях, например когда нужен map объекта или глубокое сравнение, можно что то подтянуть (и то имеет смысл просто копирнуть пару таких функций в свой проект).
А вот это ещё один минус вашего подхода, как потом использовать тул из других файлов? Как мне получить активный тул? Представте например что функция updateTool находится в другом файле.
Если выносить в отдельный файл, то вместе с функциями, что требуют состояние в замыкании, включая updateTool. Если нужно раздать доступ к какой либо части состояния на все приложение, всегда можно экспортировать соответствующую функцию getState.
да что вы, а не потому ли вы удалили код, который просили написать в ооп напомню:
потому что вы облажались и instancer использовал items от collect? Очень типобезопасно лол.
Вообще ни разу, я удалил тк понял что мне в целом не интересно пытать ООП-шника на проблемы ООП тк уже целая статья расписана, но если вы готовы - то ок, предоставьте решение, хотя мне оно не особо нужно. И там вообще никаких проблем с типабезопасностью нет - instancer использует состояние намеренно, в этом и есть задача.
мой вариант получше вашего будет, ибо меньше возможностей накосячить (забавно что именно вы это продемонстрировали), меньше писать приходится (сравните по символам а не по строчкам если сомневаетесь) и проще читать
Код на с++ проще читать и писать ))) А на руках ходить проще чем на ногах. По поводу сравнить по символам - так сравните сами, что то мне подсказывает что ваше решение и здесь проиграет. Можно устроить тут борьбу за каждый символ, а можно прочитать статью еще раз и убедиться что если код без классов как минимум не хуже даже на примерах, специально сделанных ООП-шником, чем код с классами, то использовать классы это говнокод.
что вы активно используете методы, против которых воюете (log, push, join)
Это вообще ограничение языка, были бы функции - использовал бы их. К этому придираться - это уже видимо совсем не к чему.
Как по мне я выиграл этот спор, ну по голосам за коменты тоже.
То есть статья про "код с элементами ФП"? Парадигму, которой предлагается писать вообще весь код, и в которой я пишу уже давно сам, и которая считается мной около-идеальной, нет отдельного названия?
Логика может быть в корне неверной. Язык, в котором нет ничего лишнего, лучше, чем в котором лишнее есть. Язык,в котором можно сделать что то только единственным способом - самым правильным, лучше, чем тот, в котором способов много [и все плохие].
Если кому то понадобиться тот бред, что вы перечислили, то пусть он и запрещает явно все эти базовые вещи. Но повторюсь, никому это нафиг никогда нужно не будет, поэтому по умолчанию все это должно быть.
Если оно не влияет, и учитывая первый пункт про "по умолчанию должно быть", то это просто др***ево на пустом месте - результат непродуманности языка.
Вот это логика, а то что у вас это слабая попытка в логику.
Само по себе назначение не должно влиять вообще ни на что. Важно только можно так сделать или нет, и на что это фактически влияет.
Аналог троллейбуса из буханки, смешно))
Вы хотите сказать что добавление таких возможностей замедлит код или что? Можно было так и написать. Вот только почему то я уверен, что это все можно реализовать вообще без доп нагрузки, было бы интересно послушать доводы.
Удивительно, как вот такой код просто для создания enum с самыми базовыми возможностями у кого то вызывает ощущение "мощности" языка:
А у кого то ощущение непродуманности и невероятного оверинжиниринга.
В TypeScript у enum это все доступно из коробки, и намного удобней.
Код автора приведен по ссылке. Другим словом его назвать язык не повернется.
Практически вся коммерция на ФП сейчас. Клиентские (react, vue, redux, zustand и тп), серверные (go, nodejs express и тп). А это больше половины всех создаваемых программ.
Статья без примеров кода в каких случаях одна парадигма лучше другой, но при этом делающая какие то выводы в этом направлении - мусор. Научность статьи - нулевая.
Если нет ни одного примера кода, когда классическое ООП лучше чем ФП - значит оно никогда не лучше.
А неудачные попытки написать такие примеры можно найти в статье https://habr.com/ru/articles/885980/
Причем неудачные - все.
Про ООП, паттерны и чистый код лучше читать вот эту статью: https://habr.com/ru/articles/885980/
Для управленря загрузкой и кэшем при использовании redux советую рассмотреть react-redux-cache вместо RTK-Query. Поддерживает нормализацию, куда более производительный и менее оверинженеренный.
А вы думали в ФП чудеса происходят и там что то совершенно другое?) Суть как раз в неиспользовании классов и их ограничений, и всех проблем из статьи.
Понятие ООП я довольно четко прописал в статье. Классы не используются.
А в коде используется просто словарь с функциями.
Вот пример с добавлением инструмента в библиотеку, генерируемый на лету. Без проблем.
Еще раз, никаких проблем ни с инкапсуляцией, ни с типами там нет. И можно реализовать и с замыканием, и в отдельном фале без замыканий, хоть в ПП, хоть в ФП.
Посмотрите на мое сообщение что вы сами скинули - я как раз меняю тип с массива строк на массив чисел. Так что никаких косяков и проблем с типобезопасностью там нет вообще. Боитесь признать что в вашем любимом С++ такое невозможно сделать?)
Ошибка, в статье привел полиморфизм аж трех видов, и в спорах с ООП-шниками привел пример вообще без switch / case, на обобщениях, когда пользователь библиотеки может спокойно добавлять новые инструменты, генерируя на лету.
И вы еще и ошибаетесь что switch / case не расширяем - оборачиваешь функцию другой, добавляешь новый тип, предоставляешь библиотеке новую функцию (разумеется автор предусмотрел если делал ее расширяемой). Правда в реальном коде, в коммерческой разработке, не припомню чтоб такое хоть раз требовалось. Union type используют в коде самого проекта, когда расширение делается самым простым способом - добавлением нового case. В остальных случаях лучше использовать обобщения.
Отлично, может когда нибудь на Elixir начну писать, но пока на нем нет возможности делать мобилки / веб приложения и многое другое.
Вот только до сих пор никто так и не смог предоставить нерасширяемую, нерешаемую "задачку" даже на языке TS.
Бэкенд пишется на Go и NodeJS с его express, самое популярное ядро ОС - на С. Вы все динозавры, сидящие на своих древних, уродливых и непродуманных ООП языках.
Профессиональной среде рукожопов, выдумавших Java и C#.
Повторяю, вы уже отстали от жизни, самые популярные библиотеки для enterprise - react и redux, и пишутся именно в стиле что я описал.
Ты бы мою статью почитал сначала, секцию определения.
Вы код сам скиньте, что сравниваете, а то непонятно о чем речь.
Круто, тащим всю библиотеку ради одной функции.
В целом статья из разряда "как сложить числа с помощью jquery", когда джуны тянут в код что то не потому что надо, а потому что могут.
Давно уже пора отказаться от подобных библиотек, стандартное апи очень даже неплохое, и только в редких случаях, например когда нужен map объекта или глубокое сравнение, можно что то подтянуть (и то имеет смысл просто копирнуть пару таких функций в свой проект).
он многое удалил, а ваш код намного больше
Если выносить в отдельный файл, то вместе с функциями, что требуют состояние в замыкании, включая updateTool. Если нужно раздать доступ к какой либо части состояния на все приложение, всегда можно экспортировать соответствующую функцию getState.
Вообще ни разу, я удалил тк понял что мне в целом не интересно пытать ООП-шника на проблемы ООП тк уже целая статья расписана, но если вы готовы - то ок, предоставьте решение, хотя мне оно не особо нужно. И там вообще никаких проблем с типабезопасностью нет - instancer использует состояние намеренно, в этом и есть задача.
Код на с++ проще читать и писать ))) А на руках ходить проще чем на ногах. По поводу сравнить по символам - так сравните сами, что то мне подсказывает что ваше решение и здесь проиграет. Можно устроить тут борьбу за каждый символ, а можно прочитать статью еще раз и убедиться что если код без классов как минимум не хуже даже на примерах, специально сделанных ООП-шником, чем код с классами, то использовать классы это говнокод.
Это вообще ограничение языка, были бы функции - использовал бы их. К этому придираться - это уже видимо совсем не к чему.
facepalm
То есть статья про "код с элементами ФП"? Парадигму, которой предлагается писать вообще весь код, и в которой я пишу уже давно сам, и которая считается мной около-идеальной, нет отдельного названия?
Ну ок, ваше мнение, но не мое.