4 ms·

I am not so much scared by functional programming as I am annoyed by functional programmers. I feel that they often come over like mathematics professors that j

by cessor 12y ago

I am not so much scared by functional programming as I am annoyed by functional programmers. I feel that they often come over like mathematics professors that just fill the chalkboard with lightning speed and look at you like "seriously, how dare you ask this dumb question". They go ahead explaining to you how your language is crap for all its sideeffects, smugly explaining how their language doesn't have those and then explain to you how Simon Peyton Jones shoehorned them into haskell with a monad. Also you always appear to fail to understand monads and they always fail to explain in an understandable way (although they're not that hard to get). Functional programming is great and feels right, I am amazed how knowledge of fp affects my js, C# and Python up to this day. But from a social perspective: Loose the smugness, and then we'll talk fp.

cbp 12y ago
So you're unwilling to learn something potentially better because you're were offended by a (surely) tiny portion of its userbase? Lose the childish attitude. You owe it to your craft and users to keep learning and using better tools.
- cessor 12y ago
  I think you just somewhat proved my point.
  - dllthomas 12y ago
    For what it's worth, I've asked plenty of dumb questions, and have found the Haskell community happy to answer them.
innguest 12y ago
The reason you might be perceiving this is because once you're past the learning curve hump, the concepts become extremely obvious and the definitions stick to your head. It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't. If someone then says "how dare you ask that" then they have the wrong approach to things. Socrates asked every question and thought they were all valid. By asking the basics you learn the abstraction as if you're proving it to yourself, and that's more powerful. So it boils down to familiarity, is what I'm trying to say. I usually come across as more passionate than arrogant about it. If you stick to it, it will make sense. It took me 4 years of Haskell exploration for it all to click really hard and now I'm trying to shorten other people's paths. In my opinion the gap is around mathematical abstractions, how they're created, what do they mean, how they actually relate to reality, and what work do they accomplish for us that we then don't need to do anymore.
- mbell 12y ago
  > It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't. I think this type of explanation falls into what the parent post is talking about. That is a technical accurate but very dry way to describe a construct that simply calls the function it's given for every element in a collection and returns the accumulation of the results. Granted you can dive into all sorts of discussions about what that _really_ means and what power it gives you, but save that for much later, it isn't introductory material. An analogy to how functional programming often is taught would be if I tried to teach a new programming language by going over the BNF grammar first without context instead of starting with how the language is actually used in practice. It may be more 'technically correct' but it's a terribly ineffective way to learn for most people, even those who know and understand BNF. People are often more interested in what they can do or create with this new thing, not the nitty gritty details of how it works mathematically even if they intend to get into the details later.
  - innguest 12y ago
    You're absolutely right, but I wasn't trying to explain it, just showing how easy and natural it gets once you get past the hump. I was assuming the author already understands the benefits of FP but finds it difficult, and I was saying it definitely does get a lot easier. Having said that, for an example of how I would actually explain some FP to someone, search this page for "DomainList" and I have an explanation there. I agree with you 100%; my belief is that mathematics and its notation often gets introduced too early, before students have had a chance to build intuition.
- mineo 12y ago
  That should be "foldl f z (x:xs) = foldl f (f z x) xs" because the function f takes two arguments (the whole thing boils down to "(((z `f` x_1) `f` x_2) ... `f` x_n)").
freshhawk 12y ago
Isn't this the blub paradox all over again? I hear the exact same thing about every other programmer in the world from some PHP/Node programmers who only know that language and insist is the best choice for every possible project. I'm not saying that actual smugness doesn't exist, but almost all the time it's actually just projection from someone who's used to being in the know now struggling to understand something new. Remember when you explained to someone using a language lower on the power spectrum (VB or PHP maybe) why they should use all the cool stuff that you can do in Ruby or Python, how much more productive they would be, how much more fun it was to work in? You thought you were helping them and showing your excitement, you wish someone had told you this a long time ago! Unless you are a world class educator they were confused by some parts, threatened that their investment in their current language was losing value and worried they might not be able to function in this new world and therefore protected their ego by seeing you as smug.
- AnimalMuppet 12y ago
  First: No, it's not just the blub paradox. The Haskell (and also Lisp) posters, even on HN, seem to have a higher proportion of smug self-congratulatory explanations-that-don't-really-explains-but-let-the-explainer-bask-in-his-or-her-sense-of-superiority posts than other languages do. Second: The blub paradox (at least as posed by Paul Graham) is wrong. To see why, just look at Lisp and Haskell. Users of both languages are sure that they're at the top of the power curve. They're sure that when they look at the other language, they're looking down, and they can tell you precisely why ("it doesn't even have macros" and "it doesn't even have a decent type system", respectively). But they can't both be looking down at each other - unless languages cannot actually all be ordered along a single axis called "power". In fact, you have to ask "power for what"? Once you do, you might start to see language power more as a tree than as a single line. You can really only compare power between languages on the same branch. Pick the language that gets you the furthest in the direction that your problem lies.
  - silentOpen 12y ago
    I think you'll find that language 'power' is actually better modeled by a bounded semilattice which happens to be an idempotent commutative monoid. It's all very simple, you see...
