Понемногу изучая Rust, я столкнулся с тем, что привычные приемы проектирования "не работают". Конечно же я об ООП и его паттернах проектирования.

1) А как быть если полной поддержки ООП в ЯП нет?
2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?
3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

Например?

Есть старое структурное/процедурное программирование. Есть функциональное.

как это будет смотреться на Rust

Паттерны проектирования программисту не нужны. Они нужны только писателям книг про паттерны проектирования.

Точно так же и будет.

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

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

Меня интересует сейчас только варианты проектирования - не ООП.

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

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

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

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

Хз, по моему опыту всегда достаточно своими словами описать, что ты хочешь это сделать. Умные слова из книжки для этого не сильно нужны.

Что, неужели никогда не используешь слова "фабрика", "визитор", "фасад" или ещё чего?

Паттерны проектирования программисту не нужны. Они нужны только писателям книг про паттерны проектирования.

Что, неужели никогда не используешь слова "фабрика", "визитор", "фасад" или ещё чего? Или разъясняешь каждый раз их?
Не верю

Фабрику бывает что использую

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

Насколько часто копаешься в чужом коде?

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

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

Паттерны есть вообще почти во всем Вопрос в том, описаны ли они так же хорошо, как для ООП. Для функциональщины вроде видел литературу, но сам не читал.

Паттерны есть вообще почти во всем

1) А как быть если полной поддержки ООП в ЯП нет?

2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?

3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

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

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

Есть. Тысячи их.

В твоём случае устоялся один паттерн.

"Устоялся" это слишком громко сказано. Просто "фабрика" достаточно удобное название.

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

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

Вот, допустим, ты забыл, что такое "мост" или "посетитель" - вспомнишь, для чего они, зная только их название?

Учитывая что монады как бы совсем не из функциональщины - да

Да ну? Вспоминай, что за зверь, потому что кроме "композиция функций", "рекурсия" и "карринг" фиг что встретишь, не говоря уже о полноценных паттернах

Раскрой мысль, плиз

Try.of(...)
.success(....)
.failure(....)

Сходу не нашел. В процессе наткнулся на статью на хабре

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

Почему монады постоянно относят к ФП для меня загадка Да и слышно про них только при слове "хаскель".

Есть такое паттерн "Цепочка обязанностей", а не монада ли это случаем?

Монады и точки - это взаимно перпендикулярные сущности.

Раз забыл, значит редко используешь. Значит да, лучше обсудить детали. И значит в этом конкретном случае от паттерна толку не было.

Юзать паттерны не зная что из них чем является - нормальное явление для программиста.

ХЗ зачем я все это делал, но было интересно

Ну фиг знает. Цепочка вычеслений и цепочка вычеслений.

Всякая монада - это действительно цепочка вычислений. Но не всякая цепочка вычислений - это монада.

Что никак не объясняет почему они "перпендикулярны".

Я хз как ещё объяснять. "Монады - это точки" это примерно как "студенты - это программисты". Так вот, студенты и программисты взаимно ортогональны. Есть такая аллегория.

"объекты содержащие логику и состояние и поддерживающие цепочечные вызовы"

в Хаскеле, наоборот, без монад вообще невозможно жить.

А функциональщина она как раз про бесточечную нотацию, кажется.

Можно, но не нужно, ибо с ними удобней.

Как ты себе представляешь приложение без I/O? Без монад можно разве что либы писать.

Как ты себе представляешь приложение без I/O? Без монад можно разве что либы писать.

Монады не про IO.

Берёшь unsafePerformIO и вперёд.

This is the "back door" into the IO monad, allowing IO computation to be performed at any time.

Там все равно присутствует монада IO:

И всякие операторы вроде >>= и do-нотация - это тоже использование монад.

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

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