Абсолютно не согласен. Нужен удобный для постоянного использования синтаксис, пусть лучше его придётся один раз освоить. От предложенного варианта за три версты разит желанием впихать всё в swich «лишь бы match в язык не добавлять».
Теперь создаём новый контейнер, который будет хранить исполняемый файл
становится непонятно, где нужно создавать модуль ENAME? Внутри папки LNAME? Или рядом с ней?
Вы привели содержимое папки LNAME, почему после второго шага не сделать то же самое?)
Я, например, вообще надеялся, что уж если Jetbrains сделают .NET IDE, то наконец-то будут нормальные рефакторинги для F#, а тут «no plans for F# right now»
Полный аналог do-синтаксиса хаскеля в F# — computational expressions. Они даже несколько шире, т.к. позволяют вручную определять семантику (возможно, то же можно делать в Haskell).
Тот же пример из слайдов мог бы выглядеть как
Именно так у нас в проекте и сделано) Вот тут реализация, кому интересно: Result
Да. По сути, он будет отличаться от кода, изображённого на второй только операцией композиции)
Просто сейчас в рабочем проекте такую технику используем, по сравнению с исключениями это просто рай
Сначала я тоже был раздосадован этим моментом. В реальных случаях можно определить функцию MapError и передавать ей декоратор ошибки, пришедшей «снизу». Код при этом остаётся монадическим, а ошибки начинают не только пробрасываться, но и получают человекопонятное пояснение.
Что-же до функций validateRequest, canonicalizeEmail и т.д. — если их клеить не с помощью >> а с помощью FlatMap, то они смогут возвращать такие же человекопонятные ошибки, как и императивный код)
Такие споры давно уже пора закончить тезисом «лучше то, что удобнее использовать конкретному человеку». Кому-то просто физически нужны средства для построения более высоких абстракций, кто-то любит обходится более простыми инструментами. Крики «СЛОООЖНА» не менее смешны, чем «отстой, застрявший в каменном веке».
Как показывает мой опыт, функциональные языки дают больше возможностей для того, чтобы сделать проект в одиночку или небольшой командой, чем «проще» язык, тем в больших командах он находит применение, как-то так.
Многие говорят, правда, что при разработке на более «сложном» языке понадобится меньше программистов) Но мне тут трудно судить.
Однако это ключевое слово добавили. Refactor->rename наше всё
становится непонятно, где нужно создавать модуль ENAME? Внутри папки LNAME? Или рядом с ней?
Вы привели содержимое папки LNAME, почему после второго шага не сделать то же самое?)
Ну, как всегда…
Нет, не криминал, но занятие тоже очень «почётное»
P.S. И кто-то очень быстро стал «Full-stack developer»
Забавно читать это в коменте человека, занимающегося парсингом сайтов)
Именно так у нас в проекте и сделано) Вот тут реализация, кому интересно: Result
Просто сейчас в рабочем проекте такую технику используем, по сравнению с исключениями это просто рай
Что-же до функций validateRequest, canonicalizeEmail и т.д. — если их клеить не с помощью >> а с помощью FlatMap, то они смогут возвращать такие же человекопонятные ошибки, как и императивный код)
Как показывает мой опыт, функциональные языки дают больше возможностей для того, чтобы сделать проект в одиночку или небольшой командой, чем «проще» язык, тем в больших командах он находит применение, как-то так.
Многие говорят, правда, что при разработке на более «сложном» языке понадобится меньше программистов) Но мне тут трудно судить.
Присоединяюсь! Таким, как эта статья, хотелось бы видеть каждое краткое введение в язык.
Сдаётся мне, там далеко не только из-за статьи школьника проблемы