<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
On Thu, 2009-02-26 at 13:59 +1300, Richard O'Keefe wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 25 Feb 2009, at 11:22 pm, Michael T. Richter wrote:
> You're begging the question, Joe. WHY did it gain this temporary
> victory?
</PRE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Surely it's incredibly simple?
</PRE>
</BLOCKQUOTE>
<PRE>
</PRE>
Yes, actually, it is. It is also incredible that people are weighing in with opinions that boil down to "they're too stupid to get it" or "marketing won the day" when the real answer is staring us in the face.<BR>
<BR>
The reason imperative languages won the day (temporarily) in computing is that they had decided advantages over the functional (which you enumerate so nicely in the portion I snipped). In many cases they still do, not least of which is the case that there is a huge number of imperative programmers available as a resource and a not-so-huge number of functional programmers.<BR>
<BR>
If functional programming is to take root in any serious way, its advocates have to face up to those advantages and show either that they no longer exist (memory and CPU requirements, say) or that the other advantages of functional languages outweigh the disadvantages (productivity and correctness, say). Consoling ourselves (and I again stress that I am in favour of the functional, not opposed!) with platitudes concerning superiority or victim mentality won't win us the day.
<PRE>
</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
The machine I happily used as an undergraduate was a *mainframe*
with a cycle time of 2.4 microseconds and a theoretical maximum
of 6MB of ferrite core memory.
</PRE>
</BLOCKQUOTE>
<BR>
<python type="monty">You had it good. When I was ...</python><BR>
<BR>
<IMG SRC="cid:1235623488.6805.9.camel@isolde" ALIGN="middle" ALT=";)" BORDER="0"><BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
It's that simple. Nobody objected to automatic memory management
in the shell, or in AWK, or in REXX. They were "scripting"
languages, not real programming languages. Nobody expected them
to be efficient. But for *real* programming, oh no, garbage
collection was too slow, too space hungry, too hard, don't want
to go there.
</PRE>
</BLOCKQUOTE>
<BR>
The irony of this is that automated memory management is frequently faster as well as more correct than manual. A lot of the opposition to garbage collection comes from people whose information comes from, like, the '50s or '60s. There were advances in the ensuing decades....<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
By the time Java came along, computers were fast enough and had
enough memory that the cost of garbage collection didn't bother
a new generation of programmers. And there had been a lot more
work on garbage collection algorithms.
</PRE>
</BLOCKQUOTE>
<BR>
I submit that even at the time of C++ garbage collection algorithms were more than suited to the task. It was the old guard of programmers switching over to C++ from C that were the hurdle, not the technology.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> <<A HREF="mailto:ttmrichter@gmail.com">ttmrichter@gmail.com</A>> (<B>GoogleTalk:</B> ttmrichter@gmail.com)<BR>
<I>The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny..." (Isaac Asimov)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>