From: Samantha Atkins (samantha@objectent.com)
Date: Sun Apr 29 2001 - 12:22:18 MDT
Ben Goertzel wrote:
>
> > Well, in a more dynamic and powerful language it might only be 100,000
> > lines. :-)
>
> True, Java is a very verbose language. On the other hand, it's also really
> easy to read, unlike LISP
I promise to shut up about languages after this. :-)
How easy Lisp is to read depends on who wrote the program and what you
are used to. One of the really good things about Lisp is that it is
easy to roll a language specific to the problem domain on top of raw
lisp and use that for most of the coding without giving up a lot of
efficiency and without losing Lisp's many strengths.
>
> The problem is that self-organizing cognition pushes the limits of what's
> achievable with current computers. (And anyone who knows me, knows that I'm
> more likely in any given instance to be guilty of overoptimism than
> overpessimism... )
>
>
> > But there is no reason whatsoever that Lisp cannot handle anything that
> > Java can and then some.
>
> As was pointed out recently on this list, major firms are now pouring tens
> of millions of dollars into making Java workable for large-scale, real-time
> applications. Unless I'm mistaken, the same is not true for LISP.
>
It has already been done largely. We had optimizing compilers and JITs
for Lisp better than anything Java has yet or even has on the boards in
the early 90s. The DoD used to be pretty big behind Lisp as were several
companies and many academics. Too bad the work isn't made use of more
today. We are re-inventing a lot of wheels.
>
> On the other hand, testing a big Java program when all existing profilers
> crash on apps with many threads and copious RAM usage, also sucks... and
> consumes all the time that was saved programming in Java instead of C....
>
Yeah. You would pretty well have to write your own if you want to test
something like this. Even then you might have trouble or find it quite
slow as you are already pushing the limits of what fits in a 32-bit
pointer address space with WebMind it seems.
> > 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.
>
> I don't think you can do what I suggested in Java, even by looking at class
> files. The values of local method variables during execution are only
> contained inside the JVM, in RAM, not in the class files.
>
Well, the methods and method calls are more static than that so you
should be able to find those from the class file structure run through
one of the Java assembler type tools like Jasmin or part of kawa (which
is actually a Scheme interpreter on the JVM).
OK. I'll leave posts about languages alone for now as promised. :-)
- samantha
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT