Is anything easier to do in java than in lisp?
Rober...@yahoogroups.com
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.
John Harlow
> 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.
Ryan J. Bovorasmy
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!
Kenny Tilton
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
Kristian Elof Sørensen
> 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
adam connor
>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.
Kenny Tilton
adam connor wrote:
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
Tayssir John Gabbour
> 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.
Stijn De Saeger
... just a dark thought on this rainy tuesday... hehe.
s.
<Rober...@YahooGroups.Com> wrote in message
news:REM-2004...@Yahoo.Com...
Lowell Kirsh
Lowell
Christian Hofer
*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
Chris
maybe that's just me?
- sarge
Edi Weitz
> 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.
Edi Weitz
> I haven't seen many enterprise-scale systems delivered using Lisp,
> but maybe that's just me?
Yes, that's just you.
Edi.
Tayssir John Gabbour
prefer Common Lisp greatly to Java. Despite Java having some
advantages.
tayss...@yahoo.com (Tayssir John Gabbour) wrote in message news:<866764be.04050...@posting.google.com>...
Pascal Costanza
Rober...@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/
Larry Barowski
"John Harlow" <sirsa...@hotmail.com> wrote in message
news:4r6dnTrJxsG...@comcast.com...
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.
Dave Roberts
> 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, ldave-...@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Tim Bradshaw
> 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
Wade Humeniuk
<Some Observations and a question(s)>
Of course. Its easier to write Java programs in Java.
Wade
Andrew Cristina
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
Matthew Danish
> ;;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 <mda...@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."
Ryan J. Bovorasmy
> 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.
Matthew Danish
> 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...
Antonio Menezes Leitao
> *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
Frederic Brunel
> 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
Svein Ove Aas
Yep, and it just did my homework for me.
A bit of documentation, and... :P
Antonio Menezes Leitao
> > 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
Antonio Menezes Leitao
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.
Antonio Menezes Leitao
>
>> 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.
Antonio Menezes Leitao
> Rober...@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.
Antonio Menezes Leitao
> 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
> Rober...@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.
Mike Kozlowski
Antonio Menezes Leitao <Antonio...@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/
David Steuber
> 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.
Antony Sequeira
>>Rober...@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.
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
Antonio Menezes Leitao
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.
Antonio Menezes Leitao
> Antonio Menezes Leitao <Antonio...@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.
Antonio Menezes Leitao
>> 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
Mike Kozlowski
Kenny Tilton <kti...@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.
Kenny Tilton
Mike Kozlowski wrote:
> In article <xbClc.87639$WA4....@twister.nyc.rr.com>,
> Kenny Tilton <kti...@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
Mike Kozlowski
Kenny Tilton <kti...@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.
Kenny Tilton
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.
Mike Kozlowski
Kenny Tilton <kti...@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).
Christophe Rhodes
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)
Wade Humeniuk
>
> 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
niko...@random-state.net
> 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
Espen Vestre
> 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)
Edi Weitz
> 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.
Mike Kozlowski
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
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?
Kenny Tilton
>
> In article <rK6mc.58071$Nn4.13...@twister.nyc.rr.com>,
> Kenny Tilton <kti...@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
Wade Humeniuk
>
> 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
William Bland
>
> 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).
Russell McManus
I use Lispworks for Linux under NetBSD i386 all the time. cl-xml
should work with this combination.
-russ
Jan Gregor
in jvm. Use jikes, it is very fast compared to javac. i think because
is written in C or C++.
Kenny Tilton
>
> 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.
David Steuber
> 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.
Mike Kozlowski
David Steuber <da...@david-steuber.com> wrote:
>Mike Kozlowski <m...@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...
Thomas Schilling
> 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.
Mike Kozlowski
Thomas Schilling <tjs...@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?
niko...@random-state.net
> 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
adam connor
>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
>In article <opr7jw73...@news.CIS.DFN.DE>,
>Thomas Schilling <tjs...@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
>thing. It would be nice if Java had something similar.
um, it would be nice if Lisp had something similar, I meant.
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Kenny Tilton
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.
David Steuber
> 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)))
William Bland
> 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 ;-)
Philippe Crama
> ...
> 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).
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
Thomas Schilling
>> 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.
Marco Baringer
> 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
Paolo Amoroso
> 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
Paul F. Dietz
> 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
Marco Antoniotti
Be patient with the web site and with the documentation. But most of it
is already there.
Cheers
--
marco
Hannah Schroeter
Espen Vestre <espen@*do-not-spam-me*.vestre.net> wrote:
>Wade Humeniuk <whum...@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.
Antonio Menezes Leitao
> 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
adam connor
>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...
William Bland
> William Bland <ne...@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 ;-)
André Thieme
> 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é
--
Rober...@yahoogroups.com
> 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.
Pete Kirkham
> 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
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" <zod...@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
Antonio Menezes Leitao
> 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.
Thomas F. Burdick
> 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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Ari Johnson
> Antonio Menezes Leitao <Antonio...@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. ;)
Thomas F. Burdick
> 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 :-)
Ari Johnson
> Ari Johnson <ar...@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.
Rober...@yahoogroups.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.
Rober...@yahoogroups.com
> 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.
Antonio Menezes Leitao
>> From: Antonio Menezes Leitao <Antonio...@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.
Jeff Dalton
> * 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
Jeff Dalton
* 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
Svein Ove Aas
> * 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)?
niko...@random-state.net
> 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
Svein Ove Aas
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
niko...@random-state.net
> 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
Svein Ove Aas
> Svein Ove Aas <svein+u...@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.)
niko...@random-state.net
>> 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
Svein Ove Aas
> Svein Ove Aas <svein+u...@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.
Björn Lindberg
> niko...@random-state.net wrote:
>
> > Svein Ove Aas <svein+u...@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