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.
The other point is that there are pure OO languages, pure functional languages, pure logic languages, pure imperative languages, and rarely is a problem easily and comfortably expressed entirely in one pure paradigm.
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."
I've seen ForTran programs written in Haskell, believe it or not. You need to learn not just the language syntax, but the underlying ideas and techniques.
"I've seen ForTran programs written in Haskell, believe it or not."
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"
(Yes, line numbers and all.)
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 .
Personally, of all PGs writing (that I've read, and that's definitely not all of it) I like that bit the least.
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.
I hear what you say, but there was a time when I thought imperative, non-structured programming was all there was, and anything like structured programming, then later OOP, then later FP, was just more complexity that was unnecessary. As I've grown to become more comfortable with each of those I've realised that they are more than just extra bells and whistles - they are ways of thinking.
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' :)
Yea I've heard the blub story told over many times.
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.
It's not about how easy something is to do. The greatest value of functional programming is robustness. In 10 years of professional programming, I'd estimate that something around 90% of the nastiest bugs I've discovered would have been preemptively prevented by using a strictly functional style. Sometimes these bugs are just the result of poor thinking, but often they are the subtle result of changes over time that would be almost impossible to anticipate.
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.
I think you may have missed the point of the blub story, then.
> 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.