From PG's famous essay (even quoted on WikiPedia):
> ... when our hypothetical Blub programmer looks in the other
> direction, up the power continuum, he doesn't realize he's
> looking up. What he sees are merely weird languages. He
> probably considers them about equivalent in power to Blub,
> but with all this other hairy stuff thrown in as well.
> Blub is good enough for him, because he thinks in Blub.
But learning, properly learning a functional language gives you more experience, more ways of thinking, more techniques, more options.
"The dedicated real programmer can write
ForTran programs in ANY language."
Then you can make the choice.
I once wrote a toy library that lets you write BASIC in Haskell:
main = runBASIC $ do
10 PRINT "BASIC in Haskell"
18 GOSUB 1000
20 GOTO 10
15 PRINT "Out-of-order line"
1000 PRINT "gosub"
Lennart Augustsson extended that to allow things like "10 PRINT 2 + 2" (no parentheses needed), along with most of the rest of BASIC; his approach effectively implemented a full parser and treated everything as a token. He also added LLVM-based code generation. See http://hackage.haskell.org/package/BASIC .
Maybe that's because I'm a 'Blub' programmer, in spite of some real effort to 'dig' the functional programming method, maybe it is because I think that it exposes a sort of smug attitude towards those that program in 'lesser' languages.
There is a taste of an attitude there that I can't rhyme with the other things that PG wrote.
You don't show the advantages of a language or a technique by making the argument about people, especially not by talking down to them from that high up.
As I continue to learn more about them, so I continue to become a better programmer even in languages that don't exactly match the paradigms. Learning structured programming has made my assembly coding better, even when I use all the nasty tricks available. Learning about FP, logic and constraint programming has made my C++ and Python coding better.
I'm sure I don't yet know everything, or even half of everything. I don't (often) use a pure FPL, but knowing, really knowing, about pure FP has made my thinking better.
Who knows what remains to be discovered or invented that will expand our thinking further.
I'm on to that, as you know from our email exchanges, but I don't like the idea of presenting the one as 'better' than the other.
Both FP and IP have earned their place in the toolbox, and even though I'm much more familiar and comfortable with the 'IP' portion of it I can see the power of some of the concepts behind FP. But I find it very hard to believe that FP is so much better than IP that it warrants talking down to the people using it.
> As I continue to learn more about them, so I continue to become a better programmer even in languages that don't exactly match the paradigms.
Agreed, and even while I definitely have not 'grokked' functional programming yet to the point where it would make sense for me to write some small utility in an FP language I can see how just learning about FP has influenced my coding style in other languages.
> Who knows what remains to be discovered or invented that will expand our thinking further.
Working on that :)
It's mostly a matter of constraints on this end, I probably took on more than I can handle in terms of work that simply needs doing and I hoped that through FP I would find some shortcut allowing me to become more productive. It has worked in a sense, some of the code I wrote for other projects has become more clean because of reading about and playing with FP, but in a concrete sense where I can substitute a functional language for an imperative one and get more mileage out of my days it hasn't (yet).
But I'm optimistic that one day it will, and as long as I can see it influence my thinking in a positive way I'll continue to study it.
One of the biggest eye openers so far was 'memoization', I'm not even sure that I understand it well enough to paraphrase it, but when looking at the source of hashlife it suddenly clicked: When you work in a functional way and you are guaranteed that there are no side effects stemming from lower layers you can replace the call to a function with a bunch of arguments, no matter how complex with its result. That literally blew my mind, even though in hindsight it is a blindingly obvious thing.
That such a 'small' thing as side effects could have such polluting effects on higher level code that a thing like memoization is impossible gave me a lot of energy to continue my 'quest' :)
Must have been messy.
I understand functional programming perfectly well. It's just that for most of the time, it's easier to think imperatively. Yes, there are some special problems (Towers of Hanoi, Ackermann's) where functional programming is truly the way to go. But in most cases it isn't.
FYI I use gotos in my C programs when I see it's the easiest & clearest to get something done. I think you should go with what best suits the situation.
What troubles me though is when you go out of your way to do everything functional-style, even when you know there are easier ways of doing it. And the problem is this happens way too often to be ignored. Some functional programmers just push the functional idiom into everything they do, to such a point that understanding their code is like solving a sudoku puzzle.
Functional programming imposes some constraints that range from mild discipline to mind-bendingly difficult. However in general I can't think of many constraints that provide a better power-to-weight ratio (garbage collection is probably one).
If Haskell was the dominant language and functional programming was how everything was done all the time, then I could buy into the argument that there are easier ways to do things. However as it stands, not enough people really grok functional programming (myself included) to optimally apply those principles towards the creation of robust systems in non-pure languages.
That's perfectly okay, of course. It just means it's a little early to start making final conclusions.
> What troubles me though is when you go out of your way to do everything functional-style, even when you know there are easier ways of doing it.
The point is that you (to possibly generalize a bit since I don't know you) are 'going out of your way' to write everything in an imperative style because you don't know there are easier ways of doing it.
This is exactly what the blub story is saying. You are looking 'up' at functional languages and saying "in most cases that's just esoteric weirdness that I don't need" because you think in blub.
Here's an alternate version of your last sentence from a hypothetical functional programmers perspective:
> Some imperative programmers just push the idiom into everything they do, to such a point that understanding their code is like untangling spaghetti.