Зависит от учебника. Условные TAPL и LADR — по три месяца на каждую параллельно с работой. Рилевская Category Theory in Context — примерно два с половиной месяца, но это было вне работы, тратя на этак вторую половину книги часов по шесть в день, да и с теоркатом я был знаком в приложениях (поэтому первая половина была довольно халявной). Гольдблаттовские «Топосы» — где-то полтора года, если вычесть пропуски.
Совмещать с работой — ну как, есть же вечера и выходные.
Рассуждать я могу хоть проще, хоть сложнее, это не проблема.
Жаль, что на собеседования такие люди не приходят. Мы бы их наняли и, раз для них это не проблема, мигом бы разобрались и с легаси, и с непонятными багами, и с прочим всем.
Действительно для ФП не подходит так как в ФП нет ни данных, ни методов, ни поведения, ни разделения типов создания и использования, не говоря уже об объектах.
И логики нет, видимо.
Данные — есть, есть просто ваши ООП-данные и функции.
Методы — это просто функции.
Поведение — это то, что функции делают.
Разделение типов создания и использования — есть (хоть через параметрический полиморфизм, например, хоть через явные преобразования).
Объекты — тоже есть, любые типы.
мне не нужны ограничения ФП
Не нужно легче рассуждать о коде и его поведении? А что вы такое пишете, если не секрет?
Была тут одна статья на хабре, но это было давно и неправда.
Подспудное понимание, что плюсы — дерьмовый продакшен-язык, было со мной всегда. Просто я любил программирование само по себе и любил ребусы, а C++ подкидывает этих ребусов достаточно. Но одно дело — решать эти ребусы («мама, посмотри как я могу!») по фану по вечерам в личных проектах, где ты не несёшь ответственности, где тебя не разбудят в три ночи (или, в некоторых областях, не отдадут под суд) из-за проблем в твоём коде, и где ты можешь забить на поддержку старого кода/скучную задачу/понимабельность кода сокомандниками/етц, и другое дело — собсна, нести ответственность при продакшен-разработке со всеми вытекающими.
Понимание перестало быть подспудным и материализовалось большим и не терпящим игнорирования восклицательным знаком, когда я несколько месяцев не трогал плюсы, а вместо этого трогал другие пет-проекты на других языках и вообще другие разделы человеческого знания (потому что компанию, где я работал, купили, и отдел C++-программистов со мной вместе отправили на мороз, выплатив покрывающие мои потребности на несколько лет отступные, так что у меня были ресурсы расслабиться). Я как-то порефлексировал над изменениями настроения и всяким прочим и понял, насколько меня тошнит от C++ и насколько без него легче дышать: тошнит от невозможности писать код, которому я могу доверить управление чужой пенсией-инвестициями; от того, что ни я, ни окружающие меня люди, несмотря на топовые в области зарплаты и доскональнейший отсев, не знают плюсы и регулярно совершают ошибки и проблемы, связанные с самим языком и его кривейшим дизайном, а не с предметной областью; от очередных костылей и кривостей, привносимых новыми стандартами (сможете сказать сходу, для каких T валидна функция template<auto t> const auto& staticify() { return t; }, и почему?); от каких-то добавляемых в разных стандартах мелких деталей, которые всё равно делят язык на «до» и «после» (сможете сходу назвать отличия std::launder иstd::start_lifetime_as и вспомнить, в каком стандарте был std::start_lifetime_as, а в каком — std::start_lifetime_as_array?); от необходимости все эти стандарты держать в более-менее активной памяти, потому что собираемое старой версией легаси никуда не девается, и суммарная сложность языка растёт как снежный ком, а суммарная когнитивная сложность языка перегружает любой мозг, потому что дизайн языка совершенно неортогонален сам по себе, а временной аспект его эволюции («в этом стандарте это работает так-то, а в том — UB») добавляет ещё один совершенно когнитивно неортогональный аспект; от дизайна комитетом в худшем смысле, который и ведёт к этой неортогональности, и что не исправится вообще никогда…
Не логичнее ли сегодня рассматривать его книгу 2024 года Functional Design: Principles, Patterns, and Practices, в которой он преподносит свои принципы SOLID уже в иной форме, чем раньше.
Так она ещё хуже, потому что:
Обсуждаемая книга 2008-го года о продакшен-коде написана человеком, который не писал продакшен-код 18 лет, а книга 2024-го года о продакшен-коде написана человеком, который не писал продакшен-код 34 года, и это видно.
Пик слайтли релейтед
Недядя Боб не понимает функциональщину ещё больше, чем он не понимает ООП.
Если цель — найти причины не любить Боба, то это отличная книга. Если цель — научиться разрабатывать ПО в функциональной парадигме, то это отвратительная книга, и книги domain modeling made functional или algebra-driven design лучше в <целочисленное переполнение> число раз.
Но в молодости высока вероятность создать семью не с той (не с тем). Как достичь идеала, я не знаю.
Изначально планировать долгосрочные отношения и выходить из них, если понятно, что долгосрока не выйдет (даже если она поехавшая, но очень хорошая в постели / он плохой парень, но дарит карусель эмоций), и не делать тяжело обратимых действий (вроде рождения детей, которых можно завести и в 30), пока не станет понятно, что это действительно надолго.
Возможно, вокруг вас рептилоиды нет нужного человека.
Имеете право. У каждого свой путь...
Просто в 34 уже привыкаешь к определённым паттернам, и те вещи, на которые был готов в 17, уже кажутся кринжовым бредом и тратой времени непонятно зачем. Детей я не хочу, со всем остальным могу (и привык) справляться самостоятельно.
ИМХО итого истина где-то посередине: сделать PoC (или, по моему опыту, условную местечковую тулзу для условного работодателя уровня «автоматизировал загрузку новой версии сайта на FTP-сервер») можно в одиночку, но потом таки придётся работать с другими людьми, если хочется, чтобы проект взлетел.
А так как мы вроде обсуждаем промышленное программирование за деньги, а бизнесам всяким нужны не только PoC'и, и платят они не за это, то либо сидишь всю жизнь делаешь местечковые тулзы-загружалки на FTP-сервера, либо приходится работать в команде (при всей моей нелюбви к командам).
Абстрактное мышление это не врожденная способность, а приобретаемая. Любовь к математике может быть на генном уровне, а способность абстрактно мыслить – только после полноценного образования.
Способность к абстрактному мышлению вполне может быть генетически обусловлена. Да, для её раскрытия нужны, скажем так, тренировки и обучение, но это не значит, что обязательно именно математическое образование. Этими тренировками и обучением может быть само программирование.
Только я даже после первого, технического ВУЗа, чувствовал свои пробелы в образовании, из-за которых возник даже, отчасти, комплекс неполноценности.
А у меня комплекс неполноценности возник после изучения фундаментальной математики, и? О чём это говорит?
и вы чувствуете себя успешным после пары курсов по программированию
Ложная дихотомия. Можно вместо пары курсов по программированию те же 4-6 лет потратить на глубокое изучение программирования, пет-проекты, опенсорс-контрибьюшны, и так далее.
У нас, в провинции, просто не было программистских команд, и сейчас нет.
И удалёнки нет? И интернета нет?
У меня был знакомый из какой-то депрессивной деревни, который работал со мной в команде удалённо лет 15 назад.
Большая часть кода для этих модулей найдена на Гитхабе и CodeProject. Собрал всё вместе, получился индивидуальный проект, целью которого является подготовка данных для другого моего пет-проекта (тоже модульного типа): «Новая компьютерная программа для запоминания иностранных слов и фраз»
Без фундаментальной математики и понимания декартово замкнутых категорий в этих задачах никуда.
Науку и высокие технологии никто вроде отменять еще не собирается.
Потому что у этого термина действительно нет хорошо определённого объективного значения, и проще будет, как это обычно бывает в человеческом языке, оперировать недоопределёнными терминами.
Вряд ли на таком определении можно строить какую-то объективную теорию.
А у нас нет объективной теории ООП, инкапсуляции, и тому подобных вещей. Любые попытки построить такую теорию разбиваются о неприменимость её на практике.
Ну или давайте с другой стороны. Что такое по-вашему инкапсуляция?
По сути вы подменили одно умное слово другим умным словом, а это даже как-то не красиво. В таком направлении дискуссия мне не интересна.
Для протокола отмечу, что вы сами начали разговор с того, что написание в ФП-стиле с передачей лямбд в функции может ломать инкапсуляцию, но теперь при попытках поговорить по существу требуете от других прямо определять этот термин. Почему вам не нужно было его определять, когда вы сказали, что инкапсуляция от этого ломается?
Edwin Brady — автор единственного в мире по-настоящему строго типизированного языка —: «ну да, ну да, кустарь я».
Ну он же далеко не единственный автор. Вот первая версия:
— на пару с не-рискну-транслитерировать-фамилию.
Вот вторая версия:
(плюс 570 commits 69 663++ 27 241-- в репе с blodwen). Снова далеко не один, и в моём личном опыте я с gallais и buzden встречался в обсуждении пуллреквестов или у них в дискорде сильно чаще, чем с самим Эдвином.
В продакшеге у вас один код который его сетит и он всегда исполняется при инициализации, а в тестах вы резетете его после/перед каждым тестом. Да конечно можно и функцию резет в самом типе реализовать, но она не нужна в продакшнене, а опшионал ее и так реализует.
А если бы вы просто имели параметр в конструкторе, то вам бы не пришлось ничего ресетить: вы просто создаёте новый объект на каждый новый экземпляр класса. Десинглтонизация снова выигрывает!
Я как раз на плюсах и пишу там помимо * и -> есть еще и валью и валью_ор и в 23 ещё и прочие функциональные зены и элсы подвезли.
Первый тейк - относится не к невозможности писать в функциональном стиле, а что в сях не очень с полиморфизмом(обойдёмся без void*), и эти требования как то выше не предполагались. Хотя я на функциональных языках не программировал, мб это там повсеместно.
Это там именно что повсеместно. По крайней мере, в ML-семействе.
А второе - да, ошибся, код написал за 3 минуты.
Это как раз норм (для C++), потому что C++ и C не приучают думать в терминах типов. Функциональщик начал бы с написания сигнатуры и автоматически подумал «а как я инт-то верну на пустых входных данных? надо в Maybe завернуться».
а волнует он не потому что это "общепринято", а потому что человек это такая скотина которая в одиночку не живет обычно
Человек живёт в стае, а не в парах. Да, человек в среднем моногамен (или скорее полигиничен) на фоне других живых существ, но это не то же самое, что хотеть пару.
Хаскелист, конечно.
Зависит от учебника. Условные TAPL и LADR — по три месяца на каждую параллельно с работой. Рилевская Category Theory in Context — примерно два с половиной месяца, но это было вне работы, тратя на этак вторую половину книги часов по шесть в день, да и с теоркатом я был знаком в приложениях (поэтому первая половина была довольно халявной). Гольдблаттовские «Топосы» — где-то полтора года, если вычесть пропуски.
Совмещать с работой — ну как, есть же вечера и выходные.
И это относится к исходному тезису… как?
Раз уж среди работников есть прилежные, раздолбаи, рокстары и пассажиры, то и среди работодателей вероятно есть разные с разными предпочтениями?
Как ещё интерпретировать ваше «мне делать нужно» как очевидно отрицающий мой поинт ответ?
Разговор не про это, а про то, чтобы немножко подумать перед тем, как бросаться писать новый код.
А, ну классическое «некогда думать, делать надо».
Жаль, что на собеседования такие люди не приходят. Мы бы их наняли и, раз для них это не проблема, мигом бы разобрались и с легаси, и с непонятными багами, и с прочим всем.
И логики нет, видимо.
Данные — есть, есть просто ваши ООП-данные и функции.
Методы — это просто функции.
Поведение — это то, что функции делают.
Разделение типов создания и использования — есть (хоть через параметрический полиморфизм, например, хоть через явные преобразования).
Объекты — тоже есть, любые типы.
Не нужно легче рассуждать о коде и его поведении? А что вы такое пишете, если не секрет?
Была тут одна статья на хабре, но это было давно и неправда.
Подспудное понимание, что плюсы — дерьмовый продакшен-язык, было со мной всегда. Просто я любил программирование само по себе и любил ребусы, а C++ подкидывает этих ребусов достаточно. Но одно дело — решать эти ребусы («мама, посмотри как я могу!») по фану по вечерам в личных проектах, где ты не несёшь ответственности, где тебя не разбудят в три ночи (или, в некоторых областях, не отдадут под суд) из-за проблем в твоём коде, и где ты можешь забить на поддержку старого кода/скучную задачу/понимабельность кода сокомандниками/етц, и другое дело — собсна, нести ответственность при продакшен-разработке со всеми вытекающими.
Понимание перестало быть подспудным и материализовалось большим и не терпящим игнорирования восклицательным знаком, когда я несколько месяцев не трогал плюсы, а вместо этого трогал другие пет-проекты на других языках и вообще другие разделы человеческого знания (потому что компанию, где я работал, купили, и отдел C++-программистов со мной вместе отправили на мороз, выплатив покрывающие мои потребности на несколько лет отступные, так что у меня были ресурсы расслабиться). Я как-то порефлексировал над изменениями настроения и всяким прочим и понял, насколько меня тошнит от C++ и насколько без него легче дышать: тошнит от невозможности писать код, которому я могу доверить управление чужой пенсией-инвестициями; от того, что ни я, ни окружающие меня люди, несмотря на топовые в области зарплаты и доскональнейший отсев, не знают плюсы и регулярно совершают ошибки и проблемы, связанные с самим языком и его кривейшим дизайном, а не с предметной областью; от очередных костылей и кривостей, привносимых новыми стандартами (сможете сказать сходу, для каких
Tвалидна функцияtemplate<auto t> const auto& staticify() { return t; }, и почему?); от каких-то добавляемых в разных стандартах мелких деталей, которые всё равно делят язык на «до» и «после» (сможете сходу назвать отличияstd::launderиstd::start_lifetime_asи вспомнить, в каком стандарте былstd::start_lifetime_as, а в каком —std::start_lifetime_as_array?); от необходимости все эти стандарты держать в более-менее активной памяти, потому что собираемое старой версией легаси никуда не девается, и суммарная сложность языка растёт как снежный ком, а суммарная когнитивная сложность языка перегружает любой мозг, потому что дизайн языка совершенно неортогонален сам по себе, а временной аспект его эволюции («в этом стандарте это работает так-то, а в том — UB») добавляет ещё один совершенно когнитивно неортогональный аспект; от дизайна комитетом в худшем смысле, который и ведёт к этой неортогональности, и что не исправится вообще никогда…Как-то так.
Так она ещё хуже, потому что:
Обсуждаемая книга 2008-го года о продакшен-коде написана человеком, который не писал продакшен-код 18 лет, а книга 2024-го года о продакшен-коде написана человеком, который не писал продакшен-код 34 года, и это видно.
Недядя Боб не понимает функциональщину ещё больше, чем он не понимает ООП.
Если цель — найти причины не любить Боба, то это отличная книга. Если цель — научиться разрабатывать ПО в функциональной парадигме, то это отвратительная книга, и книги domain modeling made functional или algebra-driven design лучше в <целочисленное переполнение> число раз.
Изначально планировать долгосрочные отношения и выходить из них, если понятно, что долгосрока не выйдет (даже если она поехавшая, но очень хорошая в постели / он плохой парень, но дарит карусель эмоций), и не делать тяжело обратимых действий (вроде рождения детей, которых можно завести и в 30), пока не станет понятно, что это действительно надолго.
Просто в 34 уже привыкаешь к определённым паттернам, и те вещи, на которые был готов в 17, уже кажутся кринжовым бредом и тратой времени непонятно зачем. Детей я не хочу, со всем остальным могу (и привык) справляться самостоятельно.
Это ты proofs for free не смотрел ещё.
Притащил вам ещё салютов
Скрытый текст
Наконец-то мы избавились от этих тиранов!
ИМХО итого истина где-то посередине: сделать PoC (или, по моему опыту, условную местечковую тулзу для условного работодателя уровня «автоматизировал загрузку новой версии сайта на FTP-сервер») можно в одиночку, но потом таки придётся работать с другими людьми, если хочется, чтобы проект взлетел.
А так как мы вроде обсуждаем промышленное программирование за деньги, а бизнесам всяким нужны не только PoC'и, и платят они не за это, то либо сидишь всю жизнь делаешь местечковые тулзы-загружалки на FTP-сервера, либо приходится работать в команде (при всей моей нелюбви к командам).
Способность к абстрактному мышлению вполне может быть генетически обусловлена. Да, для её раскрытия нужны, скажем так, тренировки и обучение, но это не значит, что обязательно именно математическое образование. Этими тренировками и обучением может быть само программирование.
А у меня комплекс неполноценности возник после изучения фундаментальной математики, и? О чём это говорит?
Ложная дихотомия. Можно вместо пары курсов по программированию те же 4-6 лет потратить на глубокое изучение программирования, пет-проекты, опенсорс-контрибьюшны, и так далее.
И удалёнки нет? И интернета нет?
У меня был знакомый из какой-то депрессивной деревни, который работал со мной в команде удалённо лет 15 назад.
Без фундаментальной математики и понимания декартово замкнутых категорий в этих задачах никуда.
Платят за них ну так, разве что.
Потому что у этого термина действительно нет хорошо определённого объективного значения, и проще будет, как это обычно бывает в человеческом языке, оперировать недоопределёнными терминами.
А у нас нет объективной теории ООП, инкапсуляции, и тому подобных вещей. Любые попытки построить такую теорию разбиваются о неприменимость её на практике.
Ну или давайте с другой стороны. Что такое по-вашему инкапсуляция?
Для протокола отмечу, что вы сами начали разговор с того, что написание в ФП-стиле с передачей лямбд в функции может ломать инкапсуляцию, но теперь при попытках поговорить по существу требуете от других прямо определять этот термин. Почему вам не нужно было его определять, когда вы сказали, что инкапсуляция от этого ломается?
Надо продолжать традиции предыдущих президентов!
Ну он же далеко не единственный автор. Вот первая версия:
— на пару с не-рискну-транслитерировать-фамилию.
Вот вторая версия:
(плюс 570 commits 69 663++ 27 241-- в репе с blodwen). Снова далеко не один, и в моём личном опыте я с gallais и buzden встречался в обсуждении пуллреквестов или у них в дискорде сильно чаще, чем с самим Эдвином.
А если бы вы просто имели параметр в конструкторе, то вам бы не пришлось ничего ресетить: вы просто создаёте новый объект на каждый новый экземпляр класса. Десинглтонизация снова выигрывает!
Запретили уже стайлгайдом или линтером
*и->?Это там именно что повсеместно. По крайней мере, в ML-семействе.
Это как раз норм (для C++), потому что C++ и C не приучают думать в терминах типов. Функциональщик начал бы с написания сигнатуры и автоматически подумал «а как я инт-то верну на пустых входных данных? надо в Maybe завернуться».
Человек живёт в стае, а не в парах. Да, человек в среднем моногамен (или скорее полигиничен) на фоне других живых существ, но это не то же самое, что хотеть пару.