8 Jun
2013
8 Jun
'13
3:17 a.m.
>> What do you see as the biggest obstacles for
adopting the FP
>> abstractions in "everyday programming thought"?
> The biggest obstacle I see is that FP is not how computers actually
> work. Computer hardware is fundamentally sequential imperative.
Indeed, that has been my primary objection to the
lumbering pigs that
are object-oriented codebases. [...]
FP does have the same problem. Lispers and Schemers,
in particular,
say it's "no longer a problem" because "computers are so much faster
now" and "have so much memory". This is directly indicative of the
problem.
Agreed. But it also contains some truth. Sometimes, especially when
doing exploratory computing or other one-offs, the programmer time
versus CPU cycles tradeoff is weighted in favour of saving programmer
time. That's when higher-level languages like Lisp, or Prolog, or
Haskell, or etc, come into their own - even more so when one matches
the problem particularly well; consider, for example, FFTW's use of
OCAML to find code fragments that do useful things (the documentation
remarks that their code generator has found algorithms they do not
understand).
Of course I myself am a schemer, when I wear that hat,
and I do fully
half of my work these days in R.
Certainly. To dogmatically decree that FP has no place is just as
false as to dogmatically decree that it is an advance over everything
else. Like most (all?) other programming methodologies, it has a
place, but that place is not everywhere.
Part of being a good programmer is knowing how to pick a paradigm (and
language) appropriate to the task at hand. Sometimes code space
efficiency wins, so you go for something small, usually slow and
probably interpreted. Sometimes execution time wins, and you go for
something compiled close to the hardware, like C or occasionally even
assembly. Sometimes programmer time wins and you go for whatever is
most familiar to the coder and not a horrible match to the problem,
which could be C or sh or R or APL or perl or whatever. Occasionally
the language is externally constrained, as when tweaking an existing
codebase or doing an assignment for a programming-language course, and
you have little choice.
But, if all you have is a hammer, all problems look like nails. Even
when they're actually screws...or velcro. Insisting on your favourite
language regardless leads to one-liners like "when your hammer is C++,
everything looks like a thumb" or "I had a problem; I used Java to
attack it and now I have a problem factory".
So I see it from both sides. The power of those
languages just has
to be experienced to be believed...
Indeed. When I managed to write generators using continuations, I was
both pleased and proud, on the one hand, and appalled, on the other -
the former because it worked, and in a conceptually pleasing way; the
latter because it worked very wastefully - it absolutely slaughtered
execution speed, running slow even on my fast machines. (Not that my
Lisp was any kind of speed demon to begin with. But, even for it, this
was slow.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B