From: ··········@YahooGroups.Com
Subject: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may03-001@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.
> 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.
"John Harlow" <··········@hotmail.com> wrote in message
···························@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.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may19-001@Yahoo.Com>
> From: "John Harlow" <··········@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?
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!
On Mon, May 03, 2004 at 05:49:03PM -0500, Ryan J. Bovorasmy wrote:
> ;;lisp
> (car (cdr foo))
(first (rest foo)) ;; read: first of the rest of foo
or why not
(let ((var (rest foo)))
(first var))
or even
(prog (var)
(setq var (rest foo))
(return (first var)))
> // C++ (assume I've made a linked list with push & pop type methods)
> var = llist.rest();
> return var.first();
P.S. Have you been using Lisp in a Box, then, or did you set it up
yourself?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
On Mon, 03 May 2004 19:52:13 -0400, Matthew Danish wrote:
> On Mon, May 03, 2004 at 05:49:03PM -0500, Ryan J. Bovorasmy wrote:
>> ;;lisp
>> (car (cdr foo))
>
> (first (rest foo)) ;; read: first of the rest of foo
>
> or why not
>
> (let ((var (rest foo)))
> (first var))
>
> or even
>
> (prog (var)
> (setq var (rest foo))
> (return (first var)))
Oh, yeah I know there's better/different ways to do it, it's
just that as a beginner, writing some of the more complex functions
seemed difficult. I got over it though.
>
>> // C++ (assume I've made a linked list with push & pop type methods)
>> var = llist.rest();
>> return var.first();
>
> P.S. Have you been using Lisp in a Box, then, or did you set it up
> yourself?
I use a computer provided by my school that deul boots with
Windows and Linux. I ended up setting up the lisp environment
in linux with Emacs, SLIME, Clisp and sdcl, using interactive elisp
functions to switch between Clisp and sdcl. The main reason I did
that is because I don't really know much about the implementations,
so I figured having two could prove to be useful. Trying to set up
the environment in windows proved to be difficult for me though, and
I ended up downloading some limited shareware product. I'll give
you're "lisp in a box" a try though.
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
On Mon, 03 May 2004 19:24:14 -0500, Ryan J. Bovorasmy wrote:
> *snip*
>
> Like I said though, I don't really see any signifigant reason why
> Java *beats* lisp, [...]
The only significant reason, for me, is the libraries. Huge
libraries, in fact. But that's not enough reason to say that Java beats
Lisp in any meaningful way.
> [...]
> "It's easier to write Java programs in Java."
> [...]
Not anymore. Try Linj.
Welcome to comp.lang.lisp.
Antonio Leitao
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may17-002@Yahoo.Com>
> From: Antonio Menezes Leitao <··············@evaluator.pt>
> The only significant reason, for me, is the libraries. Huge
> libraries, in fact.
Are you referring to the Java API which is all nicely documented
(module a few obvious mis-statements such as the one I found whereby it
claims the arcsin etc. functions take an angle as an argument) on the
WebSite? Or third-party libraries which can be difficult to find and
even more difficult to get a license to use?
But in any case, are these libraries for tasks that people typically
want to use, or for relatively obscure things you'd hardly ever want to
use unless you are writing an application specifically for some kind of
task that's already been done? Which of these libraries, specifically,
go far beyond what Common LISP already provides plus what any random CL
programmer can add in a few minutes time, to where the availability of
the library would more than compensate for the greater difficulty
developing software in Java compared to CL?
> > "It's easier to write Java programs in Java."
> Not anymore. Try Linj.
Well that's a third-party add-on, not the mainstream Java or CL API.
Also it's still under development, not yet ANSI-standardized nor even
close, so depending on it for a major commercial software project is
likely to be a mistake. The debate here is between two nice stable
programming languages not likely to grossly change out from under the
programmer-team during the course of a software project.
Still, it's interesting and I might try it myself someday. How
difficult is it to download to FreeBSD Unix, and how much disk space
does it take in total after installation (keeping original files around
in case need to re-install)? I have only 20 megabytes unused on my
personal account currently, and I will need most of that myself.
On Mon, 17 May 2004 00:32:18 -0700, RobertMaas wrote:
>> From: Antonio Menezes Leitao <··············@evaluator.pt>
>> The only significant reason, for me, is the libraries. Huge
>> libraries, in fact.
>
> Are you referring to the Java API which is all nicely documented
> (module a few obvious mis-statements such as the one I found whereby it
> claims the arcsin etc. functions take an angle as an argument) on the
> WebSite? Or third-party libraries which can be difficult to find and
> even more difficult to get a license to use?
Both, actually. BTW, which third-party libraries are you talking about?
> But in any case, are these libraries for tasks that people typically
> want to use, or for relatively obscure things you'd hardly ever want to
> use unless you are writing an application specifically for some kind of
> task that's already been done?
On another post, I said:
When I need to use something that I know someone has already done, I
just google for 'Java' and 'something'. I always find a jar that solves
the problem and that I can explore in Linj. OTOH, if I need to invent
something that (probably) no one has invented before, then I develop it
in Common Lisp and latter, if need arises, I add some type declarations
and make it run in Linj.
As you can see, I understand your point and I made it myself earlier.
> Which of these libraries, specifically,
> go far beyond what Common LISP already provides plus what any random CL
> programmer can add in a few minutes time, to where the availability of
> the library would more than compensate for the greater difficulty
> developing software in Java compared to CL?
I think we are talking about different concepts of "library".
Let me give a few short examples:
- I had to read a Microsoft Excel file describing the layout of forms
(using colored cells) and relevant information for the fields in the
form. Using the Jakarta POI the task was easy. And the license
seems fine, IMHO. How much time would I need to implement similar
functionality in Common Lisp?
- To write code for cell phones you will probably need the MIDP
libraries which are available for Java but not for Common Lisp. The
resulting code must also run on the JVM. These are requirements that
can't be solved in Common Lisp in a few minutes time.
- If you need to process scalable vector image files, you can
choose between several libraries in Java (with all sorts of licenses). I
couldn't google one for Common Lisp.
The list could go on. But that's not the point. Let me repeat
something I also said earlier in another post:
Anyway, when we don't have access to Java libraries (and we don't need
neither applets, nor "write once, run (debug?) everywhere", nor the
security model, nor the remaining few qualities of Java), Common Lisp is
a much better choice.
I hope this clarifies my position regarding Java and Common Lisp.
>> > "It's easier to write Java programs in Java."
>> Not anymore. Try Linj.
>
> Well that's a third-party add-on, not the mainstream Java or CL API.
> Also it's still under development, not yet ANSI-standardized nor even
> close, so depending on it for a major commercial software project is
> likely to be a mistake.
I think you are taking the wrong view of Linj. Linj will never be
ANSI-standardized. What's the purpose of standardazing something that
wants to be as similar to ANSI Common Lisp as possible?
I've been using Linj for commercial software in the last few years and my
only mistake was not using it earlier. Yes, Linj has bugs. But so has
any Common Lisp implementation you use. Yes, Linj is under
active development. So is Java.
Anyway, it is possible to drop Linj at any time and continue the
development with the Java sources files produced by the Linj compiler.
You can even develop part in Linj and part in Java.
> The debate here is between two nice stable programming languages not
> likely to grossly change out from under the programmer-team during the
> course of a software project.
Java has been changing from the beginning. I know that the changes are
mostly backward compatible but I would hardly considered the language as
"stable" (and much less as "nice"). Have you tried to run Java 1.2 on
older browsers?
> Still, it's interesting and I might try it myself someday. How difficult
> is it to download to FreeBSD Unix, and how much disk space does it take
> in total after installation (keeping original files around in case need
> to re-install)? I have only 20 megabytes unused on my personal account
> currently, and I will need most of that myself.
Linj isn't available for FreeBSD yet. Linj's size is expected to increase
in the next version (to include the extended loop macro) but your request
can be fulfilled in less than 5 megabytes, including the runtime sources
(in .linj, .java and .class versions).
Antonio Leitao.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun20-003@Yahoo.Com>
> From: Antonio Menezes Leitao <··············@evaluator.pt>
> > Are you referring to the Java API which is all nicely documented
> > (module a few obvious mis-statements such as the one I found whereby it
> > claims the arcsin etc. functions take an angle as an argument) on the
> > WebSite? Or third-party libraries which can be difficult to find and
> > even more difficult to get a license to use?
> Both, actually. BTW, which third-party libraries are you talking about?
Any that I am unable to find out about. In my search for Java libraries
for a browser/spider to handle cookies for HTTP sessions, all I could
find was Jakarta, a third-party library, nothing in standard libraries,
and the documentation for Jakarta indicated there are three ways
cookies are done and you have to just try different ways to see which
way a particular server is using, so it's a pain even with Jakarta to
write any software to handle cookies the server throws at you.
I looked for interval arithmetic, but can't find what I want.
> Java has been changing from the beginning. I know that the changes are
> mostly backward compatible but I would hardly considered the language as
> "stable" (and much less as "nice").
Hmm. Does the jvm suddenly change out from under the user, causing old
already-compiled code to suddenly stop working? Or is the jvm fine but
the system library no longer supports the method you have been using,
or the method no longer does exactly what it used to do? Or is it just
that if you try to re-compile the old code that compiled fine before,
it might no longer compile because some basic syntax it used has been
depricated and expunged from the compiler? Or just that there's new
stuff you haven't been using and you feel bad that your old program
still does things the old way instead of taking advantage of new
features?
> Have you tried to run Java 1.2 on older browsers?
I don't know what that question means. I run java on a computer, not on
a browser. Please clarify the question.
By the way, is there any way to ask javac or java what version it is,
or to otherwise learn that information on a given system? On Unix, I
can use the whereis command, which on this FreeBSD Unix shell account
I'm using gives the directory as /usr/local/jdk1.2.2/bin/ so does that
mean we have version 1.2.2 installed here? But there's no way to run a
java-applet-enabled browser here (via VT100 dialup) as far as I know,
so that info probably isn't usefully related to your question. But on
campus where I'm taking a java class, they have jcreator on MicroSoft
Windows 2000 Professional, or somesuch. Is there a way on that system
to learn what version of java is installed?
> Linj isn't available for FreeBSD yet.
Sigh. (Both java and CL are platform independent, so I wonder why Linj
can't be ported easily here?)
From: Antonio Menezes Leitao
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <87u0x5c0gk.fsf@evaluator.pt>
··········@YahooGroups.Com writes:
>> From: Antonio Menezes Leitao <··············@evaluator.pt>
>> > Are you referring to the Java API which is all nicely documented
>> > (module a few obvious mis-statements such as the one I found whereby it
>> > claims the arcsin etc. functions take an angle as an argument) on the
>> > WebSite? Or third-party libraries which can be difficult to find and
>> > even more difficult to get a license to use?
>> Both, actually. BTW, which third-party libraries are you talking about?
>
> Any that I am unable to find out about. In my search for Java libraries
> for a browser/spider to handle cookies for HTTP sessions, all I could
> find was Jakarta, a third-party library, nothing in standard libraries,
> and the documentation for Jakarta indicated there are three ways
> cookies are done and you have to just try different ways to see which
> way a particular server is using, so it's a pain even with Jakarta to
> write any software to handle cookies the server throws at you.
>
> I looked for interval arithmetic, but can't find what I want.
My experience is that there are many more alternatives in the Java
camp than in the Lisp camp. Some of the alternatives are crap, of
course, but the probability of finding something that suits your needs
is, IMHO, higher in the Java camp.
>> Java has been changing from the beginning. I know that the changes are
>> mostly backward compatible but I would hardly considered the language as
>> "stable" (and much less as "nice").
>
> Hmm. Does the jvm suddenly change out from under the user, causing old
> already-compiled code to suddenly stop working? Or is the jvm fine but
> the system library no longer supports the method you have been using,
> or the method no longer does exactly what it used to do? Or is it just
> that if you try to re-compile the old code that compiled fine before,
> it might no longer compile because some basic syntax it used has been
> depricated and expunged from the compiler? Or just that there's new
> stuff you haven't been using and you feel bad that your old program
> still does things the old way instead of taking advantage of new
> features?
My claim was related to the language stability. The syntax is
changing and new language constructs are still being added.
>> Have you tried to run Java 1.2 on older browsers?
>
> I don't know what that question means. I run java on a computer, not on
> a browser. Please clarify the question.
Applets are Java programs intended to run on the browser. Obviously,
the browser must contain a JVM. The problem is that you cannot use
certain language features because older implementations of the JVM
do not implement those features.
> By the way, is there any way to ask javac or java what version it is,
> or to otherwise learn that information on a given system? On Unix, I
> can use the whereis command, which on this FreeBSD Unix shell account
> I'm using gives the directory as /usr/local/jdk1.2.2/bin/ so does that
> mean we have version 1.2.2 installed here?
java -version
> But there's no way to run a java-applet-enabled browser here (via
> VT100 dialup) as far as I know, so that info probably isn't usefully
> related to your question. But on campus where I'm taking a java
> class, they have jcreator on MicroSoft Windows 2000 Professional, or
> somesuch. Is there a way on that system to learn what version of
> java is installed?
I don't know: I'm using linux.
>> Linj isn't available for FreeBSD yet.
>
> Sigh. (Both java and CL are platform independent, so I wonder why Linj
> can't be ported easily here?)
Because I didn't found the time yet to install a FreeBSD system.
Best regards,
Ant�nio Leit�o.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun26-001@Yahoo.Com>
> From: Antonio Menezes Leitao <··············@evaluator.pt>
> > I looked for interval arithmetic, but can't find what I want.
> My experience is that there are many more alternatives in the Java
> camp than in the Lisp camp. Some of the alternatives are crap, of
> course, but the probability of finding something that suits your needs
> is, IMHO, higher in the Java camp.
So how should I go about searching for something, for example interval
arithmetic, with high probability of actually finding something
suitable?
> The syntax is changing and new language constructs are still being
> added.
So new source code might not compile under old compiler because it
happens to use some new syntax? Would any old syntax cease to work
under new compiler?
> >> Have you tried to run Java 1.2 on older browsers?
> > I don't know what that question means. I run java on a computer, not on
> > a browser. Please clarify the question.
> Applets are Java programs intended to run on the browser. Obviously,
> the browser must contain a JVM. The problem is that you cannot use
> certain language features because older implementations of the JVM
> do not implement those features.
So what you really mean to ask was:
Have you tried to run Applets that use new language features, in
browsers that have old versions of the jvm?
No. The only Java-capable browser I've ever used for running an Applet
is Internet Explorer at DeAnza College, and that seems to be a recent
version of IE that had no trouble running my Applet.
> > On Unix, I
> > can use the whereis command, which on this FreeBSD Unix shell account
> > I'm using gives the directory as /usr/local/jdk1.2.2/bin/ so does that
> > mean we have version 1.2.2 installed here?
> java -version
java version "1.2.2"
Classic VM (build jdk1.2.2-FreeBSD:root:2000/11/25-02:08, green threads, nojit)
Thanks. Indeed what we have here is pretty old! But for my class work,
it seemed to work, except when I tried to run a GUI application here,
whereupon compilation ran just fine but a runtime exception occurred
because it was trying to find an X11 server, which of course doesn't
exist here. Too bad java doesn't support VT100 term the way lynx does
for HTML forms.
public class guiH {
public static void main(String[] args) {
JOptionPane.showMessageDialog(null, "Welcome", "Title",
JOptionPane.INFORMATION_MESSAGE);
System.exit(0);
}
}
Exception in thread "main" java.lang.InternalError: Can't connect to X11 window
server using ':0.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:58)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:124)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:63)
at java.awt.Font.initializeFont(Font.java:262)
at java.awt.Font.<init>(Font.java:292)
at javax.swing.plaf.metal.DefaultMetalTheme.<init>(DefaultMetalTheme.java:59)
at javax.swing.plaf.metal.MetalLookAndFeel.createDefaultTheme(MetalLookAndFeel.java:709)
at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLookAndFeel.java:713)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:363)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:390)
at javax.swing.UIManager.initializeDefaultLAF(UIManager.java:850)
at javax.swing.UIManager.initialize(UIManager.java:926)
at javax.swing.UIManager.maybeInitialize(UIManager.java:948)
at javax.swing.UIManager.getUI(UIManager.java:559)
at javax.swing.JOptionPane.updateUI(JOptionPane.java:1318)
at javax.swing.JOptionPane.<init>(JOptionPane.java:1281)
at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:630)
at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:498)
at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:478)
at guiH.main(guiH.java:4)
Apparently swing doesn't support VT100 term. I'm not trying to do any
actual graphics, just put up some text in a box. Why can't it put up
something like:
/===== Title =======\
| |
| Welcome |
| OK |
\===================/
with OK currently selected just like in lynx?
All these claims about java being platform independent are hooey!
> Because I didn't found the time yet to install a FreeBSD system.
But if java were platform independent, as claimed, you could just
publish the compiled (.class) files and anybody could download them to
FreeBSD Unix and they'd just *work* from the start, right?
From: Antonio Menezes Leitao
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <87k6xuym7h.fsf@evaluator.pt>
··········@YahooGroups.Com writes:
>> From: Antonio Menezes Leitao <··············@evaluator.pt>
>> > I looked for interval arithmetic, but can't find what I want.
>> My experience is that there are many more alternatives in the Java
>> camp than in the Lisp camp. Some of the alternatives are crap, of
>> course, but the probability of finding something that suits your needs
>> is, IMHO, higher in the Java camp.
>
> So how should I go about searching for something, for example interval
> arithmetic, with high probability of actually finding something
> suitable?
You google for it. Type "interval arithmetic java" on google and you
will get several promising links (they look promising to me, at
least), including:
- the Brandeis Interval Arithmetic Constraint Solver (with Java source
code)
- interval.sourceforge.net/interval (a 100% Java, verifiable
implementation of interval arithmetic operations and constraint
contractors for the arithmetic operations and elementary functions
(exp,log,sin,cos,tan,asin,acos,atan,sin2pi,...)
>> The syntax is changing and new language constructs are still being
>> added.
>
> So new source code might not compile under old compiler because it
> happens to use some new syntax? Would any old syntax cease to work
> under new compiler?
You said that Java is a "nice stable language". What is your
definition for "stable language"? Is adding annonymous inner classes a
minor change? Is adding automatic boxing and unboxing a minor change?
Is adding generic types a minor change?
>> >> Have you tried to run Java 1.2 on older browsers?
>> > I don't know what that question means. I run java on a computer, not on
>> > a browser. Please clarify the question.
>> Applets are Java programs intended to run on the browser. Obviously,
>> the browser must contain a JVM. The problem is that you cannot use
>> certain language features because older implementations of the JVM
>> do not implement those features.
>
> So what you really mean to ask was:
> Have you tried to run Applets that use new language features, in
> browsers that have old versions of the jvm?
Yes. I'm sorry I was not clear enough.
> No. The only Java-capable browser I've ever used for running an Applet
> is Internet Explorer at DeAnza College, and that seems to be a recent
> version of IE that had no trouble running my Applet.
>
>> > On Unix, I
>> > can use the whereis command, which on this FreeBSD Unix shell account
>> > I'm using gives the directory as /usr/local/jdk1.2.2/bin/ so does that
>> > mean we have version 1.2.2 installed here?
>> java -version
>
> java version "1.2.2"
> Classic VM (build jdk1.2.2-FreeBSD:root:2000/11/25-02:08, green threads, nojit)
>
> Thanks. Indeed what we have here is pretty old! But for my class work,
> it seemed to work, except when I tried to run a GUI application here,
> whereupon compilation ran just fine but a runtime exception occurred
> because it was trying to find an X11 server, which of course doesn't
> exist here. Too bad java doesn't support VT100 term the way lynx does
> for HTML forms.
> public class guiH {
> public static void main(String[] args) {
> JOptionPane.showMessageDialog(null, "Welcome", "Title",
> JOptionPane.INFORMATION_MESSAGE);
> System.exit(0);
> }
> }
> Exception in thread "main" java.lang.InternalError: Can't connect to X11 window
> server using ':0.0' as the value of the DISPLAY variable.
> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
> ...
> at guiH.main(guiH.java:4)
> Apparently swing doesn't support VT100 term. I'm not trying to do any
> actual graphics, just put up some text in a box. Why can't it put up
> something like:
> /===== Title =======\
> | |
> | Welcome |
> | OK |
> \===================/
> with OK currently selected just like in lynx?
Java never claimed to be VT100-compatible.
> All these claims about java being platform independent are hooey!
Yes. You are right. But I'm curious: what is your definition for
"platform independent"?
>> Because I didn't found the time yet to install a FreeBSD system.
>
> But if java were platform independent, as claimed, you could just
> publish the compiled (.class) files and anybody could download them to
> FreeBSD Unix and they'd just *work* from the start, right?
I'm sure that you can do that without problems (as long as your
FreeBSD system has all the needed stuff). But that's not the problem
with Linj. Maybe I was not clear enough in my previous explanations:
The Linj compiler that translates from Linj to Java is written in
Common Lisp and it needs a Common Lisp environment to run. It is the
Linj compiler that is not platform independent because binary Common
Lisp code is not platform independent.
Sorry for the confusion.
Best regards,
Ant�nio Leit�o.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun29-001@Yahoo.Com>
> From: Antonio Menezes Leitao <··············@evaluator.pt>
> You google for it. Type "interval arithmetic java" on google
I already did that several weeks ago.
> and you will get several promising links (they look promising to me,
> at least)
They looked promising to me too, until I actually clicked on the links
and started reading the details.
> - the Brandeis Interval Arithmetic Constraint Solver (with Java
> source code)
>>You need a java-enabled web brower to run the applet.
I don't have any such browser here on VT100 dialup into Unix shell. By
the way, Java Applets don't usually work. I wrote one for a class
assignment and put it up here: http://www.rawbw.com/~rem/Lab7.htm and
it works fine from InterNet Explorer in the computer lab at De Anza
College, but it doesn't work in InterNet Explorer in the instructor's
office, and it doesn't work in the classroom adjoining the computer
lab. (In the latter two places, the main dialog comes up, but none of
the buttons do anything.)
>>the current version is NOT sound since it relies on Java's underlying
>>math library which is not proven to be accurate to the last bit.
I.e. they don't really implement interval arithmetic, instead they use
ordinary sloppy floating-point arithmetic for the guts of it, then
pretend it's accurate when running interval constraints on top of that,
so it's not at all what I'm looking for which is interval arithmetic
where it counts to guarantee bounds on results of arithmetic
operations.
> - interval.sourceforge.net/interval (a 100% Java, verifiable
> implementation of interval arithmetic operations and constraint
> contractors for the arithmetic operations and elementary functions
> (exp,log,sin,cos,tan,asin,acos,atan,sin2pi,...)
>>Platforms supported
>> * RedHat Linux 6.1 on the PC and Macintosh OS X
>> Note: Porting to other architectures should not be hard. The only
>> non-portable code is that which deals with setting the rounding
>> modes!
The only java system I have access to from home is FreeBSD Unix, which
is neither of the above two systems. I have no idea what would have to
be done inside the jvm to set rounding modes on FreeBSD Unix.
> Is adding annonymous inner classes a minor change?
No, that's a major sort of thing. If I try to port somebody else's
software that depends on that in a key place, I'd probably have to
rewrite the whole module to get it to work under an old version of
java.
> Is adding automatic boxing and unboxing a minor change?
Yeah, it'd be a pain to explicitly box/unbox everywhere the compiler
gives an error message, if there are lots of places, but it's a simple
fix linear in number of such places, so I'd consider it a minor change.
> Is adding generic types a minor change?
I don't know what that phrase means in java jargon. I know what
abstract classes and interfaces are, and how you can declare a variable
of the generic class and make it dispatch at runtime. Also I know about
the Object class and how LISP-like no-declared-type programming can be
done by passing everything as Object variables to static methods and
then having the static method do a typecase of the argument to dispatch
to all the specific methods. But I don't know whether the phrase you
used is anything like either of those.
> I'm curious: what is your definition for "platform independent"?
If the desired task makes sense on a set of platforms, then the program
or whatever does that task on them all. For example, text-mode Web
browsing makes sense on both GUI systems and VT100 dialups, and indeed
some browsers work on GUI systems and some work on VT100 dialups so a
truly platform independent web browser would make sense, but in any
case using the appropriate web browser for each platform the text-mode
Web pages do indeed work on all such platforms. So text-mode Web pages
are in that sense platform independent. (They even work with
Web-by-email services!) There's no reason applets shouldn't work
everywhere HTML FORMs work, except the people in charge of java haven't
bothered to do that.
> The Linj compiler that translates from Linj to Java is written in
> Common Lisp and it needs a Common Lisp environment to run. It is the
> Linj compiler that is not platform independent because binary Common
> Lisp code is not platform independent.
Oops, sorry, in all this discussion of java classes that people say I
can download and run anywhere, I forgot Linj isn't java code. But if
you generate fasl files and then load them into a CL environment,
although the contents of the fasl files themselves are dependent on the
CPU, the process of making them is system independent (compile-file
..) so if you avoid calling anything from the SYSTEM package, if you
stick to making ANSI CL calls, it should be easy to make Linj run on
any ANSI-compliant CL system. I guess I'm overlooking something.
From: Antonio Menezes Leitao
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <87pt7hfn78.fsf@evaluator.pt>
··········@YahooGroups.Com writes:
>> From: Antonio Menezes Leitao <··············@evaluator.pt>
>> You google for it. Type "interval arithmetic java" on google
>
> I already did that several weeks ago.
>
>> and you will get several promising links (they look promising to me,
>> at least)
>
> They looked promising to me too, until I actually clicked on the links
> and started reading the details.
>
>> - the Brandeis Interval Arithmetic Constraint Solver (with Java
>> source code)
>
>>>You need a java-enabled web brower to run the applet.
But if it comes with source code, why don't you take the parts that
you need and start using them?
> I don't have any such browser here on VT100 dialup into Unix shell. By
> the way, Java Applets don't usually work. I wrote one for a class
> assignment and put it up here: http://www.rawbw.com/~rem/Lab7.htm and
> it works fine from InterNet Explorer in the computer lab at De Anza
> College, but it doesn't work in InterNet Explorer in the instructor's
> office, and it doesn't work in the classroom adjoining the computer
> lab. (In the latter two places, the main dialog comes up, but none of
> the buttons do anything.)
Perhaps you are experiencing the "stability" that you claimed for Java.
>>>the current version is NOT sound since it relies on Java's underlying
>>>math library which is not proven to be accurate to the last bit.
> ...
> The only java system I have access to from home is FreeBSD Unix, which
> is neither of the above two systems. I have no idea what would have to
> be done inside the jvm to set rounding modes on FreeBSD Unix.
Perhaps you could ask the authors of the package.
>> Is adding annonymous inner classes a minor change?
>
> No, that's a major sort of thing. If I try to port somebody else's
> software that depends on that in a key place, I'd probably have to
> rewrite the whole module to get it to work under an old version of
> java.
>
>> Is adding automatic boxing and unboxing a minor change?
>
> Yeah, it'd be a pain to explicitly box/unbox everywhere the compiler
> gives an error message, if there are lots of places, but it's a simple
> fix linear in number of such places, so I'd consider it a minor
> change.
>
>> Is adding generic types a minor change?
>
> I don't know what that phrase means in java jargon. I know what
> abstract classes and interfaces are, and how you can declare a variable
> of the generic class and make it dispatch at runtime. Also I know about
> the Object class and how LISP-like no-declared-type programming can be
> done by passing everything as Object variables to static methods and
> then having the static method do a typecase of the argument to dispatch
> to all the specific methods. But I don't know whether the phrase you
> used is anything like either of those.
Google is your friend. Type "generic types java" and the first link
you get will take you to:
JSRs: Java Specification Requests
JSR 14: Add Generic Types To The JavaTM Programming Language
Extending the JavaTM programming language with generic types (aka
parameterized types).
>> The Linj compiler that translates from Linj to Java is written in
>> Common Lisp and it needs a Common Lisp environment to run. It is the
>> Linj compiler that is not platform independent because binary Common
>> Lisp code is not platform independent.
>
> Oops, sorry, in all this discussion of java classes that people say I
> can download and run anywhere, I forgot Linj isn't java code. But if
> you generate fasl files and then load them into a CL environment,
> although the contents of the fasl files themselves are dependent on the
> CPU, the process of making them is system independent (compile-file
> ..) so if you avoid calling anything from the SYSTEM package, if you
> stick to making ANSI CL calls, it should be easy to make Linj run on
> any ANSI-compliant CL system. I guess I'm overlooking something.
Perhaps you are overlooking the fact that Linj is distributed in
binary form.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may13-002@Yahoo.Com>
> From: Kenny Tilton <·······@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.
From: André Thieme
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7hbuq$a00$1@ulric.tng.de>
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: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may08-009@Yahoo.Com>
> From: "Ryan J. Bovorasmy" <······@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.
On Sat, 08 May 2004 19:38:34 -0800, RobertMaas wrote:
> 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.
Unless someone does the re-write for you :-)
In (the next version of) Linj you write:
(setq index (search str1 str2))
and you get
index = str2.indexOf(str1)
> 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 (the next version of) Linj you write:
(position c str)
(position c str :from-end t)
(position c str :start 3)
(position c str :end 5 :from-end t)
and you get
str.indexOf(c)
str.lastIndexOf(c)
str.indexOf(c, 3)
str.lastIndexOf(c, 4)
but it's not a real replacement for Common Lisp. In the Linj version of
this function you don't have :test, :test-not or :key and you can't mix
:start and (:from-end t) or :end and (:from-end nil). Compared with
Common Lisp sequence operations, the Java String class is really poor. And
if you need modifiable strings, you must use StringBuffer which is even
worse.
> 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.
If you are talking about java.util.Vector, then Java does implement
similar operations (and I included them in Linj). Regarding LinkedList,
there is a subset of the operations, but LinkedList, IMHO, is not what
Lispers want. Linj provides its own implementation (named cons) that is
much more useful. Here is an example where all three data types are used
with the same operation:
(defun test-string-list (str vect list)
(declare (string str) (Vector vect) (cons list))
(+ (position #\c str)
(position #\c vect :from-end t)
(position #\c list :key #'car :test #'eql)))
The translation you get in Java is:
public static int testStringList(String str, Vector vect, Cons list) {
return str.indexOf('c') +
vect.lastIndexOf(new Character('c')) +
list.position(new Character('c'), Predicate2.EQL_FUNCTION, Cons.CAR_FUNCTION);
}
Also note that Linj had to adapt the primitive type argument whenever the
method parameter required reference types.
> 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)
Linj now supports (a subset of) search.
> 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??
My guess: because they were targeting C++ programmers. Is there a
standard C++ function that does that?
>> 2. It makes working with lists easy.
>
> Indeed, in java working with linked lists must be an awful pain.
It is!
> 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.
Precisely. But in some cases you can do type inference and insert casts
automatically. Here is one (crazy) example:
(defun test-list ()
(let ((list '(1 "2" 3)))
(if (string= (second list) "two")
(+ (first list) (third list))
(first list))))
In Linj, '+' and 'string=' are operations which require certain types of
arguments. You can't use them in any other way. So, if the compiler
knows the actual argument types, it will check if they match its
expectations. If it doesn't know the actual argument types (meaning that
all it knows is that they are subclasses of Object, then it can restrict
those types to what it expects, leaving the downcast typecheck to runtime,
as can be seen in the following translation:
public static Object testList() {
Cons list = Cons.list(Bignum.valueOf(1), "2", Bignum.valueOf(3));
if (((String)list.second()).equals("two")) {
return ((Bignum)list.first()).add((Bignum)list.third());
} else {
return list.first();
}
}
> 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.
Humm. Strings are not lists of characters, neither in Common Lisp, nor in
Java. The Java position is defendable on the argument that an
integer can be used as a caracter for the indexOf operation without
confusion.
However, it is interesting to note that your example works as expected in
Linj:
(position 65 '(#\A #\B 65 66))
is translated into
Cons.list(new Character('A'),
new Character('B'),
Bignum.valueOf(65),
Bignum.valueOf(66)).
positionKey(Bignum.valueOf(65), null, null, 1);
and the correct result (2) is computed.
Antonio Leitao.
PS: These examples will only work in the next Linj version. While testing
them I found that the current Linj version lacked lots of useful stuff.
Antonio Menezes Leitao <··············@evaluator.pt> writes:
> On Sat, 08 May 2004 19:38:34 -0800, RobertMaas wrote:
>
> > 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??
>
> My guess: because they were targeting C++ programmers. Is there a
> standard C++ function that does that?
Yep, the STL `search' function can take a BinaryPredicate. I think
they were looking in CL's direction when they came up with this one.
Now, it's possible that Java was targeting the C++ programmers who
would have written their own loop, anyway...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Antonio Menezes Leitao <··············@evaluator.pt> writes:
>
>
>>On Sat, 08 May 2004 19:38:34 -0800, RobertMaas wrote:
>>
>>
>>>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??
>>
>>My guess: because they were targeting C++ programmers. Is there a
>>standard C++ function that does that?
>
>
> Yep, the STL `search' function can take a BinaryPredicate. I think
> they were looking in CL's direction when they came up with this one.
>
> Now, it's possible that Java was targeting the C++ programmers who
> would have written their own loop, anyway...
Java was targeting the C++ programmers who are too ignorant to know
about the STL. ;)
Ari Johnson <·····@hotmail.com> writes:
> Thomas F. Burdick wrote:
>
> > Yep, the STL `search' function can take a BinaryPredicate. I think
> > they were looking in CL's direction when they came up with this one.
> >
> > Now, it's possible that Java was targeting the C++ programmers who
> > would have written their own loop, anyway...
>
> Java was targeting the C++ programmers who are too ignorant to know
> about the STL. ;)
Well, that would explain the lack of MI, parametric types, ... and,
uh, interest on my part in the language :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
>
>>Thomas F. Burdick wrote:
>>
>>
>>>Yep, the STL `search' function can take a BinaryPredicate. I think
>>>they were looking in CL's direction when they came up with this one.
>>>
>>>Now, it's possible that Java was targeting the C++ programmers who
>>>would have written their own loop, anyway...
>>
>>Java was targeting the C++ programmers who are too ignorant to know
>>about the STL. ;)
>
>
> Well, that would explain the lack of MI, parametric types, ... and,
> uh, interest on my part in the language :-)
...and why it's so popular with manager types.
··········@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" <······@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: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun19-001@Yahoo.Com>
> From: Pete Kirkham <·················@cafemosaic.co.uk>
> How would you see that in lisp without using the introspector running
> in an interactive environment?
If you use ordinary nested-list structures when first developing your
new program, the ordinary read-eval-print loop is all you need to see
the result of every step you key in manually. Only a poor teacher would
insist on brand new students, never programmed before, using other
kinds of structures from the very start. And any experienced lisp
programmer would know to use ordinary nested-list structures when
developing something that is really difficult to do, then switch to
other kinds of structures later if there's a really good reason to do
so. By comparison, in java generally you hardly ever use
nested-linklist structures, you use instances of classes, for which
there isn't a standard useful way to print them. So even with BeanShell
you won't have the ease of lisp. (If BeanShell provides a useful
printed representation of every class instance, somebody please correct
what I said there. By the way, does anybody have a CGI interface to
BeanShell so that I could play with it to get a feel for how nice it
is?)
> People expect more than can be delivered through an HTML form, let
> alone VT100.
Google does just fine with HTML forms, and it's pretty popular, both
regular Web search, and Google Groups.
Yahoo Groups does fine with HTML forms too, except for their live chat
service which requires something more.
> Or lambda, which is so old it's ancient Greek.
Without changing the syntax, what word would you like in place of
lambda? Maybe anonymous-function, or just anonfunc to keep it short?
> programmers are taught that a program is 'like a recipe', so how can
> a recipe take part of the cookbook as an ingredient?
Actually I like that metaphor! Lisp allows you to write programs that
not just follow recipies a human wrote, but write their own recipes and
then follow them just the same! Macros are a crude beginning to that
idea: You write a template that converts one kind of form into another
kind of form, with the latter being a recipe that the computer can
follow. So for example you could have the macro form:
Fried eggs and toast <n>
expand into:
Put oil and <n> eggs into frypan and turn on burner.
Put <n> pieces of bread into toaster-oven, set to high, and press on.
When eggs are almost done, turn over.
After toaster oven turns off, wait a few seconds then remove toast.
When eggs are all done, remove from pan, place on top of toast, and
turn off burner.
So depending on the number you put for <n>, you get a different recipe.
(With cakemixes etc. where you have to measure strange amounts of
different ingredients proportionally, the parameterized recipe is much
more useful than my trivial example above. Most such recipes give the
amounts for a standard size such as to serve four, and tell you to us
proportionally larger or smaller amounts to serve other numbers of
people, which is a royal pain to do manually. So having the ability to
have the computer generate the desired recipe could be seen as an
advantage to anyone who ever cooks such recipes.) Then once the student
understands that metaphor, and has written simple programs manually,
combining the two ideas to write a macro that writes a program would be
understandable.
> too many people are taught to program rather than taught to think.
Why do you assume it's an either-or situation, not both??
> 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'
I disagree. In either lisp or C you can do it either way.
> Lisp syntax structures its calls starting with the result (though the
> effect is still procedural), Java syntax structures its calls starting
> with your arguments.
For static methods, that's not true at all. Package and class and
function name is first, arguments come later, making them the same as
ordinary lisp function calls where package:functionname precede
arguments.
For instance methods it's only partly true. The object reference comes
first, then the dot, then the method name interpreted within the class
that the object has at runtime, then the other arguments which are
interpreted per their compiletime declared class not their actual
runtime class in deciding which overloaded method to call.
But there seems to be a fundamental difference in the *semantics*:
http://cl-cookbook.sourceforge.net/clos-tutorial/
... OO systems which only allow you to
specialize on the first argument. This argument is then given
linguistic prominence, and the function call is given a new syntax to
reflect that:
Hmm, sounds like java is an example of such an OO language, am I correct?
CLOS supports multi-methods - methods that can specialize on more than
one argument.
So that's why the same kind of syntax, one argument up front the rest
later, isn't used in lisp (specifically CLOS).
> the Java syntax fits in with the model of program-as-recipe
Ignoring the point about how Java doesn't make it easy for programs to
compose programs, whereas lisp does: I disagree. Either language can be
programmed the same way: Define a function (method) which takes
arguments, do some calculation based on them, do some more calculation
based on those calculations, etc., until it has the finished result,
then return that result. (Either can return multiple values: CL
explicitly via an efficient mechanism, Java via allocatinging a vector
and returning that, which is the old way lisp did it before
multiple-value returns were implemented. That's just an efficiency
issue.) You get some ingredients, do various mixing and cooking of
them, and at the end you have something to eat. Function/method calling
within a function/method is like a sub-recipe for making some difficult
ingredient, such as won tons which are an ingredient in won ton soup.
Again, I see no essential difference between Java and Lisp in having
recipe as a metaphor.
> > 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.
Incorrect. Just yesterday I was working on a GUI program (AWT Applet)
in Java, and needed to find the appropriate version of a particular
method. I wanted to specify the message text, title, type of message,
and nothing else. But that particular combination wasn't available, so
I had to use a method that required additional arguments, and supply
dummy values for each of them. Optional arguments wouldn't have helped,
because the *first* argument of the method I used was one of the
arguments I didn't want to have to specify myself. Optional arguments
only let you stop supplying arguments from some point onward, they
don't let you skip early arguments and include later ones. Keyword
arguments would have allowed me to specify exactly the arguments I
wanted, and let the rest default to reasonable values. Look at this
mess:
static String showInputDialog(Component parentComponent,
Object message)
Doesn't let me specify title, hence useless for my need.
static String showInputDialog(Component parentComponent,
Object message, Object initialSelectionValue)
Doesn't let me specify title, hence useless for my need.
static String showInputDialog(Component parentComponent,
Object message, String title, int messageType)
What I want, except I have to supply the first argument somehow even
though it's a pain, but null seems to work (put dialog in middle of
whole screen instead of centered within current Applet if I specify
that as the parentComponent).
static Object showInputDialog(Component parentComponent,
Object message, String title, int messageType, Icon icon,
Object[] selectionValues, Object initialSelectionValue)
Requires several arguments I can't supply, hence useless for my need.
static String showInputDialog(Object message,
Object initialSelectionValue)
Doesn't let me specify title, hence useless for my need.
Oh if you're curious why I'm using a swing JOptionPane method within an
AWT Applet: Because AWT doesn't have anything like that yet, a
deficiency of Java'a GUI API.
> IDEs also help in the other aspect that keywords do, by showing the
> programmer what the names of the arguments are.
But there are five different overloaded versions of the same-name
method, so it's impossible for the IDE to know which of the five should
have its argument names shown to programmer. By comparison with CL with
keyword arguments an IDE could do the "right thing" of clearly
indicating which arguments if any are required then what keyword
arguments may be used, perhaps by a pull-down menu hanging from the
cursor the way Visual Basic's IDE deals with a list of all the GUI
controls that might be specified for an event handler.
> > 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 a big loser: Suppose you want to have a list that can contain any
mixture of twenty different types, mostly built-in types. You *cannot*
create an interface for these twenty types, then make each of the
twenty types implement your new interface, because you are not allowed
to re-define system-supplied API classes to make them implement a new
interface they didn't before. So you'd have to extend each of the
system-supplied classes to be a version that was just like the system
version but which implemented your new interface. Then you'd have to
keep track of whether you were using your extension or the original
type throughout your program, doing downcasting explicitly as needed.
It's a waste of effort, probably easier to just use Object type which
needs explicit typecase dispatch in your code, but Java doesn't have
typecase, so daisy chain of:
else if (obj instanceof type<n>) { ... }
no big deal. Or better, have a single static method that maps from the
twenty object types to an integer which is used as an index in your
emulated typecases, so you can just use a switch select statement.
Then when you start to use a 21th type of object in your list, you just
modify the static method to include that new type, and you search for
all calls to that static method to make sure all your code can handle
the new object type. As for the actual code you run after you've found
which type the object is: You can then cast to the actual type it is,
and use method overloading to make the syntax parallel so it looks nice
and can be eyeballed to see if it's all correct:
else if (obj instanceof BigInteger) { return processObj((BigInteger) obj); }
else if (obj instanceof Double) { return processObj((Double) obj); }
else if (obj instanceof Character) { return processObj((Character) obj); }
or equivalent with static function returning index which is named constant.
switch (MyTypes.objToTypeCode(obj)) {
case MyTypes.TYPE_BIGINTEGER: return processObj((BigInteger) obj); break;
case MyTypes.TYPE_DOUBLE: return processObj((Double) obj); break;
case MyTypes.TYPE_CHARACTER: return processObj((Character) obj); break;
default: throw new MyTypes.unknowntype... }
Referring to the generic sequence functions in CL, specifically in this
example used with a linked-list (although a general vector would work
just the same, with different syntax in the example):
> > 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, ...
That's irrelevant to my point, which was about generic sequences (lists
or vectors of generic element type), not specialized sequences of
characters-only. Suppose in java you make a linked list, or array, as
the representation of a sequence of Objects of various types. Does the
Java API provide any method(s) equivalent to this?
position item sequence &key :from-end :test :test-not :start :end :key
> java.util.Arrays.asList(new Object[]{
> new Character('A'),
> new Character('B'),
> new Integer(65),
> new Integer(66),
> }).indexOf(new Integer(65))
The ugly part there is the creation of the list itself, in the absense
of any parser such as READ in lisp. But I thought Java had software to
handle serialization and deserialization of data for purpose of
communicating across the network? How hard is it to set up a a Java
equivalent to CL's READ-FROM-STRING function that created all the
necessary stringinput/bufferedreader daisy chain and fed it through a
deserialization method to allow something like:
MyParser.deserializeLispSyntax("(#\A #\B 65 66)").indexOf(new Integer(65))
Too bad there's no way to add new methods to a system-supplied API
class, in this case String, or else you could maybe do this:
"(#\A #\B 65 66)".deserializeLispSyntax().indexOf(new Integer(65))
> (normally I'd use a script to generate such lists in Java, with lisp
> being the scripting language of choice)
I don't quite understand what you mean there. Do you mean you actually
run CL as a sub-process under Java and pass it the s-expression as a
string and somehow get back a linked list or array in the jvm, such as
by CL doing callbacks to Java API methods to build up the Java object
piece by piece? Or do you mean you'd run a CL program to convert the
s-expresssion syntax to XML or other serial representation known by
Java, and then use Java's built-in XML-or-whatever deserializer to load
the object into the jvm?
> Most languages, Java included, are destined to evolve into lisp or
> remain niche languages.
Hmm, that's the opposite of what a certain very opinionated DeAnza
instructor said (LISP is an A.I. langauge, not useful for anything
except that niche -- paraphrased to fit the current context).
I agree with you, not him, of course, on this point. CL is the general
purpose language, all other languages are niche languages, but some are
evolving to escape their niche to become as general as CL.
(I have to count Scheme as a niche language, sigh.)
Still I would like CL to become even more general, such as including
what PSL (Portable Standard LISP) called "SysLisp", which is a way to
cross-compile s-expressions via LAP into low-level assembly code that
can be included in ordinary assembly-language programs that can be
assembled to run stand-alone as an application or as a module in some
non-LISP environment, thereby allowing using SysLisp to write the main
part of compilers and even operating systems, even the kernel,
replacing C as the standard language for writing such. Maybe this has
already been done but isn't and won't be in the ANSI standard because
it's not of enough general use?
From: Joe Marshall
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <7jtzlnrg.fsf@ccs.neu.edu>
··········@YahooGroups.Com writes:
> If you use ordinary nested-list structures when first developing your
> new program, the ordinary read-eval-print loop is all you need to see
> the result of every step you key in manually. Only a poor teacher would
> insist on brand new students, never programmed before, using other
> kinds of structures from the very start.
I disagree. The amount of pain that new students experience over list
structure is enormous. Structures give you a certain amount of `type
safety' and self-documentation that lists do not have.
> And any experienced lisp programmer would know to use ordinary
> nested-list structures when developing something that is really
> difficult to do, then switch to other kinds of structures later if
> there's a really good reason to do so.
I do that sometimes, but I often use CLOS classes.
··········@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.
On Mon, May 03, 2004 at 07:22:19PM -0500, adam connor wrote:
> Even to my newbie eyes, Lisp is hands down the better language (except
> possibly for manipulating bits and bytes);
Hmm, you should check out LDB, (SETF LDB), and also bit-vectors. I like
it better than C. Moving numbers or bits around in Java feels like
tying shoe-laces with boxing gloves on, by comparison.
> 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.
Which is rather amusing considering its origins. I guess they just
couldn't squeeze the bloated thing anywhere else. And Lisp still beats
Java at this arena, in terms of development, thanks to the top-level and
dynamic features. (I once had to figure out how to install Tomcat...
how do people ever get to use that thing? What a mess.)
> 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.
http://www.cliki.net/ perhaps? There is even a PDF library...
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun06-001@Yahoo.Com>
> From: Matthew Danish <·······@andrew.cmu.edu>
> > 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.
> http://www.cliki.net/ perhaps?
I was hoping to find a library of functions to deal with cookies in Web
sessions. I took the time to browse there, anything having to do with
Web, anything about networking, anything about libraries (as opposed to
complete programs), nothing I could find that seemed to deal with what
I seek. I used "cookies" as search term, and nothing that turned up
looked like what I seek. I dread having to implement handling of
cookies from scratch.
On Sun, 6 Jun 2004 ··········@YahooGroups.Com wrote:
> > From: Matthew Danish <·······@andrew.cmu.edu>
> > > 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.
> > http://www.cliki.net/ perhaps?
>
> I was hoping to find a library of functions to deal with cookies in Web
> sessions. I took the time to browse there, anything having to do with
> Web, anything about networking, anything about libraries (as opposed to
> complete programs), nothing I could find that seemed to deal with what
> I seek. I used "cookies" as search term, and nothing that turned up
> looked like what I seek. I dread having to implement handling of
> cookies from scratch.
Not sure what there is to "dread" about handling cookies, it's just
another header value to set. Both portable AllegroServe and mod_lisp
offer ways to handle cookies; but I understand you are using your own
custom CGI shim, so I really cannot see how a separate library can provide
the functionality you need. Do you know how cookies work?
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun22-002@Yahoo.Com>
> From: Matthew Danish <·······@andrew.cmu.edu>
> Not sure what there is to "dread" about handling cookies, it's just
> another header value to set.
But my client-spider would have to keep a database of all the cookies
sent so-far from the server, and on each new HTTP connection send back
just the appropriate ones based on domain prefix, right?
> Both portable AllegroServe and mod_lisp offer ways to handle cookies;
> but I understand you are using your own custom CGI shim, so I really
> cannot see how a separate library can provide the functionality you
> need.
Ah, you seem to be talking about what happens at the other end, what
the server such as Yahoo! Mail does. I guess I didn't make it clear at
the moment I'm mostly interested in the client end of it. (Although
someday I might add cookies to my own CGI server applications, but
that's not the how-to info I'm currently seeking.)
> Do you know how cookies work?
Somewhat. I was looking at some documentation that seemed to say there
are three different, incompatible, kinds of cookies: The original from
Netscape, the RFC one, and a third I forget where it came from. Before
I can even deal with the first cookie from Yahoo! Mail, I need to
somehow find out which of the three kinds of cookies it's throwing at
me. Given the level of interativity I'll need to do these preliminary
investigations, I think I'll have to use CL instead of Java.
From: Marco Baringer
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <m2d63qfexl.fsf@convey.it>
··········@YahooGroups.Com writes:
>> From: Matthew Danish <·······@andrew.cmu.edu>
>> Not sure what there is to "dread" about handling cookies, it's just
>> another header value to set.
>
> But my client-spider would have to keep a database of all the cookies
> sent so-far from the server, and on each new HTTP connection send back
> just the appropriate ones based on domain prefix, right?
aserve (and it's cousin portableaserve) has an http client which
handles cookies (and chosing which ones to send when and parsing the
returned cookies). i've successfully used this client to build
numerous http spiders.
--
-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
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun27-001@Yahoo.Com>
> From: Marco Baringer <··@bese.it>
> aserve (and it's cousin portableaserve) has an http client which
> handles cookies (and chosing which ones to send when and parsing the
> returned cookies). i've successfully used this client to build
> numerous http spiders.
Hey, that sounds like the sort of cookie-handling package I was looking for.
Is it freely availble? Where can it be found online?
Hmm, I did a google search for that name, and found a reference to:
aserve is the abbrvted name for AllegroServe, a Web server written in
Common Lisp.
which links to:
AllegroServe (formerly Allegro iServe) is a LLGPLed Web server which
is designed for use with Allegro Common Lisp. It can serve
dynamically-created pages through its HTML generator in addition to
static content.
which clearly describes a server, not a client/spider.
Google search for the portable version:
Portable AllegroServe is a fork of the AllegroServe webserver, adapted
to work with other CL implementations, not only with Allegro CL. So
far the following implementations are supported, to varying degrees:
* CMU Common Lisp
Ah, CMUCL which is what we have here on this ISP, but again it seems to
be a server not a client/spider.
So I'm confused. Did you get the names mixed up and tell me the wrong
one, the server instead of what I wanted and what you described as used
to implement several spiders? Or does the server also include the
cookie-jar manager despite it being irelevant to a server, and that's
the part you are referring me to?
(Maybe the client part is used to test the server main part?)
On Sun, 27 Jun 2004 ··········@YahooGroups.Com wrote:
> AllegroServe (formerly Allegro iServe) is a LLGPLed Web server which
> is designed for use with Allegro Common Lisp. It can serve
> dynamically-created pages through its HTML generator in addition to
> static content.
> which clearly describes a server, not a client/spider.
AllegroServe (and Portable AllegroServe) includes a client in addition to
the server functionality.
http://opensource.franz.com/aserve/aserve-dist/doc/aserve.html#cliient-request
From: Svein Ove Aas
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <ca01sq$b3d$1@services.kq.no>
··········@YahooGroups.Com wrote:
>> From: Matthew Danish <·······@andrew.cmu.edu>
>> > 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.
>> http://www.cliki.net/ perhaps?
>
> I was hoping to find a library of functions to deal with cookies in Web
> sessions. I took the time to browse there, anything having to do with
> Web, anything about networking, anything about libraries (as opposed to
> complete programs), nothing I could find that seemed to deal with what
> I seek. I used "cookies" as search term, and nothing that turned up
> looked like what I seek. I dread having to implement handling of
> cookies from scratch.
Perhaps there isn't such a library. You probably aren't the first to want
one, but given that you looked for one - and would presumably have used
it - how about releasing your own library once you have something that
works?
It doesn't need to be perfect.
It doesn't even need to be decent; *anything*'s better that no library at
all.
(Maybe there should be a "partial library, use at your own peril" page?)
adam connor wrote:
> ··········@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
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, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7ane8$6lr$1@reader2.panix.com>
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>I think you have summarized things perfectly. Have you missed the vast
>Lisp libraries? No, but look at all the seedlings:
Except that a hundred half-assed, unfinished librarylets are, in some
ways, more irritating than nothing at all.
After digging through all the resources I can find -- Cliki,
common-lisp.net, archives of this newsgroup, mailing lists -- and
asking questions, I finally managed to find an XML parser that
actually works in clisp, xmls.
Except that it's a half-assed, incomplete parser that doesn't emit XML
declarations on output, or take into account things like character
sets at all. (I've heard people say derisively that XML is just a
weak implementation of s-expressions; this is only true if you spend
all your time in 7-bit ASCII.)
And even once it's parsed, well, great, now I have this nifty
s-expression representation... that won't work with any other tool in
the known universe. Can I hand it off to an XSLT processor, the way I
could hand a DOM Document off in Java or C#? I cannot (and not just
because there isn't one). Can I run XPath over it? I cannot (and not
just because there is no XPath engine).
And see, if there wasn't any XML parser at all, it'd be an obvious
problem, and you could get a group of people together to, you know,
make a standard one. But because "it's so easy!" to do things in CL,
you've got a half-dozen implementations that do all the easy parts of
XML parsing, and there's no chance at all for a standard, good parser.
Dozens of shitty, incomplete libraries are not a promising start on a
semi-standard, good library; they're just clutter.
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski wrote:
> In article <·····················@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>I think you have summarized things perfectly. Have you missed the vast
>>Lisp libraries? No, but look at all the seedlings:
>
>
> Except that a hundred half-assed, unfinished librarylets...
That's just nitpicking, isn't it? :) which one(s) are you working to
improve?
are, in some
> ways, more irritating than nothing at all.
What part of "incubator" do you not understand?
Where do you think the open source fairy /gets/ the good libraries she
leaves under your pillow? Answer: From a primordial soup of good and bad
stuff she wades through to find the good ones. Look at the bright side:
at least there now is an evolutionary pond (common-lisp.net) in which
organisms (good and bad) are able to swim about and do the survival of
the fittest thing.
All you have observed is that the process is just now picking up steam
and so there is a lot of crud out there, including tired old projects
getting a dead-cat bounce from the new energy in the CL community.
> make a standard one. But because "it's so easy!" to do things in CL,
> you've got a half-dozen implementations that do all the easy parts of
> XML parsing, and there's no chance at all for a standard, good parser.
I think you are right. cl-xml is a serious tool with a /lot/ off effort
put into making it easy to install, but at the first difficulty I just
said to hell with it and parsed an XML file with my own primitive hack I
did faster than I could have gotten cl-xml installed and learned it and
tweaked it (probably) to get what I wanted. (it was a one-time deal
after which I would be able to leave the XML behind forever.)
>
> Dozens of shitty, incomplete libraries are not a promising start on a
> semi-standard, good library; they're just clutter.
OK, new rule for the SourceForge and common-lisp.net incubators: only
polished, mature, portable projects with thorough documentation may be
/started/... oh, hang on.
Could we discuss this again in a year? Right now I have to get back to:
cells
cl-opengl
cl-ftgl
cl-openal
cl-magick
cello
(And, yes, they are half-assed and incomplete, thank you very much.)
:)
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
Kenny Tilton wrote:
>
>
> Mike Kozlowski wrote:
>
>> make a standard one. But because "it's so easy!" to do things in CL,
>> you've got a half-dozen implementations that do all the easy parts of
>> XML parsing, and there's no chance at all for a standard, good parser.
>
>
> I think you are right. cl-xml is a serious tool with a /lot/ off effort
> put into making it easy to install, but at the first difficulty I just
> said to hell with it and...
This is an unfortunate coincidence: I was only confirming the tendency
to roll one's own. I was not commenting in any way on the quality of
cl-xml (which I have heard rocks).
But now that I think of it? Why are you not using cl-xml? I recall you
say xmls was the one you found that works with CLisp. Not fair. If CLisp
cannot keep up, don't blame the Common Lisp open source community for
that, blame yourself for limiting yourself to one quirky
semi-implementation.
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
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7avhq$9ct$1@reader2.panix.com>
In article <························@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>But now that I think of it? Why are you not using cl-xml? I recall you
>say xmls was the one you found that works with CLisp. Not fair. If CLisp
>cannot keep up, don't blame the Common Lisp open source community for
>that, blame yourself for limiting yourself to one quirky
>semi-implementation.
Fair enough, but the problem is that I need to run on NetBSD, and only
clisp does. So I guess I can blame either the Lisp interpreter
maintainers for not writing portable code, or the NetBSD people for
not writing a portable BSD (though other languages appear to work on
it unproblematically).
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski <···@klio.org> writes:
> In article <························@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>>But now that I think of it? Why are you not using cl-xml? I recall you
>>say xmls was the one you found that works with CLisp. Not fair. If CLisp
>>cannot keep up, don't blame the Common Lisp open source community for
>>that, blame yourself for limiting yourself to one quirky
>>semi-implementation.
>
> Fair enough, but the problem is that I need to run on NetBSD, and only
> clisp does. So I guess I can blame either the Lisp interpreter
> maintainers for not writing portable code, or the NetBSD people for
> not writing a portable BSD (though other languages appear to work on
> it unproblematically).
I use Lispworks for Linux under NetBSD i386 all the time. cl-xml
should work with this combination.
-russ
From: Wade Humeniuk
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <cr7mc.7447$F04.7271@clgrps13>
Mike Kozlowski wrote:
>
> Fair enough, but the problem is that I need to run on NetBSD, and only
> clisp does. So I guess I can blame either the Lisp interpreter
> maintainers for not writing portable code, or the NetBSD people for
> not writing a portable BSD (though other languages appear to work on
> it unproblematically).
>
Looking at the NetBSD site it appears that it has a Linux Compatibility
Package (just like FreeBSD). You should be able to run CLs that are
built for Linux. I have tried LWL on FreeBSD and it appears to work
fine. Perhaps CMUCL will also run on NetBSD?
Wade
Wade Humeniuk <········@telus.delete.net> writes:
> I have tried LWL on FreeBSD and it appears to work
> fine.
not quite on-topic, but: LWL runs excellently on OpenBSD as well.
--
(espen)
Hello!
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
>Wade Humeniuk <········@telus.delete.net> writes:
>> I have tried LWL on FreeBSD and it appears to work
>> fine.
>not quite on-topic, but: LWL runs excellently on OpenBSD as well.
Interesting. I tried cmucl's Linux/x86 binaries on OpenBSD/x86, but
things did *not* work back then. But cmucl's runtime is very picky
about VM layout, anyway (things like ghc, which implements an exact
generational GC, are less picky, for example).
Kind regards,
Hannah.
From: ·········@random-state.net
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7b04m$9e2i1$1@midnight.cs.hut.fi>
Mike Kozlowski <···@klio.org> wrote:
> Fair enough, but the problem is that I need to run on NetBSD, and only
> clisp does.
Not quite true. SBCL <http://www.sbcl.org/> should run there as well.
Cheers,
-- Nikodemus
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7b40p$asi$1@reader2.panix.com>
In article <··············@midnight.cs.hut.fi>,
<·········@random-state.net> wrote:
>Mike Kozlowski <···@klio.org> wrote:
>
>> Fair enough, but the problem is that I need to run on NetBSD, and only
>> clisp does.
>
>Not quite true. SBCL <http://www.sbcl.org/> should run there as well.
That appears to be the case, yeah. I'm not sure how I missed that;
maybe I just was staying away from the pre-1.0 thing. Someone else
pointed out that NetBSD has a Linux compatibility package, which is
useful information...
--
Mike Kozlowski
http://www.klio.org/mlk/
From: Wade Humeniuk
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <z9amc.8133$F04.1464@clgrps13>
Mike Kozlowski wrote:
>
> That appears to be the case, yeah. I'm not sure how I missed that;
> maybe I just was staying away from the pre-1.0 thing. Someone else
> pointed out that NetBSD has a Linux compatibility package, which is
> useful information...
>
It slipped my mind at the time but CMUCL also has a native FreeBSD
executable. Since NetBSD can run FreeBSD apps (in some compatibility
mode).....
Wade
From: Christophe Rhodes
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <sqwu3q7w6x.fsf@lambda.dyndns.org>
Mike Kozlowski <···@klio.org> writes:
> In article <························@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>>But now that I think of it? Why are you not using cl-xml? I recall you
>>say xmls was the one you found that works with CLisp. Not fair. If CLisp
>>cannot keep up, don't blame the Common Lisp open source community for
>>that, blame yourself for limiting yourself to one quirky
>>semi-implementation.
>
> Fair enough, but the problem is that I need to run on NetBSD, and only
> clisp does. So I guess I can blame either the Lisp interpreter
> maintainers for not writing portable code, or the NetBSD people for
> not writing a portable BSD (though other languages appear to work on
> it unproblematically).
What is a Lisp "interpreter"? Answering this question might reveal
why compilers tend only to be ported when there's either a commercial
pressure or a demand that is backed up with willingness to invest
effort.
On the assumption that you wouldn't mind a compiler (and, I concede,
the rather stronger assumption that by "NetBSD" you mean "NetBSD
running on an x86") you may wish to investigate sbcl.
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)
Mike Kozlowski <···@klio.org> wrote in message news:<············@reader2.panix.com>...
> ...
> Fair enough, but the problem is that I need to run on NetBSD, and only
> clisp does. So I guess I can blame either the Lisp interpreter
> maintainers for not writing portable code, or the NetBSD people for
> not writing a portable BSD (though other languages appear to work on
> it unproblematically).
Although only clisp is is pkgsrc, there is also (besides other possibilities)
ecl (http://ecls.sf.net) that I have built on alphaev6-netbsd161 and on
i386-netbsd161 (I had some trouble on alpha [as you will see in the
ECL mailing list archives], but these are now resolved)
HTH
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7auld$93e$1@reader2.panix.com>
In article <························@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>Mike Kozlowski wrote:
>> Except that a hundred half-assed, unfinished librarylets...
>
>That's just nitpicking, isn't it? :) which one(s) are you working to
>improve?
None. My mad Lisp skillz are at the point where I'm lucky if I can
use a library, much less write one.
(Also, boy, that's the world's most irritating standard open source rebuttal.)
>Where do you think the open source fairy /gets/ the good libraries she
>leaves under your pillow? Answer: From a primordial soup of good and bad
>stuff she wades through to find the good ones. Look at the bright side:
>at least there now is an evolutionary pond (common-lisp.net) in which
>organisms (good and bad) are able to swim about and do the survival of
>the fittest thing.
>
>All you have observed is that the process is just now picking up steam
>and so there is a lot of crud out there, including tired old projects
>getting a dead-cat bounce from the new energy in the CL community.
Yeah, fair enough. I'm just saying, if I were using some new language
that doesn't have many users yet, I might be irritated that there were
no libraries to do X, but at least I'd know it quickly. With CL, I'm
finding that it _looks_ like there are a dozen libraries to do X, but
none of them actually do it well.
>> Dozens of shitty, incomplete libraries are not a promising start on a
>> semi-standard, good library; they're just clutter.
>
>OK, new rule for the SourceForge and common-lisp.net incubators: only
>polished, mature, portable projects with thorough documentation may be
>/started/... oh, hang on.
What I'd say, rather, is: New rule for someone looking to start up a
new library to do X -- check to see if there's already somebody out
there writing a library to do X, and see if you could maybe help
polish up their implementation, rather than starting out your own.
And yeah, I know how open source works, and why that's not realistic.
Even in Java, you've got umpty zillion different app frameworks
hanging around under the auspices of Jakarta, many of which are
zombies. But the Java community is big enough that it can afford to
waste effort on redundant, stupid libraries...
Also, and I might be completely off-base here, it seems to me that the
existence of a closed-source commercial Lisp with a better
implementation (and, presumably, libraries) than any of the open
source ones, really hurts. In a language ecosystem where the best
implementation is free (Perl, Python), people who do real
production-quality work are all going to be using the free system, and
will all be interested in improving the free system. But in an
ecosystem where the best implementation is commercial and closed,
people who do real production work are only interested in getting that
closed system improved, so there's little benefit redounding to the
larger community. If only hobbyists use the free stuff, getting the
production-quality stuff created is going to happen slowly if at all.
--
Mike Kozlowski
http://www.klio.org/mlk/
On Wed, 5 May 2004 14:45:01 +0000 (UTC), Mike Kozlowski <···@klio.org> wrote:
> Yeah, fair enough. I'm just saying, if I were using some new
> language that doesn't have many users yet, I might be irritated that
> there were no libraries to do X, but at least I'd know it quickly.
> With CL, I'm finding that it _looks_ like there are a dozen
> libraries to do X, but none of them actually do it well.
You were talking about XML parsers, right? And "none of them do it
well", right?
Wait, there's CL-XML by James Anderson, there's cxml taken from
Gilbert Baumann's Closure code, there's pxmlutils, a port of Franz'
parser which comes with AllegroCL, and there's xmls which you
mentioned and about which its homepage has to say that it only
"recognizes a useful subset of the XML spec." There are also various
FFI bindings to expat. Did you really try them all before you decided
to write a Usenet posting saying they're all crap?
Edi.
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7b4u8$b7u$1@reader2.panix.com>
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de> wrote:
>On Wed, 5 May 2004 14:45:01 +0000 (UTC), Mike Kozlowski <···@klio.org> wrote:
>
>> Yeah, fair enough. I'm just saying, if I were using some new
>> language that doesn't have many users yet, I might be irritated that
>> there were no libraries to do X, but at least I'd know it quickly.
>> With CL, I'm finding that it _looks_ like there are a dozen
>> libraries to do X, but none of them actually do it well.
>
>You were talking about XML parsers, right? And "none of them do it
>well", right?
>
>Wait, there's CL-XML by James Anderson, there's cxml taken from
>Gilbert Baumann's Closure code, there's pxmlutils, a port of Franz'
>parser which comes with AllegroCL, and there's xmls which you
>mentioned and about which its homepage has to say that it only
>"recognizes a useful subset of the XML spec." There are also various
>FFI bindings to expat. Did you really try them all before you decided
>to write a Usenet posting saying they're all crap?
I tried xmls, and it was as advertised: A useful subset, but not a
large enough one for my needs.
To the others, CL-XML won't work with clisp (but might otherwise be
fine, the pre-1.0 version number notwithstanding). Cxml appears to
need ASDF, which I was unable to install (due to my own ineptitude,
I'm sure), but didn't appear to be complete enough (it doesn't support
validation, for instance) for me to go to lengths to get it working;
and pxmlutils requires dependencies that I couldn't get working on
clisp.
And, at any rate, much of my point is that having to go digging around
and evaluating multiple packages (all of which appear to be either
pre-1.0 or incomplete or unportable, or some combination of the above)
for a basic XML parser is enormously frustrating.
And -- perhaps more importantly -- the lack of parser standardization
means that no high-level libraries can layer in a parser-independent
manner. If I have a SOAP library or an XSLT processor or an RSS
generator, it's going to be tightly bound to whatever XML parser it
requires; I won't be able to swap out parsers as I need. So the only
hope is for a whole, top-to-bottom implementation suite that handles
every XML-related standard ever. Is that really the Lisp Way?
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski <···@klio.org> wrote:
+---------------
| To the others, CL-XML won't work with clisp ...
...
| and pxmlutils requires dependencies that I couldn't get working on clisp.
+---------------
Blaming this and that XML library for one Lisp implementation's problems
doesn't seem helpful. Have you considered trying a more recent version
of CLISP, or even (*gasp!*) trying a different implementation of Common
Lisp altogether?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kenny Tilton
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <40992CA3.A21D7247@nyc.rr.com>
Mike Kozlowski wrote:
>
> In article <························@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
> >Mike Kozlowski wrote:
>
> >> Except that a hundred half-assed, unfinished librarylets...
> >
> >That's just nitpicking, isn't it? :) which one(s) are you working to
> >improve?
>
> None. My mad Lisp skillz are at the point where I'm lucky if I can
> use a library, much less write one.
>
> (Also, boy, that's the world's most irritating standard open source rebuttal.)
Guilty. I overloaded a response to you with a sound-bite from my ongoing
campaign to get Lispniks to realize that we would have more libraries if
Lispniks worked on more libraries.
> Also, and I might be completely off-base here, it seems to me that the
> existence of a closed-source commercial Lisp with a better
> implementation (and, presumably, libraries) than any of the open
> source ones, really hurts.
Good point. The uncommercial languages have an advantage in that regard.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
On Wed, 05 May 2004 17:58:27 +0000, Kenny Tilton wrote:
>
> Guilty. I overloaded a response to you with a sound-bite from my ongoing
> campaign to get Lispniks to realize that we would have more libraries if
> Lispniks worked on more libraries.
>
Well, it worked. Rather than jump in and start writing random (and
most likely useless) Lisp programs in my quest to learn CL, you've made me
think it would be better to start (now that I know the basics) by learning
UFFI and writing bindings for C libraries.
The only problem at the moment is I don't know what C libraries I should
look at. Does anyone maintain a list of good C libraries that have
bindings and, more importantly, ones that do not yet? Such a list might
be a good resource for people like me to use as a TODO list.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
From: Kenny Tilton
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <40995FE1.7A29C446@nyc.rr.com>
William Bland wrote:
>
> On Wed, 05 May 2004 17:58:27 +0000, Kenny Tilton wrote:
> >
> > Guilty. I overloaded a response to you with a sound-bite from my ongoing
> > campaign to get Lispniks to realize that we would have more libraries if
> > Lispniks worked on more libraries.
> >
>
> Well, it worked.
woohoo! Lisp newbies have a chance to be heros. The old hands are worn
out, weary of the battle. Once more into the breach, my ass.
Newbies are supercharged by having discovered this incredible language,
but also are accustomed to having scads of libraries around, so they
really feel the pain.
The neat thing is that macros can really tame a nasty library such as
OpenGL, so newbies also have an excuse to dive into Graham's On Lisp and
find out why Lispniks speak in hushed tones of the Unbearable
Staggeringness of Macros.
> Rather than jump in and start writing random (and
> most likely useless) Lisp programs in my quest to learn CL, you've made me
> think it would be better to start (now that I know the basics) by learning
> UFFI and writing bindings for C libraries.
>
> The only problem at the moment is I don't know what C libraries I should
> look at. Does anyone maintain a list of good C libraries that have
> bindings and, more importantly, ones that do not yet? Such a list might
> be a good resource for people like me to use as a TODO list.
I think these things always go better when driven by necessity and/or
interest, but it sounds as if you are just casting about for something
to do. Here are some possible sources of inspiration:
1. whining on cll by people who did not find XXX under their pillow this
morning
2. lists of bindings available for Python or Perl or whatever: just to
see if something lights your fire.
3. stuff kenny needs: Open Dynamics, text-to-speech (Festival? not sure
that is portable)
4. common-lisp.net: as has been noted, it ain't all great, and you know
there was enough interest at some point.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
William Bland <····@abstractnonsense.com> writes:
> The only problem at the moment is I don't know what C libraries I should
> look at. Does anyone maintain a list of good C libraries that have
> bindings and, more importantly, ones that do not yet? Such a list might
> be a good resource for people like me to use as a TODO list.
You may create a page for that at CLiki, or use the
existing wish list page.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Thu, 06 May 2004 09:36:34 +0200, Paolo Amoroso wrote:
> William Bland <····@abstractnonsense.com> writes:
>
>> The only problem at the moment is I don't know what C libraries I should
>> look at. Does anyone maintain a list of good C libraries that have
>> bindings and, more importantly, ones that do not yet? Such a list might
>> be a good resource for people like me to use as a TODO list.
>
> You may create a page for that at CLiki, or use the
> existing wish list page.
>
>
> Paolo
Done:
http://www.cliki.net/Bindings%20for%20libraries
Feel free to remove libraries that don't make sense as targets for Lisp
bindings - I didn't know exactly what everything was, but I did try to
remove the really obvious ones!
It was the first wiki page I've done, so go ahead and flame me if I did
something wrong ;-)
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
From: Marco Baringer
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <m2n04mrnt2.fsf@bese.it>
William Bland <····@abstractnonsense.com> writes:
> The only problem at the moment is I don't know what C libraries I should
> look at. Does anyone maintain a list of good C libraries that have
> bindings and, more importantly, ones that do not yet? Such a list might
> be a good resource for people like me to use as a TODO list.
A list of c libs for which no bindings exist? it'd be pretty long :)
For starters you could take a look at icu, sdl, gtk or posix, or you
could work on ffigen. If you want to make bindings for something than
just pick something, you, personally, use and write the bindings. It
doesn' neccessarily have to be immediatly usefull to anyone other than
yourself.
--
-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
Kenny Tilton <·······@nyc.rr.com> said:
>Mike Kozlowski wrote:
>> Also, and I might be completely off-base here, it seems to me that the
>> existence of a closed-source commercial Lisp with a better
>> implementation (and, presumably, libraries) than any of the open
>> source ones, really hurts.
>
>Good point. The uncommercial languages have an advantage in that regard.
A couple of other points: 1) In order to use it at work, it has to
have enough libraries to pass the credibility test, or it has to have
some other huge advantage that can be credibly communicated to
management. The latter is very hard work, which slows down the meme.
(Even if Lisp had fantastic libraries it would take some work, because
it doesn't have the name recognition that comes from a big marketing
effort.)
2) In order for newbies to get quick successes, it helps a lot if
there are enough decent libraries (and they are easy enough to
install) to achieve quick successes. Java has this. Perl has this.
Python has at least some of this. It's tougher in Lisp.
That there are so many of us _still_ interested is a tribute to how
good the underlying language is; it rocks. But we have a ways to go...
Oh, and we all know the Free Software Fairy isn't going to leave it
under our pillow. But asking newbies to make up the difference
probably won't work. Some of us like to build up our confidence in
private...
adam connor wrote:
> .... But asking newbies to make up the difference
> probably won't work. Some of us like to build up our confidence in
> private...
Fair enough. On the other hand, FFI work requires a good understanding
of C (I think) and has the advantage of not requiring a lot of original
Lisp code, just enough to prove the bindings work, and then you are a
hero. Getting back to the C bit, esp. if the library is a C++ library,
one can contribute just by writing a pure-C interface to the C++.
I understand about the fear of public failure, but the flip side is that
one gets to work alongside Lisp gurus on day one.
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
adam connor <···················@mail.com> writes:
> Oh, and we all know the Free Software Fairy isn't going to leave it
> under our pillow. But asking newbies to make up the difference
> probably won't work. Some of us like to build up our confidence in
> private...
I can attest to that. I didn't mind posting fractal code because that
was really just recreational programming. That is, there was no
intent on building any kind of product from it or even reusable
library.
On the other hand, I'm working on a Lisp side interface to Apache +
mod_lisp. I am fully aware of the cl-modlisp package that depends on
kmrcl and other code based on modlisp.lisp (examples are in the
package that modlisp.c is in).
The basic deal is that I have my own ideas on what a Lisp application
server should look like and want to write my own framework using SBCL
(chosen for its native threads capability on Linux).
I still have a few pieces that need to be assembled. I'm writing it
as an ASDF package from the ground up and I have already hard coded
sb-thread use into it. I will probably also be hard coding
sb-bsd-socket into it. On top of all that, it looks like because Lisp
seems to care about binary streams vs character streams I will do this
on top of binary streams because I want to be able to handle all mime
types.
My dilema is that I am not really ready to share code yet. I have no
confidence. At the same time, early review could be a good thing. At
least I don't have much code written yet.
The architecture I am working on is based on an abandoned project I
started some time back (around 1997 I think) in Java. I was working
on a full blown HTTP front end that would essentially map URIs to
function calls (in a Java interface). Now what I am doing is leaving
the HTTP handling to Apache and seeing if mod_lisp is a good
communications channel to a running Lisp where URIs will get mapped to
function calls in Lisp.
I've got the high level view in my head. It's really just a matter of
getting it down in working Lisp code. There are some technical
details also like being able to slam the socket closed on a bogus
request so that I don't have to read all the data in. That one isn't
super high on my priority list, but it is fairly high on my nice to
have list.
So this Lisp thing that I am not ready to share yet would be an
alternative to cl-modlisp that a Lisp web application would sit on.
'((Apache mod_lisp) (my-apache-listener (web-app1 web-app2 web-appN)))
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
On Wed, 05 May 2004 20:33:38 -0500, adam connor wrote:
> Oh, and we all know the Free Software Fairy isn't going to leave it
> under our pillow. But asking newbies to make up the difference
> probably won't work. Some of us like to build up our confidence in
> private...
Yeah I know... but I have the attitude that I'll never learn anything
*really* worth knowing if I don't take a few risks now and then, and look
stupid every so often.
Expect to see my first attempts at UFFI code soon, most likely complete
with laughable newbie mistakes that you can all laugh at... don't worry,
I've got a thick skin ;-)
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
On Wed, 05 May 2004 20:33:38 -0500, adam connor wrote:
> A couple of other points: 1) In order to use it at work, it has to
> have enough libraries to pass the credibility test, or it has to have
> some other huge advantage that can be credibly communicated to
> management. The latter is very hard work, which slows down the meme.
> (Even if Lisp had fantastic libraries it would take some work, because
> it doesn't have the name recognition that comes from a big marketing
> effort.)
>
> 2) In order for newbies to get quick successes, it helps a lot if
> there are enough decent libraries (and they are easy enough to
> install) to achieve quick successes. Java has this. Perl has this.
> Python has at least some of this. It's tougher in Lisp.
>
> That there are so many of us _still_ interested is a tribute to how
> good the underlying language is; it rocks. But we have a ways to go...
>
> Oh, and we all know the Free Software Fairy isn't going to leave it
> under our pillow. But asking newbies to make up the difference
> probably won't work. Some of us like to build up our confidence in
> private...
Common Lisp is in an "interesting" position at this moment. Although
there's no doubt that it's much more productive than other languages,
there's also this fuzzy perception that it doesn't "connect" well with
the new technologies that pop up every day. Even in these days of Web
Services where we can hide Common Lisp behind a server and develop web
applications much easier than, say, with Java, there's always the
problem of being able to deal with new requirements that, somehow,
involve other technologies and/or other "standards". Can we overcome
this problem? I've been thinking about this in the last few years and
I would like to share the following simple ideas (and receive all the
criticisms you want to give me):
- We should be ready to accept that new technologies are constantly
emerging
- We cannot compete with Java in the embracing of these
technologies.
Let me justify the previous statements.
First, regarding the emergence of new technologies.
I google a bit and I could find that, from 1975 till 2004, we saw the
following "standards" for web services (surely, I'm missing many other
related standards):
EDI, CORBA, COM, RPC, RMI, HTTP, HTML, XML, ASN.1, BER, NDR, XDR, CDR,
JRMP, GIOP/IIOP, DCE/DCOM, ONC, XML-RPC, XML-Schema, WDDX, SOAP, WSDL,
UDDI, RSS, ETC :-)
Many of these standards came out in the last few years. Why would
they stop here? There are people that are being paid to invent new
"standards" (even if these "standards" have the same name but a
different version number). IMHO, we should expect more and more
"standards".
Second, regarding competition with Java.
I also google a bit for the following terms:
Java 67 300 000 hits.
Lisp 2 350 000 hits.
Common Lisp 698 000 hits.
First conclusion: in spite of the growing interest in Common Lisp, we
are still extremely small and the tendency (IMHO) is for the
difference to increase. Let's now see how Common Lisp deals with two
randomly choosen "standards":
EDI 1 900 000 hits.
EDI + Java 249 000 hits.
EDI + Common Lisp 4 880 hits.
UDDI 491 000 hits.
UDDI + Java 123 000 hits.
UDDI + Common Lisp 598 hits.
I know that most of these hits are just irrelevant and if I was
seaching for some sort of library that can deal with, say, EDI, just a
small percentage of those hits would be useful. The obvious result is
that I have a much higher probability of finding something relevant in
Java than in Common Lisp.
This is not surprising given the huge momentum that Java enjoys.
Either because Sun and IBM are pouring billions of dollars in the
language or because it atracted thousands of C++ programmers, or
because of many other reasons, the fact is that it is impossible for
the Common Lisp community to fight this war.
Even in universities, Java is replacing other (better) languages (such
as Smalltalk) based on the argument that it's more useful to the
students to learn something that they will probably use when they
finish their graduation. I don't agree with this view and I fight
this decision in all university meetings but, again, it is hard to
stop it.
So, let me repeat the question: how can we overcome this problem?
The only solution I see is to take advantage of the Java language and
use it in our own benefit. We must become Java parasites. My idea is
to suck Java blood to feed my Lisp projects. It tastes badly, but the
projects survive :-)
I used this aproach with Per Bothner's Kawa many years ago and I
follow it now with Linj. Linj was made to solve one particular problem
which is to develop in a Common Lisp-like style but produce readable Java
source code that I can deliver to other Java maintainers and, obviously
integrate with Java libraries.
But Linj is not the final solution. Due to the requirement that
Linj's output must be readable Java code, there are many Common Lisp
features that Linj can't use because they are really hard to translate
to readable Java. But if we drop this requirement (and there are
lots of application areas where we can do it), we can explore the full
power of Common Lisp and, at the same time, take advantage of the huge
Java momentum. What I think we really need is a Common Lisp compiler
with a backend for JVM and that integrates with Java as smoothly as
Linj does. Will it be Armed Bear Lisp? I don't know. But I know
that it might be easier to develop one Common Lisp compiler backend
that can take advantage of all the libraries being developped for Java
than to write a different Common Lisp library for each new technology.
Antonio Leitao
Antonio Menezes Leitao <··············@evaluator.pt> said:
>But Linj is not the final solution. Due to the requirement that
>Linj's output must be readable Java code, there are many Common Lisp
>features that Linj can't use because they are really hard to translate
>to readable Java. But if we drop this requirement (and there are
>lots of application areas where we can do it), we can explore the full
>power of Common Lisp and, at the same time, take advantage of the huge
>Java momentum. What I think we really need is a Common Lisp compiler
>with a backend for JVM and that integrates with Java as smoothly as
>Linj does. Will it be Armed Bear Lisp? I don't know. But I know
>that it might be easier to develop one Common Lisp compiler backend
>that can take advantage of all the libraries being developped for Java
>than to write a different Common Lisp library for each new technology.
I'll buy that, but despite Java's enormous lead in libraries, it's not
quite as desperate as you make it sound. An example: I can think of
three good Java regexp libraries off the top of my head, and I'm
pretty sure I've seen more. But I don't need three; one is sufficient.
This is what allows the Macintosh to survive in a world dominated by
Windows.
That is not to say that a compile-to-bytecode approach doesn't have
merit. Is the JVM a good place for hosting dynamic languages? Reports
seem to vary...
Mike Kozlowski <···@klio.org> writes:
> Dozens of shitty, incomplete libraries are not a promising start on a
> semi-standard, good library; they're just clutter.
Perl started out that way. Python started out that way. And so on.
Since XML has become an industry standard (for better or worse) as a
data exchange format, I suppose it would indeed be a good idea to pick
a CL XML parser and finish it for full SAX, DOM, and whatever else is
needed type functionality.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7bsg1$k1c$1@reader2.panix.com>
In article <··············@david-steuber.com>,
David Steuber <·····@david-steuber.com> wrote:
>Mike Kozlowski <···@klio.org> writes:
>
>> Dozens of shitty, incomplete libraries are not a promising start on a
>> semi-standard, good library; they're just clutter.
>
>Perl started out that way. Python started out that way. And so on.
It occurs to me that what I'm tripping on, to some extent, is that
Common Lisp is an _old_ language, and I'd expect it to be more mature
and developed than Python and Perl, not sitting around with Ruby in
the hot-new-thing category...
--
Mike Kozlowski
http://www.klio.org/mlk/
From: ·········@random-state.net
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7c2p6$94eon$1@midnight.cs.hut.fi>
Mike Kozlowski <···@klio.org> wrote:
> It occurs to me that what I'm tripping on, to some extent, is that
> Common Lisp is an _old_ language, and I'd expect it to be more mature
> and developed than Python and Perl, not sitting around with Ruby in
> the hot-new-thing category...
It is wierd, yes. In a sense CL is both old and new:
* It's a Lisp, and as such it's pushing fifty years, right there with
Fortran.
* Even Common Lisp is fairly old: the activity that resulted in Common
Lisp started (afaict) in 1981 (five years after Smalltalk-76), and
CLtL1 was published in 1984, making it about the same age with C++ and
early Perl.
* Even the more recognizable form presented in CLtL2 is "old": published
in 1990, it hits the same timeframe with GvR writing Python, and Dylan
and Haskell appearing on the scene.
* The ANSI standard was published 1994, just a bit before Java was
released and Ruby hit 1.0.
* I'm under the impression that after the stadard was published it still
took some years before major implementations were "essentially
conformant", but I may be mistaken. A historical perspective on this
from someone in the know would be fascinating.
* The resurgent interest and open source activity is newer still -- but I
can't think of a reasonable way to date it.
So, Common Lisp the Idea is over 20 years old, but standardized Common
Lisp as we know it, with high quality implementations (both commercial an
open source), is -- depending on your emphasis -- from ten to five years
old. In other words: CL really is the hot new thing, but unlike most hot
new things it has the benefit of experience. ;-)
As I was looking up the dates for this, it really struck home how badly CL
must have been hurt mindsharewise by the loooong standardization process,
Dylan appearing and (or so I've understood) essentially forking the
community just as the standard was settling down, and then Java hype
coming along right after the standard was finally published.
Cheers,
-- Nikodemus
From: Paul F. Dietz
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <HYWdnQs276s53Afd4p2dnA@dls.net>
Mike Kozlowski wrote:
> It occurs to me that what I'm tripping on, to some extent, is that
> Common Lisp is an _old_ language, and I'd expect it to be more mature
> and developed than Python and Perl, not sitting around with Ruby in
> the hot-new-thing category...
Lisp needed suitably powerful and cheap hardware before it really
came into its own. When that kind of hardware became available,
other languages also popped up to occupy the niche.
Paul
David Steuber wrote:
> Since XML has become an industry standard (for better or worse) as a
> data exchange format, I suppose it would indeed be a good idea to pick
> a CL XML parser and finish it for full SAX, DOM, and whatever else is
> needed type functionality.
I'm not quite sure, but AFAIK, SAX is that kind of XML-Parser (are there
others?) that works by calling some customized functions when encountering
a starting tag, closing tag, attribute, etc ...
Maybe that's quite useful for parsing whole files, dunno, but isn't it
really awful if you have dependencies, e.g. when I want to find a special
element inside another special element with some special attribute? (then
you have to substitute the element matching functions when the first
condition applies)
My solution to this kind of prob (which can only be implemented in CL, I
think) is to create a kind of regular expression parser for trees with
embeddable code.
I'm currently working on something like this, on the one hand to get
practice in CL, OTOH because I think it might be really useful as a
flexible framework for information extraction from XML/HTML-files.
I'll give an announcement here when it's in a presentalbe state.
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c7c05t$l82$1@reader2.panix.com>
In article <················@news.CIS.DFN.DE>,
Thomas Schilling <······@yahoo.de> wrote:
>David Steuber wrote:
>> Since XML has become an industry standard (for better or worse) as a
>> data exchange format, I suppose it would indeed be a good idea to pick
>> a CL XML parser and finish it for full SAX, DOM, and whatever else is
>> needed type functionality.
>
>I'm not quite sure, but AFAIK, SAX is that kind of XML-Parser (are there
>others?) that works by calling some customized functions when encountering
>a starting tag, closing tag, attribute, etc ...
>
>Maybe that's quite useful for parsing whole files, dunno, but isn't it
>really awful if you have dependencies, e.g. when I want to find a special
>element inside another special element with some special attribute? (then
>you have to substitute the element matching functions when the first
>condition applies)
SAX is very low-level; to detect nestings like that, you need to build
a state machine with your callback functions/event handlers. The
point of SAX is to be able to read an XML document as it comes in,
without first building an in-memory tree (which is infeasible for,
say, a 150MB XML file).
These days, most people would probably use a pull parser like .NET's
XmlReader, for that sort of situation...
>My solution to this kind of prob (which can only be implemented in CL, I
>think) is to create a kind of regular expression parser for trees with
>embeddable code.
You mean XPath?
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski <···@klio.org> said:
>In article <················@news.CIS.DFN.DE>,
>Thomas Schilling <······@yahoo.de> wrote:
>>Maybe that's quite useful for parsing whole files, dunno, but isn't it
>>really awful if you have dependencies, e.g. when I want to find a special
>>element inside another special element with some special attribute? (then
>>you have to substitute the element matching functions when the first
>>condition applies)
>
>SAX is very low-level; to detect nestings like that, you need to build
>a state machine with your callback functions/event handlers. The
>point of SAX is to be able to read an XML document as it comes in,
>without first building an in-memory tree (which is infeasible for,
>say, a 150MB XML file).
Just to follow up; SAX is very low-level, but it forms a good basis
for layering other tools on top -- and because it is standardized, one
has some freedom in mixing and matching the layers. This is a good
thing. It would be nice if Java had something similar.
It really is a weakness in this context that Lisp has no central,
canonical, open source implementation; that helps communities built
around langauges like Perl and Python focus on building useful
extensions. (And even Java, which is not open source, benefits from
this.) While having an ANSI standard is great, the multi-vendor nature
of Lisp means there are lots of solutions that only work on a
particular platform; for example, I've been looking at SSL sockets
libraries and it seems to be a patchwork of such implementations, as
well as bindings to C-level libraries. (Maybe I'm missing
something...)
Urk. I don't really mean to carp. It is a fantastic language. I'm just
spoiled by working in Java, where someone else has always done most of
my work for me.
adam connor <···················@mail.com> said:
>thing. It would be nice if Java had something similar.
um, it would be nice if Lisp had something similar, I meant.
Mike Kozlowski wrote:
>> My solution to this kind of prob (which can only be implemented in CL, I
>> think) is to create a kind of regular expression parser for trees with
>> embeddable code.
>
> You mean XPath?
Uhm, actually more something linke XSLT. But a little more usable (i.e.
legible). E.g. this could be a possible usage:
(let ((links 0))
(match-html (some-file)
(:somewhere ;; match not only at top-level
((:or
("i" ("a")) ;; find a <A>-tag inside an <I>
("a" ("i"))) ;; or the other way round
(incf links)))) ;; <- embedded code
(format t "italic links: ~a~%" links))
Well, ok, maybe it's more like some data extraction tool, but I think it
could even be used for transformation work.
www.cl-xml.org
Be patient with the web site and with the documentation. But most of it
is already there.
Cheers
--
marco
Thomas Schilling wrote:
> David Steuber wrote:
>
>> Since XML has become an industry standard (for better or worse) as a
>> data exchange format, I suppose it would indeed be a good idea to pick
>> a CL XML parser and finish it for full SAX, DOM, and whatever else is
>> needed type functionality.
>
>
> I'm not quite sure, but AFAIK, SAX is that kind of XML-Parser (are there
> others?) that works by calling some customized functions when
> encountering a starting tag, closing tag, attribute, etc ...
>
> Maybe that's quite useful for parsing whole files, dunno, but isn't it
> really awful if you have dependencies, e.g. when I want to find a
> special element inside another special element with some special
> attribute? (then you have to substitute the element matching functions
> when the first condition applies)
>
> My solution to this kind of prob (which can only be implemented in CL, I
> think) is to create a kind of regular expression parser for trees with
> embeddable code.
>
> I'm currently working on something like this, on the one hand to get
> practice in CL, OTOH because I think it might be really useful as a
> flexible framework for information extraction from XML/HTML-files.
>
> I'll give an announcement here when it's in a presentalbe state.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun02-001@Yahoo.Com>
> From: Mike Kozlowski <···@klio.org>
> Except that a hundred half-assed, unfinished librarylets are, in some
> ways, more irritating than nothing at all.
If you're expecting to just grab a fully working fully documented
library and use it in an application, I agree. But if you're planning
to develop such a library yourself, a large number of starts may be
enlightening as to the ways the task can be approached, to avoid
putting a lot off effort into a single idea that comes to your mind
only to discover you totally overlooked a better way.
> After digging through all the resources I can find -- Cliki,
> common-lisp.net, archives of this newsgroup, mailing lists -- and
> asking questions, I finally managed to find an XML parser that
> actually works in clisp, xmls.
What, a hundred XML parser wannabes but only one of them actually
works? What do the others do? Just bomb out the first time you feed
them anything whatsoever? Work fine on some kinds of data but bomb out
on others? Never bomb but gloss over lots of information you wish
they'd properly process? A reasonable next step for you (to help the CL
community) would be to document what you discovered: For each alleged
XML parser you found, tell where you found it (URL or whatever), what
happened when you tried to load it into various versions of CL that you
have available, and what happened when you tried to use it to parse
various XML test data (you please list URLs of such test data, either
that you found readily available, or that you created yourself and now
have on your own WebSite). Since you already went to the work of trying
these many alleged XML parsers, you have much of the work already done
in evaluating them, you merely need to write up what you already
learned about each, sort of like Consumer Reports.
> Except that it's a half-assed, incomplete parser that doesn't emit
> XML declarations on output, or take into account things like
> character sets at all.
And of course for that one XML parser that worked at all, likewise you
need to document what sample XML input you gave it and what it did with
it and what it didn't do that you say it should have done.
> And even once it's parsed, well, great, now I have this nifty
> s-expression representation... that won't work with any other tool in
> the known universe.
Well that's hardly a valid complaint. After all you wanted a parser,
not an interface to other specific tools that exist. If the parser had
properly organized all the data within the original XML input, then
presumably it wouldn't have been difficult to generate any desired
format from that, whatever format is needed to interface to your
favorite existing tool. But all you can reasonably expect the parser
itself to do is correctly collect each important piece of data and
correctly organize all these pieces in a hierarchial structure that
shows their correct nested-semantic relationships as intended by the
input syntax, making it relatively easy for a subsequent program to
traverse the parse tree to explore deeper semantic relationships.
> if there wasn't any XML parser at all, it'd be an obvious problem,
> and you could get a group of people together to, you know, make a
> standard one. But because "it's so easy!" to do things in CL, you've
> got a half-dozen implementations that do all the easy parts of XML
> parsing, and there's no chance at all for a standard, good parser.
Well it's *relatively* easy to do things in CL compared to doing them
in other languages, but some tasks are difficult in *any* language, and
I guess the people who started work on those various XML parsers didn't
realize how difficult that task would be before they bravely started
work, and didn't have funding to finish the task, but felt their start
might be useful to somebody with funding or free time on their hands,
so they volunteered their incomplete code to the online repository.
Despite your feelings to the contrary, I feel it's good that CL is so
easy that so many people were able to individually make some progress,
and only sad that all these people except the earliest couldn't have
known of earlier efforts before starting out from scratch again. But if
you would nicely document what they have and haven't accomplished
so-far, maybe the next person starting from your document would be able
to pick which unfinished code is the best approach and pick up where
that person left off instead of starting from scratch one more time.
At the very minimum, would you be willing to simply list the URLs of
the source code of each of those incomplete XML parsers, grouped
according to which won't even load into CL because they're
syntactically incorrect or require other stuff you can't locate, which
load but don't work even the slightest on rather simple test data you
present via another URL, and which pass the simple-test but fail on
slightly more difficult test data which you present via another URL?
From: John Thingstad
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <opr82fh6napqzri1@mjolner.upc.no>
Grinding documantation is easier in java than lisp. JavaDoc
On Wed, 02 Jun 2004 19:08:53 -0700, <··········@YahooGroups.Com> wrote:
>> From: Mike Kozlowski <···@klio.org>
>> Except that a hundred half-assed, unfinished librarylets are, in some
>> ways, more irritating than nothing at all.
>
> If you're expecting to just grab a fully working fully documented
> library and use it in an application, I agree. But if you're planning
> to develop such a library yourself, a large number of starts may be
> enlightening as to the ways the task can be approached, to avoid
> putting a lot off effort into a single idea that comes to your mind
> only to discover you totally overlooked a better way.
>
>> After digging through all the resources I can find -- Cliki,
>> common-lisp.net, archives of this newsgroup, mailing lists -- and
>> asking questions, I finally managed to find an XML parser that
>> actually works in clisp, xmls.
>
> What, a hundred XML parser wannabes but only one of them actually
> works? What do the others do? Just bomb out the first time you feed
> them anything whatsoever? Work fine on some kinds of data but bomb out
> on others? Never bomb but gloss over lots of information you wish
> they'd properly process? A reasonable next step for you (to help the CL
> community) would be to document what you discovered: For each alleged
> XML parser you found, tell where you found it (URL or whatever), what
> happened when you tried to load it into various versions of CL that you
> have available, and what happened when you tried to use it to parse
> various XML test data (you please list URLs of such test data, either
> that you found readily available, or that you created yourself and now
> have on your own WebSite). Since you already went to the work of trying
> these many alleged XML parsers, you have much of the work already done
> in evaluating them, you merely need to write up what you already
> learned about each, sort of like Consumer Reports.
>
>> Except that it's a half-assed, incomplete parser that doesn't emit
>> XML declarations on output, or take into account things like
>> character sets at all.
>
> And of course for that one XML parser that worked at all, likewise you
> need to document what sample XML input you gave it and what it did with
> it and what it didn't do that you say it should have done.
>
>> And even once it's parsed, well, great, now I have this nifty
>> s-expression representation... that won't work with any other tool in
>> the known universe.
>
> Well that's hardly a valid complaint. After all you wanted a parser,
> not an interface to other specific tools that exist. If the parser had
> properly organized all the data within the original XML input, then
> presumably it wouldn't have been difficult to generate any desired
> format from that, whatever format is needed to interface to your
> favorite existing tool. But all you can reasonably expect the parser
> itself to do is correctly collect each important piece of data and
> correctly organize all these pieces in a hierarchial structure that
> shows their correct nested-semantic relationships as intended by the
> input syntax, making it relatively easy for a subsequent program to
> traverse the parse tree to explore deeper semantic relationships.
>
>> if there wasn't any XML parser at all, it'd be an obvious problem,
>> and you could get a group of people together to, you know, make a
>> standard one. But because "it's so easy!" to do things in CL, you've
>> got a half-dozen implementations that do all the easy parts of XML
>> parsing, and there's no chance at all for a standard, good parser.
>
> Well it's *relatively* easy to do things in CL compared to doing them
> in other languages, but some tasks are difficult in *any* language, and
> I guess the people who started work on those various XML parsers didn't
> realize how difficult that task would be before they bravely started
> work, and didn't have funding to finish the task, but felt their start
> might be useful to somebody with funding or free time on their hands,
> so they volunteered their incomplete code to the online repository.
> Despite your feelings to the contrary, I feel it's good that CL is so
> easy that so many people were able to individually make some progress,
> and only sad that all these people except the earliest couldn't have
> known of earlier efforts before starting out from scratch again. But if
> you would nicely document what they have and haven't accomplished
> so-far, maybe the next person starting from your document would be able
> to pick which unfinished code is the best approach and pick up where
> that person left off instead of starting from scratch one more time.
>
> At the very minimum, would you be willing to simply list the URLs of
> the source code of each of those incomplete XML parsers, grouped
> according to which won't even load into CL because they're
> syntactically incorrect or require other stuff you can't locate, which
> load but don't work even the slightest on rather simple test data you
> present via another URL, and which pass the simple-test but fail on
> slightly more difficult test data which you present via another URL?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun08-002@Yahoo.Com>
> From: Kenny Tilton <·······@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.
··········@YahooGroups.Com wrote:
>>From: Kenny Tilton <·······@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.
Gee, I thought it was scatological and self-deprecating.
Say, are you the one who trashed the Young Lispers page on cliki a year
or so ago in protest over the perceived age discrimination? <busted>
:)
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
On Mon, 03 May 2004 19:22:19 -0500, adam connor wrote:
> ··········@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.
I agree.
> 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.
But you can take advantage of all of them without loosing (entirely) the
Lisp flavour.
>
> 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. :-(
That's one reason I decided to invent Linj. You can explore (some of) the
abstraction mechanisms we have in Common Lisp and generate (readable) Java
programs automatically.
> [...]
> 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.
Another good selling point for Linj.
When I need to use something that I know someone has already done, I just
google for 'Java' and 'something'. I always find a jar that solves the
problem and that I can explore in Linj. OTOH, if I need to invent
something that (probably) no one has invented before, then I develop it in
Common Lisp and latter, if need arises, I add some time declarations and
make it run in Linj.
Antonio Leitao.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun01-001@Yahoo.Com>
> From: adam connor <···················@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=MPG.181d3bff87e5e3019896bc%40news.altopia.com
http://www.google.com/groups?selm=MPG.189cdcc34068c297989849%40news.altopia.com
http://www.google.com/groups?selm=MPG.19fa15acd99503139896f9%40news.pop4.net
http://www.google.com/groups?selm=4007efbe%241%40giga.realtime.net
http://jakarta.apache.org/commons/httpclient/features.html
http://jakarta.apache.org/commons/httpclient/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.
··········@YahooGroups.Com writes:
> > From: adam connor <···················@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.
From: André Thieme
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c9lh61$4c2$1@ulric.tng.de>
··········@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�
--
<··········@YahooGroups.Com> wrote in message
······················@Yahoo.Com...
> > From: adam connor <···················@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: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun20-004@Yahoo.Com>
> From: "Alex Kay" <···@spam.not>
> Cookie is in javax.servlet.http
I'm looking at:
http://java.sun.com/j2se/1.4.2/docs/api/overview-summary.html
but I don't see any mention of ...servlet..., guessing:
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/package-summary.html
no mention there either, also none here either:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/package-summary.html
Ah, I looked in Enterprise Edition, and found it:
http://java.sun.com/j2ee/1.4/docs/api/overview-summary.html
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/package-summary.html
Unfortunately that's not free, and it deals only with the server end
which is the other end from what I'm wishing to program.
On the off chance my ISP has j2ee, I tried to import it, no it fails:
Package javax.servlet.http not found in import.
As I understand it, what I need is a static variable that holds a jar
full of cookies (or a local variable I keep passing around everywhere),
whatever the server has sent me so-far, a method that puts new cookies
into the jar when parsing the header from the server, and a method that
compares my next request URL with the cookies in the jar and transmits
all appropriate cookies with my request, right? If I ever get the
energy, I'll just have to write it from scratch using CL...
On Mon, 03 May 2004 20:14:33 +0000, Wade Humeniuk wrote:
> ··········@YahooGroups.Com wrote:
> <Some Observations and a question(s)>
>
> Of course. Its easier to write Java programs in Java.
>
> Wade
Not entirely true. Although I've only barely played around with it, linj
(http://www.evaluator.pt/linj.html) looks like it makes it easier to write
java programs in a lisp than in java.
Andy
Andrew Cristina wrote:
> On Mon, 03 May 2004 20:14:33 +0000, Wade Humeniuk wrote:
>
>> ··········@YahooGroups.Com wrote:
>> <Some Observations and a question(s)>
>>
>> Of course. Its easier to write Java programs in Java.
>>
>> Wade
>
> Not entirely true. Although I've only barely played around with it,
> linj (http://www.evaluator.pt/linj.html) looks like it makes it easier
> to write java programs in a lisp than in java.
Yep, and it just did my homework for me.
A bit of documentation, and... :P
On Tue, 04 May 2004 12:06:45 +0200, Svein Ove Aas wrote:
> Andrew Cristina wrote:
>
>> On Mon, 03 May 2004 20:14:33 +0000, Wade Humeniuk wrote:
>>
>>> ··········@YahooGroups.Com wrote:
>>> <Some Observations and a question(s)>
>>>
>>> Of course. Its easier to write Java programs in Java.
>>>
>>> Wade
>>
>> Not entirely true. Although I've only barely played around with it,
>> linj (http://www.evaluator.pt/linj.html) looks like it makes it easier
>> to write java programs in a lisp than in java.
>
> Yep, and it just did my homework for me.
> A bit of documentation, and... :P
Humm, you can include (some) documentation in Linj source code:
(defun f ()
"This is a very interesting function. It returns 1"
1)
(defclass g ()
((one-slot :initform 1 :documentation "This slot is initialized with 1")
(two-slot :initform 2 :documentation "This slot is initialized with 2")))
In Java:
public class Documentation extends Object {
// methods
// This is a very interesting function. It returns 1
public static int f() {
return 1;
}
}
class G extends Object {
// slots
// This slot is initialized with 1
protected int oneSlot =
1;
// This slot is initialized with 2
protected int twoSlot =
2;
}
You can also tweak the documentation a bit (like avoid writing the //slots
or //methods). But I know that I need to work a bit more to
improve it provide other documentation hooks.
Thanks,
Antonio Leitao.
PS: Take a carefull look at Linj output before submiting it as homework.
It may contain code that a Java programmer would never write.
··········@YahooGroups.Com wrote in message news:<·················@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.
Dammit, I didn't realize this was crossposted. Keep in mind that I
prefer Common Lisp greatly to Java. Despite Java having some
advantages.
···········@yahoo.com (Tayssir John Gabbour) wrote in message news:<····························@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.
On Mon, 03 May 2004 20:23:49 -0700, Tayssir John Gabbour wrote:
>
>> So I ask, is there any particular kind of task where java has an
>> advantage over LISP?
If I'm allowed to include Linj in the Lisp family, then the answer is 'no'.
> Applet security. People mention applets are dead, but I am not
> concerned with popularity in this case.
Linj allows you to create applets.
> READ in lisp is deadly. The fact *read-eval* can be set is irrelevant;
> there should be syntactic sugar like say SAFEREAD. Or something.
Linj allows provides you with a (limited-capabilities) READ but you can
write your own.
> Bunch o libraries, dunno...
Linj can use them.
> Friendly package system.
Linj takes advantage of it.
> Weak pointers/tables as standard, though I dunno how pervasive it is in
> CL implementations.
Linj has them.
> Portable.
Humm. The Linj compiler is as portable as Common Lisp code is. [Given the
current state of Common Lisp implementations regarding the standard, I
would say that Linj is not ver portable (see thread 'The Hyperspec and
portability between Common Lisp compilers (long)') but it runs in CMUCL,
SBCL and Allegro in Linux. As soon as I have time, I'll try to make it
run in MacOS].
The output from the Linj compiler is as portable as Java is.
> Graphics.
Linj has them.
> Concurrency or reasonable facsimile thereof.
Linj has it.
> Drags people halfway to lisp because of its braces 'n semicolon UI.
Linj drags people 3/4 way to lisp because it doesn't have braces (but you
can use semicolon to make comments :-)
> One can often rob lisp and claim to invent something new in Java.
Linj robbed everything from Lisp.
> Pain, terror, anguish, McDonald's.
Quick, take a Linj pill :-)
Antonio Leitao.
From: Mike Kozlowski
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c78ec4$lqi$1@reader2.panix.com>
In article <······························@evaluator.pt>,
Antonio Menezes Leitao <··············@evaluator.pt> wrote:
>On Mon, 03 May 2004 20:23:49 -0700, Tayssir John Gabbour wrote:
>>
>>> So I ask, is there any particular kind of task where java has an
>>> advantage over LISP?
>
>If I'm allowed to include Linj in the Lisp family, then the answer is 'no'.
It's worth noting that (according to your Web site), Linj's license is
significantly more restrictive than Java's...
--
Mike Kozlowski
http://www.klio.org/mlk/
On Tue, 04 May 2004 15:54:44 +0000, Mike Kozlowski wrote:
> In article <······························@evaluator.pt>, Antonio
> Menezes Leitao <··············@evaluator.pt> wrote:
>>On Mon, 03 May 2004 20:23:49 -0700, Tayssir John Gabbour wrote:
>>>
>>>> So I ask, is there any particular kind of task where java has an
>>>> advantage over LISP?
>>
>>If I'm allowed to include Linj in the Lisp family, then the answer is
>>'no'.
>
> It's worth noting that (according to your Web site), Linj's license is
> significantly more restrictive than Java's...
Yes, that's a fact. I'm (really) sorry that I don't have as much money to
invest on Linj as Sun has to invest on Java. If I had, believe me, I
would give Linj for free (and I would also give lots of other things for
free).
Although the original question was related to tasks and not to licensing
issues, I agree that Linj and Java have different licensing terms that may
give Java an advantage. My claim is that there are (many) other
advantages on Linj's side.
Antonio Leitao.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun04-003@Yahoo.Com>
> From: ···········@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: Lowell Kirsh
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c77j6f$o94$1@mughi.cs.ubc.ca>
Any of you heard of BeanShell? It's a REPL for Java. It's not bad, actually.
Lowell
··········@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.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun11-001@Yahoo.Com>
> From: Lowell Kirsh <······@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?
··········@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
On Tue, 04 May 2004 02:11:30 +0200, Kristian Elof S�rensen wrote:
> > 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.
Not exactly the same thing but you can take a look at the Beanshell
(www.beanshell.org) to see a (kind of) repl. I also use the Beanshell
in my Linj compiler (see below) to provide an interactive environment
for Java development with Lisp.
> 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.
You mean this?
(defun map-list (l f)
(declare (abstract-list l) (procedure f))
(dotimes (i (size l))
(funcall f (get l i))))
(defun main ()
(let ((v (new 'Vector)))
(add v "One")
(add v "Two")
(map-list v #'(lambda (e) (format t "Elem: ~A~%" e))) ;;no variable capture
(let ((copy (new 'Vector)))
(map-list v #'(lambda (e) (add-element copy e))) ;;variable capture
(print copy))))
I agree that it's painfull to do it in Java. Fortunately, the Linj
compiler will do it for you:
public static void mapList(AbstractList l, Procedure f) {
int limit = l.size();
for (int i = 0; i < limit; ++i) {
f.funcall(l.get(i));
}
}
public static void main(String[] outsideArgs) {
Vector v = new Vector();
v.add("One");
v.add("Two");
mapList(v,
new Procedure() {
public void funcall(Object e) {
System.out.print("Elem: ");
System.out.println(e);
}});
final Vector copy = new Vector(); //note: it became final
mapList(v,
new Procedure() {
public void funcall(Object e) {
copy.addElement(e);
}});
System.out.print("" + '\n' + copy + " ");
}
}
> Optional arguments and keyword arguments.
You mean this?
(defun optionals-and-keys (x &optional (y 2) &key z (w 3 w-p))
(format t "x:~A y:~A z:~A w:~A w-p:~A~%" x y z w w-p))
(defun main ()
(optionals-and-keys "Hi")
(optionals-and-keys "Hi" 1)
(optionals-and-keys "Hi" 1 :w 5)
(optionals-and-keys "Hi" 1 :w 0 :z 3))
Again, it's painful to do in Java because it requires a
lot of discipline (out of reach for lazy programmers like myself but easy
for Linj):
public static void optionalsAndKeys(Object x, int y, Object z, int w, boolean wP) {
System.out.print("x:");
System.out.print(x);
System.out.print(" y:");
System.out.print(y);
System.out.print(" z:");
System.out.print(z);
System.out.print(" w:");
System.out.print(w);
System.out.print(" w-p:");
System.out.println(wP);
}
public static void main(String[] outsideArgs) {
optionalsAndKeys("Hi", 2, null, 3, false);
optionalsAndKeys("Hi", 1, null, 3, false);
optionalsAndKeys("Hi", 1, null, 5, true);
optionalsAndKeys("Hi", 1, Bignum.valueOf(3), 0, true);
}
>
> macros
You mean this? (forget about variable capture, multiple evaluation and
such)
(defmacro do-vector ((e v) &body body)
`(dotimes (i (size ,v))
(let ((,e (get ,v i)))
,@body)))
(defun main ()
(let ((v (new 'Vector)))
(add v "One")
(add v "Two")
(do-vector (elem v)
(print v))
(let ((copy (new 'Vector)))
(do-vector (elem v)
(add copy v)))))
The usual Java replacement for macros is copy & paste (but Linj takes care
of that automatically):
public static void main(String[] outsideArgs) {
Vector v = new Vector();
v.add("One");
v.add("Two");
{
int limit = v.size();
for (int i = 0; i < limit; ++i) {
Object elem = v.get(i);
System.out.print("" + '\n' + v + " ");
}
}
Vector copy = new Vector();
int limit = v.size();
for (int i = 0; i < limit; ++i) {
Object elem = v.get(i);
copy.add(v);
}
}
> CLOS dispatches on the type of the instance where java dispatches on the
> type of the reference. Yippiiiiiiiii!!!!!!
That's not true. Just like CLOS, Java dispatches on the type of the
receiver (but there's only one receiver):
(defclass a ()
())
(defmethod to-string ((e a))
"I'm an A")
(defclass b ()
())
(defmethod to-string ((e b))
"I'm a B")
Let's put two different instances on a Vector (to force Java to forget
about the original types) and let's print them (using our previous macro):
(defun main ()
(let ((v (new 'Vector)))
(add v (make-instance 'a))
(add v (make-instance 'b))
(do-vector (e v)
(format t "Elem: ~A~%" e))))
Upon compilation and execution, you get the correct result:
Elem: I'm an A
Elem: I'm a B
Here is the corresponding Java code:
import java.util.Vector;
class A extends Object {
public String toString() {
return "I'm an A";
}
}
class B extends Object {
public String toString() {
return "I'm a B";
}
}
public class Dispatch extends Object {
public static void main(String[] outsideArgs) {
Vector v = new Vector();
v.add(new A());
v.add(new B());
int limit = v.size();
for (int i = 0; i < limit; ++i) {
Object e = v.get(i);
System.out.print("Elem: ");
System.out.println(e);
}
}
}
If you don't like the automatic to-string invocation, you can think about
any other example, but you'll have to add a common superclass or a
common interface so that Java knows that both A and B implement a
given method. But that doesn't interfere with dispatching.
Maybe you were referring to overloading. In this case, I agree that
dispatching depends on the type of the argument references. Anyway, with
optional, keyword and rest parameters, you don't need overloading.
> 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?
Because they want to atract C++ programmers?
> Built in assertations, as compared to the add-on in later versions of
> java.
You mean this?
(defun print-natural (x)
(declare (int x))
(assert (> x 0))
(print x))
The Java translation looks funny:
import linj.Cons;
import linj.Symbol;
public class Assertion extends Object {
// methods
public static void printNatural(int x) {
if (x <= 0) {
throw new Error("The assertion " +
Cons.list(Symbol.intern(">"), Symbol.intern("x"), linj.Bignum.valueOf(0)) +
" failed.");
}
System.out.print("" + '\n' + x + " ");
}
}
> The condition system does everything java exceptions does and then 10x
> more. Restart a condition etc.
Yes. That's true. But Java exceptions are not bad (with the exception of
checked exceptions) and they correspond, more or less to a
combination of unwind-protect and handler-case.
Java is not bad when we think of it as an assembly language.
Best regards,
Antonio Leitao
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may29-001@Yahoo.Com>
> From: Antonio Menezes Leitao <··············@evaluator.pt>
> Not exactly the same thing but you can take a look at the Beanshell
> (www.beanshell.org) to see a (kind of) repl.
Hmm, I looked at that, browsed the documentation for an hour or so, and
it looks interesting, especially since the whole download is less than
300k bytes, so I might be able to install it on my personal account on
my ISP without going over allocation. But there is mention of classpath
etc., and mention that something has to be somewhere in an absolute
location. I'm just one of hundreds of ordinary users on this ISP, so I
would not be allowed to install anything except in some sub-directory
within my own home directory. I currently have a ~/JavaWork/ directory,
and for BeanShell I'd like to make a second level ~/JavaWork/BeanShell/
and have absolutely everything (original jar file, all unjarred files
that result, anything then installed, etc., as well as all my source
files that use BeanShell) located in various places within that
subdirectory. But all the system java stuff, i.e. the jsp, and the
javac and java programs, would remain where they are now in system
space. Is that possible, splitting all the BeanShell specific stuff and
the java general stuff between my own sub-directory (new) and system
directories (as-is) like that? Would I need to execute some shell
command to connect up things properly, for example by setting some
system/global/shell variable classpath or somesuch, every time I log in
and want to run BeanShell again, probably need to put some shell
command in my .login or .cshrc or somewhere like that? (Note, this is
FreeBSD Unix running tcsh.)
On Tue, 04 May 2004 02:11:30 +0200, Kristian Elof S�rensen <····@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.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004may22-004@Yahoo.Com>
> From: Kristian Elof Sxrensen <····@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.
··········@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.
On 4 May 2004 03:03:51 -0700, ···········@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.
From: Frederic Brunel
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <lazn8o5zm9.fsf@in-fusio.com>
··········@YahooGroups.Com writes:
> 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?
The Java language and its associated libraries are a different
thing, be careful about that!.
ANSI Common Lisp is a language specification, more like ANSI C. For
now on, there is no JDK-like package with Common Lisp (maybe CirCLe)
but you can find all the libraries you need.
> 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.
Unicode is certainly *not* built into Java. You have 2 bytes wide
strings, but the string equality between two Unicode strings is
*not* implemented. Franz CL has a *real* support for Unicode.
--
Frederic Brunel
On Tue, 04 May 2004 11:07:58 +0200, Frederic Brunel wrote:
> ··········@YahooGroups.Com writes:
>
>> 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?
>
> The Java language and its associated libraries are a different
> thing, be careful about that!.
>
> ANSI Common Lisp is a language specification, more like ANSI C. For
> now on, there is no JDK-like package with Common Lisp (maybe CirCLe)
> but you can find all the libraries you need.
How can you know all the libraries I need? And where can I find them? Do
you have Common Lisp libraries for, say, read and write Word, Excel, DVI,
MP3, OggVorbis, PPM, TIFF, PNG? I would love to have libraries for this
stuff in Common Lisp but, unfortunately, I can only find them in Java.
>> 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.
>
> Unicode is certainly *not* built into Java. You have 2 bytes wide
> strings, but the string equality between two Unicode strings is
> *not* implemented. Franz CL has a *real* support for Unicode.
Unicode is certainly built into Java. According to the Java Language
Specification:
Lexical Structure
This chapter specifies the lexical structure of the Java programming
language.
Programs are written in Unicode (�3.1), but lexical translations are
provided (�3.2) so that Unicode escapes (�3.3) can be used to include
any Unicode character using only ASCII characters.
[...]
Also, Java characters are Unicode and Strings are made of Unicode
characters. If you look at the documentation for method length in class
String you'll find:
public int length()
Returns the length of this string. The length is equal to the number
of 16-bit Unicode characters in the string.
If you need to compare strings unicode-wise, you should use the Collator
class.
Antonio Leitao.
Antonio Menezes Leitao wrote:
>>··········@YahooGroups.Com writes:
>> Unicode is certainly *not* built into Java. You have 2 bytes wide
>> strings, but the string equality between two Unicode strings is
>> *not* implemented. Franz CL has a *real* support for Unicode.
>
>
> Unicode is certainly built into Java. According to the Java Language
> Specification:
>
> Lexical Structure
>
> This chapter specifies the lexical structure of the Java programming
> language.
>
> Programs are written in Unicode (�3.1), but lexical translations are
> provided (�3.2) so that Unicode escapes (�3.3) can be used to include
> any Unicode character using only ASCII characters.
> [...]
>
> Also, Java characters are Unicode and Strings are made of Unicode
> characters. If you look at the documentation for method length in class
> String you'll find:
>
> public int length()
>
> Returns the length of this string. The length is equal to the number
> of 16-bit Unicode characters in the string.
>
> If you need to compare strings unicode-wise, you should use the Collator
> class.
>
> Antonio Leitao.
Hi, this is my first post to cll, never mustered enough courage to ask
any question, so I'll start with a reply.
Please see
http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
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.
Regards,
-Antony
On Tue, 04 May 2004 17:48:33 +0000, Antony Sequeira wrote:
>> Antonio Leitao.
> Hi, this is my first post to cll, never mustered enough courage to ask
> any question, so I'll start with a reply.
Welcome to comp.lang.lisp.
> Please see
> http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
> 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.
Java is a moving target. The article you mentioned is from May 2004!
Anyway, the idea I got from the proposed changes is that they want to
extend the already existent (vast) support in Java for Unicode in order to
include the "Supplementary Characters" of Unicode.
Thanks for the info,
Antonio Leitao
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun12-001@Yahoo.Com>
> From: Antony Sequeira <·············@hotmail.com>
> Please see
> http://java.sun.com/developer/technicalArticles/Intl/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: Christian Hofer
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c77mv5$13l$1@online.de>
··········@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
get a job?
... just a dark thought on this rainy tuesday... hehe.
s.
<··········@YahooGroups.Com> wrote in message
······················@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.
On Tue, 04 May 2004 15:57:22 +0900, Stijn De Saeger wrote:
> get a job?
> ... just a dark thought on this rainy tuesday... hehe.
> s.
That was my problem too. I love to develop in Lisp but my clients want
Java (don't ask why). So after a few years developing in Java I decided
to build my own language. This would be as similar to Common Lisp as I
could make it and the compiler would have to produce Java code just like
I was used to write myself.
I'm not totally pleased with the result but I think it's good enough to
get you a job and also some fun doing it. My clients don't yet believe
the code was not hand-written :-)
Antonio Leitao.
Antonio Menezes Leitao <··············@evaluator.pt> writes:
> I'm not totally pleased with the result but I think it's good enough to
> get you a job and also some fun doing it. My clients don't yet believe
> the code was not hand-written :-)
Is that a good or bad reflection on typical Java code?
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
On Tue, 04 May 2004 16:41:58 +0000, David Steuber wrote:
> Antonio Menezes Leitao <··············@evaluator.pt> writes:
>
>> I'm not totally pleased with the result but I think it's good enough to
>> get you a job and also some fun doing it. My clients don't yet believe
>> the code was not hand-written :-)
>
> Is that a good or bad reflection on typical Java code?
My clients were used to my Java code (which I would classify as code
written by a Lisp programmer forced to write in Java). Linj generates
code that just tries to emulate what I would have written.
In many cases, Linj generates code very similar to typical Java code. But
if you start using lambda lists with optional, keyword or rest parameters,
method combination (:before, :after or :around), multiple values, and
all those useful features of Common Lisp, your code will start to be less
and less "typical". Although I spent a very long time fine tuning Linj to
generate "good" Java code (according to my sense of aestetics), there are
certain features that are really hard to do in "plain" Java.
Anyway, I'm always looking forward for comments regarding Linj's code
generation.
Antonio Leitao.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun05-001@Yahoo.Com>
> From: "Stijn De Saeger" <···@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.
··········@YahooGroups.Com wrote:
>>From: "Stijn De Saeger" <···@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.
The ones that get me are the "must have X years of experience in Y",
where Y is usually Java or C#/.NET and X is on the range (0,12] months
greater than the time from public announcement of Y to the date of
posting. And then they try to argue with me when I point out that Y
hasn't been around X years; when they themselves have been in the
recruiting business for significantly less than X years and I've been in
the programming business for significantly more than that.
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++.
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun14-001@Yahoo.Com>
> From: Jan Gregor <··········@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?
··········@YahooGroups.Com writes:
> > From: Jan Gregor <··········@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?
Try asking on comp.lang.java.insane-requirements.
We need a c.l.lisp.i-r too, come to think of it.
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
··········@YahooGroups.Com wrote in message news:<·················@Yahoo.Com>...
> > From: Jan Gregor <··········@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?
From: Howard Ding <······@hading.dnsalias.com>
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <m3brjkon81.fsf@frisell.localdomain>
······@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
<······@hading.dnsalias.com>
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
From: Joe Marshall
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <lliosl4a.fsf@ccs.neu.edu>
······@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.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> ······@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.
From: Joe Marshall
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <y8moo2ss.fsf@comcast.net>
Erann Gat <·········@flownet.com> writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
> wrote:
>
>> ······@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
Hello!
Joe Marshall <·············@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.
Joe Marshall <·············@comcast.net> writes:
> Erann Gat <·········@flownet.com> writes:
>
>> 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.
I don't know where this fits into the larger world of GC, but I heard
about a neat trick for some purely functional languages.
If you disallow mutation you can have the invariant that no object in
the heap points to any object newer than itself, and if you order
objects in memory from oldest to newest then all the pointers will
point "backwards." You can then mark-and-sweep the heap in a single
pass by starting at the newest object and going backwards: any object
that has not been marked by the time you reach it must be garbage,
since none of the older objects can possibly point to it.
Described in this paper:
http://citeseer.ist.psu.edu/armstrong95one.html
I think you need to ban letrec as well as mutation. No idea how
practical this is wrt other algorithms, but I think it's neat :-)
Cheers,
Luke
From: Christophe Rhodes
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <sqisdsvo6g.fsf@cam.ac.uk>
······@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)
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
From: Marco Baringer
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <m23c4walcx.fsf@convey.it>
······@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
······@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.
Mario S. Mommer <········@yahoo.com> wrote in message news:<··············@germany.igpm.rwth-aachen.de>...
> ······@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.
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
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·······················@twister.nyc.rr.com>...
> 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?
Well, I'm not really sure which of those two languages is the more
dead one ... ;-). But I would say they are both quite dead, which is a
pity for both of them. The only thing Lisp has that Smalltalk hasn't
is macros. I'm not really sure I fully comprehend the power of macros.
So I won't make a statement whether you can live without them or not.
But I think Smalltalk is more organized than Lisp and in case of
Squeak you can change the compiler/VM to add those macros to Squeak.
> confusedly, kenny
From: André Thieme
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <cas87l$t82$1@ulric.tng.de>
Oliver Plohmann schrieb:
> Well, I'm not really sure which of those two languages is the more
> dead one ... ;-). But I would say they are both quite dead, which is a
> pity for both of them. The only thing Lisp has that Smalltalk hasn't
> is macros. I'm not really sure I fully comprehend the power of macros.
> So I won't make a statement whether you can live without them or not.
> But I think Smalltalk is more organized than Lisp and in case of
> Squeak you can change the compiler/VM to add those macros to Squeak.
Did you know that Dr. Alan Kay, the inventor of Smalltalk said some few
years ago, that Lisp is "the greatest single programming language ever
designed"?
(http://www.paulgraham.com/quotes.html)
Andr�
--
Andr� Thieme <······························@justmail.de> wrote in message news:<············@ulric.tng.de>...
> Did you know that Dr. Alan Kay, the inventor of Smalltalk said some few
> years ago, that Lisp is "the greatest single programming language ever
> designed"?
> (http://www.paulgraham.com/quotes.html)
>
> Andr�
>
Hi Andr�!
I didn't know, but I'm not all that surprised. Smalltalk has many
similarities with Lisp (e.g., Smalltalk blocks and Lisp lambda
expressions, non-destructive programming, and other things).
Cheers, Oliver
From: André Thieme
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <canddp$lm9$1@ulric.tng.de>
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�
--
Andr� Thieme <······························@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)
From: Christopher C. Stacy
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <usmcvo28g.fsf@news.dtpq.com>
>>>>> On Wed, 16 Jun 2004 09:56:02 +0200, Espen Vestre ("Espen") writes:
Espen> Andr� Thieme <······························@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.
Espen> I think there's a bootstrapping problem here: Such interfaces
Espen> (don't know about SAP, but we're interfacing to a number of weird
Espen> protocols where I work) are easy to write in lisp, so every active
Espen> lisper who needs it writes his own and doesn't think of sharing
Espen> his little hack, so the next lisper writes it himself too... and
Espen> so on.
If he writes a good implementation, why not sell it?
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun25-004@Yahoo.Com>
> From: ······@news.dtpq.com (Christopher C. Stacy)
> If he writes a good implementation, why not sell it?
Because there's virtually no market for lisp software. I've never seen
anyone express an interest in purchasing lisp software from random
programmers such as myself. I've written lots of software, much in
lisp, that I'd like to sell, but there's no point in even inquring
about somebody to buy some particular piece of my software with the
whole market virtually non-existant in the first place.
From: Christopher C. Stacy
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <uvfheyams.fsf@news.dtpq.com>
>>>>> On Fri, 25 Jun 2004 17:09:36 -0700, RobertMaas ("RobertMaas") writes:
>> From: ······@news.dtpq.com (Christopher C. Stacy)
>> If he writes a good implementation, why not sell it?
RobertMaas> I've written lots of software, much in lisp, that I'd
RobertMaas> like to sell, but there's no point in even inquring about
RobertMaas> somebody to buy some particular piece of my software with
RobertMaas> the whole market virtually non-existant in the first place.
Simply writing your software in Lisp will not make it marketable.
What marketable software products have you produced that happen to
be written in Lisp, and what happened when you tried to market them?
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun23-001@Yahoo.Com>
> From: ······@plohmann.com (Oliver Plohmann)
> 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 ...
That's the advantage of LISP! In those other languages, if you have a
linked-list, or vector (one-dimensional array), or other sequence of
data, origSeq, and you want to process each element in sequence, and
build up the list of results, resSeq, you need to do something like
this (this is Java, the easiest of those non-LISP languages to use):
Enumeration e = origSeq.toEnumeration();
Queue q = new Queue();
while (e.hasMoreElements())
q.push(processData((sometype)(e.nextElement())));
New restype resSeq = QueueToResSeqType(q);
(For some appropriate toEnumeration method, some appropriate type of
data you are handling, some processData routine you want to use, and
some appropriate QueueToResSeqType method for converting to the kind of
sequence you want at the end.)
In CL it's this easy:
(setq resSeq (map 'resSeqType #'processData origSeq))
And who says LISP has too many parens!! Java has more!!
> 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.
I feel sorry for you having suffer such a droid of a teacher. But he's
not alone. Most books give really stupid examples of recursion, such as
factorial and fibonacci. Factorial isn't too bad, because if you don't
use the regular definition but instead carefully code it to be tail
recursive, then on some compilers the generated code is essentially a
tight iterative loop. But recursive factorial without a cache is
totally stupid because it's exponentially slower than iterating to
build a list of previous results, or even rotating three local
variables. Your instructor should have come up with some example where
recursion is *much* easier than doing it using an iteration loop and a
state machine with an explicit stack. For example, given a multi-level
list, full of strings, replace all occurances of the 'f' word with
"(expletive deleted)". OK to copy all structure so nothing except the
strings are shared between original and result.
(defun replace-naughty-words (naughtyWord listStructure)
(cond ((consp listStructure)
(cons (replace-naughty-words naughtyWord (car listStructure))
(replace-naughty-words naughtyWord (cdr listStructure))))
((null listStructure) nil)
((not (stringp listStructure)) (error "Not valid structure"))
((string-equal listStructure naughtyWord) "(expletive deleted)")
(t listStructure)))
Nah, that's too hard for a beginner. I'll have to think of something
easier. OK, how about this: Given a positive integer, if it's larger
than 9 then break it into two approximate halves and then if either of
those numbers is larger than 9 break again etc. until all the pieces
are less than or equal to 9, and express these partial sums as lists.
For example:
27 -> (13 14) -> ((6 7) (7 7))
(defun split-past-9 (n)
(if (> n 9) (list (split-past-9 (floor n 2))
(split-past-9 (ceiling n 2)))
n))
> tell me why recursiveness and non-destructiveness in Lisp is such a
> holy thing
Your question is based on a false assumption. Recursiveness isn't holy,
it's just a useful way to decompose many kinds of problems that branch
in an unlimited number of directions. Non-destructiveness is useful
too, but again not holy. If you want more than one process, or more
than one time in a single process, to look at the same data, it helps
if one process or one time doesn't modify the data causing the later
process or time to see the modified data instead of the original when
it was supposed to see the original. You can get around this by making
a deep copy of the data structure, and handing a different copy to each
process, but if only a few changes are going to made, and most of the
structure is the same before and after, this wastes a lot of space
compared to sharing everything that didn't change. But it's a design
decision which way to go for any given application.
How would you write a deep-copy/clone function/method without recursion
anyway? If there are only a fixed number of levels of structure, you
can write a separate function for each level. But if the number of
levels deep is unlimited, that doesn't work, and you need the hassle of
using a stack to emulate recursion yourself, or just write the
function/method recursively in the first place.
By the way, the right way to demonstrate a recursive definition of
factorial is by splitting the product into two sub-products of nearly
the same length, not by splitting a single term off one end or the
other and recursing on all the rest.
By the way, Tower of Hanoi is nicely solved by a recursive algorithm,
but if you can figure out how to do it yourself then there's a nice
iterative demo of it where you cycle around mod 3 manipulating three
explicit stacks representing the three towers.
··········@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/
From: Tim Bradshaw
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <ey3k6zr2u3v.fsf@cley.com>
* 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
Tim Bradshaw <···@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
From: ··········@YahooGroups.Com
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <REM-2004jun13-001@Yahoo.Com>
> From: Tim Bradshaw <···@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?
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,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
Alan Crowe <····@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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
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: ·········@random-state.net
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c8bdcb$aislg$1@midnight.cs.hut.fi>
Svein Ove Aas <··············@brage.info> wrote:
> 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)?
If your application has specialized needs, it may be viable. If not,
there are pre-existing libraries for this kind of stuff. The latest one
being CL-STORE by Sean Ross:
"CL-STORE is a package for writing/reading CL objects from streams"
"CL-STORE currently supports serialization of
* All numbers (float, ratios, integers, complexes)
* Character, and Strings
* Vectors and Arrays
* Hash Tables
* Lists
* Instances of Structures
* Instances of CLOS Classes
* Conditions
* CLOS Classes
* And Combinations of the above"
http://www.common-lisp.net/project/cl-store/
Cheers,
-- Nikodemus
·········@random-state.net wrote:
> Svein Ove Aas <··············@brage.info> wrote:
>
>> 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)?
>
> If your application has specialized needs, it may be viable. If not,
> there are pre-existing libraries for this kind of stuff. The latest one
> being CL-STORE by Sean Ross:
>
> "CL-STORE is a package for writing/reading CL objects from streams"
>
> "CL-STORE currently supports serialization of
> * All numbers (float, ratios, integers, complexes)
> * Character, and Strings
> * Vectors and Arrays
> * Hash Tables
> * Lists
> * Instances of Structures
> * Instances of CLOS Classes
> * Conditions
> * CLOS Classes
> * And Combinations of the above"
>
> http://www.common-lisp.net/project/cl-store/
Looks useful, thanks. I think I'll put it on the library recommendation
page; there's nothing on serialization there yet.
"Specialized needs" indeed; I need to serialize functions. I think I can
handle that by myself, though. :P
From: ·········@random-state.net
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c8bg65$aislg$2@midnight.cs.hut.fi>
Svein Ove Aas <··············@brage.info> wrote:
> Looks useful, thanks. I think I'll put it on the library recommendation
> page; there's nothing on serialization there yet.
Um. I think library recommendations might carry more weight if there was
some experience behind them in the use of said libraries.
CL-STORE does indeed look usefull, but I confess no actual experience with
it.
> "Specialized needs" indeed; I need to serialize functions. I think I can
> handle that by myself, though. :P
Might be more difficult then you anticipate unless you can do without
closures and can get by with something like:
(serialize '(lambda (...) ...) ...) ; list, not a function
;; Turn a serialized list starting with lambda into a function
(coerce (deserialize-lambda serialized-lambda) 'function)
;; or
(compile nil (deserialize-lambda serialized-lambda))
I don't see any way to portably serialize closures, but am happy to be
proved wrong...
By specialized needs I ment something more along the lines of
"symbols, objects of classes X, Y, and Z, and tons of double floats".
Cheers,
-- Nikodemus
·········@random-state.net wrote:
> Svein Ove Aas <··············@brage.info> wrote:
>
>> Looks useful, thanks. I think I'll put it on the library recommendation
>> page; there's nothing on serialization there yet.
>
> Um. I think library recommendations might carry more weight if there was
> some experience behind them in the use of said libraries.
Quite possibly; however, I think a potentially bad recommendation is
better than no recommendation at all. You recommended it to me, after
all.
>> "Specialized needs" indeed; I need to serialize functions. I think I
>> can handle that by myself, though. :P
>
> Might be more difficult then you anticipate unless you can do without
> closures and can get by with something like:
>
> (serialize '(lambda (...) ...) ...) ; list, not a function
>
>
> ;; Turn a serialized list starting with lambda into a function
> (coerce (deserialize-lambda serialized-lambda) 'function)
>
> ;; or
>
> (compile nil (deserialize-lambda serialized-lambda))
>
> I don't see any way to portably serialize closures, but am happy to be
> proved wrong...
They don't need to carry along state, just code. Closures should work just
fine as long as I don't care about bringing along their internal state.
It's basically a "remote update" scenario.
> By specialized needs I ment something more along the lines of
> "symbols, objects of classes X, Y, and Z, and tons of double floats".
It would be "symbols, objects of classes X, Y and Z, tons of tiered
numbers, keywords, code, and whatever objects/types said code might
reference in the future".
(By "tiered numbers", I mean numbers that have bignum magnitudes, but
still allow for precise positions relative to other numbers with the same
magnitudes. Stars in several distinct galaxies, in other words.)
From: ·········@random-state.net
Subject: Re: Is anything easier to do in java than in lisp?
Date:
Message-ID: <c8bip2$aislg$3@midnight.cs.hut.fi>
Svein Ove Aas <··············@brage.info> wrote:
>> I don't see any way to portably serialize closures, but am happy to be
>> proved wrong...
> They don't need to carry along state, just code. Closures should work just
> fine as long as I don't care about bringing along their internal state.
Two possibilites present themselves:
1) You're way ahead of my game and have solution cooking.
2) You don't really understand that closures (and all functions,
really) are opaque objects in CL. You cannot pull them apart
and put them back togather -- which is essentially required for
any serialization scheme. By hooking into implementation internals
you may be able to do that, but not portably. See:
* (lambda () 1)
#<FUNCTION "#'(LAMBDA NIL 1)" {9023575}>
* (inspect *)
FUNCTION #<FUNCTION "#'(LAMBDA NIL 1)" {9023575}>..
> 0
The object contains nothing to inspect.
What you ca do, though (and maybe that's what you ment), is work around
this opacity by saving those function definitions you're interested in,
_and_ making sure such functions live in the global environment (no
references to lexical environment).
One such scheme would be to have something like: (untested)
(defun save-function (fun lambda-form)
(setf (gethash fun *functions*) lambda-form)
fun)
(defun get-function (fun)
(or (gethash fun *functions*) (error "oops")))
(defmacro defun* (name &body body)
`(save-function (defun ,name ,@body) `(lambda ,@body)))
(defmacro lambda* (&body body)
`(save-function (lambda ,@body) `(lambda ,,@body)))
(defun serialize-function (fun)
(serialize (cons +lambda-tag+ (get-function fun))))
And on the deserializing side check for +lambda+tag+ and coerce / compile
the cdr to function.
Cheers,
-- Nikodemus
·········@random-state.net wrote:
> Svein Ove Aas <··············@brage.info> wrote:
>
>>> I don't see any way to portably serialize closures, but am happy to be
>>> proved wrong...
>
>> They don't need to carry along state, just code. Closures should work
>> just fine as long as I don't care about bringing along their internal
>> state.
>
> Two possibilites present themselves:
>
> 1) You're way ahead of my game and have solution cooking.
>
> 2) You don't really understand that closures (and all functions,
> really) are opaque objects in CL. You cannot pull them apart
> and put them back togather -- which is essentially required for
> any serialization scheme. By hooking into implementation internals
> you may be able to do that, but not portably. See:
It's nr 3: I'm not really transporting code, just source. I tend to think
of those as synonyms, which I suppose they aren't, really.
Svein Ove Aas <··············@brage.info> writes:
> ·········@random-state.net wrote:
>
> > Svein Ove Aas <··············@brage.info> wrote:
> >
> >> Looks useful, thanks. I think I'll put it on the library recommendation
> >> page; there's nothing on serialization there yet.
> >
> > Um. I think library recommendations might carry more weight if there was
> > some experience behind them in the use of said libraries.
>
> Quite possibly; however, I think a potentially bad recommendation is
> better than no recommendation at all. You recommended it to me, after
> all.
I'm not so sure. Recommendations on that page that turn out to be bad
will tend to reduce the credibility of the page itself. I thought the
whole point of that page was to recommend reliable, well-proven
libraries?
Bj�rn
Bj�rn Lindberg wrote:
> Svein Ove Aas <··············@brage.info> writes:
>
>> ·········@random-state.net wrote:
>>
>> > Svein Ove Aas <··············@brage.info> wrote:
>> >
>> >> Looks useful, thanks. I think I'll put it on the library
>> >> recommendation page; there's nothing on serialization there yet.
>> >
>> > Um. I think library recommendations might carry more weight if there
>> > was some experience behind them in the use of said libraries.
>>
>> Quite possibly; however, I think a potentially bad recommendation is
>> better than no recommendation at all. You recommended it to me, after
>> all.
>
> I'm not so sure. Recommendations on that page that turn out to be bad
> will tend to reduce the credibility of the page itself. I thought the
> whole point of that page was to recommend reliable, well-proven
> libraries?
>
Well, mostly... I still think a pointer is better than no pointer, though.
It's easy enough to mark it as "doubtful" or whatever.
·········@random-state.net wrote:
> Svein Ove Aas <··············@brage.info> wrote:
>
>
>>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)?
>
>
> If your application has specialized needs, it may be viable. If not,
> there are pre-existing libraries for this kind of stuff. The latest one
> being CL-STORE by Sean Ross:
>
> "CL-STORE is a package for writing/reading CL objects from streams"
>
> "CL-STORE currently supports serialization of
> * All numbers (float, ratios, integers, complexes)
> * Character, and Strings
> * Vectors and Arrays
> * Hash Tables
> * Lists
> * Instances of Structures
> * Instances of CLOS Classes
> * Conditions
> * CLOS Classes
> * And Combinations of the above"
>
> http://www.common-lisp.net/project/cl-store/
Looks interesting. I have a couple of questions (there is no email on
the site)
1 - How does it compare to the SAVE-OBJECT library of old?
2 - How does it compare to the WIRE/REMOTE packages of CMUCL?
Cheers
--
Marco