473,839 Members | 1,460 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 8103
> 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.toUpp erCase 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\uDC 00".
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.)
Jul 17 '05 #41
> 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?
Jul 17 '05 #42
> From: Jan Gregor <gr********@NOS PAMquick.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?
Jul 17 '05 #43
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 = "GenuineInt el" Id = 0x544 Stepping = 4
Features=0x8001 bf<FPU,VME,DE,P SE,TSC,MSR,MCE, CX8,MMX>
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
Jul 17 '05 #44
Alan Crowe <al**@cawtech.f reeserve.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.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Jul 17 '05 #45
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********@Yaho oGroups.Com wrote in message news:<RE******* ********@Yahoo. Com>...
From: Jan Gregor <gr********@NOS PAMquick.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?

Jul 17 '05 #46
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>
Jul 17 '05 #47
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 #36rJesusColleg eCambridge)
Jul 17 '05 #48
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
Jul 17 '05 #49

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.
Jul 17 '05 #50

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.