Да и
там, где можно использовать
и
как круто
очень разные вещи.
В Python не знаю, а в Java HOF выглядят примерно так
class MyFunction implements BiFunction<A, B, Function<C, D>>Closure — точно так же, но ещё указав аргумент конструктора (нет, в Scala и Java8 стиле это делать плохо т.к. кложуры не инлайнятся и пересоздаются (не путать с чистыми функциями) по месту использования.
Не в кассу. Знаю «что», не знаю «зачем».
тайпкласы сферические, а еще и типы высших порядков, моноиды с функторами
Вот мне и надо понять — где такая задача, что я (одно из следующих):
И импортировать его надо. А это не то же самое? Только имплиситы менее наглядны. Там больше «магии» и поди разбери какой имплисит инвокится. Не, пусть лучше Java-style многословно, но зато всё под контролем.
В случае ООП — мне просто нужно реализовать нужный контракт.
Я не дизайню эти языки. Возможно это просто коммерческие фичи чтоб нагнать хайп. По моему опыту — Scala без ScalaZ и котов гораздо лаконичнее, более понятна и несёт меньше шума. Да и вообще должны быть ну ооочень веские аргументы для того чтоб применять, скажем, free там, где можно использовать final-tagless подход.
У меня есть набор данных A и набор данных B в разные моменты времени в одной и той же точке програмы. Мне нужно выполнить операцию foo(). Зачем мне применять ad-hoc polymorphism и открывать коду с каким количеством структур я должен выполнить foo() и изменять и перекомпиливать это место когда добавится новая структура, если я могу просто реализовать на них контракт что несёт foo() и выполнить её в том месте, а не писать
case A(aData) => fooA(aData) case B(bData) => fooB(bData)
Да не может оно пугать. Просто на той же Java curry понятнее выглядит. lazy — тут другое. Тут уже с синтаксисом проблемы. Возможно это у меня с непривычки, возможно не только у меня, но часто наталкиваюсь на путаницу между
=> Bи
A => B. Как минимум пару раз было.
статическую типизацию? Вывод типов? Замыкания? Иммутабельность? Декларативность?
всё это есть и в ООП если его правильно применять. Например Scala as Scala, а не Scala as Haskell даёт возможность строить взаимодействие на контрактах, скрывая детали реализации в то время когда «присобачив», например, ReaderMonad ты expose-ишь во внешний клиентский код детали реализации, которые этому коду знать не обязательно. Тем самым завязываясь на эти детали реализации (внося coupling). Вывод: если без чего-то можно обойтись — то лучше без этого обойтись.
хак полувековой давности
не аргумент. ФП возрастом примерно такой же, просто только сейчас эти, описаные ещё в 60х-70х, концепции начали применять на практике.
Been there, done that. Зачем, если я могу решить задачу без них?
под изысканной функциональщиной в том числе, понимается
чистые функции и инкапсуляция сайд-эффекта. Больше ничего в функциональщине не нужно. Остальное — от лукавого и оверхеда там больше чем пользы.
Тайпклассы
Пока никто так и не обьясних на#$@ оно надо?
банального применения обобщённой функции
так мы не решаем обобщенную задачу. У нас задачи специализированы.
Как и все без дженериков — руками специализируя алгоритм под определённый тип. Потом уповая что это не копипаста, а такое решение.
Или (что вероятнее, но менее правильно) будут кастовать. Вот тут то и отхватят проблему типизации в своём уютненьком «Goscript» или «Gohp» кому какой сорт ближе к душе.
Вообще не то и только одну из подзадач и не лучшим/более лёгким способом.
Да нет, благодаря таким как он и автор пхп — говно. А могло бы быть по-другому, не будь таким низким порог входа или знай и используй лучшие практики.
Кто ж тебя просит пользовать скалу как хаскель? Можно же Scala as Java или Scala as Scala — тогда от того же Go отличается явно не количеством абстракций.
В Go нативно реализованы channel’ы, но нет Actor Model (или я просто о такой не знаю). Actor Model отличная есть в Erlang’е, но нет годных channel’ов (снова таки, я могу не знать). В Scala благодаря либам есть и то и другое. И используя Scala as Scala (так, например, Akka написана) ты получаешь всё это + дженерики + обширную JVM инфраструктуру.
Ну обьяснил бы что это Actor model — принципиально другой подход к вычислениям, обработке состояния. Что подходу уже больше 40 лет, но только недавно его откопали и реализовали так что он крайне удобен в коммерческом продакшне там где тебе нужно работать не на одной железке, а на кластере таких. Что с этой либой ты получаешь бесплатное масштабирование горизонтально и вертикально.
обратное не верно
я же как раз против этого выступаю
именно по этому string-типизированые програмы — плохо и нужны value-objects.