a-nikolaev 12y ago
Some Haskell proponents tend to be a bit annoying, Yes. But they are only a (not so big) subset on Haskell users. Then, there are other FP languages, which you can easily learn in a few days/weeks, very nice and natural, e.g. OCaml, or SML, or maybe Scheme(Clojure?).
sgift 12y ago
Program in Java for a while and you get immune to smugness. "Java is so ..." Yeah, yeah, bring it on. While you do that I'll solve the problem and can go home. Programming in PHP must have a similar effect.

by cessor 12y ago

cbp 12y ago

So you're unwilling to learn something potentially better because you're were offended by a (surely) tiny portion of its userbase? Lose the childish attitude. You owe it to your craft and users to keep learning and using better tools.

cessor 12y ago
I think you just somewhat proved my point.
- dllthomas 12y ago
  For what it's worth, I've asked plenty of dumb questions, and have found the Haskell community happy to answer them.

innguest 12y ago

The reason you might be perceiving this is because once you're past the learning curve hump, the concepts become extremely obvious and the definitions stick to your head. It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't. If someone then says "how dare you ask that" then they have the wrong approach to things. Socrates asked every question and thought they were all valid. By asking the basics you learn the abstraction as if you're proving it to yourself, and that's more powerful. So it boils down to familiarity, is what I'm trying to say. I usually come across as more passionate than arrogant about it. If you stick to it, it will make sense. It took me 4 years of Haskell exploration for it all to click really hard and now I'm trying to shorten other people's paths. In my opinion the gap is around mathematical abstractions, how they're created, what do they mean, how they actually relate to reality, and what work do they accomplish for us that we then don't need to do anymore.

mbell 12y ago
> It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't. I think this type of explanation falls into what the parent post is talking about. That is a technical accurate but very dry way to describe a construct that simply calls the function it's given for every element in a collection and returns the accumulation of the results. Granted you can dive into all sorts of discussions about what that _really_ means and what power it gives you, but save that for much later, it isn't introductory material. An analogy to how functional programming often is taught would be if I tried to teach a new programming language by going over the BNF grammar first without context instead of starting with how the language is actually used in practice. It may be more 'technically correct' but it's a terribly ineffective way to learn for most people, even those who know and understand BNF. People are often more interested in what they can do or create with this new thing, not the nitty gritty details of how it works mathematically even if they intend to get into the details later.
- innguest 12y ago
  You're absolutely right, but I wasn't trying to explain it, just showing how easy and natural it gets once you get past the hump. I was assuming the author already understands the benefits of FP but finds it difficult, and I was saying it definitely does get a lot easier. Having said that, for an example of how I would actually explain some FP to someone, search this page for "DomainList" and I have an explanation there. I agree with you 100%; my belief is that mathematics and its notation often gets introduced too early, before students have had a chance to build intuition.
mineo 12y ago
That should be "foldl f z (x:xs) = foldl f (f z x) xs" because the function f takes two arguments (the whole thing boils down to "(((z `f` x_1) `f` x_2) ... `f` x_n)").

freshhawk 12y ago

Isn't this the blub paradox all over again? I hear the exact same thing about every other programmer in the world from some PHP/Node programmers who only know that language and insist is the best choice for every possible project. I'm not saying that actual smugness doesn't exist, but almost all the time it's actually just projection from someone who's used to being in the know now struggling to understand something new. Remember when you explained to someone using a language lower on the power spectrum (VB or PHP maybe) why they should use all the cool stuff that you can do in Ruby or Python, how much more productive they would be, how much more fun it was to work in? You thought you were helping them and showing your excitement, you wish someone had told you this a long time ago! Unless you are a world class educator they were confused by some parts, threatened that their investment in their current language was losing value and worried they might not be able to function in this new world and therefore protected their ego by seeing you as smug.

AnimalMuppet 12y ago
First: No, it's not just the blub paradox. The Haskell (and also Lisp) posters, even on HN, seem to have a higher proportion of smug self-congratulatory explanations-that-don't-really-explains-but-let-the-explainer-bask-in-his-or-her-sense-of-superiority posts than other languages do. Second: The blub paradox (at least as posed by Paul Graham) is wrong. To see why, just look at Lisp and Haskell. Users of both languages are sure that they're at the top of the power curve. They're sure that when they look at the other language, they're looking down, and they can tell you precisely why ("it doesn't even have macros" and "it doesn't even have a decent type system", respectively). But they can't both be looking down at each other - unless languages cannot actually all be ordered along a single axis called "power". In fact, you have to ask "power for what"? Once you do, you might start to see language power more as a tree than as a single line. You can really only compare power between languages on the same branch. Pick the language that gets you the furthest in the direction that your problem lies.
- silentOpen 12y ago
  I think you'll find that language 'power' is actually better modeled by a bounded semilattice which happens to be an idempotent commutative monoid. It's all very simple, you see...

a-nikolaev 12y ago

Some Haskell proponents tend to be a bit annoying, Yes. But they are only a (not so big) subset on Haskell users. Then, there are other FP languages, which you can easily learn in a few days/weeks, very nice and natural, e.g. OCaml, or SML, or maybe Scheme(Clojure?).

sgift 12y ago

Program in Java for a while and you get immune to smugness. "Java is so ..." Yeah, yeah, bring it on. While you do that I'll solve the problem and can go home. Programming in PHP must have a similar effect.