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