473,854 Members | 1,580 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
73 8114


Oliver Plohmann wrote:
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).


How long ago was your Lisp class?

The funny thing is that anyone posting on c.l.lisp a recursive solution
where any of the many Lisp iteration mechanisms (various do's, various
map's, loop) would suffice can reliably count on being flamed as a
closet schemer.

Me, I got a huge kick out of recursion when I started my Lisp family
programming in Logo. It took a little mind-bending, but I grokked the
power straight away. So I for one do not pounce on those who recur for
recursion's sake, but then neither do I eschew iteration where it will,
um, do.

btw, sounds like you gave up on recursion and Lisp too fast, before you
had mastered recursion. Recursion is worth understanding for those times
when iteration is the wrong hammer.

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 #51
Oliver Plohmann wrote:
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. It's a quasi-religious thing with some *Scheme*
advocates, but (most?) Common Lisp programmers view the
recursion fetish with something between dismay and disdain.

Paul
Jul 17 '05 #52
Oliver Plohmann schrieb:
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.


As others already pointed out: Lisp /does support/ iteration.

Hmm, what do you do when you can apply iteration on a problem but your
language doesn't support it? While Lisp can be extended to support your
kind of iteration as if it always had been in the language before in
many other languages you often run into the problem to describe a good
iteration with basic mechanisms - all the time.
In Java for example you could not easily loop over collections until Sun
came up with 1.5. When a new paradigm of iterating is needed you would
have to ask again Sun to implement it and wait perhaps one or two years.
In that time tens of thousands of lines of code would have been written
with a not so powerfull iteration method.

In these situations it would have been nice to have macros like Lisp does.
No Oliver, I think when we look at language constructs we won't find big
advantages of Java over Lisp. We need to look at libraries. There we can
find many things which Java has and Lisp doesn't.
You want to integrate SAP? No problem with Java with original drivers
from SAP. In Lisp.. you would have to write them yourself.
André
--
Jul 17 '05 #53
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 isn't holy. There are some advantages to non-destructive
solutions. As you pointed out, it is easier to debug if your input
isn't getting smashed. Non-destructive solutions compose easier and
can maximize sharing. The results of pure functions can be cached.
The compiler can easily re-order computations if they do not
side-effect.

Jul 17 '05 #54
In article <ll**********@c cs.neu.edu>, Joe Marshall <jr*@ccs.neu.ed u>
wrote:
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 isn't holy. There are some advantages to non-destructive
solutions. As you pointed out, it is easier to debug if your input
isn't getting smashed. Non-destructive solutions compose easier and
can maximize sharing. The results of pure functions can be cached.
The compiler can easily re-order computations if they do not
side-effect.


GC is also potentially a lot faster for side-effect-free code.

E.
Jul 17 '05 #55
Erann Gat <gN*******@flow net.com> writes:
In article <ll**********@c cs.neu.edu>, Joe Marshall <jr*@ccs.neu.ed u>
wrote:
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 isn't holy. There are some advantages to non-destructive
solutions. As you pointed out, it is easier to debug if your input
isn't getting smashed. Non-destructive solutions compose easier and
can maximize sharing. The results of pure functions can be cached.
The compiler can easily re-order computations if they do not
side-effect.


GC is also potentially a lot faster for side-effect-free code.


Yes! Thanks for mentioning that. The `write-barrier' for
generational GC does not need to apply to newly allocated storage, and
ephemeral garbage costs practically nothing.
--
~jrm
Jul 17 '05 #56
André Thieme <ad************ *************** *@justmail.de> writes:
You want to integrate SAP? No problem with Java with original drivers
from SAP. In Lisp.. you would have to write them yourself.


I think there's a bootstrapping problem here: Such interfaces
(don't know about SAP, but we're interfacing to a number of weird
protocols where I work) are easy to write in lisp, so every active
lisper who needs it writes his own and doesn't think of sharing
his little hack, so the next lisper writes it himself too... and
so on.
--
(espen)
Jul 17 '05 #57
Hello!

Joe Marshall <pr***********@ comcast.net> wrote:
[...]
GC is also potentially a lot faster for side-effect-free code.

Yes! Thanks for mentioning that. The `write-barrier' for
generational GC does not need to apply to newly allocated storage, and
ephemeral garbage costs practically nothing.


Of course, if you add non-strictness into the mix, you get hidden
side effects again (updating a deferred calculation with its result),
so you need write-barriers or so again.

You still gain the greater ease to reason about some aspects of the
code though.

Kind regards,

Hannah.
Jul 17 '05 #58
Mario S. Mommer <m_******@yahoo .com> wrote in message news:<fz******* *****@germany.i gpm.rwth-aachen.de>...
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).


You were right. We were using Scheme back then ;-). Thanks for the
answers. Usually ppl just start to flame you and your question remain
unanswered. Okay then, maybe I have a look at Lisp again.

Regards, Oliver
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.

Jul 17 '05 #59


Oliver Plohmann wrote:
You were right. We were using Scheme back then ;-). Thanks for the
answers. Usually ppl just start to flame you and your question remain
unanswered. Okay then, maybe I have a look at Lisp again.
Hang on, what happened to?:
It makes probably more sense to compare
Lisp and Smalltalk - they are more alike and both almost dead.


Why look at a near-dead language?

confusedly, 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 #60

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.