I'm going to save these HN comments for 5 years time when the hype on functional programming has died down a bit. Will be very humorous to read this again then.
No chance. The hype will recurse forever. Even on stackoverflow.
Deploy the canaries!
Deconstructing Functional Programming [video]
91–100 of 116 posts
Re: Deconstructing Functional Programming [video]
#92Earlier quoted context omitted.
>The points he makes against obtuse names based in category theory are valid No, they aren't. When you have a class of "things" that doesn't have a name most people are familiar with, you are left with two options. Either choose a name people are familiar with, but which is wrong and misleading. Or choose the correct name and people have to learn a name. Are we seriously so pathetic as an industry that learning 3 new…
To an extent, I think it's a valid criticism. There are two main problems with the mathy names that many concepts in Haskell have. The first is that they hide the meaning. For example, "Monoid" is a really scary term, and explaining it further as "something with an identity and an associative operation" really doesn't help much either. Calling it instead "Addable" or "Joinable", and explaining it instead as "things w…
Isaac Asimov, in one of his essays, gave an analogy for those unfamiliar with, or perhaps frightened by the scary name of, the "complex" numbers: street addresses. Should programming languages get rid of that scary name and refer to complex numbers as "addressable"?
Re: Deconstructing Functional Programming [video]
#93Earlier quoted context omitted.
It's a problem with ML syntax, but one that can easily be overcome with parentheses. Sort of like how a circumspect C programmer uses parentheses in complex mathematical expressions rather than relying on everyone being able to correctly remember complex order of operation rules. OTOH, pipeline operators make a good case for currying. There really is something nice about being able to write sliceOfBread |> smearWith…
I just want to point out that the pipeline operator (or, more accurately, the forward application operator), is not provided by many ML implementations, but it's trivial to define it yourself. Here it is in Standard ML: infix |>; fun x |> f = f x; The definition is also similar in Haskell: x |> f = f x And in OCaml: let (|>) x f = f x;; F# and Elm provide this operator out of the box.
Why isn't it used more in haskell?
Re: Deconstructing Functional Programming [video]
#94[deleted]
As someone who went through the same thing, my best advice is, don't read monad tutorials; just write monadic code. Reading too much can just be confusing and might make you feel like an idiot for not understanding it yet. In the beginning it might be weird, and you'll no doubt spend a great deal of time puzzling over obscure type errors, but it will eventually become intuitive, if you're actually writing code and wo…
I know it's a running joke how many monad tutorials and analogies there are. And I get the humor and very much enjoy the joke.
However, I was able to gain a solid understanding of monads by working through a number of those tutorials. Over that period of time, I came to suspect, and then eventually confirm, that I had previously created my own monad for a particular purpose in C# (my case was checking the value of something in an XML tree, an attribute of an element of an element of an element, where the attribute might be missing, or its parent element might be missing, or its parent, and so on. So it was much like Bracha's ".?" sugar example).
So, monad tutorials actually (eventually) made the concept clear to me. It's fun to make fun of them, and they deserve to take a little heat, but we have to give them credit where credit is due too.
Re: Deconstructing Functional Programming [video]
#95[deleted]
I recommend: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... But in the end I think for most people 'understanding' the concept of monads is just something that is not to be had within a couple of hours. It takes a little bit of patience thinking about them and using them for a while.
The core problem seems to be that we just don't (yet) have good words for this particular space of abstractions. Many programmers have thought about or solved the same problem monads address, but they haven't mentally labelled the concept, and we certainly have agreed as an industry on these labels. So we're all struggling to try to talk about some things we don't have terms for.
Re: Deconstructing Functional Programming [video]
#96Earlier quoted context omitted.
>The points he makes against obtuse names based in category theory are valid No, they aren't. When you have a class of "things" that doesn't have a name most people are familiar with, you are left with two options. Either choose a name people are familiar with, but which is wrong and misleading. Or choose the correct name and people have to learn a name. Are we seriously so pathetic as an industry that learning 3 new…
To an extent, I think it's a valid criticism. There are two main problems with the mathy names that many concepts in Haskell have. The first is that they hide the meaning. For example, "Monoid" is a really scary term, and explaining it further as "something with an identity and an associative operation" really doesn't help much either. Calling it instead "Addable" or "Joinable", and explaining it instead as "things w…
I hate to say this sort of, because it is going to sound snobby, and I do not believe in being snobby. But the undeniable truth is, there's a fraction of the world's population of programmers who simply do not have the particular mental traits that would allow them to ever be completely comfortable and confident with a concept as abstract as monad.
Some people will call me Satan now, and others will jump on what I said and say, "Hell yeah, the world is full of dumb blub programmers." But both those groups are misunderstanding me.
I think a programmer who cannot understand this level of abstraction can still do plenty of valuable things as a programmer. I would not call them dumb. They may be -- and many are -- fabulously creative, driven, capable and highly productive.
There's a certain type of programmer who is more comfortable with abstraction and whose brain is more wired to deal with these amorphous, unnamed concepts. The same kind of brain wiring is needed to go far with mathematics.
But as FP becomes more prominent, this is going to become a dividing issue. Some will not make the transition, or will do so only partially. I think it's great to try to communicate better where possible, but even the best communication is not going to completely erase the issue.
Re: Deconstructing Functional Programming [video]
#97Earlier quoted context omitted.
I just want to point out that the pipeline operator (or, more accurately, the forward application operator), is not provided by many ML implementations, but it's trivial to define it yourself. Here it is in Standard ML: infix |>; fun x |> f = f x; The definition is also similar in Haskell: x |> f = f x And in OCaml: let (|>) x f = f x;; F# and Elm provide this operator out of the box.
Why isn't it used more in haskell?
For one thing, nobody could agree what it should be named...
http://thread.gmane.org/gmane.comp.lang.haskell.libraries/18...
Re: Deconstructing Functional Programming [video]
#98[deleted]
I recommend: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... But in the end I think for most people 'understanding' the concept of monads is just something that is not to be had within a couple of hours. It takes a little bit of patience thinking about them and using them for a while.
My first non haskell monad tutorial was this dorophone.blogspot.com/2011/04/deep-emacs-part-1.html
very 'operational', zero magic, good to get your hands dirty.
Dans' tutorial you linked is one of my favorite too.
Re: Deconstructing Functional Programming [video]
#99I found Bracha's talk poor. That guy really has a chip on his shoulder vis-a-vis functional programming. A lot of things he said were not well though out. Here are some examples. - He claimed that tail recursion could be seen as the essence of functional programming. How so? - He complained that tail recursion has problems with debugging. Well, tail recursion throws away stack information, so it should not be a surpr…
Indeed, I found his talk pretty poor as well. A lot of it comes down to not wanting to learn new terminology, and forgetting that a lot of "common sense" terminology from, say, Java, is also learned. I don't get more insight from "FlatMappable" than from "Monad"; in both cases I must learn about them first, and neither is intuitive without prior knowledge. It is instructive to read Bracha's blog too, mostly for the c…
> His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production?
He pointed out that a more nominal type system is a solution. Because when you give meaningful names to your types the error messages will become clearer and not full of long, inferred types that reveal potentially confusing or unimportant implementation details.
Re: Deconstructing Functional Programming [video]
#100Earlier quoted context omitted.
Indeed, I found his talk pretty poor as well. A lot of it comes down to not wanting to learn new terminology, and forgetting that a lot of "common sense" terminology from, say, Java, is also learned. I don't get more insight from "FlatMappable" than from "Monad"; in both cases I must learn about them first, and neither is intuitive without prior knowledge. It is instructive to read Bracha's blog too, mostly for the c…
> His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production? He pointed out that a more nominal type system is a solution. Because when you give meaningful…
Most programming languages with Damas-Hindley-Milner do not prevent you from using explicit type annotation, and inventing semantically meaningful type names.
More importantly, I think the reason why error messages are sparse and not meaningful in languages with Damas-Hindley-Milner is that nobody bothered to improve the situation. And the reason why nobody botheres is that it's simply not a problem in practise. Any even moderately experienced programmer can easily detect and fix typing errors as they are given in Haskell, Ocaml, F#, Scala etc.