CL missing some modernisms...
David Bakhash
I've lately been programming a lot in Java, as Java makes provisions
for many of the development needs I'm encountering, such as internet
friendlyness, distributed computing, and object serialization. I want
to ask questions about CL, just to see if there are people out there
that can verify if CL is really antiquated or not.
1. Java has object serialization; Lisp doesn't (always)
Lisp has the ability to "serialize" certain types of objects
for which it has a print method that works well enough so that
(read) will read the object back. This applies, of course, to
strings, lists, integers, but not to hash-tables, CLOS
objects, etc.
Now, for what it's worth, there is a package out there
(`save-object') which provides methods for writing all sorts
of objects to a file so that they can be read again, using the
standard Lisp `read' function. This is cool, but it's a very
heinus piece of code, and it doesn't do what you want it to
efficiently for many types, such as hash-table.
Another thing that's wierd about Lisp is that it's so big.
Would it have been so bad if they had something like an
`import' keyword, and somehow used the package system to
simplify code, and to make adding functionality to CL simpler?
In other words, you don't usually see platform-independent
libraries to Lisp, that are part of the Lisp specification.
What I'm trying to say is that if the Lisp community wanted to
make simple sockets part of the standard, then it might be
nice to make a lisp.net package for that stuff to go into.
2. multi-threading
The way Lisp is now, there's no platform-independent way to do
threads. I feel that this should be standardized, and in a
way that is analogous to Java.
Instead of naming off more and more, I wish that Lisp were redesigned
so that it kept all the nice things it has, like first-class
functions, but also incorporated some of the Java paradigms, and maybe
even compiled down to Java VM bytecode. It is still a better language
syntactically than any other one I've ever used, but that's just my
opinion.
Instead of starting a huge Lisp vs. Java thread here, I would much
rather that someone simply answer my questions about feasibility, if
CL can really grow to meet these needs, and what it will take.
dave
Tim Bradshaw
> 1. Java has object serialization; Lisp doesn't (always)
>
This leads me to ask a question about Java, and I suspect I might get
a better answer here than in a Java newsgroup (this is perhaps the
best property of comp.lang.lisp!)
Say, in Java, you hace two objects whose slots point into a large set
of structures which share some parts. If you serialise those objects
& then unserialise them in another implementation, is that sharing
preserved?
I guess this really means `is object identity preserved by
serialising'? If it is, can anyone tell me *how* it is? It seems to
me that the only general way to do this is to keep a permanent
unique-ID for every object, although perhaps I'm being naive.
--tim
Daniel R Barlow
>I guess this really means `is object identity preserved by
>serialising'? If it is, can anyone tell me *how* it is? It seems to
>me that the only general way to do this is to keep a permanent
>unique-ID for every object, although perhaps I'm being naive.
If your objects contain open files or network sockets even that's not
sufficient. Suddenly you're into hairy issues of "what does object identity
actually _mean_?"
Somehow I suspect it doesn't try.
-dan
Marco Antoniotti
David Bakhash <ca...@bu.edu> writes:
> hey,
>
> I've lately been programming a lot in Java, as Java makes provisions
> for many of the development needs I'm encountering, such as internet
> friendlyness, distributed computing, and object serialization. I want
> to ask questions about CL, just to see if there are people out there
> that can verify if CL is really antiquated or not.
I believe the problem is different. Java developers had the luxury of
including in the language standard, things that had been floating
around CL for a long time.
>
> 1. Java has object serialization; Lisp doesn't (always)
>
> Lisp has the ability to "serialize" certain types of objects
> for which it has a print method that works well enough so that
> (read) will read the object back. This applies, of course, to
> strings, lists, integers, but not to hash-tables, CLOS
> objects, etc.
>
> Now, for what it's worth, there is a package out there
> (`save-object') which provides methods for writing all sorts
> of objects to a file so that they can be read again, using the
> standard Lisp `read' function. This is cool, but it's a very
> heinus piece of code, and it doesn't do what you want it to
> efficiently for many types, such as hash-table.
So the problem is not that CL does not have "serialization". It is
that there is no "standard" and "fully specified way" to do it.
> Another thing that's wierd about Lisp is that it's so big.
> Would it have been so bad if they had something like an
> `import' keyword, and somehow used the package system to
> simplify code, and to make adding functionality to CL simpler?
> In other words, you don't usually see platform-independent
> libraries to Lisp, that are part of the Lisp specification.
>
> What I'm trying to say is that if the Lisp community wanted to
> make simple sockets part of the standard, then it might be
> nice to make a lisp.net package for that stuff to go into.
Fine. Let's define the "CL.NET" package (I am serious about the
name). I.e. let's define what goes in there and what should not. First
let's write a proposal, and then let's have a "reference"
implementation. (BTW. when I write "let's" I mean: "go ahead and
write it - I have not that much time" :) )
...other stuff skipped,
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Kent M Pitman
> > Now, for what it's worth, there is a package out there
> > (`save-object') which provides methods for writing all sorts
> > of objects to a file so that they can be read again, using the
> > standard Lisp `read' function. This is cool, but it's a very
> > heinus piece of code, and it doesn't do what you want it to
> > efficiently for many types, such as hash-table.
>
> So the problem is not that CL does not have "serialization". It is
> that there is no "standard" and "fully specified way" to do it.
PRINT-OBJECT
MAKE-LOAD-FORM
Or am I misunderstanding?
CL also has readtables and *print-readably* which I bet is a concept
foreign to Java.
I think what CL missed and what Java got right was that Java just goes
ahead and claims things it doesn't have, while the Lisp community is
honest about the complexity of reality. Just look at Java's "security"
and ask yourself how they could have taken a very limited reading of a
word like that and applied such a unqualified term to it. Now, if they'd
said "type security", I might not think so dimly of them. But when they
remove any hint of qualifying adjective, I have to ask myself why a "secure"
language can have a way to turn itself off in the security tab of a browser.
If Lisp just said it had serialization and didn't fuss over messy little
details like object identity or like intentional vs representational types,
it would be fine. But because we say we only solve the problems that are
easily solvable and that we held back on the harder problems, leaving them
for users to solve with the help of domain knowledge that make the
problems more tractable, we get in trouble.
Marco Antoniotti
Kent M Pitman <pit...@world.std.com> writes:
> Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
>
> > > Now, for what it's worth, there is a package out there
> > > (`save-object') which provides methods for writing all sorts
> > > of objects to a file so that they can be read again, using the
> > > standard Lisp `read' function. This is cool, but it's a very
> > > heinus piece of code, and it doesn't do what you want it to
> > > efficiently for many types, such as hash-table.
> >
> > So the problem is not that CL does not have "serialization". It is
> > that there is no "standard" and "fully specified way" to do it.
>
> PRINT-OBJECT
>
> MAKE-LOAD-FORM
>
> Or am I misunderstanding?
As usual, you are right and that this is all you really need. What
happens in Java is that the functionality is *packaged* much better.
> CL also has readtables and *print-readably* which I bet is a concept
> foreign to Java.
All right. Java (at least in my little world :) ) now has pretty print
streams as well. Guess where I copied the code from :) Write me in
private if you want the package.
Tim Bradshaw
>
> I think what CL missed and what Java got right was that Java just goes
> ahead and claims things it doesn't have, while the Lisp community is
> honest about the complexity of reality. Just look at Java's "security"
> and ask yourself how they could have taken a very limited reading of a
> word like that and applied such a unqualified term to it. Now, if they'd
> said "type security", I might not think so dimly of them. But when they
> remove any hint of qualifying adjective, I have to ask myself why a "secure"
> language can have a way to turn itself off in the security tab of a browser.
This is what I was trying to get at -- I bet that java does not deal
with object identity when serialising, so serialising is really useful
only for rather simple data structures. This is rather similar to the
`copy constructor' thing that C++ has. It's fairly obvious that
a default copy constructor is really almost never useful, because the notion
of `a copy' of an object is very dependent on what the object is, and all
interesting cases you need to just write a copy function which depends on
intimate details of the object.
So Lisp is honest and says it doesn't have feature x because feature x is
either very very hard to do right (serialising), or not actually a useful
feature at all. But language comparisons are made on feature count, not
on these subtle arguments, and the languages which have lots of features
are winning *even though those features are useless*.
What makes it doubly bizarre is that Lisp *does* deal with object identity
when serialising in the cases where there is a clear way to do it. Does
Java do even that much?
--tim
Erik Naggum
| But language comparisons are made on feature count, not on these subtle
| arguments, and the languages which have lots of features are winning
| *even though those features are useless*.
so true. this is why I don't want Common Lisp to win those comparisons,
and _prefer_ it to be dropped by people who choose the winners in them.
these people do, however, need something to "come back to" when they
discover that they have been misled, and if Common Lisp caters to the
popular vote, the chances are it will no longer have that quality.
it is sufficient that people continue to discover Common Lisp, the same
way it is sufficient that people discover classical music and even opera,
without adding techno beats and rapping the libretto. so what if young
people don't get it? most of us don't die at age 20, Madison Avenue and
Hollywood to the contrary notwithstanding.
"tired of useless and buggy features in the latest fad language yet?
discover Common Lisp -- it has all you'll ever need, and no more."
(and in the true spirit of marketing, let's make that true before they
come running. :)
#:Erik
Alain Picard
David> Now, for what it's worth, there is a package out there
David> (`save-object') which provides methods for writing all sorts
David> of objects to a file so that they can be read again, using the
David> standard Lisp `read' function. This is cool, but it's a very
David> heinus piece of code, and it doesn't do what you want it to
David> efficiently for many types, such as hash-table.
Inefficient or not, I wouldn't mind using it, but it seems broken
in CMU CL 18b. Does anyone have a later version of save-object,
or a patch? Thanks.
--ap
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
John Wiseman
> This leads me to ask a question about Java, and I suspect I might
> get a better answer here than in a Java newsgroup (this is perhaps
> the best property of comp.lang.lisp!)
>
> Say, in Java, you hace two objects whose slots point into a large
> set of structures which share some parts. If you serialise those
> objects & then unserialise them in another implementation, is that
> sharing preserved?
Yes. From the Java serialization specification:
The writeObject method (see Section 2.3, "The writeObject Method")
serializes the specified object and traverses its references to
other objects in the object graph recursively to create a complete
serialized representation of the graph. Within a stream, the first
reference to any object results in the object being serialized or
externalized and the assignment of a handle for that
object. Subsequent references to that object are encoded as the
handle. Using object handles preserves sharing and circular
references that occur naturally in object graphs. Subsequent
references to an object use only the handle allowing a very
compact representation.
Reading serialized objects recreates the object graph.
I don't know enough about the subject to know whether Java handles the
boundary cases and other hard stuff correctly, but the approach seems
generally sound.
> I guess this really means `is object identity preserved by
> serialising'? If it is, can anyone tell me *how* it is? It seems
> to me that the only general way to do this is to keep a permanent
> unique-ID for every object, although perhaps I'm being naive.
I think this is a different question. Java's spec says that if I
write out a structure that looks like (and I love that I have a
standardized Lisp way of writing this, so just imagine Java analogs):
(1 #1=(2 3 4) #1#)
when I read it in I'll get a structure that looks like
(1 #1=(2 3 4) #1#)
Now you're asking whether if the original structure will be EQ to the
structure I serialized in. Or whether, if I call Java's readObject 5
times on the same thing, I'll get 5 things that are all EQ.
No.
Now that would be hard.
[
Just for fun, if Java serialization were supposed to act that way,
what would be the result of evaluating (the Java analog) of the
following:
(let ((x '(2 3 4)))
(let ((structure (list 1 x x)))
(write-object object-stream x)
(setf (car x) 2)
(reset-stream-position object-stream)
(eq x (read-object))))
I don't think you want to even try to make that return T...
]
This is how the default serialization works. Customizing
serialization might let you do something totally different, I don't
know enough to say.
John Wiseman
P.S. The Java serialization specification is at
<http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/serial-arch.doc.html>.
Tim Bradshaw
>
> The writeObject method (see Section 2.3, "The writeObject Method")
> serializes the specified object and traverses its references to
> other objects in the object graph recursively to create a complete
> serialized representation of the graph. Within a stream, the first
> reference to any object results in the object being serialized or
> externalized and the assignment of a handle for that
> object. Subsequent references to that object are encoded as the
> handle. Using object handles preserves sharing and circular
> references that occur naturally in object graphs. Subsequent
> references to an object use only the handle allowing a very
> compact representation.
>
Can this be taken to imply that if I serialise 2 objects which share
parts then that sharing is preserved? (Assuming I do so in the same
stream, I suppose). That's impressive if so.
(sorry, I could read the spec, but my java is poor enough that it wouldn't
help me that much!)
--tim
Tim Bradshaw
> Can this be taken to imply that if I serialise 2 objects which share
> parts then that sharing is preserved? (Assuming I do so in the same
> stream, I suppose). That's impressive if so.
>
I just realised this morning what this means -- a stream that is used
for serialising has to keep track of every non-trivial object it's
ever seen (where, I think, `non-trivial' means `EQL is the same as EQ'
for it (it's not just non-immediate because bignums need to not be
kept track of)), so these streams grow like crazy. And even that's
not enough, because there are mutable objects in Java, so it can't
actually work right at all. I guess I'm asking too much of
serialising (really I'm asking it to be a non-cache-coherent shared
memory). I should read the java stuff to see what is actually offered.
--tim
John Wiseman
> > Can this be taken to imply that if I serialise 2 objects which share
> > parts then that sharing is preserved? (Assuming I do so in the same
> > stream, I suppose). That's impressive if so.
> >
>
> I just realised this morning what this means -- a stream that is used
> for serialising has to keep track of every non-trivial object it's
> ever seen (where, I think, `non-trivial' means `EQL is the same as EQ'
> for it (it's not just non-immediate because bignums need to not be
> kept track of)), so these streams grow like crazy.
Yes, sharing is preserved and this is basically how it works. Once
created, an ObjectOutputStream pretty much keeps track of all objects
written to it.
It doesn't really have to grow like crazy (and it can certainly end up
being more compact when you have lots of shared structure), and it's
not a far-out technique. The basic idea seems to be less fancy than
Common Lisp's output algorithm when *print-circle* is T. Apple's 3D
meta file (3DMF) format can do the same sort of thing.
> And even that's not enough, because there are mutable objects in
> Java, so it can't actually work right at all.
This Java doesn't even try to handle. If you call writeObject on an
object A, change the object, then call writeObject on the same object
with the same stream, You'll get a stream that contains the following:
<object A>
<pointer to object A>
where <object A> is a serialized representation of the object before
it was modified.
John
Martin Cracauer
>1. Java has object serialization; Lisp doesn't (always)
If I'm not mistaken, what Java has is a *standard* *interface* classes
must implement to be serializable. There is no "automatic"
serialization of your classes unless you add the support by hand. Of
course, it is extremely useful to standardizese the object's interface
the serializer will use.
But when it comes to automatically support serialization for your
code, Lisp is even ahead, due to Java's primitive lowlevel /
user-defineable type seperation.
>2. multi-threading
> The way Lisp is now, there's no platform-independent way to do
> threads. I feel that this should be standardized, and in a
> way that is analogous to Java.
A major part of the differences between the concurrency interfaces in
commercial Common Lisp is due to it's quite differnt implementations
and given strengths, especially when it comes to synchronization.
If you want to write portable code, you could take one the available
implementations of a Common API:
- The one from ILU (free) ftp://parcftp.xerox.com/pub/ilu/
- The one from CLIM, which is shipped with CLIM, but wrappers from
commercial interfaces to the CLIM subset should come for free.
The free CL's that implement concurrency mostly implement the CLIM
interface, like CMUCL and Clisp (but not ECL), so it's not really the
fault of the Lisp community but just the companies not getting
together, driving people to use the free alternatives.
I have an overview of Lisp thread interfaces at
http://www.cons.org/cracauer/lisp-threads.html
>Instead of naming off more and more, I wish that Lisp were redesigned
>so that it kept all the nice things it has, like first-class
>functions, but also incorporated some of the Java paradigms, and maybe
>even compiled down to Java VM bytecode.
I'm afraid I'm convinced the whole Bytecode things is complete
nonsense except for Web applications.
The problems the bytecode approach of Java tried to solve are really
to be attacked by standard APIs and descent crosscompiling support,
such as CMUCL has or like gcc works on the free UNIX systems. Ever
installed ports/devel/linux_devel on FreeBSD?
Instead, bytecodes bring you either bad performance and/or slow
startup due to JIT compilation and serious bugs in compilers due to
their pressure to compile fast code fast. Doing both is seriously more
complicated than just compiling fact code *or* doing fast
compiles. Read the factorization example from Microsoft's compiler?
Ever tried to use javac (the one from the JDK) with a JIT? Ever
wondered by the free software explosion we see mostly doesn't even
mention Java?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a semi-reliable operating system, eh?
arthurg...@my-dejanews.com
crac...@bik-gmbh.de (Martin Cracauer) wrote:
> David Bakhash <ca...@bu.edu> writes:
>
> >1. Java has object serialization; Lisp doesn't (always)
>
> If I'm not mistaken, what Java has is a *standard* *interface* classes
> must implement to be serializable. There is no "automatic"
> serialization of your classes unless you add the support by hand. Of
> course, it is extremely useful to standardizese the object's interface
> the serializer will use.
Actually, this isn't true. Java supports automatic serialization of your
classes, but allows you to override the standard serialization for any class
you define.
I once wrote a program that, given a set of Java class files, automatically
wrote C++ code to serialize and deserialize Java objects of those classes.
The generated code was used for communication between a client-side program
written in C++ and an existing Java server that already used Java Object
Serialization to communicate with another client, which had been written in
Java. The fact that Java classes handled serialization automatically made
this all quite easy. (Of course, the code generator was written in Lisp.)
> But when it comes to automatically support serialization for your
> code, Lisp is even ahead, due to Java's primitive lowlevel /
> user-defineable type seperation.
I agree wholeheartedly. Years ago, we gave MIT Scheme the ability to do
FASDUMP to any I/O port. This made communicating via the network quite easy,
since any type of object (except a code object, unfortunately) could be sent
without any special declarations or other code. Even fixnums could be sent
without a problem.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Christopher R. Barry
> I'm afraid I'm convinced the whole Bytecode things is complete
> nonsense except for Web applications.
While I find the Java bytecode technology far from satisfactory,
having an architecture neutral intermediary language between the
source and machine code that can be dynamically compiled is very
useful.
With the traditional approach of compiling to machine code for each
target, which means possibly obtaining at a great expense either an
architecture/OS/compiler combo or at the very least a cross-compiler
if it exists and functions reliably, you must also perform seperate
compiles for that target if you want to use an extension found in some
representatives of that architecture like MMX or optimize for a
specific processor of that architecture such as the PII.
Dynamic compilation will be vital to decent performance with future
generations of future processors such as the Merced which no longer
schedule instructions to execute in parallel in hardware but instead
have the compiler do it at compile time, hardcoding what previously
could be done by the processor transparently at runtime, so that your
binaries are tied closer to the specific processor than ever before.
Kind of like how processors like the P6 broke a lot of older Pascal
and other similarely compiled programs compiled by not-too-perfect
compilers with errors like "runtime error 200", so will these types of
problems be extremely difficult to avoid with processors such as the
Merced, without causing a negative performance impact by not so
aggresively assuming that certain latencies will always be for so many
clock-ticks among other issues....
Also, more and more now PC vendors are shipping bandwidth-starved
450-500MHz Pentium II/III processor based computers with the same old
crappy IDE disk drives so loading a small applet-like code packet from
the disk and then dynamically compiling it to a much larger machine
binary-image can even be faster than just loading the binary-image, or
at the worst negligibly slower.
The major problem with the Java bytecode is that it hides too much
information from the JIT. It and others like it are abstractions of
machines. It is better to use abstractions of programs, or of
programming languages, so that vital information needed for performing
optimizations is maintained.
There are at least two architecture-neutral distribution technologies
that already exist and are superior to Java's model. They are
TenDRA/ANDF (only implemented for Unixes for now)
<http://alph.dra.hmg.gb/TenDRA/>
and Juice (only for the Oberon language right now)
<http://caesar.ics.uci.edu/juice/index.html>
The best place to get started for information on this type of thing is
<http://www.ics.uci.edu/~franz/>
At the last link you can find Dr. Franz's doctoral dissertation on
SDE, the most promising of the current dynamic compilation
technologies, though there is no free implementation of it.
At any rate, there's no reason why the JVM can't radically improve in
the future. JDK 1.2 bytecode doesn't need to run on 1.0 JVMs, and
indeed it doesn't, so in the future the JVM and the bytecode could be
far, far superior, since backwards-compatibility isn't an issue.
> The problems the bytecode approach of Java tried to solve are really
> to be attacked by standard APIs and descent crosscompiling support,
> such as CMUCL has or like gcc works on the free UNIX systems. Ever
> installed ports/devel/linux_devel on FreeBSD?
No. And most commercial companies that are supporting Linux versions
of their software are not doing BSD versions, such as Allegro, Oracle,
SAP, etc....
> Instead, bytecodes bring you either bad performance and/or slow
> startup due to JIT compilation and serious bugs in compilers due to
> their pressure to compile fast code fast.
It can only get better, and caching a JIT's output for future loads is
not an infeasible concept. Some architecture-neutral distribution
models do the "caching" only once.
> Ever tried to use javac (the one from the JDK) with a JIT?
Yes, the TYA JIT. I had to hack the TYA source to get rid of those
retarded messages it displays though.
> Ever wondered why the free software explosion we see mostly doesn't
> even mention Java?
Huh? In a well-publicized move, IBM open sourced their Jikes Java
compiler. The real problem is that instead of working together there
are 20 different free software Java projects and none of them have
produced an implementation of the quality of the blackdown.org port of
Sun's JDK (AWT/Swing/GUI stuff was horribly broken for all other
implementations last I checked). And Sun's JDK is supposed to be the
crappiest Java platform for Windows.
The GCJ front-end to EGCS will be real nice once it's ready for
primetime.
Christopher