Functional Programming For The Rest of Us
defmacro.org
Functional Programming For The Rest of Us
1–10 of 69 posts
Re: Functional Programming For The Rest of Us
#2This is a much clearer explanation of the benefits than most of the other attempts I have seen.
Re: Functional Programming For The Rest of Us
#3I was disappointed because I was hoping it was a new piece -- in general, I have found coffeemug's writing well worth my time.
Re: Functional Programming For The Rest of Us
#4Aside: I am maybe 50-60 hours into my first haskell project using yesod. I have read about half of "real world haskell" and about half of "learn you a haskell".
Other than this, all of my experience is in iterative languages. (c++,python,php).
One thing that comes up is "if your program compiles it's almost certain to be correct"; and it has been true again and again for me. It's an odd, eery feeling that honestly I haven't quite groked how it is happening that way.
I don't understand completley what I am doing, a combination of not thinking like a FPer, not knowing the idioms of Yesod, and not being entirely familiar with the syntax of Haskell; so I am sometimes stuck on "how" to get the type that I need.
So I will sometimes try a couple things almost randomly; then it will compile and it basically is always doing what I want it to do.
Re: Functional Programming For The Rest of Us
#5Aside: I am maybe 50-60 hours into my first haskell project using yesod. I have read about half of "real world haskell" and about half of "learn you a haskell". Other than this, all of my experience is in iterative languages. (c++,python,php). One thing that comes up is "if your program compiles it's almost certain to be correct"; and it has been true again and again for me. It's an odd, eery feeling that honestly I…
If you add some QuickCheck specifications, the programming by brownian motion ("try a couple things almost randomly") will work even better.
Re: Functional Programming For The Rest of Us
#6/me adds this article to my pile of articles to read
Re: Functional Programming For The Rest of Us
#7Aside: I am maybe 50-60 hours into my first haskell project using yesod. I have read about half of "real world haskell" and about half of "learn you a haskell". Other than this, all of my experience is in iterative languages. (c++,python,php). One thing that comes up is "if your program compiles it's almost certain to be correct"; and it has been true again and again for me. It's an odd, eery feeling that honestly I…
I think the "if it compiles, it works" has to do with Haskell's type system being much more expressive than most static languages, and that most of your code will be declarative and pure.
Purity helps because your program will necessarily be composed of small, self-contained modules (usually functions) that have no implicit dependencies.
The type system helps because you can encode a lot of the code's intent in type signatures, which prevents code that does not match that intent from compiling.
Monads are a good example. Whenever there is some special execution requirement (eg. ordering for IO) for operations, you may be able to express the requirement as a monad, and then any operation outside that monad can't accidentally mix with it.
In addition, because monads allow you to enforce how operations are composed, there is no way for the programmer to forget to adapt the output from operation 1 so that it works as an input for operation 2. That's abstracted by "bind".
I'm a Haskell newbie myself, but there are a lot of mind-bending tidbits around the Internet in how to encode intent in various ways using the type system... It's not the most powerful system imaginable for that purpose, but as far as practical languages go, it's probably at the top.
Re: Functional Programming For The Rest of Us
#8Nice article, but its a bit irksome that the MessageHandler example drops the conditional and doesn't replace it - the code at the end of that section isn't equivalent to what he started with.
Re: Functional Programming For The Rest of Us
#9Kudos to the piece for being well written, readable, and clear. But I'm worried about a "for the rest of us" that starts off with first Plato and then lambda calculus.
The problem with "the rest of us" is that these concepts aren't inherently neat. Disclaimer: I'm not one of "rest of us". I'm learning Haskell, just because I enjoy having to think in a new way.
A lot of FP explanations start off with immutability. After plato and lambda calc, that's where this one goes, too. I think because it's a relatively simple concept, and kind of mind blowing that you could do something useful without incrementing i in a for loop. And then the follow up example is normally how you can replicate a for loop in functional programming. Which is again neat.
But if you aren't into neat things for their own sakes, you've got to ask why? Why replicate a for loop when you could just use one? (answer: you don't really replicate for loops in FP) They aren't asking why, in the sense that they're curious. They're asking why in the sense of "Why would anyone do that? That's stupid."
If you aren't into having your mind blown for no apparent reason (some aren't) the only really compelling thing about the first several pages of the piece is the "Benefits of FP". That's the motivation to learn these crazy new concepts. It should really come first. I think it should come first in any discussion of FP for people who aren't familiar with it.
Because for most people to learn, they need a motivation. Your programs will be faster because you can do concurrency super easy is pretty good motivation. Sadly, "because it's neat," is generally not.
Re: Functional Programming For The Rest of Us
#10i wrote this article off about when it makes incorrect comparisons between immutable values and final variables. someone who read it, is the rest of the article worth reading, or even accurate?
there's certainly a need for articles like this, targetting an audience of java devs, if only they were correct. I haven't found much.