From: Samantha Atkins (firstname.lastname@example.org)
Date: Sun Apr 29 2001 - 04:47:53 MDT
Ben Goertzel wrote:
> Choice of programming language is always a tricky and personal issue, huh?
> I first have to confess that I, personally, have never cared for LISP very
> much. I just don't enjoy programming in it as much as a lot of other
> languages. My favorites are functional languages like Haskell and Miranda.
> Next is Java, of which C++ and C# seem like perversions.... I know pure
> LISP is a functional language, but even there, the parenthese-mad syntax
> annoys me: the currying of Haskell syntax is so much cleaner!
> Also, the fact that we already have 700,000 lines of Webmind code in Java
> causes me to strongly hope that a high-performance Java comes out, so I
> don't have to worry about other languages. If we rewrite little crucial
> bits of the code in C now but leave the rest in Java, maybe we can put the
> crucial bits back into Java later when Java improves.
Well, in a more dynamic and powerful language it might only be 100,000
lines. :-) I believe Haskell and most of the functional languages were
intially developed in Lisp.
> But about LISP... I'll try to be objective here and put my "religious"
> sympathies aside ;>
> A main point is, I don't believe that fully optimized LISP is likely to
> perform nearly as well fully optimized C on most problems. This is
> personal experience, plus a perusal of the literature a few years ago.
I have seen other literature about optimizing systems for Lisp giving
performance from 2x that of C to better than C. There are also reports
of people being *much* more productive in Lisp. I can dig up the
references if there is interest. To me, the ease of expression and
productivity is much more important than raw execution speed. The speed
can always be improved by putting sufficient ingenuity into
Generally I find environments where an interpreter is available and full
reflection is present to be much more productive to code in. Java, C,
C++, C# do not have this. Lisp systems invented and profected JIT
conversion to machine language long before Java came on the scene. Java
reminds me of Pascal. A lot of time is spent making the finicky
compiler happy at the cost of a lot of frustration of the person
attempting to design and program as they think and as is natural for the
problem at hand. Language may not determine thought but it sure can
greatly frustrate and stifle it.
> Also, even more critically, I have never heard of a truly large-scale LISP
> app: gigabytes of RAM, multiple processors, multiple servers, etc.
I have never heard of a very successful hyper-large Java system either.
But there is no reason whatsoever that Lisp cannot handle anything that
Java can and then some. It is after all a simpler language
implementation wise. At one time Lisp machines (chip level lisp) were
even built. They failed due to the AI overhype of the 80s / early 90s
but not due to deficiencies in the language.
I will grant that Lisp is almost too flexible. Good Lispers can run
rings around Java and C folks. Bad Lispers can get bogged down more
easily than in Java. Well, maybe I'll retract that. In my humble
opinion very few programmers actually write good code and especially
good OO code regardless of the language.
I grok Java well but I find it quite frustrating and boring. It slows
me down a lot.
If you are going to the C world for core functionality then I recommend
doing some OO in Objective C. It is small, clean and relatively
powerful compared to C++ and is part of the GNU gcc now. Many years ago
I did some twists to this language to support distributed messages and
transparent persistence in suprisingly few LOC. It supports dynamic
messaging which is a godsend for proxies and pluggable frameworks.
> Perhaps a handful of such apps exist, unbeknownst to me. But given the
> relative preponderance of such apps in C/C++, it stands to reason that C/C++
> compilers have been much more fully tested and tuned for this type of
C/C++ is a bad joke as far as programmer productivity. On a large app
you will spend an ungodly amount of time waiting for the universe to
remake itself because you tweaked something in some include file that
rippled across the entire fragile mess. Making changes in big C/C++
systems is a nightmare. I should know, I've been part of the design,
implementation and maintenance of enough of them. COM/DCOM and CORBA
brought a bit of relief but not enough. C/C++ compiles out all
intelligence in the source code. There is no information about classes,
structs, inheritance and so on present in the runnable code. They did
not have to do it that way. It doesn't even buy them any extra speed.
But they did.
And of course the other great bane of large C based systems is garbage
collection. An efficient GC is crucial to large systems. There is
provably no way to get it right by hand over that much code touched by
that many people. Reference counting? No circular dependency handling
and 3-4 times as slow as good generational scavenging. But forget about
full GC without type information through tagging or some other means.
Conservative GC that assumes everything that looks like a pointer is one
is the best that can be done in unmodified C compiler systems unless you
roll your own heap and do defacto tagging using types. But then you are
departing from C and using it as more your assembly language anyway.
And in conservative GC you lose the ability to do compaction.
Where are the tools? I learned OO in a Smalltalk world and later on
Symbolics machines. I know what good tools that really support
efficient programming and maintenance can be like. But this was in the
dark ages of the 80s and early 90s. Now we know better. Now we, SI
help us, have graduated to Java and C#! Gag me.
Sorry. I know I rant. But the sorry state of languages and tools
really pisses me off as a working programmer for these last two decades.
C environment tools (including C++) have not changed or improved hardly
at all in the last 15 years. That is a disgrace. It is certainly *not*
because the existing tools (if you can call them that) were adequate.
> Object oriented design is very very nice for a large-scale software system
> of any kind, also. LISP does not provide this, unless there's an
> ObjectiveLisp I'm not aware of.
Ever heard of CLOS which is the king of OO languages and where almost
every new development in OO was first perfected? Much of the cutting
edge of OO theory and practice is still there. Have you read "The
MetaObject Protocol"? Do you know about Aspect programming? More Lisp
> The ease of reflection in LISP is a major point. But Java has built-in
> reflection as well.
Java reflection is a poor joke. It is more introspection than
reflection. It does not allow modifying program structure or reflection
on the call relationships in the static code or in running programs.
You have to tack on extra debuggers, special compilers and so on to get
any semblance of this and then only if you learn some arcane debugger
format or compiled lass file structure.
> In LISP, can one "method" look into another while it's running and see the
> ephemeral values of local variables inside that method? (I know, this is
> Java terminology; I forget the LISP terminology.) If so, then this is a
> more powerful kind of reflection than Java currently provides.
Certainly. And you can easily write code to find every usage,
definition, override and so on of any method as such reflection is
naturally supported. You could sort of do it in Java if you dropped
down to class file format and were pretty patient. In Lisp I can
rewrite the methods of an instance for special circumstances or to
evolve the code on the fly. In C/Java it would be a very ugly set of
hacks to accomplish anything remotely similar.
Lisp, despite the nasty ()'s, is an extremely powerful tool that has
been wrongly ignored.
I am also quite fond of scripting languages like Python and especially
the relatively new import from Japan, Ruby. Ruby is fully OO
(everything is a first class object) with quite a few lisp abilities
added in and full GC. It makes a excellent prototyping and glue
language to hook together various modules in other languages whether
they are in other languages for legacy reasons or for better
Python is used at some of the really big national defense labs to hook
together huge scientific programming projects spread across multiple
banks of supercomputer level machines and in multiple languages. There
is simply no way they could keep up with demand and the changing mix
tractably with a large C/C++ or Java project.
Smalltalk is used in some highly mission critical systems in the
finacial world. It is very popular on Wall Street where Smalltalk
wizards configure complete new trading tools and systems and modify
holds in near real time to satisfy the huge hunger for just one more
edge over the competition.
Truthfully there are places where C is very good. It makes a useful
universal assmebler and is quite good for coding tight highly efficient
data structures and components. But large systems and integrating and
modifying components dynamically are not its strengths.
What would be most ideal in the current state of things is if there was
a relatively transparent, efficient means to hook together components
and code snippets in multiple languages. .NET is one try, CORBA and COM
are others. I think all of these have some real weaknesses but CORBA is
the most adaptable across multiple platforms and languages. .NET does
what people have already done with the Java VM. The Java VM is
seriously constrained in its primitve operation set to what Java
supports. Yet people have managed to support 100 language
implementations in Java and some of those directly running on top of the
JVM like Jython, at least two variants of Scheme and I believe I've even
seen a Haskell in the mix.
Speaking of platforms, is WebMind particular about OS? I confess to
being mainly a Linux bigot. For some reason every time I get my hands
on a new windoze machine, despite my solemn intentions otherwise, it
eventually ends up being wiped and loaded with Linux. I do Windows for
$$$ but I do Linux generally on my own time.
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT