В начале
А потом удивляемся почему код гавно и идем спешно читать про рефакторинг, SOLID и дизайн-паттерны :)
Простите, а какой Agile или даже Scrum может быть в аутсорсе? 99.9% проектов работают по Fixed Price или много реже по Time & Material схеме. Если заказчик в аустсорсинге не готов платить в том числе и за эксперимент, и за изменения (переработку функционала), к тому же требует зафиксировать содержание, бюджет, сроки, о каком Agile, Scrum и ректоспективе может идти речь?
Назовите хоть одну причину почему девелоперы на любой галере должны быть заинтересованы в ретро, если завтра их может заменить другой гребец из какого-нибудь Бангалора, а у самой галеры вообще другая схема профита и нулевая заинтересованность в успехе развития бизнеса заказчика и его долгосрочных стратегических перспектив?
Ретроспектива как и постоянная и частая обратная связь с заказчиком — ключевой момент здорового Agile-а. Формальные методологии, церемонии и процессы здесь не имеют никакого значения.
А, да, у адепта все вокруг адепты, уже писал об этом, вы решили личным примером показать?
Зачем с больной головы на здоровую перекладываете? Поищите по тексту кто впервые употребил слово «адепт» и в отношении кого. Развешали на всех ярлыки, а сами белый и пушистый?
Далее про имена — демагог всегда от идей перейдёт к тому что какой-то дядя аяй скажет, а какой-то нет.
Ссылка на источники или материалы это демагогия? Так вы тут оперировали кучей имён, да и книг как вполне авторитетных. Или вы полагаете что ваш сугубо личный опыт он по-дефолту эмпиричней любого другого? Спешу вас огорчить, кол-во лет и седины еще не делают из человека Гэндальфа.
Насчет 7ми нот — то ясно, понятно, вы — не в курсе разницы между способом описания и самого описываемого.
Это вообще мимо.
Ох уж эти адепты...
Ну вот опять... :)
LISP, появился в 1958
утрировано, все что можно выразить, и выражалось, и использовалось в LISP в 60ых — универсально.
Ну не комильфо адепту ООП ссылаться на Lisp в таких количествах :)
Когда вы определяете набор функций или классов для работы в определенной предметной области, вы тоже создаете DSL... Всякие ORM — это тоже DSLКогда вы называете осмысленно переменную — вы уже двигаетесь в сторону DSL :)
Посмотрел бы я как вы используете ORM на одних только осмысленных переменных :) DSL без полноценной поддержки на уровне системы типов и/или компилятора это ни о чем.
ну вы еще теорию заговора приплетите :)
это ж главное в адептовости — нефальсифицируемость.выяснять же — почему так сложилось адепт конечно не будет. у него базы для этого нет.
Конечно. Ведь религия не позволяет пойти по ссылке с видео в моём
вообще-то структуры с прибитыми к ним методами обработки — делались и на plain C
Возвращаемся к структурным языкам? Давайте еще фортран с коболом помянем. Бьерн Страуструп смотрит на вас с неодобрением... Cи не есть C++, не надо только вот на структуры данных оттуда ссылаться, там ни наследования тебе, ни конструкторов с деструкторами , ни полиморфизма без напильника через vtable :)
а идея у обоих вещей — универсальна :)
хоть if-elsами ее запишиадепты просто не в курсе — идей и их истории, их взаимосвязи
их универсальности, или новизны
А вся western музыка базируется на 7 нотах (12 если с хроматизмами). Но тут и рэпчик и попса и джаз и классика. А девятую симфонию Бетховена можно и битбоксом сыграть при отсутствии скрипки и контрабаса :)
хотя и кортежи, и record types — это универсальные структуры данных, на которые адепты ФП «почему-то» наложили «монополию» :)
а pattern matching — развитие «микро DSL»
Уже вдруг стали универсальными? :) Вот смотрю топ-лист фич C# 9.0:
В C# 11 обещают завезти discriminated unions. Тоже станет универсальной структурой данных внезапно? :) А как на счет LINQ? Или extension методов которые вообще ни разу не ООП а больше напоминает mixins в JavaScipt? А те же records которые вы назвали универсальной структурой почему-то идут в наборе с non-destructive mutation и read-only семантикой и по оператору сравнения. А имьютабилити так все и пропитано, это ли не одна из главных фич ФП?
Так что все выглядит как раз до наоборот — ООП ребята уверовали что это универсальные структуры данных и развитие микро DSL :) Лет через пяток так вообще будут веровать что ф-и высшего порядка это всегда была фича ОО :) Вон как молодые японцы например уверены что на Хиросиму и Нагасаки ядерные бомбы сбросил СССР
Там где вы видите только разговоры о популярности ФП, я вижу что синтаксис и стиль написания кода на чисто ООП-шных некогда ЯП давно мигрировал в мультипарадигму (чаще это микс ФП и ООП) и сейчас уже найти код в классике OOP/OOD становится все сложней — очень уж все разбавлено extension methods, LINQ, pattern matching и это только будет продолжаться. А в том же JS вообще никогда не было дизайна по классике ООП с его прототипированием и ф-ми возможностями — он всегда был миксом.
а pattern matching — развитие «микро DSL»
Да ладно, не юлите... а в контексте ЯП что есть DSL? :)
обкатано было да, в академических ЯП, прежде чем попасть в мейнстрим
как и многое в других областях — вначале в науке, в исследованиях, а потом уже в массовое производство.
Да, F# в Microsoft долго был в R&D, там обкатывали идеи и внедряли в C# и успешно делают это до сих пор. Последние лет 5 F# активно стали двигать и развивать как самостоятельный продукт, даже у VB.NET такой вот поддержки почему-то нет. VB оставили в основном для устаревших веб-форм и язык не развивается.
Как я уже говорил, мейнстрим он не из-за его высокой эффективности таковой, а потому что так сложилось. Через N лет C# 20 или Java 20 будут возможно слегка отличаться синтаксисом от F#/Scala при этом будучи полноценно мультипарадигменными ЯП с охеренным уклоном в ФП, но адепты ООП и любители динозавров все так же будут рассказывать байки о непопулярности ФП и эффективности учений Карла Маркса Гради Буча при этом не замечая что у них в коде почему-то рекорды заменили классы, switch/case волшебным образом превратился в паттерн-матчинг, а чтобы войти в режим классики ООП/ООД им теперь нужно явно входить в режим legacy-compatibility :)
Это все только подтверждает то, что есть инструмент и есть руки его держащие — не все те руки знают как инструмент работает :)
а кто сказал что DDD — основной тренд, признак тру проектирования? ;)
Никто. Смотря какие системы строить, часто оно и нафик не нужно. Все таки DDD позиционируется для сложных доменов и как по мне, помогает разрулить сложность и читаемость кода (хотя и привносит другую сложность).
Кстати все тот же Эрик Эванс уже долгие годы сожалеет о том, что он поместил Entities, Value Objects, Repositories и прочее в начало книги, т.к. читатель дальше не осиливает, а все интересное как раз дальше — про то как готовить слона, стратегии, дизайн, трансформации и поведение.
Про поплуярность FP я тут противоречий не вижу. В последние годы вот позапихивали кортежи, record types, pattern matching и прочее ФП в C# с которым я работаю уже лет 13. А LINQ так вообще в 2008 туда впихнули. Вместо C# можно смело подставлять Java, Python и т.п. Вопрос, зачем и как это коррелирует с популярностью ФП? Можно ведь и без этого обойтись, делать все по Бучу и паттернам банды
и почему с адептами обычно нет никакого смысла обсуждать все это — серьезно :)
Адепты они везде отдают привкусом религиозности. Разве адепты ООП или DDD другие?
Конечно, использовать Scala только как улучшенную Джаву, особенно когда есть Kotlin, по моему микроскопом гвоздезабивание.
Да, но Kotlin используют преимущественно в Android разработке и довольно-таки эффективно. На счет как замены для остальной Java, насколько слышал от джавистов, пока еще нет той поддрежки по библиотекам и остальному.
По тому что пишут на Scala — в основном сложные распределенные системы и платформы. Не знаю насколько много in-house софта и бизнес-ориентированных систем на Scala, но наличие ADT и ф-й с композицией должно позволять красиво делать DDD со всеми сопутствующими штуками а-ля event sourcing, CQRS и т.п. Другое дело что не все разрабы/конторы готовы осваивать этот швейцарский нож с его 88 версиями :)
Простите, а ничего что дип лёрнинг модели композиционны, а компоненты не мутабельны? Весь процесс глубокого обучения можно рассматривать как оптимизацию набора составных функций, то есть сами модели по своей сути функциональны. В принципе модели это по существу — математические модели. Например, искусственные нейронные сети состоят из связанных узлов, каждый из которых выполняет простые математические операции.
Математические аргументы: colah.github.io/...osts/2015-09-NN-Types-FP
Практические примеры ML библиотеки: github.com/originrose/cortex
Не единым TensorFlow и PyTorch. Здесь как раз смотрят на ФП в первую очередь за такими штуками как safe(типы) и performance (параллелизм).
Взаимно!
вот именно!
и? оглянитесь — и прикиньте — а почему он был тогда там, а сейчас — здесь? что было причиной?
Так я ж написал — легко учить + стабильное увеличение популяции нубов (ключевое!), комьюнити, тузлы/фреймворки, поддержка спонсорами.
Сейчас практически у всех топ 15 языков есть большинство аттрибутов: спонсоры, комьюнити, экосистема. Сложность, эффективность и технологические изюмики уже другое дело. Тут и от домена применения зависит и от много еще чего. Пока большинство будут нубами, они всегда будут в топ двигать самое ходовое и легкое в обучении (не путать со скоростью разработки и тем более сопровождения). Это как есть попса, а есть джаз, блюз, рок и классика.
JavaScript и Python они сейчас достаточно всеприменимы во всех областях более-менее.Сугубое ИМХО что их вытеснят рано или поздно узконаправленные вглубь яп — R в machine learning и статистике, какие-нить ФП или ООП с кучей ФП заимствований (Java/C#) в клауде и дистрибьютед и так далее.
оглянуться, а не смотреть вперед, в будущее где «функциональное программирование зохавает весь мир!»
Структурное же захавало, ООП же захавало :) Почему бы и ФП нет :) Не знаю как в других ЯП, но в C# последние года
общее правило — любые технология, метод, подход, способ X — что повышают скорость выживут.
А весьма вероятно станут — основными.
а никакой прямой корреляции с академичностью, правильностью, «думами математиков» этот X не имеет
Рейтинги в прогнозировании будущего ЯП это как гадание на кофейной гуще. Да и неблагодарное это дело. Где был пайтон в нулевых? Как появился в 1991, полз черепахой к успеху: С.С++, C#, Java и Ruby были всегда популярнее и долгими годами держали планку. Если верить дядюшке Бобу, популяция программистов удваивается каждые 5 лет. Следовательно мы имеем много нубиков которые обычно стартуют с JS и Python как самого быстро способа войти в айти. Ну и Scratch туда же :)
Тут корреляция с эффективностью ЯП весьма косвенная и неустойчивая.
Кол-во вакансий по C#/Java, Kotlin, Scala, Go меньше тоже не становится. Можно так же отметить что существующие Python/PHP/JavaScript проекты не самые интересные и прогрессивные с точки зрения tech. Да, сайтики, малость in-house софта, немного мэшин лернинга быстро своять позволяют, но всякие там Эриксоны, Фейсбуки, Гуглы и Мозилы выдают нечто вроде Erlang, Rust, Go вовсе не от хорошей эффективности яп с дин. типизацией. :)
и однако ж, поди ж ты, пишут и до сих на них.
ужас?
Не, пямятник при жизни им.
да, GC рулит
Ну не единым же GC
странно, типы ж — это так удобно, так здорово, не то что ООП, которое годы и годы учить.
интерны за год осваивают ФП!
Так себе подкол :) Осваивают, но не Haskell же наскоком.. OCaml-овский F# или Lisp почеловечнее будет. Это как освоить C++ (или скорее C#) за год на базе знаний скажем по Turbo Pascal — писать код уже можно, но под присмотром. Как аналогия ООП программиста еще без знания SOLID и паттернов вдоль и поперек.
pbs.twimg.com/...t_?format=png&name=medium
А что после SOLID-то ? Правильно, ФП :)
blog.ploeh.dk/...-next-step-is-functional
у какого какой опыт.
я уже встречал проекты которые с джавы на пыху переписывают :)с полгода назад даже была статья от одного лида, из команды неслабой в США компании, как они с джавы в пыху ушли.
Интересно какая мотивация и rationale?
Си — это инструмент, острый, как бритва: с его помощью можно создать и элегантную программу, и кровавое месиво. Брайан Керниган
не страшно жить в мире где ладно там сервера на линухе, а ембедед этой бритвой сделан?
Все верно. Но система типов в Си или С++ достаточно базовая по сравнению с той же Java/C# - использование указателей, более примитивные абстаркции, нет проверки на граничные значения в тех же массивах и т.п. И да, на C++ писать сложнее и времязатратнее, но там где нужна производительность и высокий уровень контроля самое оно.
Конечно есть контр-пример — Haskell — писать еще сложенее и порог входа. Но тут уже другие гарантии от компилятора по типам... это скорей не бритва, а топорик с резиновой рукоятью и к нему перчатки из стекловолокна.
ну а веб с пыхой на бекенде — не страшно?
Страшно, вот и переписываем на C# и Angular/TypeScript :)
Раз уже ссылаетесь на старину Боба, то он чем старее, тем более гладиолус. Приведу пару его цитат из куда более свежего:
My favorite language of all, the language that I think will outlast all the others, the language that I believe will eventually become the standard language that all programmers use......is Lisp.
And then, a decade ago I found SICP. And after that I found Clojure. Clojure is a Lisp that rides on top of the Java ecosystem (and does not have CARs or CDRs, or CADADAADR s).I wasn’t convinced right away. It took a few years. But after the usual stumbling around and frustration, I began to realize that this language was the easiest, most elegant, least imposing language I had ever used — and not by a small margin.
blog.cleancoder.com/...019/08/22/WhyClojure.html
По поводу статической vs динамической типизации и тестов:
If you compare the two functions that Mark and I wrote (and if you understand Haskell, which I don’t) I think you’ll find that the two implementations are somewhat similar. The testing strategies we employed were, however, very different.The tests I wrote show that I was concerned almost entirely with the desired behavior of the function. The tests walk that behavior forward one small step at a time using the TDD style.
Mark, however, was far more concerned with expressing correctness in terms of generic types. The vast majority of his thought process was consumed with the type structure that properly represented the problem. He then verified behaviors with property-based QuickCheck style tests, and after-the-fact tests.
Which is better?
„Answering that question with specificity is above my pay grade.” — Barack Obama.
Which of us wound up with fewer tests? In either case I think the four base assertions are adequate. However, as part of the process I wrote 8 assertions and Mark wrote two property-based QuickCheck tests, and three after-the-fact regression tests. Does that amount to 5 vs. 8? Or do those QuickCheck tests count for more? I don’t know. I’ll let you decide.
blog.cleancoder.com/.../06/08/TestsAndTypes.html
При всех современных тулзах: линтерах и продвинутых IDE можно вполне себе успешно писать и код с динамической типизацией. Да, при этом покрытие тестами по поведению и входным данным должно быть куда более серьезное чем в аналогичных системах со статической типизацией, так как нужно учитывать что может прийти null,nil,NaN,object,any и т.п. Читаемость и сопровождаемость систем с дин. тип. в значительной степени будет зависить от соблюдения коде конвеншинов, опыта разработчиков и тулзов по отлавливанию ведьм. Статическая типизация, с другой стороны, позволяет на уровне типов отсечь невалидные данные, повысить самодокументируемость кода и меньше зависить от тулзов. ЯП со стат. типизацией и улучшеным выводом типов (Haskell, F#, Idris) к тому же делают аннотацию вообще не нужной в большинстве случаев и код выглядит примерно как в яп с дин. типизацией.
Гибкость джаваскрипта позволяет делать многие вещи и писать мультипарадигменно. Обратная сторона медали, это то что с таким же успехом джс позволяет легко снести себе бошку. Стать действительно хорошим джаваскрипт разработчиком (или любого другого яп с дин. типизацией) и писать эффективнй код, требует много больше времени и практики.
TypeScript в этом плане видится как попытка все-таки не снести себе бошку и сделать жизнь разрабов легче, а код более самодокументируемым.
а вы его заметили, отличие? ;)
это ж и спрашивалось — и в чем оно?
Та не, то просто хайп, никакого отличия. Не берите в голову, а то еще всякие монады с аппликативами сниться будут и по ночам зигохистоморфный препроморфизм приходить будет :)
и вы все равно не можете его показать, разительное отличие?
через3-4 года — практики?
Даже уже и не хочу, а то вы в этой ветке единственный истинно заинтересованный в ФП. Давайте договоримся что ООП = ФП, только бирочка другая.
я что, идиот вестись на хайп, и бросаться грудью на амбразуру?
желающих то хоть отбавляй, я им дорогу уступаю, и смотрю на последствия :)
Ахаха, а вы мне рассказываете про шишки набил :) Все понятно с вами. За сим и откланиваюсь.
дну из главных фич ФП — иммутабельность данных. на малых объемах это копирование — незаметно. но на приличных — требуется поддержка на уровне транслятора, как то в тру ФЯ — Haskell и OCaml. Про F# не знаю, не копал, может и там сделано правильно.
Чисто для прикола, посмотрите вот fable.io
вопросов по делу было рассыпано — вы их даже не заметили :)
то есть — либо и не читали, либо вообще не понимаете о чем речь :)
Видимо мало одного адепта на вашу боль и вопросы, вы больше были увлечены доказательством того что никакого разительного отличия от ООП и нет то.
говорю ж — восторг адепта как мультипликатор его малой осведомленности и в том что он проповедует :)
Та не, восторг был года
кто такой же — ну пусть попробует простое такое ФП, и перейдет на него :) отговаривать такого смысла нет — он же на восторг и хайп повелся. а шишки — полезны и такие.
кто пробовал, или понимает в чем главные боли в разработке — будет выискивать решения этих проблем, или задаст вопросы.
ответов — ессно не найдет и не получит :)
Это само собой. Все ищущие ответы получают, а вот вы их на форумах ищите среди адептов и не находите :) Вот диво. А ведь еще там всякие книжки есть по ФП.
ну, я по крайней мере за годы не услышал.
может другие — услышали, и да, мир каааак ломанется на ФП, и оставит всех скептиков за бортом истории.
Так если вы бы слушать хотели... :) Не знаю меняется мир или нет но вот списочек книг по функциональному Джаваскрипту намекает что интерес есть и если покопаться то до чертиков библиотек и фрейморков можно будет в джс найти написаных в ФП: www.amazon.com/...ship,137&ref=nb_sb_noss_1
Так обычно сразу в микросервисы и не прыгают. Сразу начинаешь как монолит, а когда система обрастает фичами и новые комманды приходят, тогда уже в микросервисы имеет смысл двигаться. Тут преимущества больше в области изоляции, скейлинга, автономности коммнад и тех. стека. Но по цене серьезного усложнения архитектуры и оркестрации. Ничего не бывает бесплатно, даже в ФП платишь перформансом частенько :)
ну а что остается, если ни на один вопрос по делу вы не в состоянии ответить :)только прикалываться, да троллить :)
Ну да ну да... а sum и product типы, ADT и моделирование это не по делу, а теория по-вашему :) Даже с кодом с примерами :)
любому достаточно пообщаться с адептами — и решить все для себя самостоятельно :)
ФП в антирекламе не нуждается. ее успешно делают адепты
Так что же вы тут делаете в ветке по ФП, адептов отбиваете? Так они и так все сами поймут :)
В детстве акробатика, плавание, тхэквондо, каратэ. Сейчас кикбоксинг, муай тай и комбобоксинг (тема такая местная и очень популярная, фитнес под музыку с отрабатыванием техники ударов на боксерской груше). Но пока локдауны в наших краях и закрыто все.