Hacker News Reader

Comment by cessor | Hacker News Reader

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.

View on HN

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.

I think you just somewhat proved my point.

For what it's worth, I've asked plenty of dumb questions, and have found the Haskell community happy to answer them.

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.

> 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.

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.

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)").

Thank you for the correction!

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.

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.

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...

But Lisp and Haskell are arguably the best in their categories, namely programming in lists and programming in functions.

Those two abstractions are several times more powerful than the overly constrained abstractions imposed by OOP. The power of lisp is that it is homoiconic, and it asks what it means to write programs that write programs. The power of Haskell is that it is algebraic, and it asks what it means to execute a mathematical proof.

Both therefore have the power to really abstract away from things in any way you want. They do not constrain the programmer with an abstraction that is too high and not composable, as are (mathematical) functions and macros (which are composable with hygiene). The prevailing paradigm offers poor substitutes for composability and can simulate very poorly abstractions that are lower than Objects (thereby needing design patterns to make up for starting so high in the abstraction tower).

But see, now you're just replacing a one-axis view with a two-axis view. I could equally well have said that a Fortran programmer looks down on both Haskell and Lisp because they don't even have a decent matrix package. Or that a C++ programmer looks down on them because they don't let you really control the details. (Despite the power of abstraction, there are plenty of situations where real control is at least as important. What do I mean by real control? Size of a variable. The ability to manipulate individual bits. Control of individual memory allocations. Et cetera.)

Program power is not one dimensional, and not two dimensional. There are more "best" languages than Lisp and Haskell. There are more categories that matter than just programming in lists and programming in functions.

Yes of course, I did not mean to imply there are only those two (that would be weird for the two to be "lists" and "functions" out of all things).

What I mean is the current mainstream languages are not the best of any category, like Haskell is up there for functional programming and lisp is up there for s-expressions. C++ is not the best for controlling details (see Rust, D, etc), in fact it's quite a broken language. I doubt Fortran is better at matrices than APL (in fact APL is arguably the best in the matrix category) and so on.

That's the problem. These languages that are best in their categories are many many times better than the mainstream languages of today, which aren't the best in any category they represent.

> 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

That's my point. It absolutely doesn't seem that way to me, because I know Haskell and Lisp.

I'm also personal friends with PHP developers who I used to work with and they have exactly the same attitude towards anyone talking about Ruby or Python or literally anything else.

They are angry at the bullshit that these smug language jerks keep throwing their way about how "bad" their perfectly good language is.

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.

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?).

Reply on news.ycombinator.com