| [reply] |
First of all, LISP hasn't been a total failure commercially. Viaweb aka Yahoo! Store comes to mind first.
No one I know had even heard of Viaweb before Paul Graham began touting it as a "success story for Lisp"! Erlang is the closest thing I've heard to a "success story" for FP; and it's an isolated case. Unix isn't written in LISP; Windows isn't written in LISP; in fact, all those horrible old LISP machine OS failed to compete with C. systems for decades. Functional programming isn't new. It's been the "latest, greatest thing" for the last fifty years or so. It's still not worth the hype, IMHO.
it was rewritten a few years ago in Perl/C++. Though I think that was more because they lacked in-house expertise once Paul Graham left.
Code that relies on individual heroics doesn't scale; that's part of my objection to functional programming. If you need to be able conceputalize the current state of sixteen different helper functions in order to keep the state of the function clearly in your head, you're probably going to fail, unless you're very smart. And when you leave, your replacement won't be, and the company will tank completely.
And just because you have trouble groking map and other functional code, that doesn't mean it wouldn't make perfect sense to someone who thought differently or had a better grasp on the subject.
You know, ad hominem is bad argument. :-( And while I may not be the best Perl programmer, I have been programming for a while (professionally since 1991), and what's more, I'm a good enough programmer to know my own limitations. I check my assumptions; and I did in this case, too.
One of my best friends is a LISP expert; though he and I disagree violently on the value of functional programming, he agreed in every single case when I asked him (and I asked often) that the functional code I was seeing was just plain bad, wrong, or occasionally, even "insane". Believe what you will of me or my abilities, but it's not just me. The FP devotees claim it's possible to write good FP code, but it's not what happens in the field, in my experience.
Aspects of functional programming are quite useful and a PITA to replicate imperatively.
I disagree. Being forced to reassemble an series of bottom-up self-referential maze of semi-correct function mappings into a single, coherent business rule is far less productive than just reading the imperative rule directly from the code.
Remember, when someone writes code, what they write doesn't matter much: in six months, it will be replaced anyway. The purpose of what they wrote it is critical; and the more layers of abstraction between the business and the code, the harder it is to discern intent.
Would you really rather read:
sub transform {
my $coderef=shift;
reduce($coderef,@_)/(@_+1);
}
sub display {
printf("Avg: %f",transform(sub { $a > $b ? $a : $b },@_));
}
OR
sub display {
my (@quarterly_results) = @_;
# compute the arithmetic mean (average) of the results
# for the past four quarters
printf("Avg: %f", average(@quarterly_results);
}
sub average {
my $average;
$average = sum(@_)/ scalar(@_);
return($average);
}
The first example is "more clever", and more typical of the FP crowd. The second is "stupider", "more boring", and ore typical of my code. I find it easier to follow the business logic, so that when my code breaks, someone can fix it.
Throw in several more layers on the call stack, and the differences become even more pronounced; when the return value of a function is literally composed of a hundred little calls to other functions, each of which tampers with different states of different variables in different scopes, it's really, really hard to reconstruct what's being done, let alone WHY. True, that's not pure FP (lots of side effects), but it's what perl supports as FP, and it's what I get saddled with by FP-wannabees.
Encouraging more functional programming will at best lead to more ivory tower code, comprehensible only to the wise few, and at worst to the drek I see lately, where FP concepts are tangled with side effects of all sorts of scopes and flavours, and the net effect is a mess uglier than most.
I'm taking a pragmatic point of view: it's like if you serve alcohol at a bar, you hire bouncers. There's no reason, in principle, why people can't be rational, reasonable adults when they drink, and conduct themselves well, and leave when asked. In theory, you won't find piles of vomit all over the floor. In practice, you'ld better get the bouncers out and the puke buckets ready! Adding alcohol in the form of FP to Perl might be fun for you, but for me it just means more code puke to clean up.
--
Ytrew | [reply]
[d/l]
[select] |
I really have to wonder why are you even using Perl in the first place; it gives people way too much rope, FP or not.
No one I know had even heard of Viaweb before Paul Graham began touting it as a "success story for Lisp"!
And that proves what, exactly? “Noone I know has” is a classic case of unrepresentative sample.
The first example is "more clever", and more typical of the FP crowd.
The other Anonymonks have already called you out on that one; this is a straw man.
Quit the fallacies.
Makeshifts last the longest.
| [reply] |
| [reply] |
One of my best friends is a LISP expert; though he and I disagree violently on the value of functional programming, he agreed in every single case when I asked him (and I asked often) that the functional code I was seeing was just plain bad, wrong, or occasionally, even "insane". Believe what you will of me or my abilities, but it's not just me. The FP devotees claim it's possible to write good FP code, but it's not what happens in the field, in my experience.
About 90% of the Perl code I've ever seen makes me want to vomit. The fact Perl is relatively easy to learn might be one of Perl's biggest weaknesses, since it results in heaping piles stinking code written by people who can barely type, let alone know the first thing about programming. But that doesn't mean that Perl is worthless, does it?
| [reply] |
Ahem. One slight correction. Instead of the functional looking...
sub average {
my $average;
$average = sum(@_)/ scalar(@_);
return($average);
}
...which is really just a verbose way of saying...
sub average { sum(@_) / scalar(@_) }
...I'm sure you meant the much easier to understand alternative...
sub average
{
my @arr = @_;
my $average = 0;
my $length = @arr;
for(my $x=0; $x<$#arr; $x++)
{
$average = $average + $arr[$x]/$length;
}
return $average;
}
| [reply]
[d/l]
[select] |
You know, ad hominem is bad argument...
One of my best friends is a LISP expert
Yeah, ad hominem is almost as bad as using unsubstantiable anecdotes.
| [reply] |
The cow is called "List::Util". People seem to like it. People often look for things like min and max, which are reduce-based functions. I'm sorry you find such things pointless and abstract. Perhaps you will one day find a language crippled enough that people can't write bad code in it, and then you will be happy. However, that language will not be Perl. Perl is full of things that do different things in different contexts, and its development trend is to give programmers more power, not to confine them.
The problem you are dealing with is bad programmers, not Perl.
Caution: Contents may have been coded under pressure.
| [reply] |
No, that is not the trend. A lot of things that perform multiple duties in Perl 5 will receive separate names in Perl 6 (the two forms of for, the two functions called select, and many other things besides).
I don’t see any reason to go counter to this trend by conflating join and reduce. List::Util has been in core for a while so is more likely to be available than this proposed extension of join, and “join” is a bad name for a reduce function anyway.
Makeshifts last the longest.
| [reply] |
| [reply] |