Sun thinks about switching Java to S-expression syntax: Lava
Rainer Joswig
Barry Margolin
s-expressions for data files, but not for representing programs themselves.
This actually has some precedents. If anyone remembers WAIS, take a look
at the format of its "source" records (the developers of WAIS were mainly
Lisp folks at Thinking Machines). And even Sun has used s-expressions
internally -- take a look at the files in /var/spool/calendar, which are
used by their OpenWindows Calendar Manager application.
S-expression is probably one of the simplest ways to represent nestable
data structures in text. I applaud the article.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Kelly Murray
> http://www.performancecomputing.com/columns/java/9903.shtml
With Sun/Netscape hiring up all the ex-lispers, maybe I can
stop trying to make Lisp better, Java will soon be good enough?
BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
Seems most people laughed at the name. Having Netscape/Sun use it
perhaps makes it not so funny anymore?
My language is now called NiCLOS(tm), the name is funny,
but is the language?
-Kelly Murray k...@niclos.com
Rainer Joswig
> The Subject line is a bit of an overstatement.
See the smiley in the body of the posting.
David Bakhash
> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
> Seems most people laughed at the name. Having Netscape/Sun use it
> perhaps makes it not so funny anymore?
> My language is now called NiCLOS(tm), the name is funny,
> but is the language?
So what's Lisp-like and what's Java-like in your language? Does your
langage compile down to Java VM code? Do you have a uniform way to
use Java classes via CLOS? I can't see how this is even remotely
possible, considering that:
1) Java has no multiple inheritance
2) Java's class definitions are lexical with respect to methods, if
you consider a class file as a lexical entity.
3) Java has no multimethods, and dispatch depends only on the class of
a single object.
I am surely no expert, but I work closely with Java and Lisp
development, and I really don't see how this would work. Where can
one read about this?
dave
Per Bothner
>s-expressions for data files, but not for representing programs themselves.
I was surprised he didn't mentioned XML, since this is largely what XML
is all about. (And, yes, they are also writing programming languages
based on XML. See XSL <http://www.w3.org/Style/XSL/> and contrast with
the Scheme-based DSSSL for doing the same task.)
XML is basically S-expressions with some bells and whistles
(as McCarthy pointed out at the Lisp User's conference).
It has a more verbose but easier checkable syntax.
As such, any proposal to use S-expressions *for Java* as Detlefs
proposes is both DOA and wrong-headed. People should be using
XML instead, because more tools will be able to handle it, and
because it will be more familiar to more people.
--
--Per Bothner
Cygnus Solutions bot...@cygnus.com http://www.cygnus.com/~bothner
Erik Naggum
| See the smiley in the body of the posting.
maybe these smileys destroy communication? maybe they detract from the
effort of being good at sarcasm, jokes, irony, or plain old lunacy.
at one point in my life, I became acquainted with the habit of thinking
that lying was OK if you held two fingers crossed behind your back. I
couldn't figure out why this was important to people. if I lied, it was
to protect something much more important than whoever I lied to, not to
play stupid tricks on people. I could play much better tricks on people
by making them believe something that would hurt them without my actually
telling them anything for which they could directly fault me. it has
since been a puzzling experience to see people fool _themselves_ so
thoroughly that if you told them the truth, they think you're lying.
"I have never had a sexual relationship with that women, Miss Lewinsky."
did you see his hands? could he have crossed his fingers or made some
other secret gesture by which he meant "the laugh's on you, buster"? and
then it got out of hand because "I was only kidding" didn't work with the
kid-me-not Kenneth Starr. maybe all the Democrats were in on it and the
moralistic Republicans will be laughed out of politics? that'd be cool.
meanwhile, there's not a single smiley on Kenneth Starr's pornographic
report, either, not even the smirk you'd expect from someone digging up
so much personal dirt about others. I think he forgot to include it:
"There is Substantial and Credible Information that President Clinton
Committed Acts that May Constitute Grounds for an Impeachment :>"
#:Erik
Barry Margolin
>* jos...@lavielle.com (Rainer Joswig)
>| See the smiley in the body of the posting.
>
> maybe these smileys destroy communication? maybe they detract from the
> effort of being good at sarcasm, jokes, irony, or plain old lunacy.
I think I assumed that the smiley in that posting was just expressing
happiness, like a true smile. I didn't realize it was a "tongue in cheek"
smiley.
Jim White
>http://www.performancecomputing.com/columns/java/9903.shtml
>
>;-)
Great. A Sun Java researcher who apparently likes LISP but doesn't know
about Kawa[1] (the Scheme for the JVM). Not only does it have
S-expressions but even compiles them to bytecodes including the
useful-seperate-from-scheme gnu.bytecode package so you can make classes
from whatever you want.
Now if they were only researching the JVM change that is really needed:
continuations.
If the JVM specification had been based on continuations instead of the
implementation-minded threads stuff they would not only have avoided
having to deprecate the whole damn thing as they have, but would have a
machine model that could/would be amenable to formal analysis (as it is
no one tries - they simply ignore the threading stuff).
jim
[1] <http://www.cygnus.com/~bothner/kawa.html>
-------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Bradley Yearwood
>Kelly Murray <k...@IntelliMarket.Com> writes:
>
>> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
>> Seems most people laughed at the name. Having Netscape/Sun use it
>> perhaps makes it not so funny anymore?
>> My language is now called NiCLOS(tm), the name is funny,
>> but is the language?
>
>So what's Lisp-like and what's Java-like in your language? Does your
>langage compile down to Java VM code? Do you have a uniform way to
>use Java classes via CLOS? I can't see how this is even remotely
>possible, considering that:
>
>1) Java has no multiple inheritance
>2) Java's class definitions are lexical with respect to methods, if
> you consider a class file as a lexical entity.
>3) Java has no multimethods, and dispatch depends only on the class of
> a single object.
Could someone please remind me of what exactly we gain by abandoning
Lisp and moving to Java?
Here is all I am able to come up with:
1) Unprecedented momentum of hype
2) Infix notation to avoid frightening dogs and small children
2.5) Reduced wear on parentheses keys on keyboards
3) Some slightly challenging concepts like macros are made to vanish
4) Some slightly suspicious hand-waving claims that useful integrity
checks can be performed on portable bytecode before running it
5) An opportunity for yet another generation of enthusiasts to reinvent
compilers, operating systems, utilities, interactive development
environments, and special purpose hardware for the nth time in ever slower
and bulkier forms
6) An opportunity to slip some sizable loads of ignorance of prior art past
snoozing patent examiners, and thus lay down potentially lucrative legal
minefields
Brad Yearwood b...@crl.com
Cotati, CA
Christopher R. Barry
> Could someone please remind me of what exactly we gain by abandoning
> Lisp and moving to Java?
Well...
* You can download a full, uncrippled Java implementation + IDE for
any major platform absolutely free, and in the case of the JDK even
get the source code. AFAIK you can only do this with the Unix
platform for Common Lisp.
* Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
* True keyboard and mouse control (you can distinguish between a
keyboard down-press and release, so you can give your text fields
Emacs-like incremental searching and bindings or do sophisticated
word completions or any other cool thing you could think up. And of
course, completely standard and cross-platform.
* On Linux (and probably other platforms), you can choose if you want
the threads in a single process (Allegro CL style), or if you want
OS-level threads. It doesn't get any better than that (as if one
standard, cross-platform interface to threads wasn't convenient
enough).
* Graphics, low-level networking, applets in browsers, sound,
look-and-feel support, the kitchen sink.... It actually seems to be
a larger language than Common Lisp, and it gives you all the access
to the primitive hardware, windowing-system and networking
functionality that you really want but in a way that will work on
Unix, Windows, Mac or whatever without even needing to recompile for
that platform. ANSI Common Lisp gives you little more primitive
hardware control and system access than ANSI C (not including CLIM,
but IMO that doesn't really count).
It's funny, my Java instructor at the college was talking about how it
took them 6-8 years or so to start offering C++ classes, but only 3
months to offer Java classes. He said a big factor in this was that
you can download everything for free to all the computers in the
lab. Lisp has yet to be offered, and probably will never be (I think
they teach a little AutoLisp though in the CAD classes).
I think every ounce of hype Java has recieved is deserved. As a
language itself, I think it's better than C, C++, Eiffel, ADA,
etc... and just about any other non logical/functional programming
language out there. But none of the logical/functional languages can
compete with it's level of standardization and the platform
independent system control it gives you. And Common Lisp sure can't
compete with its real cost in most situations (all things considered).
It would be nice if Common Lisp could at least standardise some of the
networking, threads and i/o functionality you get in Java, and if it
had a standard, accessible and reasonably priced GUI toolkit.
In a fantasy world, you could even have Common Lisp compile to Java
byte-code and run wherever the Java Runtime Environment runs and do
all the system-level stuff that Java does (yes, I've heard of Kawa
scheme).
Christopher
Marco Antoniotti
cba...@2xtreme.net (Christopher R. Barry) writes:
> It would be nice if Common Lisp could at least standardise some of the
> networking, threads and i/o functionality you get in Java, and if it
> had a standard, accessible and reasonably priced GUI toolkit.
I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
>
> In a fantasy world, you could even have Common Lisp compile to Java
> byte-code and run wherever the Java Runtime Environment runs and do
> all the system-level stuff that Java does (yes, I've heard of Kawa
> scheme).
I am no expert, but I'd almost think that compiling Common Lisp could
be easier than Scheme. The lack of CALL/CC might be a facilitating
factor. Anybody care to comment?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Erik Naggum
| * You can download a full, uncrippled Java implementation + IDE for
| any major platform absolutely free, and in the case of the JDK even
| get the source code. AFAIK you can only do this with the Unix
| platform for Common Lisp.
www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
(but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
| * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
none of the CLIM providers charge you money for trying it out before you
decide to buy it or not.
| I think every ounce of hype Java has recieved is deserved.
???
| As a language itself, I think it's better than C, C++, Eiffel, ADA,
"Ada" is named after Ada Lovelace. it's a proper name, not an acronym.
(I helped start the "Ada in Norway" user group in 1985. it's my "other"
language, and my company logo still carries symbols from the Ada world.
that people write ADA, like they write LISP, is a pet peeve.)
| And Common Lisp sure can't compete with its real cost in most situations
| (all things considered).
I don't think you are a competent judge of that, _especially_ not the
parenthetical remark.
| It would be nice if Common Lisp could at least standardise some of the
| networking, threads and i/o functionality you get in Java, and if it had
| a standard, accessible and reasonably priced GUI toolkit.
I'm still confused as to this standardization issue. yes, it would be
nice if it were standardized, but why can't you use something today?
Common Lisp is a standard _because_ it was used and gaining solid support
for a number of really complex things. if people who do not understand
how these things work refuse to use something _until_ it's standard, it
will likely never become a standard, and if, against all odds, it should,
you guys will complain and not use it, anyway.
some of us prefer languages that don't change a lot, that aren't in the
middle of the fight between good and evil, and on which long-term
investments may actually be made with solid profit expectations. Common
Lisp has a problem in that only mature people use it _after_ they have
become disgusted with other languages and their hype.
#:Erik
David B. Lamkins
R. Barry) wrote:
> b...@crl3.crl.com (Bradley Yearwood) writes:
>
>> Could someone please remind me of what exactly we gain by abandoning
>> Lisp and moving to Java?
>
> Well...
>
> * You can download a full, uncrippled Java implementation + IDE for
> any major platform absolutely free, and in the case of the JDK even
> get the source code. AFAIK you can only do this with the Unix
> platform for Common Lisp.
There are downloadable versions for Mac (Digitool trial version, and Roger
Corman's $50 shareware), PC (both Franz and Harlequin), and Linux (Franz
full version). Digitool will give you a 30-day evaluation key for the
asking. Franz's Linux version is for noncommercial use.
OTOH, if you're developing a commercial application, Lisp vendors require
that you pay for a supported version of the product (and sometimes, even for
a distribution license).
If you're building a product that can't reasonably be done except in Lisp --
and there _are_ products in that space -- then the extra cost is
justifiable. Face it, you're going to pay one way or another. Hidden costs
that I've seen with "low-cost and popular" IDEs are: lost time to market,
extra programmers, tracking down vendor bugs, being blocked 3 to 9 months
for a release that fixes a problem in the compiler, etc.
>
> * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
Have the Lisp vendors denied your request for an evaluation copy? Have you
even asked?
>
> * True keyboard and mouse control (you can distinguish between a
> keyboard down-press and release, so you can give your text fields
> Emacs-like incremental searching and bindings or do sophisticated
> word completions or any other cool thing you could think up. And of
> course, completely standard and cross-platform.
Of course, completely standard and cross-platform... Hmm, didn't Microsoft
make an argument that it had to break from the Pure Java fold because Sun
didn't want to support 3-button mice?
>
> * On Linux (and probably other platforms), you can choose if you want
> the threads in a single process (Allegro CL style), or if you want
> OS-level threads. It doesn't get any better than that (as if one
> standard, cross-platform interface to threads wasn't convenient
> enough).
So, aside from having a choice, what are the benefits? Can you do OS-native
threads in a platform-independent manner?
>
> * Graphics, low-level networking, applets in browsers, sound,
> look-and-feel support, the kitchen sink.... It actually seems to be
> a larger language than Common Lisp, and it gives you all the access
> to the primitive hardware, windowing-system and networking
> functionality that you really want but in a way that will work on
> Unix, Windows, Mac or whatever without even needing to recompile for
> that platform. ANSI Common Lisp gives you little more primitive
> hardware control and system access than ANSI C (not including CLIM,
> but IMO that doesn't really count).
Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
on the Sun platforms. But their portability claims are _vastly_ oversold.
I tried their Java-based browser (HotJava?) on a Sun workstation and was
very pleased. Later the same day, I tried it on my Mac; I threw it away
after counting some two dozen cosmetic, usability, and functional flaws in
five minutes. (Note: Given all of the hype about Java's portability, you
might ask why Sun has different HotJava versions for different platforms.)
You might be surprised to know that Common Lisp implementations also give
you access to low-level OS and hardware functionality via their FFI. Not
portable, but then neither are Mac OS APIs portable to Win32.
And of course Java doesn't have to be recompiled because it's transferred in
a platform-neutral format: byte code. Did you know that some Lisp systems
(CLISP, CMUCL) have the same capability? Do you understand that Common Lisp
source code is _highly_ portable because it doesn't encode issues of
machine-level data representation? (Yes, Java gets this half-right by
specifying fixed representations for data types. I wonder what Sun will do
when 128-bit machines hit the market. How many times has the Java
"standard" already changed?)
>
> It's funny, my Java instructor at the college was talking about how it
> took them 6-8 years or so to start offering C++ classes, but only 3
> months to offer Java classes. He said a big factor in this was that
> you can download everything for free to all the computers in the
> lab. Lisp has yet to be offered, and probably will never be (I think
> they teach a little AutoLisp though in the CAD classes).
Ah, yes. The popularity argument. A real classic. (Not now, Ethel -- I'm
busy. Just hit Ctrl-Alt-Delete, maybe it will work better next time.)
>
> I think every ounce of hype Java has recieved is deserved. As a
> language itself, I think it's better than C, C++, Eiffel, ADA,
> etc... and just about any other non logical/functional programming
> language out there. But none of the logical/functional languages can
> compete with it's level of standardization and the platform
> independent system control it gives you. And Common Lisp sure can't
> compete with its real cost in most situations (all things considered).
Every ounce of hype Java has received is still just hype. I have observed
early adopters foundering and failing with Sun's
not-quite-ready-for-primetime "free" products, and with not-free derivatives
thereof. Since these folks were actually trying to bring something to
market, there's a real cost involved. (Three or four programmers for six
months is going to cost a company about $200K to $250K in the US. That's a
lot of time and money to throw away on the basis of favorable hype,
particularly when the actual outcome doesn't meet expectations. In this
context, the expenditure of a couple tens of thousands of dollars for mature
tools and training isn't such a big deal.)
>
> It would be nice if Common Lisp could at least standardise some of the
> networking, threads and i/o functionality you get in Java, and if it
> had a standard, accessible and reasonably priced GUI toolkit.
Yeah, standards would be nice. OTOH, I can already get all of this
functionality in a platform-dependent manner and write (if needed) thin
abstraction layers around it. Frankly, I don't mind "rolling my own" while
waiting for a standard to emerge based upon actual experience. One of Sun's
own wrote a "dissenting opinion" on the perils of premature
standardization...
>
> In a fantasy world, you could even have Common Lisp compile to Java
> byte-code and run wherever the Java Runtime Environment runs and do
> all the system-level stuff that Java does (yes, I've heard of Kawa
> scheme).
And _why_ would I want to run interpreted or JIT-compiled bytecode when I
can run native code? (Remember, mobile code is handled quite nicely in Lisp
by transporting and compiling the source.)
>
> Christopher
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Wintel is the Yugo of the computer world: cheap to buy, costly to keep.
Steve Gonedes
b...@crl3.crl.com (Bradley Yearwood) writes:
<
< In article <cxjpv7f...@engc.bu.edu>, David Bakhash <ca...@bu.edu> wrote:
< >Kelly Murray <k...@IntelliMarket.Com> writes:
< >
< >> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
< >> Seems most people laughed at the name. Having Netscape/Sun use it
< >> perhaps makes it not so funny anymore?
< >> My language is now called NiCLOS(tm), the name is funny,
< >> but is the language?
< >
< >So what's Lisp-like and what's Java-like in your language? Does your
< >langage compile down to Java VM code? Do you have a uniform way to
< >use Java classes via CLOS? I can't see how this is even remotely
< >possible, considering that:
< >
< >1) Java has no multiple inheritance
< >2) Java's class definitions are lexical with respect to methods, if
< > you consider a class file as a lexical entity.
< >3) Java has no multimethods, and dispatch depends only on the class of
< > a single object.
<
< Could someone please remind me of what exactly we gain by abandoning
< Lisp and moving to Java?
<
< Here is all I am able to come up with:
<
< 1) Unprecedented momentum of hype
< 2) Infix notation to avoid frightening dogs and small children
< 2.5) Reduced wear on parentheses keys on keyboards
< 3) Some slightly challenging concepts like macros are made to vanish
< 4) Some slightly suspicious hand-waving claims that useful integrity
< checks can be performed on portable bytecode before running it
< 5) An opportunity for yet another generation of enthusiasts to reinvent
< compilers, operating systems, utilities, interactive development
< environments, and special purpose hardware for the nth time in ever slower
< and bulkier forms
< 6) An opportunity to slip some sizable loads of ignorance of prior art past
< snoozing patent examiners, and thus lay down potentially lucrative legal
< minefields
You forgot that you can run Java programs on every windows and Solaris
computer in the world!
Steve Gonedes
cba...@2xtreme.net (Christopher R. Barry) writes:
< b...@crl3.crl.com (Bradley Yearwood) writes:
<
< > Could someone please remind me of what exactly we gain by abandoning
< > Lisp and moving to Java?
<
< Well...
<
< * You can download a full, uncrippled Java implementation + IDE for
< any major platform absolutely free, and in the case of the JDK even
< get the source code. AFAIK you can only do this with the Unix
< platform for Common Lisp.
Really? You mean Java runs on every Java platform - Solaris and
windows. You do know that all software is portable right?
You can get the source code for Java on _Solaris_ if you sign an NDA,
I think you can do this for lisp as well.
Steve Gonedes
"David B. Lamkins" <dlam...@teleport.com> writes:
< Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
< of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
< on the Sun platforms. But their portability claims are _vastly_ oversold.
< I tried their Java-based browser (HotJava?) on a Sun workstation and was
< very pleased. Later the same day, I tried it on my Mac; I threw it away
< after counting some two dozen cosmetic, usability, and functional flaws in
< five minutes. (Note: Given all of the hype about Java's portability, you
< might ask why Sun has different HotJava versions for different platforms.)
This is due to the fact that Java is portable. Portable, being an
undesirable, non-existant situation which requires work to make it go
away. All software is portable, unless it just works of course.
Unix software is portable.
< And _why_ would I want to run interpreted or JIT-compiled bytecode when I
< can run native code? (Remember, mobile code is handled quite nicely in Lisp
< by transporting and compiling the source.)
I wonder why they call it `Just in Time' compiler. Sounds like some
kind of marketing savior.
Don't get me wrong, I love Java and it's cross platform OO
capabilities. Plus it makes writing mission critical easy.
Tim Bradshaw
>
> I wonder why they call it `Just in Time' compiler. Sounds like some
> kind of marketing savior.
>
Isn't computing & compiling code `just in time' one of the things that
people have been whining at Lisp -- specifically CLOS with things like
lazily computed effective methods -- about for years? I mean, it
means you have to have the compiler in memory all the time, and we
can't have that, can we? Oh, well, we can *now*.
It's just like GC: for years, `Lisp was crippled because it had GC'
now Java has it, why GC is suddenly fine. (It's really amusing
teaching Lisp to people now, suddenly they don't go all funny when you
talk about GC).
There was recently some work on class redefinition in C++, so that's
probably OK now too.
I guess we need to invent some new and outragous features for people
to complain about. (Well, there's already the CLOS MOP, but it's not
quite universal enough to be a real target for derision.)
--tim
Barry Margolin
>I guess we need to invent some new and outragous features for people
>to complain about. (Well, there's already the CLOS MOP, but it's not
>quite universal enough to be a real target for derision.)
We still have the corner on the market for parentheses. The one new
language that was going to adopt our syntax (Dylan) gave in and switched to
algebraic/imperative notation. Even the article that started this thread
only suggested using S-secpressions for data files, not programs.
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | * You can download a full, uncrippled Java implementation + IDE for
> | any major platform absolutely free, and in the case of the JDK even
> | get the source code. AFAIK you can only do this with the Unix
> | platform for Common Lisp.
>
> www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
> (but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
It's crippled, and you must pay if you want to use it commercially.
> | * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
>
> none of the CLIM providers charge you money for trying it out before you
> decide to buy it or not.
I would feel dishonest if I contacted Franz about getting an
evaluation copy of CLIM. I know that no matter how much I liked it, I
could not at this point in my life afford it.
It would be nice if it could be obtained under the same terms as the
Allegro CL Linux Trial Edition, where you can use it as long as you
like, and not feel obligated to purchase it. After having been able to
use Allegro CL so extensively, I know that at some point in the future
I would definately buy it if using Common Lisp for a big project.
> | It would be nice if Common Lisp could at least standardise some of the
> | networking, threads and i/o functionality you get in Java, and if it had
> | a standard, accessible and reasonably priced GUI toolkit.
>
> I'm still confused as to this standardization issue. yes, it would be
> nice if it were standardized, but why can't you use something today?
I am. When it comes down to it, I still _definitely_ do not prefer
Java over CL. You know, _interpreted_ Garnet gui code seems smoother
and GCs much less than Java (though the pauses are longer - scrollbars
can really suck, gotta take care of this...). There are a number of
things that Java gets right though, like knowing how to actually get a
little mind share.
> Common Lisp has a problem in that only mature people use it _after_
> they have become disgusted with other languages and their hype.
Well, certainly not disgusted yet....
Christopher
Christopher R. Barry
> cba...@2xtreme.net (Christopher R. Barry) writes:
>
> > It would be nice if Common Lisp could at least standardise some of the
> > networking, threads and i/o functionality you get in Java, and if it
> > had a standard, accessible and reasonably priced GUI toolkit.
>
> I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
At least Mark Kantrowitz's defsystem runs on just about every CL out
there. The Allegro one is kinda nicer, but I think Mark's has all the
functionality you really need to get the job done. Standardization
would not hurt though.
Christopher
Christopher R. Barry
> > * On Linux (and probably other platforms), you can choose if you want
> > the threads in a single process (Allegro CL style), or if you want
> > OS-level threads. It doesn't get any better than that (as if one
> > standard, cross-platform interface to threads wasn't convenient
> > enough).
>
> So, aside from having a choice, what are the benefits? Can you do OS-native
> threads in a platform-independent manner?
Maybe some time in the future.... You can't choose from within the
Java API itself if you want OS or in-process threads. I'm sure you're
familiar with the benefits of using one over the other in different
situations.
> > * Graphics, low-level networking, applets in browsers, sound,
> > look-and-feel support, the kitchen sink.... It actually seems to be
> > a larger language than Common Lisp, and it gives you all the access
> > to the primitive hardware, windowing-system and networking
> > functionality that you really want but in a way that will work on
> > Unix, Windows, Mac or whatever without even needing to recompile for
> > that platform. ANSI Common Lisp gives you little more primitive
> > hardware control and system access than ANSI C (not including CLIM,
> > but IMO that doesn't really count).
>
> Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
> of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
> on the Sun platforms.
Actually, it seems that Windows is the finest Java platform these days
and the most supported. All the fastest JVMs/JITs are for Windows, and
when Java 1.2 came out, the Windows version was the final one while
the Solaris one was supposed to still be beta or evaluatory or
something.
> But their portability claims are _vastly_ oversold. I tried their
> Java-based browser (HotJava?) on a Sun workstation and was very
> pleased. Later the same day, I tried it on my Mac; I threw it away
> after counting some two dozen cosmetic, usability, and functional
> flaws in five minutes.
I've never heard of any bad things about the Metroworks Java tools for
the Mac.
> You might be surprised to know that Common Lisp implementations also
> give you access to low-level OS and hardware functionality via their
> FFI. Not portable, but then neither are Mac OS APIs portable to
> Win32.
Probably because there's so little interest in such a thing. I'm sure
there are Win32 API layers that sit atop of the MacOS API though. But
Java gives you everything you really need from the platform specific
API without needing to use it.
> And of course Java doesn't have to be recompiled because it's transferred in
> a platform-neutral format: byte code. Did you know that some Lisp systems
> (CLISP, CMUCL) have the same capability?
Not quite in the same league.
> Do you understand that Common Lisp source code is _highly_ portable
> because it doesn't encode issues of machine-level data
> representation?
I understand that ANSI Common Lisp is highly portable. ANSI C also
will never, ever break when moving from 32 to 64 bits if you code
properly. It's just way easier to screw up.
> (Yes, Java gets this half-right by specifying fixed representations
> for data types. I wonder what Sun will do when 128-bit machines hit
> the market.
Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
about 64-bit platforms? What will it do when we've got 128-bit ones?
> How many times has the Java "standard" already changed?)
It's been updated twice, and the runtime environment and browsers all
still have to run the 1.0 code and 1.1 code too.
> Ah, yes. The popularity argument. A real classic. (Not now, Ethel -- I'm
> busy. Just hit Ctrl-Alt-Delete, maybe it will work better next time.)
Why can't Lisp become more popular? What's stopping it? Do you think
that the reasons outlined in "The Rise of Worse Is Better" are the
_real_ reasons?
> And _why_ would I want to run interpreted or JIT-compiled bytecode when I
> can run native code? (Remember, mobile code is handled quite nicely in Lisp
> by transporting and compiling the source.)
You could write applets in CL and basically gain all the advantages
and cross-platform functionality Java has. You can't do sockets or
threads in CL without a hell of a lot of #+ and #- and have it work in
any CL providing access to these features. And many are reluctant to
ship source code.
Christopher
Christopher R. Barry
> You forgot that you can run Java programs on every windows and Solaris
> computer in the world!
And almost every Unix computer (even Crays), and the MacOS, and NeXT,
and ...within 2 web browsers that run on OSs covering 99% of the OS
market share.
Christopher
Jon S Anthony
We use Java extensively here. We also use CL extensively here.
> * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
It's also bigger and _way_ slower.
> * On Linux (and probably other platforms), you can choose if you want
> the threads in a single process (Allegro CL style), or if you want
> OS-level threads. It doesn't get any better than that (as if one
> standard, cross-platform interface to threads wasn't convenient
> enough).
Yes, but oddly enough "green threads" (single process style) are
stunningly slow. Native threads on Solaris also suck unless you get
the right patches to run the production version - and even then they
require mind numbing amounts of cpu power to do much. Of course this
_could_ be fixed, but then why bother?
> * Graphics, low-level networking, applets in browsers, sound,
> look-and-feel support, the kitchen sink.... It actually seems to be
Sort of. Anybody actually using this stuff in real world situations
knows that there is more hype here than reality. Yes, some of it
actually works and some of it is more convenient than using something
else in certain situations. But it isn't even remotely anything like
the panacea that it is made out to be - and it often just plain
doesn't work.
> language itself, I think it's better than C, C++, Eiffel, ADA,
That's Ada - a proper name. Like Eiffel...
> independent system control it gives you. And Common Lisp sure can't
> compete with its real cost in most situations (all things
> considered).
How can you make such a claim? "Most situations" meaning..., what?
Toy oneoffs? Simple minded university class projects? Maybe. Maybe
not.
> It would be nice if Common Lisp could at least standardise some of
> the networking, threads and i/o functionality you get in Java, and
> if it had a standard, accessible and reasonably priced GUI toolkit.
Yes, it would be great if CL had a standard thread/tasking definition
- it's an important fundamental piece of functionality. Networking
stuff is really a shoulder shrug wrt "standardization" in the
language. Probably too specialized to even be appropriate.
But all of that is irrelevant in this context when you consider the
_fact_ that _nothing_ in Java is standardized! Not even the basic
constructs of the language let alone any of the libraries/APIs and
such. A _standard_ means something accepted by a _real_ standards
body - like ANSI or ISO. Sun is not a standards body and it can (and
often _does_) just change things out from under you - and then (adding
insult to injury) deprecate those changes in a future release.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Rainer Joswig
Hmm, last time I wanted to install Solaris via a Java interface:
- HotJava crashed
- Netscape on a PC had a version conflict with the Applet
- Netscape on a Mac did not really wanted to accept
my click on an install button
Well, I switched to a terminal...
Rainer Joswig
> Common Lisp has a kinda oddball size for FIXNUMs.
Which size? In MCL:
? MOST-POSITIVE-FIXNUM
536870911
On a MacIvory:
Command: most-positive-fixnum
2147483647
Simon Leinen
> s-expressions for data files, but not for representing programs themselves.
> at the format of its "source" records (the developers of WAIS were mainly
> Lisp folks at Thinking Machines). And even Sun has used s-expressions
> internally -- take a look at the files in /var/spool/calendar, which are
> used by their OpenWindows Calendar Manager application.
Yeah, I'm always pleased when I see Lispy syntax hidden in
"mainstream" applications.
Checkpoint Firewall-1 uses S-expressions to store the firewall
configuration that you (are supposed to :-) generate using a
relatively nice GUI.
I think Confluent's "Visual Thought" drawing package also uses a Lispy
representation of its drawings.
> S-expression is probably one of the simplest ways to represent nestable
> data structures in text. I applaud the article.
--
Simon.
Christopher R. Barry
> In article <87soc6f...@2xtreme.net>, cba...@2xtreme.net (Christopher R. Barry) wrote:
>
> > Common Lisp has a kinda oddball size for FIXNUMs.
>
> Which size? In MCL:
>
> ? MOST-POSITIVE-FIXNUM
> 536870911
>
> On a MacIvory:
>
> Command: most-positive-fixnum
> 2147483647
I'll retract my statement. I believed in error that the standard
required fixnums to be 30 bits, but it says that they must be at least
16 bits (well, have a range of 2^15-1 to -2^15). Pretty much the same
requirement as the ANSI C "int" type.
Christopher
Raymond Toy
Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
Simon> "mainstream" applications.
Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
Simon> configuration that you (are supposed to :-) generate using a
Simon> relatively nice GUI.
Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
Simon> representation of its drawings.
Add to that Rational Rose. It looks like the entire UML model is
stored in some Lispy representation, including window position
information.
Ray
Erik Naggum
| about 64-bit platforms? What will it do when we've got 128-bit ones?
geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
implementations do. C and C++, however, _do_ have sizes of such things.
C/C++ have the problem you allude to. Common Lisp just runs with a
little less consing on a machine with bigger machine integers.
| Why can't Lisp become more popular?
why can't opera be more popular? why can't football be less popular?
| What's stopping it?
people like you.
| You can't do sockets or threads in CL without a hell of a lot of #+ and
| #- and have it work in any CL providing access to these features.
just because you can't doesn't many other people can't. the simplest way
to do this is to write a thin veneer, perhaps using compiler macros, to
present a uniform, standard interface to the underlying implementation
(which, by the way, differs between _socket_ implementations, too), stuff
this in a file that is loaded only on the platform it applies to.
porting your system is a matter of making a new copy of this file. this,
by the way, is how intelligent people _implement_ real portability. only
if the differences are very small and very localized does it make sense
to use #- and #+. personally, I use #- and #+ only in configuration
files and in DEFSYSTEMs.
feel free to complain that this veneer isn't standardized. I fully
expect you to, but also that you will complain about whatever you get,
the same way people complain about the pathname abstraction prohibiting
them from running the whole gamut of file system options and operations
on their particular implementation.
#:Erik
Jon S Anthony
> > * True keyboard and mouse control (you can distinguish between a
> > keyboard down-press and release, so you can give your text fields
> > Emacs-like incremental searching and bindings or do sophisticated
> > word completions or any other cool thing you could think up. And of
> > course, completely standard and cross-platform.
>
> Of course, completely standard and cross-platform... Hmm, didn't Microsoft
> make an argument that it had to break from the Pure Java fold because Sun
> didn't want to support 3-button mice?
Another point here is that the behavior is (sadly, even depressingly)
quite platform dependent.
> > * On Linux (and probably other platforms), you can choose if you want
> > the threads in a single process (Allegro CL style), or if you want
> > OS-level threads. It doesn't get any better than that (as if one
> > standard, cross-platform interface to threads wasn't convenient
> > enough).
>
> So, aside from having a choice, what are the benefits? Can you do OS-native
> threads in a platform-independent manner?
Oh, yes. OTOH, the Java thread model is stunningly impoverished.
> Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
> of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
> on the Sun platforms. But their portability claims are _vastly_ oversold.
In our experience, the stuff (JDK 1.2) actually runs better overall
(less bugs and better performance) on an NT.Intel box than on a
Solaris.Sparc box. Go figure.
> Every ounce of hype Java has received is still just hype. I have
> observed early adopters foundering and failing with Sun's
> not-quite-ready-for-primetime "free" products, and with not-free
I believe this is too strong. There are definitely some good things
about Java, especially wrt (more or less) platform independent GUI and
connectivity work. While it's true that due to various central flaws,
Java will never be more than a *yawn* in the space of programming
language design, in the nuts and bolts world it does have some
advantages over other players. I suppose Java is best characterized
by the following scenario: upon first looking at it the response is
something like, "Hey, this is pretty cool"; upon further examination
and use the response becomes something like, "Wow, this could have
been a _lot_ better..."
David J. Cooper Jr.
Visula is an electronic CAD system which stores its database in a Lisp
(S-expression) format. Ironically they only use it internally and it is not
supported or documented - you have to use their (licensed, C-based) API functions to
gain access to their database.
So when I once wrote an ICAD App for circuit board design rule checking of circuits
designed in Visula, a C programmer on the project kindly offered to write some
C routines for me -- to generate the circuit board database into a Lispy syntax
again, that I could easily read into the ICAD app! But at least we were able to
document and support that format!
Erik Naggum
| www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
| (but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
* cba...@2xtreme.net (Christopher R. Barry)
| It's crippled, and you must pay if you want to use it commercially.
sigh. what _are_ the other crippled features of this version? that you
can't use it for a full-fledged commercial projects? why do you expect
to be able to do that? the Java freebies are _marketing_ stunts, not
technical arguments. do you have any idea how much money has been sunk
into Java and when the break-even time is expected to be? do you not
realize that it is an instrument of mass market destruction to reduce
Microsoft's hegemony and that Common Lisp doesn't fight that kind of wars?
and I find it slightly amusing that you, too, keep adding conditions that
make you not choose Common Lisp, no matter how people answer your gripes.
| I would feel dishonest if I contacted Franz about getting an evaluation
| copy of CLIM. I know that no matter how much I liked it, I could not at
| this point in my life afford it.
yeah, and I'm sure this is CLIM's fault. you said "Swing, unlike CLIM,
doesn't cost $4000-$7000 to even try out on Unix." which was an outright
lie, so now you would feel dishonest if you asked for a demo version, but
you didn't feel dishonest when you lied to begin with?
| It would be nice if it could be obtained under the same terms as the
| Allegro CL Linux Trial Edition, where you can use it as long as you like,
| and not feel obligated to purchase it.
you can't use it as long as you like. can't you even read licenses?
(yeah, I'm expecting another silly gripe, now.)
you clearly confused what "would be nice" with what people think they
might one day be able to profit from providing you. there ain't no such
thing as a free lunch, remember?
| After having been able to use Allegro CL so extensively, I know that at
| some point in the future I would definately buy it if using Common Lisp
| for a big project.
good for you. I won't hold my breath.
| When it comes down to it, I still _definitely_ do not prefer Java over CL.
are you desperate for reasons to use Common Lisp? is that why you bitch
and moan and invent "flaw" after "flaw" as your previous "flaws" have
proven not to be flaws? it sure doesn't look constructive to me.
| There are a number of things that Java gets right though, like knowing
| how to actually get a little mind share.
yes, by lying, overstating, hyping, misrepresenting the facts, etc.
somehow, I prefer to buy from Common Lisp sales people, not used car
sales people who jumped on the Java bandwagon.
| Well, certainly not disgusted yet....
you will, and the company that'll bring you to it: AT&T.น
#:Erik
-------
น sorry if the ad spoofed on is a little old.
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> | about 64-bit platforms? What will it do when we've got 128-bit ones?
>
> geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
> implementations do. C and C++, however, _do_ have sizes of such things.
> C/C++ have the problem you allude to. Common Lisp just runs with a
> little less consing on a machine with bigger machine integers.
The specification for C's "int" and CL's "FIXNUM" are virtually
identical.
> | Why can't Lisp become more popular?
>
> why can't opera be more popular? why can't football be less popular?
I think your analogy is not the most suitable one. I think using Lisp
over C or Java boils down to more than just personal taste and factors
analogous to your analogy.
> | What's stopping it?
>
> people like you.
Okay, what can I realistically do to make it more popular?
> | You can't do sockets or threads in CL without a hell of a lot of #+ and
> | #- and have it work in any CL providing access to these features.
>
> just because you can't doesn't many other people can't. the simplest way
> to do this is to write a thin veneer, perhaps using compiler macros, to
> present a uniform, standard interface to the underlying implementation
> (which, by the way, differs between _socket_ implementations, too), stuff
> this in a file that is loaded only on the platform it applies to.
> porting your system is a matter of making a new copy of this file. this,
> by the way, is how intelligent people _implement_ real portability. only
> if the differences are very small and very localized does it make sense
> to use #- and #+. personally, I use #- and #+ only in configuration
> files and in DEFSYSTEMs.
Has anyone done this already? Can I download a pre-done layer of
documented macro definitions from somewhere that will at least work
across CMUCL and Allegro CL? If I have to do it myself, not a huge
deal as long as I only do it for functions I use and not everything,
but standardization just makes it *that* much easier.
> feel free to complain that this veneer isn't standardized. I fully
> expect you to, but also that you will complain about whatever you get,
> the same way people complain about the pathname abstraction prohibiting
> them from running the whole gamut of file system options and operations
> on their particular implementation.
A little while back before my homework caught up with me I actually
kinda started to work on making a uniform interface between the ext:
and excl: file operation functions of Allegro and CMU Common Lisp
which provide a lot of the same functionality so that I could write
some intelligent Debian package management utilities for my personal
use to make up for where Apt and dpkg don't get it right for my
purposes. I don't want to commit to using only CMUCL or Allegro CL for
this or anything else just yet. CL-HTTP has been helpful though....
It's just *that* much more of an (IMO) unnecessary inconvenience.
Wasn't the whole point of Common Lisp that a lot of implementations
were providing largely equivalent functionality with a slightly
different interface? Everyone does sockets and threads these days and
a lot of the extension functions across implementations do almost the
exact same stuff. Are there any large, sophisticated, real-world apps
that are written these days in CL that don't do threads?
I should mention that CL-HTTP includes a lot of functions and macros
that unite some of the extension features found in all the CLs and
I've found it very useful and it's saved me a lot of time already. It
was obviously a lot of work to put all of that together and it would
be nice if this stuff could just always be relied upon to be there.
Christopher
Pierre Mai
> Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> about 64-bit platforms? What will it do when we've got 128-bit ones?
???? ANSI Common Lisp doesn't have any size for FIXNUMs. It only
mandates that FIXNUM be a supertype of (signed-byte 16). But FIXNUMs
can grow to any size the implementation can support, i.e. given that
most current 32bit implementations use 2 tag bits, I'd guess that
64bit implementations would offer FIXNUMs with 62bit range. OTOH
there might be better uses for some of the added bits, who knows.
But the most important point is, that the size of FIXNUMs in CL
matters only for points of speed, which is as it should be. In CL you
don't worry about integer bittyness, unless you really need to, which
is either for speed or data-layout reasons, where you get the tools
for doing what needs to be done. And this doesn't change one jota even
if your plattform evolves. You just get the benefits, without the
hassles.
The standard doesn't have to change in any way to accomodate 2^n
plattforms for n>16.
> > How many times has the Java "standard" already changed?)
>
> It's been updated twice, and the runtime environment and browsers all
> still have to run the 1.0 code and 1.1 code too.
Which is twice too often for a standard of a language that's only been
around for 4-5 years. But of course this is to be expected, which is
why you just don't use languages this young for real work. You don't
even start standardization efforts, with a language this young. This
is the really unprecended thing about Java that scares me! We never
ever had so large a rush to one language which as yet hasn't even
started to settle down, let alone matured to any sufficient point.
Even C++ only ever got that amount of hype and public attention after
6-10 years of it's first definition (C with classes dates to 1980, in
1984 it started to be called C++, and most of the core features were
there).
> Why can't Lisp become more popular? What's stopping it? Do you think
> that the reasons outlined in "The Rise of Worse Is Better" are the
> _real_ reasons?
If anything, things have gotten worse: Whereas prior generations
preferred Unix (which went 90% of the way) to Multics&Co. (which
tried to go 100%), in more recent times, people have gotten less
critical, accepting 80%, 70%, 60% and less, without even flinching.
They only got slightly upset, when Microsoft consistently tried to
only go 20% of the way, and mocking those who complained. But who
will we be rescued by? Java/Sun, who will be hailed for going 40% of
the way?
It seems to me that much of Java's "success" stems from the fact, that
current users/programmers prefer an application that gives you
internet access, draws pretty pictures, is slow as hell even on the
most modern machines, insecure and so buggy that it crashes
about every 5-10 minutes to a program that works reliably and
stand-alone on reasonable machines and is rock solid. Mostly because
the first application is "cool", and the other one isn't[1].
Of course CL will never be able to match Java in coolness, since
coolness and reliability are mutually exclusive in the real world,
where resources are limited, and will be distributed according to
priorities. Dito for Ada. Is this a bad thing? Not in my book.
As long as the value-system and priorities of the masses are so at
odds with my priorities, I don't want the languages and tools I choose
to go mainstream and get popular. We don't have to change CL to make
it popular[2], we have to change popular priorities and value-systems.
Then popularity will follow naturally.
Regs, Pierre.
Footnotes:
[1] Just look at WWW browsers to see a real world example of this.
[2] We may of course see the need to change and expand CL to meet
demands of its user community, w.r.t to certain features or
clarifications. There are enough things to think about, but
popularity is not the driving force here.
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre Mai
> I'll retract my statement. I believed in error that the standard
> required fixnums to be 30 bits, but it says that they must be at least
> 16 bits (well, have a range of 2^15-1 to -2^15). Pretty much the same
> requirement as the ANSI C "int" type.
Yes, and no. The important difference to C is:
a) Unless you actively prohibit this, FIXNUM arithmetic will overflow
correctly and automatically into BIGNUMs, so that a wrong estimate
on your part on the size of FIXNUMs will only cause performance
degradation and not wrong results.
b) There are additional type-specifiers that allow you to clearly
specify types based on your range and/or bit bestimates, so that
none of that "long int is 32bit, long int is 64bit, ..." guessing
is needed.
Regs, Pierre.
Pierre Mai
> > geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
> > implementations do. C and C++, however, _do_ have sizes of such things.
> > C/C++ have the problem you allude to. Common Lisp just runs with a
> > little less consing on a machine with bigger machine integers.
>
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
No, they are not, since, as Kent Pitman has said here many times, you
cannot evaluate language features and their specs in isolation, but
must always consider the whole ecosystem provided by their standards,
environments etc. Your thinking that since both C and CL standards
require int/fixnum to be 16bit or more is any kind of counter argument
to Erik's statement, just very nicely demonstrates the dangers of not
doing this.
For more details on why C's int and CL's FIXNUM are not in any way
comparable, see my previous postings.
> Wasn't the whole point of Common Lisp that a lot of implementations
> were providing largely equivalent functionality with a slightly
> different interface? Everyone does sockets and threads these days and
> a lot of the extension functions across implementations do almost the
> exact same stuff. Are there any large, sophisticated, real-world apps
> that are written these days in CL that don't do threads?
So get your CL vendor to raise the point at the next meeting of the
standards comittee, should it be decided that the standard should be
revised, rather than reapproved.
If it is so, that all available threading and socket-based networking
APIs differ only in minor details, then taking this area into the
standard might be possible and sensible. Otherwise, the other vendors
and members of the comittee will surely object ;)
> I should mention that CL-HTTP includes a lot of functions and macros
> that unite some of the extension features found in all the CLs and
> I've found it very useful and it's saved me a lot of time already. It
> was obviously a lot of work to put all of that together and it would
> be nice if this stuff could just always be relied upon to be there.
So you got all of your functionality, for all the plattforms you care?
So you can actually do everything you want, don't you? You just want
the standards body to bless this, so you can sleep better at nights?
Well, sure this would be _nice_. But nice is not important, is it?
There are so many things that would be nice. The art of engineering
is dividing up the nice from the essential and then providing the
essential. If any resources are left over, you provide as much of the
nice as seems reasonable.
Steve Gonedes
< threads in CL without a hell of a lot of #+ and #- and have it work in
< ship source code.
<
< Christopher
Actually I just saw the neatest idea for handling the `#+' in the
scigraph program. It uses a reader macro called `#FEATURE-CASE'.
Really made things easier to read.
Also, in cl-http there is a wrapper layer for threads and I think
there is another one floating around on the net.
Kent M Pitman
> ANSI Common Lisp doesn't have any size for FIXNUMs. It only
> mandates that FIXNUM be a supertype of (signed-byte 16).
And doesn't it also say that the fixnum type has to be big enough that
all array indices can be declared fixnum? That's actually a pretty
important constraint on it, almost as important as the bitcount.
It's late and I'm too lazy to go browsing to be sure, though.
> The standard doesn't have to change in any way to accomodate 2^n
> plattforms for n>16.
Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
architecture (Multics) back in the late 1970's. And I vaguely recall
there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
this biz of what are we going to do when we get to 64 bit
architectures is kinda funny...
Tim Bradshaw
> Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> about 64-bit platforms? What will it do when we've got 128-bit ones?
CL doesn't specify fixnum sizes (well it says they have to be bigger than
some small number of bits I think). RTFM before you flame.
--tim
Erik Naggum
I'm baffled. have you _read_ the specifications? a fixnum is simply a
more efficient integer, and some implementation-defined limits are less
than or equal to MOST-POSITIVE-FIXNUM, but you have know your compiler
real well before (+ fixnum fixnum) does not cause a bignum when needed.
what, precisely, is you gripe with the size of FIXNUM, anyway? methinks
you just have a fixation that you're trying blame Common Lisp for.
| > | Why can't Lisp become more popular?
| >
| > why can't opera be more popular? why can't football be less popular?
|
| I think your analogy is not the most suitable one. I think using Lisp
| over C or Java boils down to more than just personal taste and factors
| analogous to your analogy.
my point was that you ask a useless question that has no useful answer.
it is rare that you can explain why something is popular at any given
time. (and "marketing" begets the question "why did it work?", which all
marketing people will tell you is not something you sit down and predict.)
| > | What's stopping it?
| >
| > people like you.
|
| Okay, what can I realistically do to make it more popular?
you can stop posting drivel and actually go read the specification and
ask questions instead of posting wrong answers to questions people don't
ask. you see, people are _detracted_ from a gravitation towards Lisp as
they gain experience in their field and want self-improvement. this is
not at all the path you get if you ask about or measure popularity.
| Has anyone done this already? Can I download a pre-done layer of
| documented macro definitions from somewhere that will at least work
| across CMUCL and Allegro CL? If I have to do it myself, not a huge deal
| as long as I only do it for functions I use and not everything, but
| standardization just makes it *that* much easier.
I think your doing it yourself is a valuable exercise in understanding
(1) how this stuff should have been implemented, (2) the effort that goes
into standardization, and (3) the effort that goes into sharing quality
code with other people. maybe then you will realize what you're asking
for when you want everything for free.
| A little while back before my homework caught up with me I actually kinda
| started to work on making a uniform interface between the ext: and excl:
| file operation functions of Allegro and CMU Common Lisp which provide a
| lot of the same functionality so that I could write some intelligent
| Debian package management utilities for my personal use to make up for
| where Apt and dpkg don't get it right for my purposes. I don't want to
| commit to using only CMUCL or Allegro CL for this or anything else just
| yet.
this at least explains your problems. what you're doing is a waste of
time, although the purpose and goal is clear, so consider this: what you
sit down and design because CMUCL and Allegro CL do not agree on some
interface design is something you barely know how works and what you will
actually need from it once it does work. once it works well enough for
you to build something on top of, you will need to redesign it after you
have started to build something. only if you chose one implementation
and got enough stuff working to start feeding data back into the design
process can you hope to get the design right. what you're doign is
premature abstraction without an actual purpose or goal. "to make it
work in both Allegro CL and CMUCL" should not be a goal, it should fall
out your efforts as a result.
| It's just *that* much more of an (IMO) unnecessary inconvenience.
programming is all _about_ "unnecessary inconveniences", and every step
of progress tries to reduce their number. that's why good programmers
choose languages that have less unnecessary inconveniences than other
languages, but if you think you can avoid unnecessary inconveniences, I
think you should consider death and taxation first.
| Wasn't the whole point of Common Lisp that a lot of implementations were
| providing largely equivalent functionality with a slightly different
| interface?
yes, historically, this was the motivation for the standardization, as it
is with most good standardization, incidentally.
| Everyone does sockets and threads these days and a lot of the extension
| functions across implementations do almost the exact same stuff.
also true, but standards are basically removing functionality from the
market. the issue changes from "do you support FOO" to "do you conform
to the specification of FOO". the former is a feature if true, but
otherwise draws a blank. the latter draws a blank if true, and is
otherwise a reportable bug. to make standards work, all vendors must
agree to stop considering their features features, and start viewing them
as requirements. incidentally, this process parallels your Java vs CL
attitude: you argue against CL because you regard features in Java as
requirements of CL. this is, to put it mildly, hopelessly naive.
| Are there any large, sophisticated, real-world apps that are written
| these days in CL that don't do threads?
I cannot imagine otherwise. why do you?
| I should mention that CL-HTTP includes a lot of functions and macros that
| unite some of the extension features found in all the CLs and I've found
| it very useful and it's saved me a lot of time already. It was obviously
| a lot of work to put all of that together and it would be nice if this
| stuff could just always be relied upon to be there.
well, you have the CL-HTTP sources, and it is apparently not a problem
for you that you cannot use it commercially (which was a gripe you had
with Common Lisp implementations, so I have a minor problem understanding
what your actual and real concerns are).
#:Erik
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | It's crippled, and you must pay if you want to use it commercially.
>
> sigh. what _are_ the other crippled features of this version?
Can you develop GUIs with it? The whole Java experience has been very
refreshing for me. I downloaded the JDK, Swing, an Emacs IDE and an
8MB tutorial + 3MB of API documentation (and there's still many more
docs to download) all for free and very conveniently and it included a
number of cool demo GUI apps and everything I needed to do anything.
Just like that. It felt *nice*. It's so *easy* to learn as well. It's
like I have 15 million classes to choose from I can just strap
together a neat little app in 10 minutes that I could also probably do
without difficulty in CL but I'd have to write like 10 different
classes first.
> and I find it slightly amusing that you, too, keep adding conditions that
> make you not choose Common Lisp, no matter how people answer your gripes.
I never _chose_ anything. Someone flamed Java and I said what I
thought Java did right. I like my Lisp systems a lot more than my JDK,
but Java has made me aware of stuff I'd like to be able to do in Lisp.
> | I would feel dishonest if I contacted Franz about getting an evaluation
> | copy of CLIM. I know that no matter how much I liked it, I could not at
> | this point in my life afford it.
>
> yeah, and I'm sure this is CLIM's fault. you said "Swing, unlike CLIM,
> doesn't cost $4000-$7000 to even try out on Unix." which was an outright
> lie, so now you would feel dishonest if you asked for a demo version, but
> you didn't feel dishonest when you lied to begin with?
Come on Erik, be fair. If you look at the history of this thread
you'll see that I said that before being informed otherwise. Now tell
me, do you think it would be okay if I asked to evaluate it for free
when I know I can't afford it right now?
> | It would be nice if it could be obtained under the same terms as the
> | Allegro CL Linux Trial Edition, where you can use it as long as you like,
> | and not feel obligated to purchase it.
>
> you can't use it as long as you like. can't you even read licenses?
> (yeah, I'm expecting another silly gripe, now.)
Hmm... sigh. Another assumption on my part. I'll have to get around to
reading that license. Sometime.
> you clearly confused what "would be nice" with what people think they
> might one day be able to profit from providing you. there ain't no such
> thing as a free lunch, remember?
They've got to get us using their products while we're young and still
in school so we know to tell our managers that we want to use CL for a
project once we're hired instead of thinking only in terms of how to
implement a solution using C++, Perl or Java.
All the other people in my Java class have pretty much only seen C,
VB, C++ or whatever and they're probably liking Java a lot more than
even I am.... They'll never learn to think Lisp.
> | After having been able to use Allegro CL so extensively, I know that at
> | some point in the future I would definately buy it if using Common Lisp
> | for a big project.
>
> good for you. I won't hold my breath.
Thanks. I love you to. :-)
> | There are a number of things that Java gets right though, like knowing
> | how to actually get a little mind share.
>
> yes, by lying, overstating, hyping, misrepresenting the facts, etc.
Or by letting me download everything at once and overwhelming me with
all its features and functionality and cool demonstration programs and
documentation and making suddenly aware of some things I'd really like
to be doing in Lisp....
> | Well, certainly not disgusted yet....
>
> you will, and the company that'll bring you to it: AT&T.¹
:-)
Christopher
Christopher R. Barry
> Raymond Toy wrote:
>
> > >>>>> "Simon" == Simon Leinen <si...@limmat.switch.ch> writes:
> >
> > Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
> > Simon> "mainstream" applications.
> >
> > Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
> > Simon> configuration that you (are supposed to :-) generate using a
> > Simon> relatively nice GUI.
> >
> > Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
> > Simon> representation of its drawings.
> >
> > Add to that Rational Rose. It looks like the entire UML model is
> > stored in some Lispy representation, including window position
> > information.
> >
> > Ray
>
> Visula is an electronic CAD system which stores its database in a Lisp
> (S-expression) format.
While we're naming everything that uses Lispy representations we can
think of, let's not forget RTL, the intermediary representation of GNU
compilers.
Christopher