4 ms·

Perhaps this is pedantic, but that doesn't look like good procedural code to me. Instead, it looks like a set of mathematical equations. I think there is intri

Perhaps this is pedantic, but that doesn't look like good procedural code to me. Instead, it looks like a set of mathematical equations. I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability. How might you write to a MongoDB document in Haskell, for example? A common example in this space is how to specify a baking recipe. Do you list it as a series of steps to perform on the world, or do you reductively assert what a cake is from base principles? I think Haskell developers need to realize that pure functional programming is intrinsically more difficult than other kinds. It requires a much higher ceiling for abstract thought. What I'm essentially trying to assert is that you have to be smarter than average (whatever that means) to read and write Haskell code. I believe this accounts for the majority of the perceived efficiency. The cost is that you are excluding people who are not mathematically talented.

sullyj3 5y ago
It's not supposed to be good procedural code, it's supposed to be illustrative of the fact that a lot of code which people are used to seeing in procedural languages, which only involves assigning to a variable once, can be translated into a pure haskell function very straightforwardly, and it doesn't look intimidatingly esoteric like many people seem to expect. I can just as easily do it with strings if you're concerned about it being mathematical. I agree that there are many problems more naturally represented by procedural code, and as such it's important for every language, even functional languages, to have good constructs for representing a series of steps. Luckily, Haskell has such a construct in do notation. It looks like this: main = do putStrLn "What's your name" name <- getLine putStrLn ("Hello, " ++ name) I'm not familiar with MongoDB, but I found a haskell library for that and the example looks relatively straightforward to me, modulo possibly some unfamiliar syntax. It's a bit long, but it's doing more than just an insert. [1] I've heard the cake argument many times, and I agree that it's more naturally modelled as a series of steps. But I find it frustrating, because I've never heard a convincing argument for why the fact that one particular problem is more intuitively modelled as a sequence of steps, means all problems are. For example, imagine if you were never allowed to declaratively specify a DOM again using HTML, but instead you had to construct it as a series of calls to element.appendChild(). Would that really make your life easier? There are many problems for which a declarative description, not a procedure, is much more straightforward to understand. Another point is that you can also think of applying functions in succession ("function composition") as a series of steps! I find this pretty intuitive. For example, here's a function which takes a list of words and shouts them. The steps are: First concatenate the words together, then capitalize the resulting string, then append an exclamation mark: λ » shoutWords = unwords .> capitalize .> exclaim λ » shoutWords ["i'm", "shouting"] "I'M SHOUTING!" I think you're right about needing to have a certain level of smarts to get Haskell, but I think this is a consequence of some more advanced Haskell features (Typeclasses + higher kinded polymorphism), rather than the functional paradigm itself. For example, I think Elm is probably very approachable for people with a wide variety of different levels of mathematical ability. I think it's very easy to assume that functional programming is inherently more difficult, when it might well be that all that's going on is that people are more used to procedural programming because that's what they were taught first. I really would encourage anyone who thinks FP is inherently difficult to have a crack at learning Elm. [1] https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Database-MongoDB.html https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Dat...
kaba0 5y ago
> I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability I agree with you, with the caveat that some program wins from a simple imperative core, indeed! In some other areas FP shines, so I think posing the question as either or is fundamentally wrong. Fortunately nowadays most mainstream languages do support plenty of the FP paradigm, sometimes simple lambdas can take you far away. And FP languages could always either imitate state (Haskell for example has a State monad specifically for that), or straight up manipulate it through unsafes, IO monad, etc.
igouy 5y ago
> A common example in this space is how to specify a baking recipe. Is that because written language is sequential? Is that an example given by expert bakers? Is that because the baking recipe assumes a single baker rather than multiple bakers? How much of a baking recipe requires sequence? How much can be done in parallel? Why do expert programmers talking to expert programmers shift their reasoning to domains in which they may not be expert?

sullyj3 5y ago

It's not supposed to be good procedural code, it's supposed to be illustrative of the fact that a lot of code which people are used to seeing in procedural languages, which only involves assigning to a variable once, can be translated into a pure haskell function very straightforwardly, and it doesn't look intimidatingly esoteric like many people seem to expect. I can just as easily do it with strings if you're concerned about it being mathematical. I agree that there are many problems more naturally represented by procedural code, and as such it's important for every language, even functional languages, to have good constructs for representing a series of steps. Luckily, Haskell has such a construct in do notation. It looks like this: main = do putStrLn "What's your name" name <- getLine putStrLn ("Hello, " ++ name) I'm not familiar with MongoDB, but I found a haskell library for that and the example looks relatively straightforward to me, modulo possibly some unfamiliar syntax. It's a bit long, but it's doing more than just an insert. [1] I've heard the cake argument many times, and I agree that it's more naturally modelled as a series of steps. But I find it frustrating, because I've never heard a convincing argument for why the fact that one particular problem is more intuitively modelled as a sequence of steps, means all problems are. For example, imagine if you were never allowed to declaratively specify a DOM again using HTML, but instead you had to construct it as a series of calls to element.appendChild(). Would that really make your life easier? There are many problems for which a declarative description, not a procedure, is much more straightforward to understand. Another point is that you can also think of applying functions in succession ("function composition") as a series of steps! I find this pretty intuitive. For example, here's a function which takes a list of words and shouts them. The steps are: First concatenate the words together, then capitalize the resulting string, then append an exclamation mark: λ » shoutWords = unwords .> capitalize .> exclaim λ » shoutWords ["i'm", "shouting"] "I'M SHOUTING!" I think you're right about needing to have a certain level of smarts to get Haskell, but I think this is a consequence of some more advanced Haskell features (Typeclasses + higher kinded polymorphism), rather than the functional paradigm itself. For example, I think Elm is probably very approachable for people with a wide variety of different levels of mathematical ability. I think it's very easy to assume that functional programming is inherently more difficult, when it might well be that all that's going on is that people are more used to procedural programming because that's what they were taught first. I really would encourage anyone who thinks FP is inherently difficult to have a crack at learning Elm. [1] https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Database-MongoDB.html https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Dat...

kaba0 5y ago

> I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability I agree with you, with the caveat that some program wins from a simple imperative core, indeed! In some other areas FP shines, so I think posing the question as either or is fundamentally wrong. Fortunately nowadays most mainstream languages do support plenty of the FP paradigm, sometimes simple lambdas can take you far away. And FP languages could always either imitate state (Haskell for example has a State monad specifically for that), or straight up manipulate it through unsafes, IO monad, etc.

igouy 5y ago

> A common example in this space is how to specify a baking recipe. Is that because written language is sequential? Is that an example given by expert bakers? Is that because the baking recipe assumes a single baker rather than multiple bakers? How much of a baking recipe requires sequence? How much can be done in parallel? Why do expert programmers talking to expert programmers shift their reasoning to domains in which they may not be expert?