Tracy R Reed wrote:
Gabriel Sechan wrote:
You also cut the number of qualified auditors by a factor of 10. Functional
languages didn't catch on for a good reason- they're hard to understand and
hard to write in. They don't work the way most people think. I'd put 2:1
For the time being the number of auditors would be greatly reduced, yes.
But I am wondering if the reason functional languages did not catch on
was not that they are hard to understand or write in but instead because
the computing power available at the time did not lend itself to using
functional languages so we all got our start using imperative languages
and now think only imperatively.
I don't buy this.
The problem is that *humans* are imperative creatures.
Directions, recipes, driving, etc.--life is imperative. Everything we
do has side effects, and we *expect* everything that we do to have side
effects.
I'm sure english makes more sense to you and spanish is just a bunch of
jibberish also. Procedural programming was your first and you will
always think that way. Even if you learned to speak functional it would
be with a thick accent and never come easily to you like procedural does.
I learned assembly language and lisp at about the same time--12 years
old. I can think in both. Functional languages are like the old
"indexed indirect" addressing modes in assembly language. They require
one extra layer of abstraction. That extra layer of abstraction drops
the number of people who can write or understand the code by an order of
magnitude. It also drops the *speed* with which you write code. Sure,
if the problem is *hard*, the net effect is to increase your overall
productivity. If, however, the problem is straightforward, the net
effect is to lower your productivity.
I don't know much about ML but I've been looking at lisp, scheme, and
haskell lately and liking what I see. I can't really code in either yet
as I have only read the theory and some basic tutorials but I'm looking
forward to giving them a real try.
Come back after you have "coded in anger" as my mentor says. Having
used Perl, Python and Common Lisp "in anger", I don't find Java 5.0
(1.5) that problematic. There are some rough spots, but normally they
can be worked around. Recognize, however, that I am using the latest
version of the language coupled with the latest version of Eclipse IDE.
Part of what the Lisp weenies brag about is the fact that Emacs is a
really good IDE for Lisp. Eclipse is that IDE for Java.
At this point, the availability of solid, debugged libraries for Java
almost always outweighs any amount of programming language productivity
improvement I would get from the language itself. The *first* time I
have to write a library which does "X" that is already written for Java,
all that productivity boost is gone. That is why Perl kicked butt in
the early days; it had tons of libraries. Python made sure it learned
from that. Java has been similar. The Lisp folks can't even agree on a
solid unit testing library, a package system that doesn't require an IQ
above 170 to use, and a standard data structures library written and
evaluated by the best minds in the Lisp community.
I can't speak for the Haskell and ML folks, but I have seen little to
make me believe that they are that much different from the Lisp folks.
That having been said, some of the research on concurrency in functional
languages looks good:
http://www.research.microsoft.com/%7Esimonpj/papers/stm/index.htm
I might actually take a look at concurrent Haskell given that this looks
like it actually presents a model (Composable Memory Transactions) that
can abstract out concurrency problems.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
