After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities as a standard
portable part of the core language, the LISP package, and the java.lang
package, respectively. Both have big integers, although only LISP has
rationals as far as I can tell. Because CL supports keyword arguments,
it has a wider range of string search utilities etc. where :key and
:test and :start :end etc. are parametric instead of fixed or
special-cased here but not there. The only major differences I see are
speed and interactivity:
Speed comparisons on FreeBSD Unix:
javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span.
However even on immediate re-runs, javac takes between 2 and 7 seconds
to compile a very small file (23 lines total, only 10 lines of actual
code).
CMUCL takes appx. 2 seconds to start up the first time, then is
virtually instant subsequent times within a short time span.
Recompiling a 33-line file runs so blindly fast that even with
*error-output* diverted to bit sink so as to suppress listing of each
function compiled, its limited only by 19200 bps printout of the return
value.
(let ((*error-output* (make-broadcast-stream))) (compile-file "tabsp.lisp"))
#p"/home/users/rem/JavaWork/tabsp.x86f"
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
Interactivity: In CL (and virtually any LISP since the original), you
can sit in a read-eval-print loop composing and trying one line of code
at a time, storing the results of correct computation in global
variables to feed into the next step of composing&trying. By
comparison, in java you have to switch back and forth between editing
the source of not just what you want to test but a whole test rig
around it to make a "complete program", compiling that "complete
program" to bytecode, and running that "complete code" just to see if
you got one line of new code correct. Comparing the instant feedback
when typing one new LISP form into the R-E-P, against the 24+ second
turnaround to try one new line of java code, LISP is a *big* winner!
So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
Well, there's Unicode, which is built into java but not CL, but I have
no use for it at present so that doesn't count. But I'd like to write
some Web-networking code to replace the hack I currently use where lynx
is run as a sub-process under CL and lynx does all the work of handling
cookies etc. If java can do all that directly more easily than CL, I
might give it a try.
73  7885  After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways.
<snip>
What in the world? It takes me less than a second to recompile a large
application with hundreds of source files. I have no idea why your apps take
so long to compile, but it's surely not because of java per se.
Personally, I don't normally use Java, and I'm just learning lisp. I have
been programming in C/C++ for about five years though. I still think I may
be able to answer that though, by relating it to a C-paradigm:
1) More people know C/C++ than lisp.
2) Java is like C/C++, therefore it is cheap/fast/easy for people to learn.
3) Java has more support. By that, I mean more corporate support.
Another thing I noticed about using Java (the few times I have), is that
it is extraordinarily easy to write a standard-looking GUI. In other words,
Java apps look and act similarly, for the most part. Just to cover
myself, I haven't written a GUI in lisp yet, so I don't know whether or
not lisp is the same way.
Anyway, do to the fact that Java is C-like, and provides an easy, standard
GUI toolkit, it's not hard to see why a lot of people/companies are
switching to it. Also, lisp still has a lot of "ancient" terminology
embedded into the language that a lot of beginning programmers are likely
to find confusing. I must admit that when I first began learning lisp, it
seemed almost backward to me: the way the syntax is set up, you have to
write the first thing you want to do last, and the last thing you want to
do first:
;;lisp
(car (cdr foo))
// C++ (assume I've made a linked list with push & pop type methods)
var = llist.rest();
return var.first();
This is just a simple example of course, but I'm assuming you see what I
mean. My main point is that I'm not sure weather or not lisp or java is
faster, better, or which advantages one has over the other, but rather
that those things are irrelevant. Java "beats" lisp simply because it's not
lisp-like, it's C-like.
Just to cover myself again, I actually prefer lisp to Java so far, if only
because of the fact that:
1. It has aspects of a functional language.
2. It makes working with lists easy.
Btw, this probably wasn't the best way to "hi," but:
Hi, I'm new to the list!
Ryan J. Bovorasmy wrote: Personally, I don't normally use Java, and I'm just learning lisp. I have
been programming in C/C++ for about five years though. I still think I may
be able to answer that though, by relating it to a C-paradigm:
1) More people know C/C++ than lisp.
2) Java is like C/C++, therefore it is cheap/fast/easy for people to learn.
3) Java has more support. By that, I mean more corporate support.
Another thing I noticed about using Java (the few times I have), is that
it is extraordinarily easy to write a standard-looking GUI. In other words,
Java apps look and act similarly, for the most part.
I'm working on it (see Cello in sig).
Anyway, do to the fact that Java is C-like, and provides an easy, standard
GUI toolkit, it's not hard to see why a lot of people/companies are
switching to it.
I think that is well understood. The OP was wondering if anything was
/actually/ easier in Java. That is cruel since Java is such a simple,
powerless language, but c.l.l. is a hotbed of savagery and demonic
ritual torture.
... I must admit that when I first began learning lisp, it
seemed almost backward to me: the way the syntax is set up, you have to
write the first thing you want to do last, and the last thing you want to
do first:
;;lisp
(car (cdr foo))
// C++ (assume I've made a linked list with push & pop type methods)
var = llist.rest();
return var.first();
I do not know about you, but when I wrote C I was always writing code
like this (taking liberties):
if ( car( cdr( foo ) ) ) {
...
} else ....
This also corresponds to English:
"I live on what is left over after taxes are taken from the money
I earn."
Of course Hemingway would say, "Kenny earned money. They took out taxes.
He lived on the rest. In the rain."
Btw, this probably wasn't the best way to "hi," but:
Hi, I'm new to the list!
The Savages of c.l.l. will be "welcoming" you shortly.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application Ro********@YahooGroups.Com wrote: After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities as a standard
portable part of the core language, the LISP package, and the java.lang
package, respectively. Both have big integers, although only LISP has
rationals as far as I can tell. Because CL supports keyword arguments,
it has a wider range of string search utilities etc. where :key and
:test and :start :end etc. are parametric instead of fixed or
special-cased here but not there. The only major differences I see are
speed and interactivity:
Speed comparisons on FreeBSD Unix:
javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span.
However even on immediate re-runs, javac takes between 2 and 7 seconds
to compile a very small file (23 lines total, only 10 lines of actual
code).
Thats one of the reasons why java programmers have been using the jikes
compiler instead for the most recent 6-7 years ,-)
The other reason is that it produces much more informative error
messages than javac does.
Five years ago when my work machine was a 400 MHz PII with an EIDE
drive, jikes could compile 1 MB of java source per second including
start up time. It has bloated a bit since then, but it is still rare to
see a compilation taking more than 0,2 seconds for a handfull of smaller
files.
http://www-124.ibm.com/developerworks/oss/jikes/
CMUCL takes appx. 2 seconds to start up the first time, then is
virtually instant subsequent times within a short time span.
Recompiling a 33-line file runs so blindly fast that even with
*error-output* diverted to bit sink so as to suppress listing of each
function compiled, its limited only by 19200 bps printout of the return
value.
(let ((*error-output* (make-broadcast-stream))) (compile-file
"tabsp.lisp")) #p"/home/users/rem/JavaWork/tabsp.x86f"
I have the same experience.
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
What takes 24 seconds to restart?
J2EE application servers can take from many seconds to several minutes
to restart even on the fastest machines you can buy (which is one good
reason to steer clear of J2EE), but plain old java takes but a fraction
of a second.
Interactivity: In CL (and virtually any LISP since the original), you
can sit in a read-eval-print loop composing and trying one line of code
at a time, storing the results of correct computation in global
variables to feed into the next step of composing&trying. By
comparison, in java you have to switch back and forth between editing
the source of not just what you want to test but a whole test rig
around it to make a "complete program", compiling that "complete
program" to bytecode, and running that "complete code" just to see if
you got one line of new code correct. Comparing the instant feedback
when typing one new LISP form into the R-E-P, against the 24+ second
turnaround to try one new line of java code, LISP is a *big* winner!
The read-eval-print way of hacking is the single largest productivity
enhancer I have found in CL as compared to java. It is a real joy to
work this way.
Other benefits I have found in CL as compared to java:
Passing functions around with or without capturing variables with ease.
Doing this in java is so painfull that I only do it if I _have_ to.
Optional arguments and keyword arguments.
macros
CLOS dispatches on the type of the instance where java dispatches on the
type of the reference. Yippiiiiiiiii!!!!!! No more casting all over the
place, no more double-dispatch, no more "ohh when we get the
template-look-alike-crutches everything will be less painfull" - why on
earth does java do it the way it does?
Built in assertations, as compared to the add-on in later versions of java.
The condition system does everything java exceptions does and then 10x
more. Restart a condition etc.
So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
GUI
Anything that needs kernel threads. In CL land only Franz and SBCL has
kernel threads for Linux and only Franz and Lispworks have them for
windozz. The others either have no threads at all, or only have threads
simulated within a process. Without kernel threads you loose an elegant
way of spreading an application over several cpu's among other things.
Anything that needs to be installed at dozen, hundreds or thousands of
end users pc's and upgraded periodically. Lispworks has a nize start
with the deliver system that turns your lisp application into a single
executabel file that can be distributed to end users without the need
for anything else. Administrative tools to make distribution and
installation easy both for single installations and for the admin that
needs to upgrade a few thousand desktop pc's before the users come into
work the next day, are lacking.
web stuff. The CL web stuff consists of production ready products that
are roughly where php, mod_perl, jsp etc. were around 1998, and of
interesting new ideas such as using continuations to capture state
instead of the well known session-, global-, request-scopes that only
exist in
Kristian Ro********@YahooGroups.Com said: So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
I'm a newbie in Lisp but have a fair amount of experience in Java.
Java's biggest advantage vs. Lisp is its libraries, which are huge.
Want to do GUI programming? There's Swing (and SWT and Java wxWindows
bindings...) Want to make a secure sockets connection? Built-in. Want
to open zip files? Built-in. Want to manipulate PDFs? Not built-in,
but there are a number of good options. Etc. Part of this is
popularity, but to give them their due, Sun has made a huge effort on
the libraries.
Even to my newbie eyes, Lisp is hands down the better language (except
possibly for manipulating bits and bytes); it has much more powerful
abstraction mechanisms. However, Java is a C-family language, and that
seems to matter more, from a popularity standpoint, than support for
abstraction. :-(
Regarding speed: Java's big market is not in running shell scripts.
Java's biggest use is in server-side programming, and hotspot can do a
fairly good job in that environment. It may not be the fastest option,
but it's fast enough. A bigger weakness is that Java uses memory like
a drunken sailor.
I like what I've seen of Lisp a _lot_, but right now it looks like a
much more viable language for hard problems that involve tricky
algorithms than for gluing together solutions out of pre-existing
components -- the components just aren't there. A lot of business
programming consists of such glue jobs, and Java is well-situated for
that market.
Here's hoping I'm just missing the vast Lisp libraries... I would love
to be able to make an even better case for Lisp.
*snip* I do not know about you, but when I wrote C I was always writing code
like this (taking liberties):
if ( car( cdr( foo ) ) ) {
...
} else ....
*snip*
Yeah, bad example. I was just trying to stress that lisp seems
backwards if you're coming from C/C++/Java type languages.
Like I said though, I don't really see any signifigant reason why
Java *beats* lisp, I think it's just the transitional C-like
structure of it that makes it "beat" lisp. Like another poster said:
"It's easier to write Java programs in Java."
I think that's fairly well-said.
Btw, this probably wasn't the best way to "hi," but:
Hi, I'm new to the list!
The Savages of c.l.l. will be "welcoming" you shortly.
:)
heh, looking forward to it :)
adam connor wrote: Ro********@YahooGroups.Com said:
So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
I'm a newbie in Lisp but have a fair amount of experience in Java.
Java's biggest advantage vs. Lisp is its libraries, which are huge.
Want to do GUI programming? There's Swing (and SWT and Java wxWindows
bindings...) Want to make a secure sockets connection? Built-in. Want
to open zip files? Built-in. Want to manipulate PDFs? Not built-in,
but there are a number of good options. Etc. Part of this is
popularity, but to give them their due, Sun has made a huge effort on
the libraries.
Even to my newbie eyes, Lisp is hands down the better language (except
possibly for manipulating bits and bytes); it has much more powerful
abstraction mechanisms. However, Java is a C-family language, and that
seems to matter more, from a popularity standpoint, than support for
abstraction. :-(
Regarding speed: Java's big market is not in running shell scripts.
Java's biggest use is in server-side programming, and hotspot can do a
fairly good job in that environment. It may not be the fastest option,
but it's fast enough. A bigger weakness is that Java uses memory like
a drunken sailor.
I like what I've seen of Lisp a _lot_, but right now it looks like a
much more viable language for hard problems that involve tricky
algorithms than for gluing together solutions out of pre-existing
components -- the components just aren't there. A lot of business
programming consists of such glue jobs, and Java is well-situated for
that market.
Here's hoping I'm just missing the vast Lisp libraries...
I think you have summarized things perfectly. Have you missed the vast
Lisp libraries? No, but look at all the seedlings:
http://www.common-lisp.net/projects.shtml
Fortunately the situation is not as intractable as Chicken vs. Egg: Lisp
is getting discovered by more and more folks every day, in spite of the
dearth of libraries. Thx to the UFFI project it is but a week's effort
(less once you get the hang of it) to tap a C project, and C++ can be as
easy depending on how much C glue must be written. And every open source
set of bindings to a cool C library makes Lisp that much more attractive
to new Lispniks, and pretty soon we have ignition and all C libraries
are accessible from Lisp and all C/Java programmers are Lispniks.
Easy, right? :)
The key is, as we agree, Lisp is so much more fun (fast, powerful,
interactive) that it can jumpstart the process with newbies willing to
start with just the basics (including the fact that the basics are not
built-in and might take a few hours and questions on c.l.l. to get running.)
Right now all the best young Lispniks are working on making open source
Lisps easier to use. Newbies are cheap, so I suppose this helps. The old
farts are working on useful application stuff. What newby enthusiasts
need to do is pitch in on these libraries, not...
Here's hoping I'm just missing the vast Lisp libraries. I would love
to be able to make an even better case for Lisp.
....sit around waiting for the Open Source Common Lisp Library Fairy to
leave them under your pillow.
:)
slim kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application Ro********@YahooGroups.Com wrote in message news:<RE***************@Yahoo.Com>... Interactivity: In CL (and virtually any LISP since the original), you
can sit in a read-eval-print loop composing and trying one line of code
at a time, storing the results of correct computation in global
variables to feed into the next step of composing&trying. By
comparison, in java you have to switch back and forth between editing
the source of not just what you want to test but a whole test rig
around it to make a "complete program", compiling that "complete
program" to bytecode, and running that "complete code" just to see if
you got one line of new code correct. Comparing the instant feedback
when typing one new LISP form into the R-E-P, against the 24+ second
turnaround to try one new line of java code, LISP is a *big* winner!
I do not know jikes's availability, but I suggest you move over to it.
It has the incremental compilation feature, where you simply press
enter.
So I ask, is there any particular kind of task where java has an
advantage over LISP?
Applet security. People mention applets are dead, but I am not
concerned with popularity in this case.
READ in lisp is deadly. The fact *read-eval* can be set is irrelevant;
there should be syntactic sugar like say SAFEREAD. Or something.
Bunch o libraries, dunno...
Friendly package system.
Weak pointers/tables as standard, though I dunno how pervasive it is
in CL implementations.
Portable.
Graphics.
Concurrency or reasonable facsimile thereof.
Drags people halfway to lisp because of its braces 'n semicolon UI.
One can often rob lisp and claim to invent something new in Java.
Pain, terror, anguish, McDonald's.
get a job?
.... just a dark thought on this rainy tuesday... hehe.
s.
<Ro********@YahooGroups.Com> wrote in message
news:RE***************@Yahoo.Com... After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities as a standard
portable part of the core language, the LISP package, and the java.lang
package, respectively. Both have big integers, although only LISP has
rationals as far as I can tell. Because CL supports keyword arguments,
it has a wider range of string search utilities etc. where :key and
:test and :start :end etc. are parametric instead of fixed or
special-cased here but not there. The only major differences I see are
speed and interactivity:
Speed comparisons on FreeBSD Unix:
javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span.
However even on immediate re-runs, javac takes between 2 and 7 seconds
to compile a very small file (23 lines total, only 10 lines of actual
code).
CMUCL takes appx. 2 seconds to start up the first time, then is
virtually instant subsequent times within a short time span.
Recompiling a 33-line file runs so blindly fast that even with
*error-output* diverted to bit sink so as to suppress listing of each
function compiled, its limited only by 19200 bps printout of the return
value.
(let ((*error-output* (make-broadcast-stream))) (compile-file
"tabsp.lisp")) #p"/home/users/rem/JavaWork/tabsp.x86f"
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
Interactivity: In CL (and virtually any LISP since the original), you
can sit in a read-eval-print loop composing and trying one line of code
at a time, storing the results of correct computation in global
variables to feed into the next step of composing&trying. By
comparison, in java you have to switch back and forth between editing
the source of not just what you want to test but a whole test rig
around it to make a "complete program", compiling that "complete
program" to bytecode, and running that "complete code" just to see if
you got one line of new code correct. Comparing the instant feedback
when typing one new LISP form into the R-E-P, against the 24+ second
turnaround to try one new line of java code, LISP is a *big* winner!
So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
Well, there's Unicode, which is built into java but not CL, but I have
no use for it at present so that doesn't count. But I'd like to write
some Web-networking code to replace the hack I currently use where lynx
is run as a sub-process under CL and lynx does all the work of handling
cookies etc. If java can do all that directly more easily than CL, I
might give it a try.
Any of you heard of BeanShell? It's a REPL for Java. It's not bad, actually.
Lowell Ro********@YahooGroups.Com wrote: After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities as a standard
portable part of the core language, the LISP package, and the java.lang
package, respectively. Both have big integers, although only LISP has
rationals as far as I can tell. Because CL supports keyword arguments,
it has a wider range of string search utilities etc. where :key and
:test and :start :end etc. are parametric instead of fixed or
special-cased here but not there. The only major differences I see are
speed and interactivity:
Speed comparisons on FreeBSD Unix:
javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span.
However even on immediate re-runs, javac takes between 2 and 7 seconds
to compile a very small file (23 lines total, only 10 lines of actual
code).
CMUCL takes appx. 2 seconds to start up the first time, then is
virtually instant subsequent times within a short time span.
Recompiling a 33-line file runs so blindly fast that even with
*error-output* diverted to bit sink so as to suppress listing of each
function compiled, its limited only by 19200 bps printout of the return
value.
(let ((*error-output* (make-broadcast-stream))) (compile-file "tabsp.lisp"))
#p"/home/users/rem/JavaWork/tabsp.x86f"
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
Interactivity: In CL (and virtually any LISP since the original), you
can sit in a read-eval-print loop composing and trying one line of code
at a time, storing the results of correct computation in global
variables to feed into the next step of composing&trying. By
comparison, in java you have to switch back and forth between editing
the source of not just what you want to test but a whole test rig
around it to make a "complete program", compiling that "complete
program" to bytecode, and running that "complete code" just to see if
you got one line of new code correct. Comparing the instant feedback
when typing one new LISP form into the R-E-P, against the 24+ second
turnaround to try one new line of java code, LISP is a *big* winner!
So I ask, is there any particular kind of task where java has an
advantage over LISP? The only thing I can think of is networking. I've
heard that java has networking built into the language, things like
sockets, TCP/IP, HTTP, etc., whereas they aren't part of CL per se and
need to be supplied by various vendors on the side. So is this true,
that java is better than CL for networking stuff? Also, is there any
other area where java beats CL?
Well, there's Unicode, which is built into java but not CL, but I have
no use for it at present so that doesn't count. But I'd like to write
some Web-networking code to replace the hack I currently use where lynx
is run as a sub-process under CL and lynx does all the work of handling
cookies etc. If java can do all that directly more easily than CL, I
might give it a try. Ro********@YahooGroups.Com wrote:
*snip* You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
For university I had to do a Java project. We were working in a team
using Eclipse (the IDE, not the window manager). Eclipse allows to run
code, even if parts of it are broken and won't compile. (But it still
needs some awefully long seconds to start up.) In addition, it has a
scrappage where you can evaluate expressions.
Thus to be fair, using a big IDE, you can break up the
edit-compile-run-cycle a bit even in Java. Of course the question
remains, why not just use the language, where incremental development
using the read-eval-print-loop is the natural way to do things?
Chris
I haven't seen many enterprise-scale systems delivered using Lisp, but
maybe that's just me?
- sarge
On Tue, 04 May 2004 02:11:30 +0200, Kristian Elof Sørensen <el**@image.dk> wrote: Anything that needs kernel threads. In CL land only Franz and SBCL
has kernel threads for Linux and only Franz and Lispworks have them
for windozz. The others either have no threads at all, or only have
threads simulated within a process. Without kernel threads you loose
an elegant way of spreading an application over several cpu's among
other things.
I don't think AllegroCL offers native threads on Linux. However, there
are more Lisps offering native threads than you mention above. I know
of at least:
1. AllegroCL on Windows
2. LispWorks on Windows
3. Corman Lisp on Windows
4. SBCL on Linux x86
5. OpenMCL on Mac OS X and Linux PPC (I think)
6. SCL on Solaris, HP/UX, and Linux (x86 and AMD64)
I agree with you that the absence of native threads can be a big
disadvantage. One situation that comes to mind is calling out to
foreign functions where one FFI call can block all other threads if
they're not native.
Cheers,
Edi.
On 4 May 2004 03:03:51 -0700, sa*********@hotmail.com (Chris) wrote: I haven't seen many enterprise-scale systems delivered using Lisp,
but maybe that's just me?
Yes, that's just you.
Edi. sa*********@hotmail.com (Chris) wrote: I haven't seen many enterprise-scale systems delivered using Lisp,
but maybe that's just me?
Even granting that "enterprise-scale system" is well-defined, are you
aware that you have engaged in transparent logical fallacy?
-- Lucas
Dammit, I didn't realize this was crossposted. Keep in mind that I
prefer Common Lisp greatly to Java. Despite Java having some
advantages. ta*********@yahoo.com (Tayssir John Gabbour) wrote in message news:<86**************************@posting.google. com>... I do not know jikes's availability, but I suggest you move over to it.
It has the incremental compilation feature, where you simply press
enter.
So I ask, is there any particular kind of task where java has an
advantage over LISP?
Applet security. People mention applets are dead, but I am not
concerned with popularity in this case.
READ in lisp is deadly. The fact *read-eval* can be set is irrelevant;
there should be syntactic sugar like say SAFEREAD. Or something.
Bunch o libraries, dunno...
Friendly package system.
Weak pointers/tables as standard, though I dunno how pervasive it is
in CL implementations.
Portable.
Graphics.
Concurrency or reasonable facsimile thereof.
Drags people halfway to lisp because of its braces 'n semicolon UI.
One can often rob lisp and claim to invent something new in Java.
Pain, terror, anguish, McDonald's. Ro********@YahooGroups.Com wrote: So I ask, is there any particular kind of task where java has an
advantage over LISP?
Java is good at allowing the so-called "average" programmer develop
software without being able to seriously mess up things, with some
exceptions (multi-threading, for example).
Lisp is much more flexible, so it takes longer to actually become good
at it. However, it makes you much more productive as a reward.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004 http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
"John Harlow" <si********@hotmail.com> wrote in message
news:4r********************@comcast.com... After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways.
<snip>
What in the world? It takes me less than a second to recompile a large
application with hundreds of source files. I have no idea why your apps
take so long to compile, but it's surely not because of java per se.
Our 140,000 line Java app compiles in 7 seconds on a so-so machine
(dual 1GHz P3), using Sun's javac under J2SDK 1.3 or 1.4.
Kenny Tilton wrote: Fortunately the situation is not as intractable as Chicken vs. Egg: Lisp
is getting discovered by more and more folks every day, in spite of the
dearth of libraries. Thx to the UFFI project it is but a week's effort
(less once you get the hang of it) to tap a C project, and C++ can be as
easy depending on how much C glue must be written. And every open source
set of bindings to a cool C library makes Lisp that much more attractive
to new Lispniks, and pretty soon we have ignition and all C libraries
are accessible from Lisp and all C/Java programmers are Lispniks.
Only took me about a week of real effort for my resolver library, and I'm a
newbie. That isn't quite fair as it only uses a couple of UFFI functions,
but it's close.
Easy, right? :)
Generally, Lisp integrates far easier with external programs than does Java.
I love being able to call out to sb-unix functionality.
The key is, as we agree, Lisp is so much more fun (fast, powerful,
interactive) that it can jumpstart the process with newbies willing to
start with just the basics (including the fact that the basics are not
built-in and might take a few hours and questions on c.l.l. to get
running.)
Yup.
Right now all the best young Lispniks are working on making open source
Lisps easier to use. Newbies are cheap, so I suppose this helps. The old
farts are working on useful application stuff. What newby enthusiasts
need to do is pitch in on these libraries, not...
> Here's hoping I'm just missing the vast Lisp libraries. I would love
> to be able to make an even better case for Lisp.
...sit around waiting for the Open Source Common Lisp Library Fairy to
leave them under your pillow.
Very true. That's some of what I'm trying to do with findinglisp.com. I'm
trying to do useful things at the same time I'm learning the language. My
code likely sucks right now, style-wise, but at least it's functional and
useful.
--
Dave Roberts, ld***********@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp... http://www.findinglisp.com/blog
* RobertMaas wrote: javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span.
However even on immediate re-runs, javac takes between 2 and 7 seconds
to compile a very small file (23 lines total, only 10 lines of actual
code).
Are you using a machine with rather small real memory?
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! By comparison, you can stay in CMUCL and do almost
everything there, so you don't have to suffer even the two-second
first-time-start ever again during a session.
.... This would imply you are, I think - something is causing the
cached fs pages to be flushed rather aggressively.
I don't build Java stuff, but I sit next to people who do, and they
don't see these issues with Sun's 1.4.x JDK. *But* we have sensibly
configured development machines - I think they all have 4GB memory.
--tim
Ryan J. Bovorasmy wrote: I must admit that when I first began learning lisp, it
seemed almost backward to me: the way the syntax is set up, you have to
write the first thing you want to do last, and the last thing you want to
do first:
;;lisp
(car (cdr foo))
// C++ (assume I've made a linked list with push & pop type methods)
var = llist.rest();
return var.first();
After some days of use it will become easier to write what you want.
If you want the second element of a list (the first of the rest that is)
you can say "hey I need the rest"
(rest foo)
Then move your cursor to the left and tell Lisp that you are looking for
the first element:
(first (rest foo))
André
--
> From: "Ryan J. Bovorasmy" <zo****@sdf-eu.org> 1) More people know C/C++ than lisp.
Why is that? CL is easier to learn than C/C++, so why would anybody
choose C instead of CL to learn in the first place?
2) Java is like C/C++, therefore it is cheap/fast/easy for people to learn.
If somebody already is content with C, can tolerate the need to write a
whole program just to test one new line of code, can tolerate the need
to write your own conversion from input to output format (using the
built-in printf to print the pieces presumably) to see whether a
structure was built correctly, can tolerate needing to compile the
whole program then run it separately just to see the printfs to see
whether the one line of new code works correctly, why would they seek a
different language such as java, instead of stick with what they
already find good enough?
On the other hand, if somebody doesn't like the facts about C that I
mentionned above, why would one switch to a language that is even
worse, not only do you have to write a main function which is a
complete program, but you must embed it in a class, which must have the
same name as the file you put this all in, and the declaration on main
must be exactly right, and it takes ten times longer just to start up
the compiler? If you don't like C for those reasons, you really would
like try a new line of code in three seconds instead of half a minute,
why would you ever switch to java?
Another thing I noticed about using Java (the few times I have), is
that it is extraordinarily easy to write a standard-looking GUI.
Unfortunately that works only on compatible systems which support the
kind of GUI that java assumes. For example, I have no access to any
java GUI here on VT100 dialup into Unix shell account. And if you use
CGI to make your application available to the whole net, your nice GUI
can't be used, you have to use HTML FORMs, which are just as easy to
generate and process in LISP as in java. So one way your program can't
be used on the kind of account I have, and the other way LISP is just
as good as java, so where's the advantage to java if you want to allow
everyone to use your program?
lisp still has a lot of "ancient" terminology embedded into the
language that a lot of beginning programmers are likely to find
confusing.
You mean like FIRST (formerly called CAR) and REST (formerly called CDR)?
You mean like MAP and APPLY and FUNCALL (FUNction CALL)?
I do have one nit about CL terminology: The internal structure that is
represented externally by dotted-pair notation, i.e. (first . rest),
should be called a STANDARD PAIR, not a CONS. The function name CONS is
short for CONStruct, which is ambiguous, and defining it to make a CONS
cell makes the circular definition horrid. But I suppose you can
actually avoid that by using LIST* everywhere you would otherwise use
CONS, remembering that the * in that name looks a bit like a glorified
dot, reminding you that it makes something that prints as a dotted list
instead of a regular list, and in the two-argument case it makes
something that prints as just a dotted pair, the shortest possible
dotted list.
Please tell me specifically what "ancient" terminology you object to in
CL.
when I first began learning lisp, it seemed almost backward to me:
the way the syntax is set up, you have to write the first thing you
want to do last, and the last thing you want to do first:
;;lisp (car (cdr foo))
You don't have to nest function calls like that. You can write each
function call as a separate assignment:
(setq tmp (cdr foo))
(setq result (car tmp))
You have the same options in C or java as in lisp.
(setq result (fun3 (fun2 (fun1 input))))
result = fun3(fun2(fun1(input))));
(setq tmp1 (fun1 input)) tmp1 = fun1(input);
(setq tmp2 (fun2 tmp1)) tmp2 = fun2(tmp1);
(setq result (fun3 tmp2)) result = fun3(tmp2);
There's no difference between CL C/C++ and java in that respect.
You can't do this in C, but you can in CL and java:
(let* ((tmp1 (fun1 input)) double tmp1 = fun1(input);
(tmp2 (fun2 tmp1)) double tmp2 = fun2(tmp1);
(result (fun3 tmp2))) double result = fun3(tmp2);
result) return result;
(I've assumed the types of those are double-precision floating point.
In java you need to declare the type for each variable, whereas in CL
you can just use generic variables initially and declare the type only
when it really is needed to speed up a slow part of your program.)
I actually prefer lisp to Java so far, if only because of the fact
that:
1. It has aspects of a functional language.
Static methods in java are much like ordinary functions in lisp, except
they don't have keyword arguments which means you must look up a host
of almost-the-same functions instead of just one function with a bunch
of keywords you can mix in any form. But most of the API has instance
methods instead of static methods, so for example if you want to find
the index where str1 occurs within str2, you're forced to re-write
(setq index (search str1 str2))
not as
index = String.indexOf(str1, str2)
but as
index = str2.indexOf(str1)
gee, it's even backwards from CL convention there.
Anyway, back to lack of keywords, so every combination of what would be
keywords in CL becomes a totally separate functionName and/or
argumentList in java. For example:
int String.indexOf(int ch)
int String.indexOf(int ch, int fromIndex)
int String.lastIndexOf(int ch)
int String.lastIndexOf(int ch, int fromIndex)
whereas in CL you have a single function:
(position item sequence &key :from-end :test :test-not :start :end :key)
which not only works on strings, with :from-end making the difference
between indexOf and lastIndexOf, but :test :test-not and :key aren't
even available in java, and this same function works on all kinds of
sequences, not just strings, but other vectors, and linked-lists, too.
In Java if you want to do this same thing with vectors or linked-lists,
you probably need to write the function yourself, because as far as I
can tell java.lang doesn't have a class for vectors nor for linked
lists, and I don't know where else to find something like
Vector.indexOf or LinkedList.indexOf etc.
LISP also has:
(search sequence1 sequence2 &key :from-end :test :test-not :key
:start1 :end1 :start2 :end2)
for which java implementes only a small portion of the cases as:
int String.indexOf(String str)
int String.indexOf(String str, int fromIndex)
int String.lastIndexOf(String str)
int String.lastIndexOf(String str, int fromIndex)
Suppose you want to find the first or last occurrance of some name,
ignoring case. In CL it's trivial:
(search "robert" "Hi, this is Robert Maas here" :test #'char-equal)
how would you do that in java except by writing your own nested loop
from scratch?? How come the java API doesn't already include this??
2. It makes working with lists easy.
Indeed, in java working with linked lists must be an awful pain.
Either your list can contain only one kind of element, so you declair
your own class to include link-cells whose data pointer is of that
type, or you use the generic Object type and deal with having to write
code that explicitly checks the case of every element at runtime.
And I just noticed: The arguent to indexOf isn't a character at all,
it's an integer!! At least in CL you can directly pass a character
object as argument to function that searches for that character within
a string, instead of coercing it to an integer first!!
In CL, if you pass an integer instead of a character, it looks for that
integer, not the character with that ASCII code, for example:
(position 65 '(#\A #\B 65 66))
will find the 65 instead of the #\A, returning 2 instead of 0 as the
index where it found that number. Ro********@YahooGroups.Com wrote: If somebody already is content with C, can tolerate the need to write a
whole program just to test one new line of code, can tolerate the need
to write your own conversion from input to output format (using the
built-in printf to print the pieces presumably) to see whether a
structure was built correctly [snip]
How would you see that in lisp without using the introspector running in
an interactive environment? Is there any real difference between lisp
debugging environments that allow introspection and Java debugging
environments that allow introspection in this regard? Other than there
are very few lisp compilers put out without interactive introspection,
but the standard Java compiler has its debugger as a separate
application, this isn't an issue. Similarly you're out on compile speed
by between one and two orders of magnitude (.5 to 5 seconds, not half a
minute). Loading and compiling a lisp code into ACL on my machine takes
about as long as the same size of Java, the gain is many free lisp
environments allow incremental compile during debug and introspection,
whereas the free Java compiler doesn't. Commercial Java environments do.
There is a distinction between language, environment, implementation and
libraries. Lisp has always shipped with an interactive introspective
environment, it took to the mid-to-late '90s for the compiled languages
to catch up, but they pretty well have. Some Java environments have gone
further, for example supporting backwards stepping debugging so you can
try your code, find it has a bug, step backwards to before the buggy
line, edit & recompile, the continue stepping forwards.
For example, I have no access to any java GUI here on VT100 dialup into
Unix shell account.
Nor could you send SMS on a 'wind up' telephone. If your clients want
GUIs, then GUI they must have. If they want to use VT100, use something
suitable for that. But I don't think the ideas in lisp should be
restricted to yesteryears' technology.
And if you use
CGI to make your application available to the whole net, your nice GUI
can't be used, you have to use HTML FORMs, which are just as easy to
generate and process in LISP as in java.
Or easier. But then there are mutant forms of Java such as JSP that are
intended to make web programming easier by giving the equivalent of
quote and qquote in XML. (though the syntax is so ugly and they mix
abstraction layers so badly I've never used JSP)
There isn't anything like the support for web applications in Lisp than
there is in Java. I haven't used CGI itself for nearly a decade; once
you have anything more than a simple form and want a DB backend, you end
up using a framework. There is some interesting work done is lisp with
continuations for web programming, but continuations aren't part of
Common Lisp, and that's seems more equivalent to the XML based
frameworks that writing pure Java servelets.
So one way your program can't
be used on the kind of account I have, and the other way LISP is just
as good as java, so where's the advantage to java if you want to allow
everyone to use your program?
Most of the world's populace don't have access to any computer, so you
won't be programming at all by the argument of lowest common technology.
People expect more than can be delivered through an HTML form, let alone
VT100.
You mean like FIRST (formerly called CAR) and REST (formerly called CDR)?
You mean like MAP and APPLY and FUNCALL (FUNction CALL)?
Or lambda, which is so old it's ancient Greek. The problem's more one
that there is another abstraction- programmers are taught that a program
is 'like a recipe', so how can a recipe take part of the cookbook as an
ingredient? You have to think different to use lisp, and too many people
are taught to program rather than taught to think.
From: "Ryan J. Bovorasmy" <zo****@sdf-eu.org>when I first began learning lisp, it seemed almost backward to me:
the way the syntax is set up, you have to write the first thing you
This is similar to a very old argument: programming by query or navigation.
lisp/Prolog/SQL you say 'I want the first part of the rest of the list'.
C/C++/Java/CODASYL 'I have a list, I will navigate through it until I
have the second element, then return that element'
Lisp syntax structures its calls starting with the result (though the
effect is still procedural), Java syntax structures its calls starting
with your arguments.
The best response to this is 'programmers enjoy a challenge'.
On the other hand, the Java syntax fits in with the model of
program-as-recipe, and how real world navigation (which is something
human brains are good at) works. People like working that way, as it
fits in with their congnative model of how the software executes.
Anyway, back to lack of keywords, so every combination of what would be
keywords in CL becomes a totally separate functionName and/or
argumentList in java.
This is more a lack of optional arguments, rather than keyword arguments.
IDEs also help in the other aspect that keywords do, by showing the
programmer what the names of the arguments are. Not much use on a VT100,
but on any current machine it's adequate.
In Java if you want to do this same thing with vectors or linked-lists,
you probably need to write the function yourself, because as far as I
can tell java.lang doesn't have a class for vectors nor for linked
lists, and I don't know where else to find something like
Vector.indexOf or LinkedList.indexOf etc.
Collections are in the utility package, java.util. All the features you
say you need to write yourself are provided. Now-a-days, Java's biggest
advantage is the size of its libraries.
Suppose you want to find the first or last occurrance of some name,
ignoring case. In CL it's trivial:
(search "robert" "Hi, this is Robert Maas here" :test #'char-equal)
how would you do that in java except by writing your own nested loop
from scratch?? How come the java API doesn't already include this??
Probably because no one needs to do it that often. You can convert both
to lower-case, but if you wanted fast you'd have to do it as you said.
How come the lisp standard doesn't include {threads, UI, reg ex, ...}?
Nothing is complete, and the standard libraries support the things
people seem to need at the time. As CL isn't case sensitive by default,
is supports case insensitive searches, as Java supports the version of
Unicode that was current at its inception, it has other character string
facilities that CL lacks.
2. It makes working with lists easy.
Indeed, in java working with linked lists must be an awful pain.
Either your list can contain only one kind of element, so you declair
your own class to include link-cells whose data pointer is of that
type, or you use the generic Object type and deal with having to write
code that explicitly checks the case of every element at runtime.
You tend to use the singly polymorphic dispatch mechanism. It's not as
elegant as generic functions, but it's not something you notice- the
main difference is that the generic function definition has to be placed
into an 'interface' and (if using Java version<1.5) you have to 'cast'
(coerce) the elements in the list to the interface type. It's more
typing, less elegant syntax, but no more cognitive effort.
And I just noticed: The arguent to indexOf isn't a character at all,
it's an integer!! At least in CL you can directly pass a character
object as argument to function that searches for that character within
a string, instead of coercing it to an integer first!!
The coercion from char to int is automatic; this is a convenience to
counter the effect of having only one set of primitive arithmatic
operations- as all arithmetic is performed as int, you'd have to coerce
back to char if you passed the result of a bit mask etc.. As to whether
exposing such low level details is a good design policy, that's a
different matter, but it simplifies the compiler design, and the
interface to the API is the way it is to make it easier to use. In CL
you'd have to explicitly perform the conversions.
In CL, if you pass an integer instead of a character, it looks for that
integer, not the character with that ASCII code, for example:
(position 65 '(#\A #\B 65 66))
will find the 65 instead of the #\A, returning 2 instead of 0 as the
index where it found that number.
Strings are objects that wrap arrays of UTF-16 encoded characters, not
ASCII, nor are they lists of typed objects as in your example. You can't
create a string in Lisp with numbers in it, a string is a vector of
characters, each with a unique character point value in some encoding,
just like in Java.
If you are comparing function rather than syntax (which is horribly
verbose for this and many other cases), then the equivalent of your Lisp
'find the position of the first occurrence of the integer 65 in the list
....' is:
java.util.Arrays.asList(new Object[]{
new Character('A'),
new Character('B'),
new Integer(65),
new Integer(66),
}).indexOf(new Integer(65))
That will return 2 instead of 0, just like in Lisp.
(normally I'd use a script to generate such lists in Java, with lisp
being the scripting language of choice)
If you want to compare two things, your arguments carry more weight if
you actually compare like with like. Saying things like 'Java is bad
because you'd have to implement lists yourself because I don't know
where the library is in Java' or 'Java development environments don't
support object introspection' isn't going to help your point, only show
you haven't done your research.
Most languages, Java included, are destined to evolve into lisp or
remain niche languages. After 50 odd years, the rate of evolution seems
faster than ever.
Pete
> From: Kenny Tilton <kt*****@nyc.rr.com> The OP
(that's me) was wondering if anything was /actually/ easier in Java. That is
cruel since Java is such a simple, powerless language, but c.l.l. is
a hotbed of savagery and demonic ritual torture.
What, are you calling me cruel??
Anyway, so-far only three ideas have turned up:
- GUIs, which however are useless to me here on VT100 dialup into Unix shell.
- Applets, ditto, can't run applets in lynx.
- Network connections (sockets, TCP/IP, HTTP, cookies, etc.), aha some
application area where I might be able to write a program that I never
got around to doing in LISP because it would have required too much
effort.
Regarding the two directions of writing expressions that involve a
daisy chain (pipeline) of function/program calls, one way illustrated
by Unix pipeline notation or successive SETQs in interactive LISP
session, and the other illustrated by nested functional notation:
These may be compared to the two ways of solving a path-finding
problem, either starting from the starting pointing and hill-climbing
toward the goal, or backtracking from the goal trying to find the
starting point.
"I live on what is left over after taxes are taken from the money I
earn."
I need to live, on what? Expendable income.
live = use(expInc);
Error, expInc unbound variable.
But where does expendable income come from? Gross income minus taxes.
live = use(deducttaxes(grossIncome));
Error, grossIncome unbound variable.
But where does gross income come from? Earnings.
live = use(deducttaxes(wages(labor)))
Error, labor unbound variable.
How much did I work? 10 hours.
live = use(deducttaxes(wages(10)))
Horay, I can live 5 hours on that amount of income, oops!!
Of course Hemingway would say, "Kenny earned money. They took out
taxes. He lived on the rest. In the rain."
Kenny worked.
shell% kennyLabor
10 hours
Due to his work, Kenny earned money.
shell% kennyLabor | wageCalc
$150
They took out taxes.
shell% kennyLabor | wageCalc | taxDeduct
$47
He lived on the rest.
shell% kennyLabor | wageCalc | taxDeduct | liveInSFBayArea
5 hours
In the rain.
shell% kennyLabor | wageCalc | taxDeduct | liveInSFBayArea > /dev/null
P.S. IMO keyword arguments, as in CL, are a much better way to do
function/method overloading than having fixed combinations of argument
types as in java, both because you get 2**n possible combinations with
only n keywords whereas in java if you wanted all 2**n combos you'd
need to explicitly declare all 2**n different methods, and because it
doesn't matter if two or more different arguments are of the same time
you can *still* have one or the other in CL whereas in java it's
impossible to do that because there'd be ambiguity in the overloading
due to two forms having exactly the same number and types of arguments.
Tim Bradshaw <tf*@cley.com> writes: * RobertMaas wrote:
javac or java takes appx. 24 seconds to start up the first time, then
is virtually instant subsequent times within a short time span. ...
You need to re-start java every time you want to compile and every time
you want to run what you compiled, you can't just leave the jvm running
and load tasks into it. Consequently, if you go away from java for a
minute to edit the source to recompile it, etc., then you're back to 24
seconds start-up again when you want to compile what you edited, a
royal pain! ...
... This would imply you are, I think - something is causing the
cached fs pages to be flushed rather aggressively.
I don't build Java stuff, but I sit next to people who do, and they
don't see these issues with Sun's 1.4.x JDK. *But* we have sensibly
configured development machines - I think they all have 4GB memory.
"Sensibly configured ... 4GM" -- is there some automatic irony
there?
I don't have 24 second start-up for Java, but it is noticeably
slow compared to Lisp.
-- jd
Some things I find easier to do in Java:
* Threads
* GUIs
* XML processing
* Structuring systems (packages, nested class definitions)
* Little, local classes
Major lacks in Java:
* Macros
* Concise notation for functions or similar.
* Lists [Yes I know about java.util.List]
* Source code syntax for data
[Java has some for numbers, strings, arrays, but not for
Collections, Maps, instances of arbitrary classes.]
A couple of people mentioned large libraries as one of
Java's biggest advantages. They're also one of Java's
biggest disadvantages.
-- jd
Jeff Dalton wrote: * Source code syntax for data
[Java has some for numbers, strings, arrays, but not for
Collections, Maps, instances of arbitrary classes.]
I take it you mean the result of using print with *print-readably* true.
It works, I suppose, but try doing it for hash tables - in SBCL, at least,
the result involves "#.", which makes me unlikely to use it for
network-received data. In all fairness, Java fell off the haystack a mile
ago, but is there some way to fix this other than to write my own
(print)?
> From: "John Harlow" <si********@hotmail.com> It takes me less than a second to recompile a large application with
hundreds of source files. I have no idea why your apps take so long
to compile, but it's surely not because of java per se.
Maybe you've just used java a moment before, so all the pages of the
jvm and compiler are still in fast cache? Or maybe you are on a
computer where several other users also use java on a regular basis, so
at any given moment one of them is likely to either be using java at
the moment or ran java just a moment before. In any case, here where
java is hardly ever used, if I wait a few minutes since I last used
java, then try to use it again, there's a multi-second delay for it to
even start up:
% more T.sh
date
javac OneLine.java
date
% ls -lt OneLine.*
1 -rw------- 1 rem user 17 May 19 11:54 OneLine.java
% more OneLine.java
class OneLine {}
% sh T.sh
Wed May 19 12:12:46 PDT 2004
Wed May 19 12:12:57 PDT 2004
% ls -lt OneLine.*
1 -rw------- 1 rem user 188 May 19 12:12 OneLine.class
1 -rw------- 1 rem user 17 May 19 11:54 OneLine.java
That's appx. eleven seconds to start up javac then compile an
essentially empty java source file. Do you believe me now?
> From: Kristian Elof Sxrensen <el**@image.dk> Thats one of the reasons why java programmers have been using the
jikes compiler instead for the most recent 6-7 years ,-)
I did a 'whereis' here on Unix and it seems not to be present. I have
less than 20 megabytes remaining on my personal account, and I'll need
most of it myself. How much total does jikes require to install, both
source and result after installing?
The other reason is that it produces much more informative error
messages than javac does.
javac's compiler messages have been enough for me so-far. For example,
it warns me that my whole class needs to be declared abstract because I
have at least one abstract method within it, or because it extends an
abstract class but fails to define all the abstract methods from it.
And for local syntax errors, the line number is sufficient to go back
into emacs and find the offending line.
What takes 24 seconds to restart?
javac or java, if neither has been used recently The actual time
varies, sometimes as long as 24 seconds, more commonly 8-15 seconds.
Let me try the shell script I wrote the other day and see how long it
takes when I haven't used java at all for many hours:
% more T.sh
date
javac OneLine.java
date
% more OneLine.java
class OneLine {}
% sh T.sh
Sat May 22 14:03:23 PDT 2004
Sat May 22 14:03:57 PDT 2004
Gee, a full 34 seconds, give or take a second!
The read-eval-print way of hacking is the single largest productivity
enhancer I have found in CL as compared to java.
I agree. If you're experimenting with some really complicated part of
the API you've never used before, it makes the difference between "can
do" and "give up".
Optional arguments and keyword arguments.
Optional arguments are usually not so wonderful, but keywords arguments
are a **big** win! In fact for self-documenting code, optional
non-keyword arguments may actually be a bad idea. They are for things
you don't often use, right? Well if you don't often use them, then you
often forget what they are for. But keyword arguments remind you what
they are for. Compare for example in current CL:
(read-line netstream nil nil t)
It's pretty obvious that first optional argument is the stream, both
because you use it often enough to remember it, and because the actual
argument says something like that. But it's a pain to remember what the
other three optional arguments are. What if it were like this instead:
(read-line :INPUT-STREAM netstream :EOF-ERROR-P nil :EOF-VALUE nil
:RECURSIVE-P t)
Now you can just look at it and see what those arguments are, instead
of trying to guess, or running to the manual and spending several
minutes just to analyze this one line of code. For user-defined
functions with varying number of argument, there *is* no manual, and
the next programmer hasn't memorized all of this programmer's
conventions and function definitions, and shouldn't, and it's a pain to
have to look up each function definition to see what those optional
arguments are for.
CLOS dispatches on the type of the instance where java dispatches on
the type of the reference.
I don't quite understand what you mean here. In java, the compiler
enforces the rule that you can implicitly cast to a superclass, because
that will always work, but to downcast you need to explicitly cast,
which generates runtime code to throw an exception if the object isn't
really of the type you're trying to cast it to. But in fact at runtime,
regardless of whether you downcasted or not in the source, which
overridden method really gets called is determined solely by the actual
type of the object, not how the reference variable or expresion was
declared or cast.
Or are you talking about overloading, where it's the number and
sequence of declared types that determines which override-set gets
searched in the first place?
I guess I need a slightly more detailed explanation of what you are
saying about java before I understand your intent.
RM> is there any other area where java beats CL?
Anything that needs kernel threads.
Hmm, I've never used kernal threads, except when using the RUN-PROGRAM
function to call some other (non-CL) program from inside CL. Maybe it's
a case of since CL doesn't have it and I use CL it never occurred to me
that I needed it, just as non-LISP programmers don't understand why
having a near-universal READ and PRINT is useful, or why having actual
SYMBOLs at runtime is useful, etc., which we LISP programmers take for
granted and use all the time and don't want to live without. Ro********@YahooGroups.Com writes: RM> is there any other area where java beats CL?
Anything that needs kernel threads.
Hmm, I've never used kernal threads, except when using the
RUN-PROGRAM function to call some other (non-CL) program from inside
CL. Maybe it's a case of since CL doesn't have it and I use CL it
never occurred to me that I needed it, just as non-LISP programmers
don't understand why having a near-universal READ and PRINT is
useful, or why having actual SYMBOLs at runtime is useful, etc.,
which we LISP programmers take for granted and use all the time and
don't want to live without.
Threads are actually very nice when you want to do properly
parallelized computations on a multiprocessor machine. You can of
course spawn off additional processes to match the number of
processors. But threads also make it easy to share data because they
run in the same process space. Sharing data may break parallelized
computation, depending on your expectations, but sharing process
global state information can be useful. You just need fast mutexes.
That all said, Windows was the first platform that Java had native
threads. It was using Green Threads on Suns.
For good or ill, CL implementations have varying degrees of threading
support. The implementors haven't agreed on the best threading API
yet.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
> From: adam connor <ad*****************@mail.com> Java's biggest advantage vs. Lisp is its libraries, which are huge.
After your and other messages in this thread, I looked into that some,
see later below...
Want to do GUI programming?
No, I have no use for that because my only access to the net from home
is via VT100 (text only) emulator through Unix shell.
Want to make a secure sockets connection?
No, I just want to make a simple HTTP/TCP/IP connection to Yahoo! Mail
and accept cookies to establish a login session and auto-traverse my
e-mail folders, but java's libraries don't have any support for
cookies, and every time I look through the cookie RFC I cringe at the
work I'd have to do to support cookies myself. Looking at posted stuff
on that topic, I see everyone referring to this one third-party
library, for example:
http://www.google.com/groups?selm=MP...ws.altopia.com
http://www.google.com/groups?selm=MP...ws.altopia.com
http://www.google.com/groups?selm=MP...0news.pop4.net
http://www.google.com/groups?selm=40...a.realtime.net
http://jakarta.apache.org/commons/ht.../features.html
http://jakarta.apache.org/commons/ht.../tutorial.html
http://jakarta.apache.org/site/binindex.cgi
you must verify the integrity of the downloaded files using
signatures downloaded from our main distribution directories.
I have no idea how to do that. The whole point of thinking of using
java instead of CL for this kind of application is that the
capabilities are built into java standard libraries whereas with CL I'd
have to hassle with a third-party library, but here we are with a java
third-party library and more problems than I can deal with.
Java's biggest use is in server-side programming
Given that CL runs native code, which is about ten times as fast as
java's emulated bytecode, java would seem to be inferior for any
server-side application that is going to be used a lot. And because
it's so much easier to develop new software in CL, CL would seem to be
preferable for applications that aren't going to be run a lot too. So
where exactly would java have any advantage over CL there?
A bigger weakness is that Java uses memory like a drunken sailor.
Are you talking about when you call library functions that take objects
as arguments and produce a result as a newly-allocated object to
return, and rely on gc to reclaim the space later, instead of doing the
more memory-efficient thing of overwriting one of the objects with the
result whenever the old object won't be needed again? Or are you merely
referring to the memory overhead inherent in any fullfledged object on
the heap, so if you have lots of objects simultaneously allocated
there's a lot of overhead in them all? Or are you referring to the need
to load a whole package or at least a whole class just to use one
method within it?
I like what I've seen of Lisp a _lot_, but right now it looks like a
much more viable language for hard problems that involve tricky
algorithms than for gluing together solutions out of pre-existing
components -- the components just aren't there.
That's illogical. From CMUCL I can call *any* application whatsoever
that's available on Unix, via EXT:RUN-PROGRAM, so anything available to
java is also available to CL. I typically run lynx, traceroute, whois,
telnet, mail, dig, readmsg, sh, and mv from CMUCL in that way. If I
knew of any useful java applications available here on my ISP, I might
call them from CMUCL too if I wanted to piece them together with other
stuff. Glueing various applications together with CMUCL EXT:RUN-PROGRAM
is better than using a traditional shell-scripting language, because it
can be used in either foreground or background mode, with nice clean CL
callback in the latter case. Also EXT:RUN-PROGRAM lets you specify
exactly what command-line arguments you want to pass to the called
program, without worrying that some characters are magic characters
that expand into something you didn't want. If you want to do a
directory lookup with some template, and pass that list of filenames to
a program, you call (DIRECTORY <template>) explicitly, and splice the
resultant list of filenames (after mapping through namestring or
somesuch of course) into the args argument to EXT:RUN-PROGRAM, and the
rest of the time you don't accidently invoke some magic character that
does an unwanted directory template filename expansion splice. Ro********@YahooGroups.Com writes: From: adam connor <ad*****************@mail.com>
I like what I've seen of Lisp a _lot_, but right now it looks like a
much more viable language for hard problems that involve tricky
algorithms than for gluing together solutions out of pre-existing
components -- the components just aren't there.
That's illogical. From CMUCL I can call *any* application whatsoever
that's available on Unix, via EXT:RUN-PROGRAM, so anything available to
java is also available to CL. I typically run lynx, traceroute, whois,
telnet, mail, dig, readmsg, sh, and mv from CMUCL in that way.
By "components" Adam was probably referring not to complete existing
applications (which are trivial to call from any language I know) but
to documented, tested, and reused software libraries. Ro********@YahooGroups.Com wrote: but java's libraries don't have any support for cookies
Oh, you should check out http://www.jibble.org/cookies.php
:-) Java's biggest use is in server-side programming
Given that CL runs native code, which is about ten times as fast as
java's emulated bytecode, java would seem to be inferior for any
server-side application that is going to be used a lot.
Could you please point out some benchmarks that show that CL runs
usually ten times faster then Java?
André
--
<Ro********@YahooGroups.Com> wrote in message
news:RE***************@Yahoo.Com... From: adam connor <ad*****************@mail.com>
Java's biggest advantage vs. Lisp is its libraries, which are huge.
Agreed.
(snip) Want to do GUI programming?
No, I have no use for that because my only access to the net from home
is via VT100 (text only) emulator through Unix shell.
Want to make a secure sockets connection?
No, I just want to make a simple HTTP/TCP/IP connection to Yahoo! Mail
and accept cookies to establish a login session and auto-traverse my
e-mail folders, but java's libraries don't have any support for
cookies, and every time I look through the cookie RFC I cringe at the
Java does have support for cookies and for HTTP / tcp/ip connections.
You should be able to write a utility to "login" to your Yahoo!Mail and get
your email.
Look at the java.net.* package especially classes URL and Socket.
Cookie is in javax.servlet.http, although you can probably get away with
just the stuff in java.net.*
However for this kind of utility/glue-application Perl is probably a better
choice. Like Java it connects pretty well to just about everything.
About your question "Is anything easier to do in java than in lisp"?
Certainly yes.
Especially if one is as familiar with Java as you are with Lisp ;-)
For full-blown applications I'd certainly prefer Java, but for utilities
like this Perl, for certain kinds of AI apps Lisp ...
Alex
> From: ta*********@yahoo.com (Tayssir John Gabbour) I do not know jikes's availability, but I suggest you move over to it.
% whereis jikes
jikes:
% man jikes
No manual entry for jikes
I don't believe jikes is available here on the ISP I'm using. I have
less than 20 megabytes remaining on my disk allocation, and I'll need
most of that myself. How much space does it take to install jikes on
FreeBSD Unix?
Applet security.
I don't think applets would work in lynx, the only Web browser I have
available here on VT100 dialup into Unix, so applets aren't anything I
can use.
READ in lisp is deadly. The fact *read-eval* can be set is
irrelevant; there should be syntactic sugar like say SAFEREAD.
Well as soon as we all agree what definition of safe-read or whatever
is most appropriate for various applications, such as CGI server-side
programs, then we can just start using it and be out of danger.
Concurrency or reasonable facsimile thereof.
As a single user on an ISP with hundreds of users, I'm rather reluctant
to do any multi-threading whereby the admin would notice I had a whole
slew of processes simultaneously running, putting an unfair load on the
system, and tell me to *stop*doing*that*.
> From: "Stijn De Saeger" <di*@spammers.die> get a job?
Well actually that's the main reason why I'm taking the java
programming course. Early last year I saw a job ad that said "must be
able to perform duties using java", didn't say "requires 3 years
experience in (five or ten things, none of which I've ever done
before)" like all the other job ads did, so it looked like my 22 years
computer programming experience plus java might qualify me for any
similar job that turns up now. So now that I know how to program in
java, I can now perform job duties in java, what suitable jobs are
available for me?
By the way, 16 of my 22 years programming experience is in lisp, but I
haven't seen lisp programming job openings for many years.
> No, I just want to make a simple HTTP/TCP/IP connection to Yahoo! Mail
like http://yahoopops.sourceforge.net/ ?
"YahooPOPs!/Windows 0.6 has been released" (also Linux)
It's C/C++ so I'm way off-topic. Just thought someone might be interested.
With v 0.5 I noticed it lost my line feeds in plain-text messages. Kind-of
annoying.
Just tried 0.6; it seems not to have that problem.
> From: Kenny Tilton <kt*****@nyc.rr.com> look at all the seedlings:
http://www.common-lisp.net/projects.shtml
I browsed through there but didn't see anything that looked like HTTP
sessions with cookies. Did I overlook it, or is there indeed nothing
like that among those seedlings?
The old farts are working on useful application stuff.
That's a rather obscene derogatory way of referring to another human
being. Please translate that into decent language so I know who you're
referring to. If you mean anyone with more than 20 years programming
experience, well we're unemployed, unable to find anyone to pay us for
our fine work, borrowing on credit cards just to pay rent to avoid
being homeless, looking toward maxing credit cards and becoming
homeless in a few months if unemployment continues.
> From: Lowell Kirsh <lk****@cs.ubc.ca> Any of you heard of BeanShell? It's a REPL for Java.
After you mentionned it, I took a look at its Web-based documentation.
It looks interesting to try. I have less than 16 megabytes available in
my shell account, and I'll need most of that already. How much of that
would be consumed by downloading and installing BeanShell?
> From: Antony Sequeira <us***********@hotmail.com> Please see
http://java.sun.com/developer/techni...Supplementary/
Ah, thanks for posting that URL! The document is very enlightening.
What I understand from the above is -
Java chars are now just like C chars, only they are fixed to 16 bit
width, they are not unicode chars.
One slight difference: 8 bits per character could theoretically allow
using the first 128 characters as-is and the last 128 characters only
as parts of larger representations. But already many vendors hav used
those second 128 characters for special purposes, such as
pseudo-graphics characters, and special characters, so there's no
chance of discarding all but the first 128 as directly represented and
using the rest for encoding multi-byte characters. But the Unicode
Consortium has managed to get one block of 16-bit values reserved for
parts of larger character codes before anybody started to use them. So
whereas 8-bit C chars and various codings using them are ambiguous,
16-bit Unicode representation is unambiguous.
The section that describes this, unfortunately, is worded to mis-lead
at the start:
UTF-16 uses sequences of one or two unsigned 16-bit code units to
encode Unicode code points. Values U+0000 to U+FFFF are encoded in one
16-bit unit with the same value.
Not quite correct. Truth is: Values U+0000 to U+D7FF, and U+E000 to
U+FFFF, are encoded in one 16-bit unit with the same value. There are
not, and never will be, any characters assigned to code points in the
range U+D800 to U+DFFF, which are reserved for the use described below:
Supplementary characters are encoded
in two code units, the first from the high-surrogates range (U+D800 to
U+DBFF), the second from the low-surrogates range (U+DC00 to U+DFFF).
This may seem similar in concept to multi-byte encodings, but there is
an important difference: The values U+D800 to U+DFFF are reserved for
use in UTF-16; no characters are assigned to them as code points. This
means, software can tell for each individual code unit in a string
whether it represents a one-unit character or whether it is the first
or second unit of a two-unit character.
Yes, contradicting the mis-wording earlier, correcting the mistake.
Still, the claim that a java character is a Unicode character is not
correct, in particular whenever any character outside the 16-bit range
occurs. So any java software that is to be of general use in handling
characters must watch for appearance of any surrogate in any UTF-16
stream coming in, and must watch in any single-character input for
appearance of any unicode larger than 16 bits (requires generating two
16-bit values internally) or any unicode in the surrogate range (an
error in the input device). Any java software counting characters in a
UTF-16 string must likewise count pairs of surrogate codes as a single
character. Non-general-purpose software can simply abort whenever it
sees any such problem.
As to the 8-bit encoding of Unicode:
UTF-8 uses sequences of one to four bytes to encode Unicode code
points. U+0000 to U+007F are encoded in one byte, U+0080 to U+07FF in
two bytes, U+0800 to U+FFFF in three bytes, and U+10000 to U+10FFFF in
four bytes.
Technically the three-byte encoding covers only U+0800 to U+D7FF and
U+E000 to U+FFFF, because there are no characters assigned to code
points in the range U+D800 to U+DFFF. Software should probably signal
an error (exception) if it sees any violation of that.
The main decision the JSR-204 expert group had to make was how to
represent supplementary characters in Java APIs, both for individual
characters and for character sequences in all forms. A number of
approaches were considered and rejected by the expert group:
This is where the fun starts. If you're curious, read this part of the
document! All your favorite ideas were rejected!
Here are main points of the decision:
In the end, the decision was for a tiered approach:
* Use the primitive type int to represent code points in low-level
APIs, such as the static methods of the Character class.
* Interpret char sequences in all forms as UTF-16 sequences, and
promote their use in higher-level APIs.
* Provide APIs to easily convert between various char and code
point-based representations.
...
With this approach, a char represents a UTF-16 code unit, which is not
always sufficient to represent a code point. ...
Note that code points will be represented as ints, not as chars, in all
the single-character low-level API methods. But note that
Character.toUpperCase can't work in general, because sometimes the
uppercase of a single character is two characters!
Regarding source code:
For example, the character U+20000 is written as "\uD840\uDC00".
Ugly!
Then of course there's modified UTF-8 which is incompatible with UTF-8,
but is used by the jvm! Not just ugly, but disgusting!
the Java 2 SDK provides a code point input method
which accepts strings of the form "\Uxxxxxx", where the uppercase "U"
indicates that the escape sequence contains six hexadecimal digits,
thus allowing for supplementary characters.
Fun!
As to which version of java gets these changes:
The enhancements are part of version 1.5 of the Java 2 Platform,
Standard Edition (J2SE).
Here on my own ISP, we have jdk1.2.2, which seems to be much earlier,
or am I confused? (I'm looking at directory from whereis command.)
> From: Tim Bradshaw <tf*@cley.com> Are you using a machine with rather small real memory?
I don't think so. It's a commercial ISP FreeBSD Unix shell machine that
I use from home, and the ISP probably has a lot of memory to handle
lots of simultaneous users (appx. 20 at the moment, more on weekdays).
But it also takes a long time to compile a file using jcreator at
DeAnza college, where I have a whole Windows 2000 Professional machine
all to myself, but with all software (except for my own) from a shared
server of course.
I don't suppose you know how to find out on FreeBSD Unix, and on
Windows 2000 Professional, how much actual memory each has?
> From: Jan Gregor <gr********@NOSPAMquick.cz> Problem with compilation of java programs is that compiler itself
runs in jvm. Use jikes, it is very fast compared to javac. i think
because is written in C or C++.
It doesn't seem to be available on my ISP:
% man jikes
No manual entry for jikes
% whereis jikes
jikes:
%
If I were to download it and install it on my personal shell account on
the FreeBSD Unix ISP, how much disk space would be used?
RobertMaas asked I don't suppose you know how to find out on FreeBSD Unix,
dmesg displays the system message buffer. Early in that is
what kernal discovered when it was booting. For example
CPU: Pentium/P55C (165.79-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x544 Stepping = 4
Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,M MX>
real memory = 167772160 (163840K bytes)
avail memory = 158842880 (155120K bytes)
The kernal remembers all this, so you can ask it with sysctl
cawtech$ sysctl hw.physmem
hw.physmem: 164069376
cawtech$ sysctl hw.usermem
hw.usermem: 146206720
I don't know why the numbers don't agree.
There is also a vmstat command. I set it running with
vmstat -w 5
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id
0 0 0 1365776 45348 1 0 0 0 0 0 0 3 275 623 101 3 1 95
0 0 0 1363504 45348 1 0 0 0 0 0 0 0 229 9 4 0 0 100
0 0 0 46228 59756 1 0 0 0 721 0 0 0 230 30 7 0 1 99
0 0 0 46228 59756 1 0 0 0 0 0 0 0 258 124 32 0 1 99
Not much happening on my machine. The 721 is when I quit
from CMUCL, so I guess that freed 721 pages. This might be
the way to tell if your Java image is getting paged out
quickly because the machine is very busy.
Disclaimer: I am not a system administrator, nor do I play
one on TV.
Alan Crowe
Edinburgh
Scotland
Alan Crowe <al**@cawtech.freeserve.co.uk> wrote:
+---------------
| dmesg displays ...
| real memory = 167772160 (163840K bytes)
| avail memory = 158842880 (155120K bytes)
|
| The kernal remembers all this, so you can ask it with sysctl
|
| cawtech$ sysctl hw.physmem
| hw.physmem: 164069376
| cawtech$ sysctl hw.usermem
| hw.usermem: 146206720
|
| I don't know why the numbers don't agree.
+---------------
"hw.physmem" is how much physical memory there is. "hw.usermem" is
how much memory is available for being allocated for various things
like processes, buffer caches, etc. The latter omits memory which has
been "wired down" for one reason or another (such as the kernel itself,
loaded drivers, statically-alloocated tables, etc.), and is not part
of the general system pool. See "/usr/src/sys/i386/i386/machdep.c"
and "/usr/src/sys/i386/i386/pmap.c" in any recent FreeBSD.
-Rob
-----
Rob Warnock <rp**@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
The major advantage of Java, C, C++, Pascal, etc. over Lisp is that
solving anything that can be solved with an iterative solution easily
is easy. To me that's the real advantage ...
I once took a Lisp class when I was studying. I was quite curious
about Lisp. Then a programming task was given that would have been a
peace of cake when solving it with an iterative approach. Looking for
a recursive stack-based solution for Lisp caused big headaches. Since
that day I was not that interested in Lisp any more. Okay, with a
recursive solution things are non-desctructive which is convenient
when debugging. Things in Smalltalk are also non-desctructive (okay,
not 100% as in Lisp - but in general it is true) since the respective
methods in the Collection hierarchy only iterate over the receiver
collection but work on copies. It makes probably more sense to compare
Lisp and Smalltalk - they are more alike and both almost dead.
Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one). I never
dared to ask the professor. He was such a Lisp fanatic he would have
killed me on the spot ...
I suggest to take Squeak Smalltalk ( www.squeak.org) change the
VM/compiler to have macros (Squeak has a liberal license that would
allow for it). Add Lisp style lists with car and cdr and you have the
best of the imperative and non-imperative world :-).
Regards, Oliver Plohmann Ro********@YahooGroups.Com wrote in message news:<RE***************@Yahoo.Com>... From: Jan Gregor <gr********@NOSPAMquick.cz>
Problem with compilation of java programs is that compiler itself
runs in jvm. Use jikes, it is very fast compared to javac. i think
because is written in C or C++.
It doesn't seem to be available on my ISP:
% man jikes
No manual entry for jikes
% whereis jikes
jikes:
%
If I were to download it and install it on my personal shell account on
the FreeBSD Unix ISP, how much disk space would be used?
ol****@plohmann.com (Oliver Plohmann) writes: Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one). I never
dared to ask the professor. He was such a Lisp fanatic he would have
killed me on the spot ...
I'm not a Lisp guru, but your question is easily answered. They're
not holy things. Imperative code is common in Common Lisp, and if
it's a natural way to solve a particular problem, a Lisp programmer is
in no way unlikely to use it.
--
Howard Ding
<ha****@hading.dnsalias.com> ol****@plohmann.com (Oliver Plohmann) writes: Since several Lisp gurus have replied to this thread maybe one can
tell me why recursiveness and non-destructiveness in Lisp is such a
holy thing (this is a "real" question - not a rhetoric one).
It's not. Perhaps your class was an attempt (apparently not a
successful one) to teach recursion and functional programming using
some dialect of Lisp as a vehicle. Try not to confuse the medium with
the message.
Christophe
-- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) ol****@plohmann.com (Oliver Plohmann) writes: The major advantage of Java, C, C++, Pascal, etc. over Lisp is that
solving anything that can be solved with an iterative solution easily
is easy. To me that's the real advantage ...
really?
(loop for name in parameters
for value in values
do (stuff name value))
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen ol****@plohmann.com (Oliver Plohmann) writes: I once took a Lisp class when I was studying. I was quite curious
about Lisp. Then a programming task was given that would have been a
peace of cake when solving it with an iterative approach. Looking for
a recursive stack-based solution for Lisp caused big headaches. Since
that day I was not that interested in Lisp any more.
You probably mean Scheme here, or at least not Common Lisp. If
something is a peace of cake iteratively, then in Common Lisp you will
solve that iteratively (and it will be a peace of cake too).
OTOH, if it is a peace of cake recursively/functionally, then again,
you'll probably solve it recursively in Common Lisp.
Modern Common Lisp is a multiparadigm language. This thread has been closed and replies have been disabled. Please start a new discussion. |
