Wrt functional paradigm, do you think it has a higher cognitive load than procedural and/or OO?
I can’t tell: it does always take me forever to remember how to use reduce (in say elixir), but then my day job is python, so is it just because of the conceptual switch?
I actually find higher order functions like map/filter/reduce to be simpler in the long term than pervasive for loops, and my one major gripe with golang is its lack of generics that would let it have these. I don’t really understand the hate recursion gets either, and you have to learn to use it in procedural languages anyways. My issue with “pure” functional programming languages, and I’m speaking with a sample size of one here (Haskell), is that Monads and I/O seem comically difficult to use or explain. It’s possible that I just haven’t put in the hours reading through long detailed explanations of these concepts, and that if I did it’d “click” and I’d never have to think about them again, but I find statistics textbooks easier to read than the myriad monad “tutorials” I’ve been handed for this language.
I believe the world is this way because of the following two facts:
monads are very hard to get your head into;
monads are extremely simple conceptually.
This means that everyone spends a long time thinking about monads from lots of different angles, and then one day an individual just happens to grok monads while reading their fiftieth tutorial, and so they believe that this fiftieth tutorial is The One, and the particular way they were thinking about monads at the time of the epiphany is The Way. So they write yet another tutorial about how Monads Are Really Simple They’re Just Burritos, and meanwhile their only actual contribution to the Monad Exposition Problem is to have very slightly increased the number of paths which can lead an individual to comprehension.
″ higher order functions like map/filter/reduce to be simpler”: do you find most other programmers find this too?
my experience is otherwise: i get a ton of pushback asserting this stuff is too hard to read and thus should NOT be use in our shop; somehow in python even using filter is more difficult than a list comprehension with an if!!???!!
I don’t really know what most programmers are like ¯\_(ツ)_/¯, I’ve never held a real software engineering job and most of my experience comes from my current attempt at building a startup. So far my cofounder seems fine with it, but we mostly work on different codebases.
Leonard Recruiting. We’re a recruiting company for penetration testers, right now specifically web application pentesters. My cofounder and I have been working on the product part time for four months (way too long, I know) and we plan on launching our platform in about a week, which is an open, dynamic, live computer hacking exam. We haven’t even gotten seed funding yet, so it might be a little generous calling us a “startup”, though recently we’ve actually been getting some unexpected revenue by building out our exam platform for small businesses that my cofounder knows personally.
My issue with “pure” functional programming languages, and I’m speaking with a sample size of one here (Haskell), is that Monads and I/O seem comically difficult to use or explain. It’s possible that I just haven’t put in the hours reading through long detailed explanations of these concepts, and that if I did it’d “click” and I’d never have to think about them again,
Fwiw, yeah, this is basically how it went for me. Or, well, maybe not so much “reading through long detailed explanations” as “reading through through long detailed compilation errors” (though I’m sure I did both). Actually trying to use them seems probably important, not just reading about them. But yeah, I’d say that by now they seem intuitive to me, to the point where I had to resist adding my own attempt at a monad primer to this comment, and I only occasionally have to think in detail about them.
(Also, not really important, but this is more about the type system than about being a pure functional language. I don’t recommend using Elm for anything serious, but that has a similar-but-weaker type system without monads or (in some important sense) IO, while remaining purely functional. Early versions of Haskell didn’t have monads or (in the same sense) IO either.)
Wrt functional paradigm, do you think it has a higher cognitive load than procedural and/or OO?
I can’t tell: it does always take me forever to remember how to use reduce (in say elixir), but then my day job is python, so is it just because of the conceptual switch?
I actually find higher order functions like map/filter/reduce to be simpler in the long term than pervasive for loops, and my one major gripe with golang is its lack of generics that would let it have these. I don’t really understand the hate recursion gets either, and you have to learn to use it in procedural languages anyways. My issue with “pure” functional programming languages, and I’m speaking with a sample size of one here (Haskell), is that Monads and I/O seem comically difficult to use or explain. It’s possible that I just haven’t put in the hours reading through long detailed explanations of these concepts, and that if I did it’d “click” and I’d never have to think about them again, but I find statistics textbooks easier to read than the myriad monad “tutorials” I’ve been handed for this language.
I believe the world is this way because of the following two facts:
monads are very hard to get your head into;
monads are extremely simple conceptually.
This means that everyone spends a long time thinking about monads from lots of different angles, and then one day an individual just happens to grok monads while reading their fiftieth tutorial, and so they believe that this fiftieth tutorial is The One, and the particular way they were thinking about monads at the time of the epiphany is The Way. So they write yet another tutorial about how Monads Are Really Simple They’re Just Burritos, and meanwhile their only actual contribution to the Monad Exposition Problem is to have very slightly increased the number of paths which can lead an individual to comprehension.
You are very funny and have convinced me maybe possibly to try haskell again. But only maybe.
″ higher order functions like map/filter/reduce to be simpler”: do you find most other programmers find this too?
my experience is otherwise: i get a ton of pushback asserting this stuff is too hard to read and thus should NOT be use in our shop; somehow in python even using filter is more difficult than a list comprehension with an if!!???!!
I don’t really know what most programmers are like ¯\_(ツ)_/¯, I’ve never held a real software engineering job and most of my experience comes from my current attempt at building a startup. So far my cofounder seems fine with it, but we mostly work on different codebases.
What startup do you work on?
Leonard Recruiting. We’re a recruiting company for penetration testers, right now specifically web application pentesters. My cofounder and I have been working on the product part time for four months (way too long, I know) and we plan on launching our platform in about a week, which is an open, dynamic, live computer hacking exam. We haven’t even gotten seed funding yet, so it might be a little generous calling us a “startup”, though recently we’ve actually been getting some unexpected revenue by building out our exam platform for small businesses that my cofounder knows personally.
Fwiw, yeah, this is basically how it went for me. Or, well, maybe not so much “reading through long detailed explanations” as “reading through through long detailed compilation errors” (though I’m sure I did both). Actually trying to use them seems probably important, not just reading about them. But yeah, I’d say that by now they seem intuitive to me, to the point where I had to resist adding my own attempt at a monad primer to this comment, and I only occasionally have to think in detail about them.
(Also, not really important, but this is more about the type system than about being a pure functional language. I don’t recommend using Elm for anything serious, but that has a similar-but-weaker type system without monads or (in some important sense) IO, while remaining purely functional. Early versions of Haskell didn’t have monads or (in the same sense) IO either.)