473,562 Members | 3,097 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is anything easier to do in java than in lisp?

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&tryin g. 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.
Jul 17 '05 #1
73 7930
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.
Jul 17 '05 #2
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!
Jul 17 '05 #3


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

Jul 17 '05 #4
Ro********@Yaho oGroups.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&tryin g. 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

Jul 17 '05 #5
Ro********@Yaho oGroups.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.
Jul 17 '05 #6
*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 :)

Jul 17 '05 #7


adam connor wrote:
Ro********@Yaho oGroups.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

Jul 17 '05 #8
Ro********@Yaho oGroups.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&tryin g. 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.
Jul 17 '05 #9
get a job?
.... just a dark thought on this rainy tuesday... hehe.
s.

<Ro********@Yah ooGroups.Com> wrote in message
news:RE******** *******@Yahoo.C om...
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&tryin g. 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.

Jul 17 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.