Or why haven't I entirely switched to Lisp yet?
Let's look at the "symetric difference"
Lisp
full lexical closure
unequalled macro support
unequalled MOP
Java
full portable "GUI" libraries (Swing, SWT, AWT)
(no: CLIM just doesn't compete,
Cello seems promising but not there yet)
full portable threading model*
across VM invocation (RMI) (ie: strandardized, portable RPC)
unequalled "refactoring" support (Eclispe, Intelli-J)
Most of the other features, they just share on a somewhat equal footing,
which isn't that surprising when you consider that CLTL2's father is one
of the main Java architect: Guy Steele.
I've still some hopes for Paul Graham's (yet to exist) Arc. But I'm not
sure why, I can' t really hold my breath. The "GUI" stuff is "only" library,
and as long as Arc defines/comes with a "good-enough" FFI, then the
community at large could provide it. Not so with threading.
For as long as I will have to write "Portable Threaded GUI" code, and
for as long as Lisp lacks on all three of those counts, I will simply not
have choice, no matter how much I'd like to bring my Lisp wee hours
coding in the main light of my day job.
People might argue that "GUI" stuff is a "thing of the past" as everything
is moving towards the server side ... I just can't agree with that, both
from experience, and actual web browsing.
* Some argue that it is "badly broken". That's simply not true.
Or rather, the argument is irrelevant: can I write portable threaded
code in Java that works across platforms? Yes. (even if at times
difficult)
Can I write portable "process" code in CL? Hu Hmm ...
--
JFB (Still marveling at the innards of OpenMCL :-)
Some points:
- Guy Steele was involved in drafting the specification for Java but
wasn't involved at all in the design of the language proper. I expect
Java would be a lot more useful if he had been.
- Why do you believe you have to wait for Arc to do useful things with
Lisp? If you're looking for a GUI, then use a Gtk wrapper or buy one
of the commercial implentations. It isn't as if no one else in the
Lisp community has ever thought about GUI libraries. There are
certainly GUI bindings for Lisp, and it is not very difficult to do
better than Swing.
- Better refactoring support in Java than in Common Lisp? What? Do
you really find it more convenient to refactor code in a line-oriented
language that doesn't support redefinition of functions at runtime?
Have you ever used Emacs' sexp-oriented commands? It certainly doesn't
seem like it.
Honestly, what was the point of even posting this?
On 2005-10-23 01:23:57 +0100, "Bill Atkins" <·········@gmail.com> said:
> - Guy Steele was involved in drafting the specification for Java but
> wasn't involved at all in the design of the language proper. I expect
> Java would be a lot more useful if he had been.
The name "Guy Steele" appears five times in the latest (3rd) revision of
the Java Language Specifiaction, published in 2005.
http://java.sun.com/docs/books/jls/
That's a lot for someone not involved. You may also notice some other
Lisper names such as Jim des Rivieres ...
> - Why do you believe you have to wait for Arc to do useful things with
> Lisp?
Your are misconstruing what I said. My point is about *portable* (1)
+ *GUI* (2) + *threaded* (3) code. I never claimed that code that is
neither portable, threaded nor GUI based is not useful.
> It isn't as if no one else in the Lisp community has ever thought
> about GUI libraries.
*portable* ?
> There are
> certainly GUI bindings for Lisp, and it is not very difficult to do
> better than Swing.
I'm sure you tried and succeeded at designing a better "GUI" than
Swing, that is portable, and addresses today's expectations . Where can I
access your code? What's the URL?
> - Better refactoring support in Java than in Common Lisp? What? Do
> you really find it more convenient to refactor code in a line-oriented
> language that doesn't support redefinition of functions at runtime?
> Have you ever used Emacs' sexp-oriented commands? It certainly doesn't
> seem like it.
Have you ever used Eclispe? Do you know what "Rename" means in that
context, where it is scope aware/package aware/class aware? Does
you emacs mode also rename files when you change the argument to load?
> Honestly, what was the point of even posting this?
This.
It seems that getting people to acknowlege where the limits are, is
always a hard task. If you cannot simply see the limits of whatever tool
you are using and religiously consider it the best thing since slice bread,
you are just in denial.
The point of my post was to hilight what is still perceived as a serious
impediment to Lisp use in a wider context (and I'm not even talking
about syntax). If you cannot accept that, please, by all means, go back
to Emacs.
I wanted to see if anyone else, in this community, was considering the
above three issues as something important to be addressed at some stage.
The reason I mentionned Arc, is that it is not done yet, and thus could
include threading support at the language level. To me that is issue #1
with CL today in the context where I have to produce *portable* code.
Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
I just hope I wont have to say about Lisp what I have come to beleive
about Forth: Forth is a great language, if this weren't for the forthers :-(
--
JFB (Still marveling at the innards of OpenMCL :-)
verec <·····@mac.com> writes:
> On 2005-10-23 01:23:57 +0100, "Bill Atkins" <·········@gmail.com> said:
>
>
> Your are misconstruing what I said. My point is about *portable* (1)
> + *GUI* (2) + *threaded* (3) code. I never claimed that code that is
> neither portable, threaded nor GUI based is not useful.
>
>> It isn't as if no one else in the Lisp community has ever thought
>> about GUI libraries.
>
> *portable* ?
>
>> There are
>> certainly GUI bindings for Lisp, and it is not very difficult to do
>> better than Swing.
>
> I'm sure you tried and succeeded at designing a better "GUI" than
> Swing, that is portable, and addresses today's expectations . Where can I
> access your code? What's the URL?
>
I don't know if it is better or worse than SWing.
But wxCL (http://www.wxcl-project.org) is as portable as wxWidgets and clisp.
And I think both of them are pretty much portable across most OSes and
hardwares.
Also, cvs version of wxGlade (http://wxglade.sourceforge.net/), an interface
designer, allows you to create wxCL GUIs.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
The best-laid plans of mice and men go oft astray.
On 2005-10-23 05:29:01 +0100, Surendra Singhi <·········@netscape.net> said:
> I don't know if it is better or worse than SWing.
>
> But wxCL (http://www.wxcl-project.org) is as portable as wxWidgets and clisp.
> And I think both of them are pretty much portable across most OSes and
> hardwares.
> Also, cvs version of wxGlade (http://wxglade.sourceforge.net/), an interface
> designer, allows you to create wxCL GUIs.
Many thanks for the pointers. I'm going to investigate,
--
JFB (Still marveling at the innards of OpenMCL :-)
On Sun, 23 Oct 2005 04:12:53 +0100, verec <·····@mac.com> wrote:
>On 2005-10-23 01:23:57 +0100, "Bill Atkins" <·········@gmail.com> said:
>
>I wanted to see if anyone else, in this community, was considering the
>above three issues as something important to be addressed at some stage.
If you search the newsgroup, you will see that most any issue you can
name, including but not limited to your particular three, has been
discussed. There is plenty of discussion of technical issues; there
are posts with historical perspectives on why the CLHS ended up the
way it is; there are posts discussing how the standard might move
forward.
Read, learn, and think.
>The reason I mentionned Arc, is that it is not done yet, and thus could
>include threading support at the language level. To me that is issue #1
>with CL today in the context where I have to produce *portable* code.
>
>Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
>portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
It's your problem that you want all that now and can't be satisfied
with the CLHS as it exists today. It's your problem if LispWorks (or
any other vendor) costs actual money that you can't or don't want to pay.
It's your problem if you don't want to dive in and learn and work
to help move things forward.
--
Jack
On 2005-10-23 05:09:47 +0100, Jack Unrue <·······@example.tld> said:
> On Sun, 23 Oct 2005 04:12:53 +0100, verec <·····@mac.com> wrote:
>> On 2005-10-23 01:23:57 +0100, "Bill Atkins" <·········@gmail.com> said:
>>
>> I wanted to see if anyone else, in this community, was considering the
>> above three issues as something important to be addressed at some stage.
>
> If you search the newsgroup, you will see that most any issue you can
> name, including but not limited to your particular three, has been
> discussed. There is plenty of discussion of technical issues; there
> are posts with historical perspectives on why the CLHS ended up the
> way it is; there are posts discussing how the standard might move
> forward.
If this has been discussed (and I'm sure it has) then an outcome
must have been reached. Which is? I'm definitely interested to
know where CL is headed. But answers like the one we get on c.l.c++
(about C++, of course) "This will be in c00x" where x is a digit
as in 200x doesn't really solve the problem, does it? (unless x <=5
that is :)
> Read, learn, and think.
Many thanks for that enlightening comment! Duh! It didn't occur
to me! What a moron I am ...
>> The reason I mentionned Arc, is that it is not done yet, and thus could
>> include threading support at the language level. To me that is issue #1
>> with CL today in the context where I have to produce *portable* code.
>>
>> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
>> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
>
> It's your problem that you want all that now and can't be satisfied
> with the CLHS as it exists today.
Sure. It is only *my* problem. Of course! Who else on his right mind
would want to write portable threaded GUI code, I have to ask. Why
would anyone else have such a stupid need?
> It's your problem if LispWorks (or
> any other vendor) costs actual money that you can't or don't want to pay.
Who is talking about money here? I _am_ not. And I'll gladly fork the
few hundred bucks required to buy something that suits my needs. And
w.r.t Lisp I even did! I bought MCL 4.3 a few years back and was satisfied
producing *non-portable*, *non-threaded* GUI code. But today I want
portable+threaded+GUI. And MCL didn't scale. Nor does LispWorks.
Or OpenMCL.
The thing is, you just can't point me to any vendor that does provide
such a product, simply because the features I need have to be present
everywhere for the code I write to be portable.
Do you understand the issue now? Or do you still insist that I'm an
idiot simply because I ask questions you are unable to provide an
answer to?
> It's your problem if you don't want to dive in and learn and work
> to help move things forward.
I'm not sure why it is so, but I always find that the people who have
the least to say are always the most verbal.
Every time someone asks "What about X?" there's always a plethora
of cretins challenging why would anyone want X, that X is overrated
or useless.
"People who think that it is not possible should not interfere with
people actually doing it!" -- anon
--
JFB (Still marveling at the innards of OpenMCL :-)
On Sun, 23 Oct 2005 05:47:52 +0100, verec <·····@mac.com> wrote:
>On 2005-10-23 05:09:47 +0100, Jack Unrue <·······@example.tld> said:
>
>If this has been discussed (and I'm sure it has) then an outcome
>must have been reached. Which is? I'm definitely interested to
>know where CL is headed. But answers like the one we get on c.l.c++
>(about C++, of course) "This will be in c00x" where x is a digit
>as in 200x doesn't really solve the problem, does it? (unless x <=5
>that is :)
Why do you assume that the discussion is over? I haven't worked on
any standards committee for CL and I don't want to speak for those
that have, that's why I suggested you search the c.l.l. archives.
>> Read, learn, and think.
>
>Many thanks for that enlightening comment! Duh! It didn't occur
>to me! What a moron I am ...
I don't know if you're a moron, but you certainly have a penchant
for logical fallacies and putting words in people's mouths.
>
>>> The reason I mentionned Arc, is that it is not done yet, and thus could
>>> include threading support at the language level. To me that is issue #1
>>> with CL today in the context where I have to produce *portable* code.
>>>
>>> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
>>> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
>>
>> It's your problem that you want all that now and can't be satisfied
>> with the CLHS as it exists today.
>
>Sure. It is only *my* problem. Of course! Who else on his right mind
>would want to write portable threaded GUI code, I have to ask. Why
>would anyone else have such a stupid need?
I was saying that it's your problem if you need it now and are not
willing to do anything about it but complain. Is that too hard to
understand?
>> It's your problem if LispWorks (or
>> any other vendor) costs actual money that you can't or don't want to pay.
>
>Who is talking about money here? I _am_ not. And I'll gladly fork the
>few hundred bucks required to buy something that suits my needs. And
>w.r.t Lisp I even did! I bought MCL 4.3 a few years back and was satisfied
>producing *non-portable*, *non-threaded* GUI code. But today I want
>portable+threaded+GUI. And MCL didn't scale. Nor does LispWorks.
>Or OpenMCL.
Since LispWorks is portable across platforms, has multi-threading
support, and has a GUI API, I'm curious whether you made any effort
to help LispWorks make you happier regarding scalability (bug reports,
enhancements, etc)? Because it seems like LW is potentially very close
to meeting your needs.
>The thing is, you just can't point me to any vendor that does provide
>such a product, simply because the features I need have to be present
>everywhere for the code I write to be portable.
How can you reach that conclusion when you haven't finished
evaluating all the possibilities? (You apparently didn't
already know about ABCL, for instance).
>Do you understand the issue now? Or do you still insist that I'm an
>idiot simply because I ask questions you are unable to provide an
>answer to?
I never suggested that you're an idiot, but you're making progress
on convincing me so.
>> It's your problem if you don't want to dive in and learn and work
>> to help move things forward.
>
>I'm not sure why it is so, but I always find that the people who have
>the least to say are always the most verbal.
Quite.
>
>Every time someone asks "What about X?" there's always a plethora
>of cretins challenging why would anyone want X, that X is overrated
>or useless.
Where in my previous post did I question why you would want any of
those features? Where did I say they were overrated? Where did I
claim they are useless?
>"People who think that it is not possible should not interfere with
> people actually doing it!" -- anon
I'm writing code in Lisp, how about you?
--
Jack
verec wrote:
> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
This is true, of course, for any reasonable definition of portable
(`defined by the language + library standard' or something like that).
Java also gives you a much more empirically portable platform - for
instance, I've developed code to test I/O performance on my little
windows laptop and then deployed the same class files on a 24 CPU box
with 60GB of memory, and had it drive that box reasonably hard. There
might be a lisp implementation that can do that but there wasn't last
time I looked (needs native threads...).
I think the answer is that the people who designed Java learnt a lot
from their Lisp experience. With CL they spent a huge amount of time
specifying a very nice language with a really advanced object system, a
condition system which actually does what you want a condition system
to do, macros, advanced looping constructs, a fancy formatted output
system and so on. They even got half way to developing a metaobject
protocol. But they didn't address stuff like threading or GUIs *at
all*, and most of the people who *have* tried to address these issues
have spent their time trying to produce lookalikes of things that
worked on the LispMs rather than trying to sit on top of the facilities
current systems offer.
The Java designers pretty much copped out on language issues, just
producing a kind of cleaned up (GC, safety) lowest-common-denominator
system. But they did spend a huge amount of effort on things like a
threading system which would sit happily on top of the thread systems
that current OSs offer, and a huge standard library which would
interface to the features current OSs offer, and so on. And they got
most of it wrong at least once, but since they had a lot of money to
spend they tried again until they got it right (well, more of it
right).
Five years ago I would have said that it was this last point that made
the difference - the Java designers had money which allowed them to fix
mistakes that Lisp designers could not fix. In recent times this is
clearly true, but I don't think it's the whole answer: Java just has a
whole different emphasis: instead of stressing away about the language,
stress about the *interfaces*.
--tim
From: Robert Uhl
Subject: Re: Still clinking to Java?
Date:
Message-ID: <m3fyqp5hnj.fsf@4dv.net>
"Tim Bradshaw" <··········@tfeb.org> writes:
>
> The Java designers pretty much copped out on language issues, just
> producing a kind of cleaned up (GC, safety) lowest-common-denominator
> system.
AKA Yet Another C Stepchild:-)
> Five years ago I would have said that it was this last point that made
> the difference - the Java designers had money which allowed them to
> fix mistakes that Lisp designers could not fix. In recent times this
> is clearly true, but I don't think it's the whole answer: Java just
> has a whole different emphasis: instead of stressing away about the
> language, stress about the *interfaces*.
I think that this is another (perhaps better) way of saying what I was
getting at with language vs. library. Even 8 or 9 years ago I though
Java was a pretty sad language--but it offered some really neat
libraries. Common Lisp is a really net language, but with pretty sad
standard libraries (and pretty cool non-standard ones--were it not for
project like CL-PPCRE and CL-EMB my little blogging engine would be
stillborn.
But that kinda proves the point: with perl (the language the original
blosxom was written in), there's no need for a CL-PPCRE project and
little need for a CL-EMB project; with Common Lisp they are vital.
All that said, I'm happier writing Lisp than I ever was in any other
language.
--
Robert Uhl <http://public.xdi.org/=ruhl>
After you've heard two eyewitness accounts of an accident, it makes you
wonder about history. --Dave Barry
Robert Uhl <·········@NOSPAMgmail.com> writes:
> standard libraries (and pretty cool non-standard ones--were it not for
> project like CL-PPCRE and CL-EMB my little blogging engine would be
What makes something "standard"? Why aren't the above "standard" -
they certainly seem to fit the ol' IBM (and current M$) notion of
"industry standard". And in the case of such things as these (libs
and such) when viewed from several perspectives this ("industry
standard") seems to be much more important than any blessing by a
"formal body".
> But that kinda proves the point: with perl (the language the
> original blosxom was written in), there's no need for a CL-PPCRE
> project and little need for a CL-EMB project; with Common Lisp they
> are vital.
Maybe, but in what interesting (practical, useful, etc.) sense is this
important? Of course, you can flip this sort of thing around as well:
with Common Lisp there is no need for a bignum library or a rational
number library; with Perl they are vital. What's that? They aren't
vital for _your_ application. Shrug. EMB stuff isn't vital for
anything I do either - so what?
And you can continue on in this vain: with Common Lisp there is no
need for a Condition system hack; with <whatever language> this is
vital. With Common Lisp there is no need for things like the visitor
pattern; with Perl, etc. it is vital. with Common Lisp there is
little to no need to canvas people (on usenet and otherwise) about the
meaning of a construct since there is an actual formal standard for
the base language; with Perl (or Ruby or Python or ...) this can be
vital. Tradeoffs. You just have to determine what's important for
you and/or your application.
> All that said, I'm happier writing Lisp than I ever was in any other
> language.
Right. Maybe the tradeoffs work for you.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> What makes something "standard"? Why aren't the above "standard" -
> they certainly seem to fit the ol' IBM (and current M$) notion of
> "industry standard". And in the case of such things as these (libs
> and such) when viewed from several perspectives this ("industry
> standard") seems to be much more important than any blessing by a
> "formal body".
Standardisation by single implementation is bad. Standardisation by
document-describing-required-behaviour is good.
> with Common Lisp there is
> little to no need to canvas people (on usenet and otherwise) about the
> meaning of a construct since there is an actual formal standard for
> the base language; with Perl (or Ruby or Python or ...) this can be
> vital.
Standardisation by single implementation is bad. Standardisation by
document-describing-required-behaviour is good.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> jayessay wrote:
>
> > What makes something "standard"? Why aren't the above "standard" -
> > they certainly seem to fit the ol' IBM (and current M$) notion of
> > "industry standard". And in the case of such things as these (libs
> > and such) when viewed from several perspectives this ("industry
> > standard") seems to be much more important than any blessing by a
> > "formal body".
>
> Standardisation by single implementation is bad. Standardisation by
> document-describing-required-behaviour is good.
Fair enough. But despite this you still indicate that it is
"standardization", and so these things might be called "standard".
Admittedly the scare quotes are appropriate. Presumably this could be
fixed by taking these and writing up such documents for them. This
sort of thing has been done before (certainly stdlib is an example),
and can work - assuming the starting base really is "industry
standard", i.e., used by a significant majority to do the intended
work.
> > with Common Lisp there is
> > little to no need to canvas people (on usenet and otherwise) about the
> > meaning of a construct since there is an actual formal standard for
> > the base language; with Perl (or Ruby or Python or ...) this can be
> > vital.
>
> Standardisation by single implementation is bad. Standardisation by
> document-describing-required-behaviour is good.
Maybe it's bogus but I tend to think there is a significant and
important difference between the language's definition and the useful
libs du jur. YMMV...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>>jayessay wrote:
>>
>>>What makes something "standard"? Why aren't the above "standard" -
>>>they certainly seem to fit the ol' IBM (and current M$) notion of
>>>"industry standard". And in the case of such things as these (libs
>>>and such) when viewed from several perspectives this ("industry
>>>standard") seems to be much more important than any blessing by a
>>>"formal body".
>>
>>Standardisation by single implementation is bad. Standardisation by
>>document-describing-required-behaviour is good.
>
> Fair enough. But despite this you still indicate that it is
> "standardization", and so these things might be called "standard".
> Admittedly the scare quotes are appropriate. Presumably this could be
> fixed by taking these and writing up such documents for them.
That's not so easy in the general case. The difference between an
implementation and a specification is that an implementation has to nail
down all details of how things are executed while a specification can
explicitly omit such details. Existing clients of an existing
implementation might rely on implementation details (such as order of
invocation of certain functions, including callbacks). Writing a
specification that describes an existing implementation might break
clients' reliance on such details without noticing this at all at first.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> jayessay wrote:
> > "Tim Bradshaw" <··········@tfeb.org> writes:
> >
> >>jayessay wrote:
> >>
> >>>What makes something "standard"? Why aren't the above "standard" -
> >>>they certainly seem to fit the ol' IBM (and current M$) notion of
> >>>"industry standard". And in the case of such things as these (libs
> >>>and such) when viewed from several perspectives this ("industry
> >>>standard") seems to be much more important than any blessing by a
> >>>"formal body".
> >>
> >>Standardisation by single implementation is bad. Standardisation by
> >>document-describing-required-behaviour is good.
> > Fair enough. But despite this you still indicate that it is
> > "standardization", and so these things might be called "standard".
> > Admittedly the scare quotes are appropriate. Presumably this could be
> > fixed by taking these and writing up such documents for them.
>
> That's not so easy in the general case.
Agreed.
> The difference between an implementation and a specification is that
> an implementation has to nail down all details of how things are
> executed while a specification can explicitly omit such
> details.
Absolutely. Indeed this (abstracting out the irrelevant details) is
arguably one of the most important aspects of a specification.
> Existing clients of an existing implementation might rely on
> implementation details (such as order of invocation of certain
> functions, including callbacks). Writing a specification that
> describes an existing implementation might break clients' reliance
> on such details without noticing this at all at first.
This is all true. OTOH, having a starting base that is "relatively
agreed" and at least somewhat proven in practice is not such a bad
thing in attempting to get some closure on these aspects.
I suppose this is really just another take on a kind of "worse is
better" approach to such things. Even Lisp has kind of an example of
this in PCL.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Absolutely. Indeed this (abstracting out the irrelevant details) is
> arguably one of the most important aspects of a specification.
[...]
> OTOH, having a starting base that is "relatively
> agreed" and at least somewhat proven in practice is not such a bad
> thing in attempting to get some closure on these aspects.
Agreed.
> I suppose this is really just another take on a kind of "worse is
> better" approach to such things. Even Lisp has kind of an example of
> this in PCL.
I think most of what is specified in Common Lisp is based on such prior
practice.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Wed, 26 Oct 2005 20:34:20 +0200, Pascal Costanza <··@p-cos.net> wrote:
As I see it the specification is that of Perl regular expressions.
Though there are many dialects of regular expressions this seems
to be the one most want to diverge towards.
This is the 'standard' most implementations try to follow.
The actual interface is (and should be) implementation dependent.
>
> That's not so easy in the general case. The difference between an
> implementation and a specification is that an implementation has to nail
> down all details of how things are executed while a specification can
> explicitly omit such details. Existing clients of an existing
> implementation might rely on implementation details (such as order of
> invocation of certain functions, including callbacks). Writing a
> specification that describes an existing implementation might break
> clients' reliance on such details without noticing this at all at first.
>
>
> Pascal
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
jayessay wrote:
> "Tim Bradshaw" <··········@tfeb.org> writes:
> > Standardisation by single implementation is bad. Standardisation by
> > document-describing-required-behaviour is good.
>
> Fair enough. But despite this you still indicate that it is
> "standardization", and so these things might be called "standard".
Yeah, sorry, I didn't mean that. I should have used some other term
for the single-implementation case.
> Maybe it's bogus but I tend to think there is a significant and
> important difference between the language's definition and the useful
> libs du jur. YMMV...
Well, really the whole point I was trying to make was that I think the
Java people have worked out that good library standards (and failing
that, any library standards, although I think Java is gradually moving
towards good ones - NIO for instance is pretty nice) matter more than a
good language standard (or, well, the standard of a good language?) to
most people. Because people want to get stuff done, and no matter how
nice and portable your language, if it won't talk to what you want it
to talk to, you're a bit stuck. The standards bit (rather than just
the library bit) matters because unless you are, say, MS, your hope is
that by establishing a standard you can get people to write portable
systems, which they then might be persuaded to migrate to a better
platform - one you provide for instance.
Although it is only tangentially related, here's an example of how
important libraries are. Sun have a thing called DTrace, which is a
little programming language with a library. The language is a kind of
rudimentary awk/C type thing, cut down a lot (no loops, no functions,
both of which turn out to be a good thing in context), and with some
special data types added. It's horrid, but if you have any Unix
experience it's trivial to learn. But the library is many hundred
instrumantation probes into Solaris, with which you can just do magic
on live machines: you can easily find out stuff about performance in 20
minutes that would have taken weeks before. I'm trying to think of
something (in computing, easy outside it) as cool as DTrace and I
can't: it is cool as fuck, basically. And that's *entirely* because of
the interfaces it has. (If it was a standardised thing, then, well...)
--tim
On Sun, 23 Oct 2005 04:12:53 +0100, verec <·····@mac.com> wrote:
> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
No, you don't need to reiterate - just read the replies you got. As
others have pointed out there's at least one commercial Lisp
implementation (LispWorks) that'll give you exactly that. The Java
implementations you're talking about are also commercial they just
happen to be available for free. Unfortunately, LispWorks Ltd. is not
in a position comparable to Sun's or IBM's.
So, if you actually want to get some job done you know where the Lisp
vendors are. If you want to wait until all this is part of the ANSI
standard - I'm sure that'll never happen. Does that change anything
in pratice? I don't think so.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2005-10-23 12:44:34, Edi Weitz wrote:
> On Sun, 23 Oct 2005 04:12:53 +0100, verec <·····@mac.com> wrote:
>> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
>> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
>
> No, you don't need to reiterate - just read the replies you got. As
> others have pointed out there's at least one commercial Lisp
> implementation (LispWorks) that'll give you exactly that.
Or maybe Corman Lisp. Program for Windows and then use WINE on other
platforms. :-)
On 2005-10-23 05:12:53, verec wrote:
> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
So why don't you post to a Java newsgroup and praise the benefits of
Java instead of telling us that we use an inferior language?
From: Robert Uhl
Subject: Re: Still clinking to Java?
Date:
Message-ID: <m3k6g15hyk.fsf@4dv.net>
Stefan Scholl <······@no-spoon.de> writes:
>
>> Do I nead to reiterate? I need ALL THREE ATTRIBUTES at once:
>> portable+GUI+threads. Java gives it to me. NOW. CL does NOT.
>
> So why don't you post to a Java newsgroup and praise the benefits of
> Java instead of telling us that we use an inferior language?
Possibly because he prefers Lisp-the-language but Java-the-library? The
fact that folks pretty commonly complain about the fact that it's free &
relatively easy to get good, quality, (sometimes) standard GUIs running
in other languages but not in Lisp is indicative of _something_, after
all.
I understand all the arguments about why Common Lisp doesn't specify a
GUI--heck, I agree with 'em. But it is undoubtedly a hurdle which a
newbie needn't deal with when using another language.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Conservatives want to be your daddy, telling you what to do and what not
to do. Liberals want to be your mommy, feeding you, tucking you in, and
wiping your nose. Libertarians want to treat you as an adult.
--David Boaz
verec wrote:
> On 2005-10-23 01:23:57 +0100, "Bill Atkins" <·········@gmail.com> said:
>
>> - Guy Steele was involved in drafting the specification for Java but
>> wasn't involved at all in the design of the language proper. I expect
>> Java would be a lot more useful if he had been.
>
> The name "Guy Steele" appears five times in the latest (3rd) revision of
> the Java Language Specifiaction, published in 2005.
> http://java.sun.com/docs/books/jls/
> That's a lot for someone not involved.
If you want to hear a statement by Guy Steele himself about his role in
the design of Java, watch the quicktime movie on language design at
http://www.ai.mit.edu/projects/dynlangs/wizards-panels.html
Here is what he said in that panel discussion: "I had a chance to help
write the specification for the Java programming language. [...] I was
brought in not [to do] a designer's job but [to do] a biographer's job.
My principle contribution to the language was that as I was writing
[the] specificaton [...] I would constantly return to James Gosling and
say: I could describe what you did in twenty pages, or you could make a
simple change and I could describe it in two pages, which do you want?"
Just because his name is on the book cover doesn't mean anything. Those
people also just have day jobs as everyone else.
> You may also notice some other
> Lisper names such as Jim des Rivieres ...
I had the pleasure to be able to talk to Jim des Rivieres last week at
OOPSLA. He is currently involved in developing the Eclipse environment.
I have asked him how that can be as interesting as having worked on
reflection (for 3-Lisp) and the CLOS MOP. His response was that what he
is currently doing is by far not as challenging, but more rewarding in
the sense that it is satisfying to know that more people actually make
use of his work. (...nevertheless, he seemed to have enjoyed talking
about the CLOS MOP about which I have also asked him a couple of questions.)
>> There are
>> certainly GUI bindings for Lisp, and it is not very difficult to do
>> better than Swing.
>
> I'm sure you tried and succeeded at designing a better "GUI" than
> Swing, that is portable, and addresses today's expectations . Where can I
> access your code? What's the URL?
Bill doesn't need to do that. It is known that Swing is too complicated
for the job it is supposed to do. Especially the "feature" that you can
change the look & feel at runtime overcomplicates its implementation and
buys you nothing that is really useful. If I understand correctly, Swing
still doesn't provide a serialization format that is compatible across
different platforms for this reason - and that would have been useful.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Robert Uhl
Subject: Re: Still clinking to Java?
Date:
Message-ID: <m3oe5d5iql.fsf@4dv.net>
verec <·····@mac.com> writes:
>
> Have you ever used Eclispe? Do you know what "Rename" means in that
> context, where it is scope aware/package aware/class aware? Does you
> emacs mode also rename files when you change the argument to load?
It would be relatively simple (less than a dozen lines of elisp) to add
this functionality. That someone hasn't done so suggests that maybe
it's not that useful. Or possibly that everyone reimplements it for
himself, which sometimes appears to be the Lisp way.
Me? I'm pretty happy that my blosxom port is going pretty well. It's
pretty fast, too--faster, I believe, than Perl blosxom.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The purpose of the First Amendment's free-speech guarantee was pretty
clearly to protect political discourse. But liberals reject the notion
that free speech is therefore limited to political topics, even broadly
defined. True, that purpose is not inscribed in the amendment itself.
But why leap to the conclusion that a broadly worded constitutional
freedom (`the right of the people to keep and bear arms') is narrowly
limited by its stated purpose, unless you're trying to explain it away?
My New Republic colleague Mickey Kaus says that if liberals interpreted
the Second Amendment the way they interpret the rest of the Bill of
Rights, there would be law professors arguing that gun ownership is
mandatory. --Michael Kinsley Washington Post, January 8, 1990
From: Christophe Rhodes
Subject: Re: Still clinking to Java?
Date:
Message-ID: <sqach0fumf.fsf@cam.ac.uk>
"Bill Atkins" <·········@gmail.com> writes:
> - Better refactoring support in Java than in Common Lisp? What? Do
> you really find it more convenient to refactor code in a line-oriented
> language that doesn't support redefinition of functions at runtime?
> Have you ever used Emacs' sexp-oriented commands? It certainly doesn't
> seem like it.
Not in Java. In the tools that have sprung up around the Java
community. Or are you seriously arguing that emacs' built-in
sexp-oriented commands are refactoring commands in the Martin Fowler
sense?
Christophe
Christophe Rhodes wrote:
> "Bill Atkins" <·········@gmail.com> writes:
>
>> - Better refactoring support in Java than in Common Lisp? What? Do
>>you really find it more convenient to refactor code in a line-oriented
>>language that doesn't support redefinition of functions at runtime?
>>Have you ever used Emacs' sexp-oriented commands? It certainly doesn't
>>seem like it.
>
> Not in Java. In the tools that have sprung up around the Java
> community. Or are you seriously arguing that emacs' built-in
> sexp-oriented commands are refactoring commands in the Martin Fowler
> sense?
Refactoring is typically explained as a transformation of your source
code that doesn't change its semantics. sexp-oriented editing commands
don't give any guarantees in that regard, so they are of course not
refactorings in that sense.
However, it seems to me that a number of features in Common Lisp combine
well to be good enough here. Selecting an s-expression, cutting and
pasting it somewhere else and putting a defun around it is quite
straightforward. The compiler will then tell you about the free
variables which should be passed as arguments to the new function. (If
you stick to the naming conventions, this should work.)
Or: Undefining a method and changing one of its specializers "moves" the
method to a different class in the class hierarchy. Since it doesn't to
be textually enclosed in some class definition, there's no need to do
more. Selecting, cutting and pasting the method is again just a few
keystrokes or mouse clicks away.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Sun, 23 Oct 2005 15:47:49 +0200, Pascal Costanza wrote:
> Christophe Rhodes wrote:
>> "Bill Atkins" <·········@gmail.com> writes:
>>
>>> - Better refactoring support in Java than in Common Lisp? What? Do
>>>you really find it more convenient to refactor code in a line-oriented
>>>language that doesn't support redefinition of functions at runtime?
>>>Have you ever used Emacs' sexp-oriented commands? It certainly doesn't
>>>seem like it.
>>
>> Not in Java. In the tools that have sprung up around the Java
>> community. Or are you seriously arguing that emacs' built-in
>> sexp-oriented commands are refactoring commands in the Martin Fowler
>> sense?
>
> Refactoring is typically explained as a transformation of your source
> code that doesn't change its semantics. sexp-oriented editing commands
> don't give any guarantees in that regard, so they are of course not
> refactorings in that sense.
>
> However, it seems to me that a number of features in Common Lisp combine
> well to be good enough here. Selecting an s-expression, cutting and
> pasting it somewhere else and putting a defun around it is quite
> straightforward. The compiler will then tell you about the free
> variables which should be passed as arguments to the new function. (If
> you stick to the naming conventions, this should work.)
>
> Or: Undefining a method and changing one of its specializers "moves" the
> method to a different class in the class hierarchy. Since it doesn't to
> be textually enclosed in some class definition, there's no need to do
> more. Selecting, cutting and pasting the method is again just a few
> keystrokes or mouse clicks away.
Also, Java requires that the name of a class matches the pathname of the
source file that implements it so that "autoloading" works.
A large part of the refactoring support in Eclipse etc. is to manage
moving files around in the source tree and to ensure that the source
code repository reflects these changes.
There also tends to be a fair amount of boilerplate text needed for a
new Java class.
Robert Swindells
On 2005-10-22 23:47:15 +0100, Wade Humeniuk
<··················@telus.net> said:
> WHY are you whining? Get a spine and try a real CL like
> Lispworks.
As a matter of fact, I do have LispWorks. And OpenMCL.
- their "IDE" is a joke. Period.
- the CL that is within is certainly as close to CLTL2
as any other, but that misses the entire point.
The point is not about *implementation* X, Y or Z of CL,
but about *the spec* that DOES NOT allow me TODAY to
write portable+GUI+threaded code in CL. This, Java gives
it to me now. CL doesn't.
Is it possible to have an adult conversation, and not start
flames just because you cannot correctly parse a sentence?
--
JFB (Still marveling at the innards of OpenMCL :-)
verec <·····@mac.com> writes:
> but about *the spec* that DOES NOT allow me TODAY to
> write portable+GUI+threaded code in CL.
What do you mean by portable? Your code should be able to run across multiple
platforms, and not necessarily multiple lisps.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
The best-laid plans of mice and men go oft astray.
On 2005-10-23 05:34:34 +0100, Surendra Singhi <·········@netscape.net> said:
> verec <·····@mac.com> writes:
>
>> but about *the spec* that DOES NOT allow me TODAY to
>> write portable+GUI+threaded code in CL.
>
> What do you mean by portable? Your code should be able to run across multiple
> platforms, and not necessarily multiple lisps.
Thanks Surendra. You are the first one to actually understand what I
am talking about.
Are you suggesting that you know of at least one vendor that targets
at least (Mac+Win+Linux) and allows me to write a single code base that
will compile and run all three targets? Even though that code may not
port well or at all to other vendors?
That's not the full solution I was interested in, but at least that is
in the right direction.
Even though I know that Franz and LispWorks do address the targets above,
I don't know, first hand, whether:
- their ``process'' implementation shields me (or not) from the unerlying OS
which means, if they don't, that I'm back to square one.
- their "GUI" stuff is up to task (with full 2D rendering primitives, not
just dialog boxes)
Anyone with actual experience deploying on all three targets using either
vendor (or others) Lisp, and satisfied with the result?
Many Thanks.
--
JFB (Still marveling at the innards of OpenMCL :-)
Am 23.10.2005 7:00 Uhr schrieb "verec" unter <·····@mac.com> in
·························@news.aaisp.net.uk:
> On 2005-10-23 05:34:34 +0100, Surendra Singhi <·········@netscape.net> said:
>
>> verec <·····@mac.com> writes:
>>
>>> but about *the spec* that DOES NOT allow me TODAY to
>>> write portable+GUI+threaded code in CL.
Currently your best bet is LispWorks.
Allegro CL may soon cover Windows + Linux, but not Mac OS X.
Currently their graphics substrate + IDE is in beta (alpha?) for
Linux.
>> What do you mean by portable? Your code should be able to run across multiple
>> platforms, and not necessarily multiple lisps.
>
> Thanks Surendra. You are the first one to actually understand what I
> am talking about.
>
> Are you suggesting that you know of at least one vendor that targets
> at least (Mac+Win+Linux) and allows me to write a single code base that
> will compile and run all three targets? Even though that code may not
> port well or at all to other vendors?
With LispWorks you have GUI+Threading on all platforms.
You use CAPI for the portable GUI and their extended
Common Lisp for the portable threading.
Documentation for the various platforms is here:
http://www.lispworks.com/documentation/index.html
Look there for the CAPI documentation.
The MP (multiprocessing) documentation for the Macintosh
platform is here:
http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-349.htm#pgfId-8
86156
For writing applications to all these platforms (Mac, Win, Linux)
you need LispWorks on all these platforms. So the code
is portable in a way that it can compiled without
changes (the usual disclaimer here) on the various platforms.
You can't compile it once and run that compiled code on
all platforms. You need to get compiled code on each
(since LispWorks uses native code compilation).
Obvious drawback it costs the developer quite a lot to cover all three
platforms with LispWorks. Though once you have LispWorks,
there are no royalties for delivery of applications.
Plus there is another disadvantage that LispWorks' graphics substrate
is not open source (even not non-free open source). So you depend
on paying the vendor to fix bugs, implement features, improve
the library.
> That's not the full solution I was interested in, but at least that is
> in the right direction.
>
> Even though I know that Franz and LispWorks do address the targets above,
> I don't know, first hand, whether:
>
> - their ``process'' implementation shields me (or not) from the unerlying OS
> which means, if they don't, that I'm back to square one.
LispWorks has a single CAPI and MP interface on all platforms.
> - their "GUI" stuff is up to task (with full 2D rendering primitives, not
> just dialog boxes)
CAPI has drawing primitives.
> Anyone with actual experience deploying on all three targets using either
> vendor (or others) Lisp, and satisfied with the result?
If your code is not to large, you could get the personal edition of
LispWorks for these platforms and try it for yourself.
On 2005-10-23 08:23:40 +0100, Rainer Joswig <······@lisp.de> said:
>>>> but about *the spec* that DOES NOT allow me TODAY to
>>>> write portable+GUI+threaded code in CL.
>
> Currently your best bet is LispWorks.
>
> Allegro CL may soon cover Windows + Linux, but not Mac OS X.
> Currently their graphics substrate + IDE is in beta (alpha?) for
> Linux.
Thanks.
> With LispWorks you have GUI+Threading on all platforms.
> You use CAPI for the portable GUI and their extended
> Common Lisp for the portable threading.
>
> Documentation for the various platforms is here:
> http://www.lispworks.com/documentation/index.html
>
> Look there for the CAPI documentation.
>
> The MP (multiprocessing) documentation for the Macintosh
> platform is here:
> http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-349.htm#pgfId-8
> 86156
Excellent. This seems to be along the lines that Surenda suggested.
I'm going to evaluate this option. Many thanks.
> For writing applications to all these platforms (Mac, Win, Linux)
> you need LispWorks on all these platforms. So the code
> is portable in a way that it can compiled without
> changes (the usual disclaimer here) on the various platforms.
> You can't compile it once and run that compiled code on
> all platforms. You need to get compiled code on each
> (since LispWorks uses native code compilation).
>
> Obvious drawback it costs the developer quite a lot to cover all three
> platforms with LispWorks. Though once you have LispWorks,
> there are no royalties for delivery of applications.
>
> Plus there is another disadvantage that LispWorks' graphics substrate
> is not open source (even not non-free open source). So you depend
> on paying the vendor to fix bugs, implement features, improve
> the library.
I will need to evaluate how well it maps (or not) to Quartz which,
for now, I consider as my 2D yardstick (though Java 2D isn't especially
bad either, execpt for primitive drawing recording and replaying which
is lacking)
> LispWorks has a single CAPI and MP interface on all platforms.
That's a releif :-)
> CAPI has drawing primitives.
Ditto.
> If your code is not to large, you could get the personal edition of
> LispWorks for these platforms and try it for yourself.
I already do. But I must admit having been put off by what I got.
I thought to myself that if the IDE _today_ wasn't any better than
what I used in the MCL 2.x days, more than FIFTEEN years ago, then
surely, this people couldn't be trusted for graphics, attention to
detail, and valueing the user experience.
I will revist all this. There might be a gem in the rough, after all :-)
Many thanks for addressing my issues.
--
JFB (Still marveling at the innards of OpenMCL :-)
In article <·························@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
...
> I thought to myself that if the IDE _today_ wasn't any better than
> what I used in the MCL 2.x days, more than FIFTEEN years ago, then
> surely, this people couldn't be trusted for graphics, attention to
> detail, and valueing the user experience.
>
> I will revist all this. There might be a gem in the rough, after all :-)
Actually the LispWorks IDE is better than what MCL had and has. But it
historically comes from Unix, then Windows to the Mac. So
it might not be that elegant on the Mac.
Strengths for MCL:
- simple and effective development tools
- simple and effective GUI toolkit
- high hackability (source included and extensive
low-level interface to Mac OS 9 (and before).
- lots of user-provided extensions
- native CLIM
- relatively small and compact
Generally I prefer LispWorks for the following points:
- basic Lisp system available on several platforms
with good GC and runtime technology
- cross-platform GUI toolkit (-> CAPI)
- lots more development environment tools compared to MCL
- more systematic approach to IDE design
- more systematic approach to library design
- better editor (modes, source coloring, ...)
- LispWorks can be used without GUI or with an X11/Motif version of the GUI
- Cocoa interface
- database interface built-in
- good top-level-based functionality (+ inspector, debugger, ...)
Actually the IDE of LispWorks is quite good. I would rate
it as the best conventional IDE for Lisp. Obviously
it has some compromises due to what CAPI offers
(for example no drag&drop).
It is also hard to compare to a Java-based environment like Eclipse,
since the development styles are totally different. If you
switch from Java to Lisp, you will miss a few things. After
a while you will detect that some of them are there, hidden.
Later after adopting development styles that are used in
the Lisp community (incremental, interactive, ...) and when
you are starting to use some of the more advanced Lisp features
(CLOS, macros, ...) you will find it quite powerful.
Here is a video showing you some really simple programming
using the LispWorks development environment. I have tried
to avoid most of the advanced IDE usage, just using the
basic editor and listener commands. I recorded the
interaction to show a simple development process,
inspired by an article by Martin Fowler. So the
video is not really about explaining the LispWorks IDE,
but one might get a few clues from watching it. Maybe. ;-)
http://lispm.dyndns.org/mov/dsl-in-lisp.mov
You will be redirected to another server that should have
acceptable download speed. Both web servers actually
are running in some LispWorks on the Mac.
On 2005-10-23 08:16:59 -0400, Rainer Joswig <······@lisp.de> said:
> So the
> video is not really about explaining the LispWorks IDE,
> but one might get a few clues from watching it. Maybe. ;-)
>
> http://lispm.dyndns.org/mov/dsl-in-lisp.mov
Very cool demo Rainer - thanks for posting it.
warmest regards
Rainer Joswig wrote:
> Am 23.10.2005 7:00 Uhr schrieb "verec" unter <·····@mac.com> in
> ·························@news.aaisp.net.uk:
>
>
>>On 2005-10-23 05:34:34 +0100, Surendra Singhi <·········@netscape.net> said:
>>
>>
>>>verec <·····@mac.com> writes:
>>>
>>>
>>>>but about *the spec* that DOES NOT allow me TODAY to
>>>>write portable+GUI+threaded code in CL.
>
>
> Currently your best bet is LispWorks.
>
> Allegro CL may soon cover Windows + Linux, but not Mac OS X.
What's wrong with AllegroCL plus Cells-Gtk or Ltk?
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
>
>
> Rainer Joswig wrote:
>
>> Am 23.10.2005 7:00 Uhr schrieb "verec" unter <·····@mac.com> in
>> ·························@news.aaisp.net.uk:
>>
>>
>>> On 2005-10-23 05:34:34 +0100, Surendra Singhi
>>> <·········@netscape.net> said:
>>>
>>>
>>>> verec <·····@mac.com> writes:
>>>>
>>>>
>>>>> but about *the spec* that DOES NOT allow me TODAY to
>>>>> write portable+GUI+threaded code in CL.
>>
>>
>>
>> Currently your best bet is LispWorks.
>>
>> Allegro CL may soon cover Windows + Linux, but not Mac OS X.
>
>
> What's wrong with AllegroCL plus Cells-Gtk or Ltk?
>
>
Oh, right, the OP wants a non-EMACS IDE as well.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Rainer Joswig <······@lisp.de>:
>> - their "GUI" stuff is up to task (with full 2D rendering primitives, not
>> just dialog boxes)
> CAPI has drawing primitives.
While I like Lispworks very much myself, I think it is necessary to
point out that the Unix and Linux implementations of CAPI use the
Motif widget set and limit you to the core X11 rendering primitives
(implying no support for transparency).
This makes for a look that feels somewhat antiquated to me (Windows 3.1
era), which might or might not be a limitation that you can live with.
Juliusz
In article <··············@lanthane.pps.jussieu.fr>,
Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
> Rainer Joswig <······@lisp.de>:
>
> >> - their "GUI" stuff is up to task (with full 2D rendering primitives, not
> >> just dialog boxes)
>
> > CAPI has drawing primitives.
>
> While I like Lispworks very much myself, I think it is necessary to
> point out that the Unix and Linux implementations of CAPI use the
> Motif widget set and limit you to the core X11 rendering primitives
> (implying no support for transparency).
>
> This makes for a look that feels somewhat antiquated to me (Windows 3.1
> era), which might or might not be a limitation that you can live with.
I agree that Motif is not visually attractive and a bit
old fashioned.
What would be the current UI toolkit to use on X11?
Would it be Gtk? Something else?
On Fri, 28 Oct 2005 00:08:13 +0200, Rainer Joswig <······@lisp.de> wrote:
yes, that is a option.
Gnome Toolkit and Qt are the most popular options.
Each have their own window manager.
(not neccesary to run the app but it is nice to have a consistent
interface)
> In article <··············@lanthane.pps.jussieu.fr>,
> I agree that Motif is not visually attractive and a bit
> old fashioned.
>
> What would be the current UI toolkit to use on X11?
> Would it be Gtk? Something else?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Robert Uhl
Subject: Re: Still clinking to Java?
Date:
Message-ID: <m364rg7pp8.fsf@4dv.net>
Rainer Joswig <······@lisp.de> writes:
>
> I agree that Motif is not visually attractive and a bit old fashioned.
>
> What would be the current UI toolkit to use on X11? Would it be Gtk?
> Something else?
My vote would be for gtk+: portable, written in C (which is, like it or
not, the default implementation language on a POSIX system), fairly
attractive. It's not the best library ever, but it gets the job done.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I stopped and considered for a moment whether such a person would behave
any differently with his head cut right off, but then realized it would
make a difference: it would allow him to stand upright again.
--Anthony de Boer
On Sun, 23 Oct 2005 06:00:12 +0100, verec <·····@mac.com> wrote:
> Are you suggesting that you know of at least one vendor that targets
> at least (Mac+Win+Linux) and allows me to write a single code base
> that will compile and run all three targets? Even though that code
> may not port well or at all to other vendors?
>
> [...]
>
> Even though I know that Franz and LispWorks do address the targets
> above, I don't know, first hand, whether:
>
> - their ``process'' implementation shields me (or not) from the
> unerlying OS which means, if they don't, that I'm back to square
> one.
> - their "GUI" stuff is up to task (with full 2D rendering
> primitives, not just dialog boxes)
>
> Anyone with actual experience deploying on all three targets using
> either vendor (or others) Lisp, and satisfied with the result?
Hmm, didn't you just write in another posting that you /know/
LispWorks and have decided that it didn't meet your expectations?
From your questions above I can only assume that you haven't
"investigated" LispWorks for more than a couple of minutes. Well,
it's more fun to spend time on Usenet, isn't it?
Anyway, for those who are really interested: LispWorks provides a
portable solution for the GUI part as well as for the MP part,
i.e. you write code that is platform-independent. The available
target platforms are Windows, Linux, OS X, and some commercial Unix
variants. The GUI maps to "native" widgets on Windows and OS X, and
to Motif widgets on the other platforms. On Windows, OS X, and
(beginning with LW 5.0) Linux threads are OS threads, on the
commercial Unix variants threads are "green" AFAIK.
And, yes, I have actually written programs with LW that create GUIs
and use multi-processing on different platforms. See
<http://weitz.de/regex-coach/>
for one example.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2005-10-23 11:56:04 +0100, Edi Weitz <········@agharta.de> said:
> On Sun, 23 Oct 2005 06:00:12 +0100, verec <·····@mac.com> wrote:
[...]
> Hmm, didn't you just write in another posting that you /know/
> LispWorks and have decided that it didn't meet your expectations?
> From your questions above I can only assume that you haven't
> "investigated" LispWorks for more than a couple of minutes. Well,
> it's more fun to spend time on Usenet, isn't it?
Tone it down please. Arrogance is not substitute for intelligence.
I have spent THREE week-ends downloading/installing/evaluating
LispWorks, SBCL, OpenMCL and CLisp, going through all the hoops
of building the beast, finding/getting the missing bits until,
finally, I was, in most cases, granted by a tcsh prompt! I even
tried to give Emacs a fair try, and even listened to that video
showing all the "good bits" (that "slime" movie).
At which point I was utterly disapointed. If Lisp *as it exists
in the market place* (as opposed to its potential) is still
in such an _UNUSABLE_ state, then those guys simply have not
understood the lessons of history.
> Anyway, for those who are really interested: LispWorks provides a
> portable solution for the GUI part as well as for the MP part,
> i.e. you write code that is platform-independent. The available
> target platforms are Windows, Linux, OS X, and some commercial Unix
> variants.
Yep. Rainer Joswig said the same. I will definitively re-evalute
LispWorks.
> The GUI maps to "native" widgets on Windows and OS X, and
> to Motif widgets on the other platforms.
That sounds like the SWT approach. I like it.
> On Windows, OS X, and (beginning with LW 5.0) Linux threads are
> OS threads, on the commercial Unix variants threads are "green" AFAIK.
Better late than never :-)
> And, yes, I have actually written programs with LW that create GUIs
> and use multi-processing on different platforms. See
>
> <http://weitz.de/regex-coach/>
>
> for one example.
Thanks. A bit too "dialog-box-ish" for my needs though. I would be
very interested in seeing example where people *actually draw* on the
screen rather than seeing yet another screenfull of widgets.
--
JFB (Still marveling at the innards of OpenMCL :-)
In article <·························@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> On 2005-10-23 11:56:04 +0100, Edi Weitz <········@agharta.de> said:
>
> > On Sun, 23 Oct 2005 06:00:12 +0100, verec <·····@mac.com> wrote:
> [...]
>
> > Hmm, didn't you just write in another posting that you /know/
> > LispWorks and have decided that it didn't meet your expectations?
> > From your questions above I can only assume that you haven't
> > "investigated" LispWorks for more than a couple of minutes. Well,
> > it's more fun to spend time on Usenet, isn't it?
>
> Tone it down please. Arrogance is not substitute for intelligence.
>
> I have spent THREE week-ends downloading/installing/evaluating
> LispWorks, SBCL, OpenMCL and CLisp, going through all the hoops
> of building the beast, finding/getting the missing bits until,
> finally, I was, in most cases, granted by a tcsh prompt! I even
> tried to give Emacs a fair try, and even listened to that video
> showing all the "good bits" (that "slime" movie).
>
> At which point I was utterly disapointed. If Lisp *as it exists
> in the market place* (as opposed to its potential) is still
> in such an _UNUSABLE_ state, then those guys simply have not
> understood the lessons of history.
>
> > Anyway, for those who are really interested: LispWorks provides a
> > portable solution for the GUI part as well as for the MP part,
> > i.e. you write code that is platform-independent. The available
> > target platforms are Windows, Linux, OS X, and some commercial Unix
> > variants.
>
> Yep. Rainer Joswig said the same. I will definitively re-evalute
> LispWorks.
>
> > The GUI maps to "native" widgets on Windows and OS X, and
> > to Motif widgets on the other platforms.
>
> That sounds like the SWT approach. I like it.
>
> > On Windows, OS X, and (beginning with LW 5.0) Linux threads are
> > OS threads, on the commercial Unix variants threads are "green" AFAIK.
>
> Better late than never :-)
>
> > And, yes, I have actually written programs with LW that create GUIs
> > and use multi-processing on different platforms. See
> >
> > <http://weitz.de/regex-coach/>
> >
> > for one example.
>
> Thanks. A bit too "dialog-box-ish" for my needs though. I would be
> very interested in seeing example where people *actually draw* on the
> screen rather than seeing yet another screenfull of widgets.
Xanalys' 'Link Explorer' is written in LispWorks.
http://www.xanalys.com/documents/XANALYSLinkExplorer.pdf
On 2005-10-23 14:08:10, verec wrote:
> Thanks. A bit too "dialog-box-ish" for my needs though. I would be
> very interested in seeing example where people *actually draw* on the
> screen rather than seeing yet another screenfull of widgets.
The LispWorks Personal Edition 4.4.5 has an examples folder.
On Sun, 23 Oct 2005 13:08:10 +0100, verec <·····@mac.com> wrote:
> Tone it down please. Arrogance is not substitute for intelligence.
You set the tone for this thread.
> I have spent THREE week-ends downloading/installing/evaluating
> LispWorks, SBCL, OpenMCL and CLisp, going through all the hoops of
> building the beast, finding/getting the missing bits until, finally,
> I was, in most cases, granted by a tcsh prompt!
Downloading and installing LispWorks takes a couple of minutes and you
get a lot more than a "tcsh prompt."
> If Lisp *as it exists in the market place* (as opposed to its
> potential) is still in such an _UNUSABLE_ state, then those guys
> simply have not understood the lessons of history.
Sure, certainly they're all idiots and you have seen the light. See
your own remark about arrogance above.
> Thanks. A bit too "dialog-box-ish" for my needs though.
Most "real" apps are like that...
> I would be very interested in seeing example where people *actually
> draw* on the screen rather than seeing yet another screenfull of
> widgets.
CAPI provides full cross-platform support for drawing on the screen.
As others have pointed out, there are lots of examples that come with
LispWorks. Something you could have checked in the "THREE week-ends"
you mentioned.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
verec <·····@mac.com> writes:
> On 2005-10-23 11:56:04 +0100, Edi Weitz <········@agharta.de> said:
[...]
>> And, yes, I have actually written programs with LW that create GUIs
>> and use multi-processing on different platforms. See
>> <http://weitz.de/regex-coach/>
[...]
> Thanks. A bit too "dialog-box-ish" for my needs though. I would be
> very interested in seeing example where people *actually draw* on the
> screen rather than seeing yet another screenfull of widgets.
Here is a more complex, cross-platform (Windows, Linux, Mac OS X)
LispWorks/CAPI application:
Netfonds Prime Trader
http://www.netfonds.no/pt.php
Prime Trader and other Lisp applications at Netfonds
http://espen.vestre.net/eclm05/ev-ams-2005.pdf
Some screen shots:
http://www.netfonds.no/manual_pt_eng.php
one of which includes some stock charts.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
"verec" <·····@mac.com> wrote in message
······························@news.aaisp.net.uk...
> On 2005-10-23 11:56:04 +0100, Edi Weitz <········@agharta.de> said:
>
>> Anyway, for those who are really interested: LispWorks provides a
>> portable solution for the GUI part as well as for the MP part,
>> i.e. you write code that is platform-independent. The available
>> target platforms are Windows, Linux, OS X, and some commercial Unix
>> variants.
>
> Yep. Rainer Joswig said the same. I will definitively re-evalute
> LispWorks.
>
>> The GUI maps to "native" widgets on Windows and OS X, and
>> to Motif widgets on the other platforms.
>
> That sounds like the SWT approach. I like it.
>
>> On Windows, OS X, and (beginning with LW 5.0) Linux threads are
>> OS threads, on the commercial Unix variants threads are "green" AFAIK.
>
> Better late than never :-)
I find the LispWorks prices to be exhorbitant.
You can test the personal edition but unlike the Allegro free trial
LispWorks EXITS after 5 hours, and of course has the other
professional limitations (no stand alone app production etc) which
do make sense for a free version. And of course Allegro is merely
expensive, rather than exhorbitant.
Were I making a lot of money from Lisp the price of the tools would
(perhaps) be nearly irrelevant, but for me the need is a bit more
modest.
--
Herb Martin
"Herb Martin" <····@LearnQuick.com> writes:
> I find the LispWorks prices to be exhorbitant.
I think you need to lay off the herb, Martin. $1100 isn't cheap, but
I'd hardly call it exorbitant.
> Were I making a lot of money from Lisp the price of the tools would
> (perhaps) be nearly irrelevant, but for me the need is a bit more
> modest.
Lispworks Pro is a bit steep for casual hobbyists. But for small
businesses or serious hobbyists, I don't see a problem.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
On Mon, 24 Oct 2005 02:02:08 GMT, "Herb Martin" <····@LearnQuick.com> wrote:
> I find the LispWorks prices to be exhorbitant.
>
> You can test the personal edition but unlike the Allegro free trial
> LispWorks EXITS after 5 hours, and of course has the other
> professional limitations (no stand alone app production etc) which
> do make sense for a free version. And of course Allegro is merely
> expensive, rather than exhorbitant.
Assuming that you mean "exorbitant" I can't understand where you're
heading at. You're aware of the fact that a LW license that enables
you to create "stand-alone" apps costs a lot less than a similar one
for AllegroCL and that you don't have to pay runtime fees? Have you
compared these prices with those for other commercial development
environments (for other languages)?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
verec wrote:
> On 2005-10-22 23:47:15 +0100, Wade Humeniuk
> <··················@telus.net> said:
>
>> WHY are you whining? Get a spine and try a real CL like
>> Lispworks.
>
>
> As a matter of fact, I do have LispWorks. And OpenMCL.
>
> - their "IDE" is a joke. Period.
Agreed. When you get bored with trolling, try AllegroCL. But that still
will not be the match of Java IDEs. Necessity is the mother of
invention, and Java necessitates a lot. (hint.) By the same token, any
Lisp newby coming from IDE-rich languages starts off shocked at the
lameness of Lisp IDEs but discovers soon enough they Just Do Not Need
all those IDE features because Lisp is such a different animal, and so
Lisp vendors never hear any demand for those other features.
The big point being, wow, Lisp must be insanely great that huge IDE
investments can simply be skipped. Meditate on that for six months and
get back to us. Understood though if you want to troll on for a few more
weeks to deal with your loneliness.
> - the CL that is within is certainly as close to CLTL2
> as any other, but that misses the entire point.
>
> The point is not about *implementation* X, Y or Z of CL,
> but about *the spec* that DOES NOT allow me TODAY to
> write portable+GUI+threaded code in CL. This, Java gives
> it to me now. CL doesn't.
We always know a troll when we see a long list of interesting
requirements stated in the abstract. What is your application? (Ha!)
>
> Is it possible to have an adult conversation, and not start
> flames just because you cannot correctly parse a sentence?
Lisp makes mundane tasks harder, for now. CFFI looks to have established
one portability accomplishment. In other cases you might have to do a
little conditional compilation to achieve portable source by
conditionaling tapping into proprietary but swappable libraries, say for
threading. Is that the end of the world, compared to having to code Java
all day long? Well, you make clear that you are a big fan of Lisp (ha!),
so I do not have to tell you that a finite effort to achieve portable
threading is nothing compared to the orders of magnitude improvement in
productivity you get from using Lisp day in day out for the massive
application you have in mind. PWUAUUAAJHHAHAHHAHAHAHAHAHHAHA!
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
On 2005-10-23 06:05:16 +0100, Kenny Tilton <·······@nyc.rr.com> said:
>> - their "IDE" is a joke. Period.
>
> Agreed. When you get bored with trolling, try AllegroCL.
No need to be insulting to suggest AllegroCL.
> But that still will not be the match of Java IDEs.
If you say so, it must be true :-)
> The big point being, wow, Lisp must be insanely great that huge
> IDE investments can simply be skipped.
Nobody else can dictate how *I* am productive. If Emacs fits
your bill, the best to you. It doesn't fit mine.
> Meditate on that for six months and get back to us.
Yes, Dad!
> Understood though if you want to troll on for a few mor
> weeks to deal with your loneliness.
That's pretty lame.
> We always know a troll when we see a long list of interesting
> requirements stated in the abstract. What is your application? (Ha!)
- I develop on Mac, but the target is Win (and possibly Linux)
=> portable
- My client has 80 cross-words to publish per week. I have to
provide him with filled grids (he provides the templates
15x15 to 25x25) from a 100,000 words dictionary
- Once the product is finished, I expect to only provide a
"do-it" button and just write 80 files to the file system
(format not decided now, but relatively unimportant)
- But before the product is finished, it has to work! Which
means that until such time *I* am the user. And as the user
of that product while it is being developped I need:
- a "GUI" to diplay the grids and *see* the successive attempts
at filling it, so as to develop a "feel" for what sort
of algorithm works and what doesn't.
- I need threads because I want to be able to run/suspend/resume
the solver at any time, without cluttering the solver code
with GUI stuff.
- I've done it in Java this far, precisely because of the above
problems (thread+GUI)
I've reached 92% completion of the grid in about 7 minutes.
That's my best result so far, and, obviously, I'm not done.
Nothing less than 100% is acceptable of course. And preferably
in an amount of time suitable to produce 80 such filled grids
per weeks, so it can take many minutes, but not many hours.
The combinatorial explosion just rules out any brute force
approach.
Obviously, as soon as I get something that I deem acceptable,
I just don't want to switch language _at that point_ and recode
what I will have needed so many experiments to get right. So
the prototyping language must be the deployment langauge.
> PWUAUUAAJHHAHAHHAHAHAHAHAHHAHA!
????
--
JFB (Still marveling at the innards of OpenMCL :-)
I'm more a Python guy and currently looking at Lisp from the distance.
I feel a bit sorry for you, because this really shows the arrogant
behaviour of the Lisp community. They may be right about Lisp as a
language transcends Java IDE, but nobody seems to have the social
skills to tell.
> - I develop on Mac, but the target is Win (and possibly Linux)
> => portable
> - My client has 80 cross-words to publish per week. I have to
> provide him with filled grids (he provides the templates
> 15x15 to 25x25) from a 100,000 words dictionary
> - Once the product is finished, I expect to only provide a
> "do-it" button and just write 80 files to the file system
> (format not decided now, but relatively unimportant)
> - But before the product is finished, it has to work! Which
> means that until such time *I* am the user. And as the user
> of that product while it is being developped I need:
> - a "GUI" to diplay the grids and *see* the successive attempts
> at filling it, so as to develop a "feel" for what sort
> of algorithm works and what doesn't.
> - I need threads because I want to be able to run/suspend/resume
> the solver at any time, without cluttering the solver code
> with GUI stuff.
> - I've done it in Java this far, precisely because of the above
> problems (thread+GUI)
After reading this "spec" i think you try to do Java Design in Lisp,
which is not The Right Thing. The GUI is more of a debugging tool not
an essential part of the product and A command line interface would do
as well, after working out the algorithm.
Threads for suspending does not seem right to me either. I'm really not
sure about this, but wouldn't a Lisper use Continuations for this?
I feel dirty to mention this on c.l.c, but my way would be Python +
wxPython (GUI) and later rewriting the core algorithm to C for speed.
On 2005-10-23 08:33:58 +0100, "beza1e1" <···············@googlemail.com> said:
> I'm more a Python guy and currently looking at Lisp from the distance.
> I feel a bit sorry for you, because this really shows the arrogant
> behaviour of the Lisp community. They may be right about Lisp as a
> language transcends Java IDE, but nobody seems to have the social
> skills to tell.
Indeed :-(
> After reading this "spec" i think you try to do Java Design in Lisp,
> which is not The Right Thing.
Let's assume that I had the Lisp that matched all the criteria
I mentionned already. Why do you think I would proceed differently?
Why do you think that Lisp magic would be such that I would not
need to *see* my grid being populated, or that I would get a better
feel for the "timing" part by *not* using threads?
> The GUI is more of a debugging tool not
> an essential part of the product and A command line interface would do
> as well, after working out the algorithm.
Indeed. Except that I don't call it "debugging" but "exploring".
And when it comes to entice your intuition, nothing is more worrysome
than tools getting in your way, not giving you immediate feedback
of the various "buttons" you can push here and there.
As I said, the final app need not the "GUI" luxury I mentionned,
*I* need it while exploring.
I'm not sure if saying that "exploring with visual aid" is doing
``Java Design in Lisp'', but if it is, so be it. And I claim that
is the right approach to me, because I'm a _visual_ guy.
> Threads for suspending does not seem right to me either. I'm really not
> sure about this, but wouldn't a Lisper use Continuations for this?
Look at this way: in the final app, there will be no (or close to no)
GUI. Why should the solver process be written to cope with it?
By writing it in its own thread, I can switch that thread to be the
unique and main thread on release, but keep it as a secondary
thread while debugging _with no code change whatsoever between the
two modes_.
Also, with appropriate language support (which, I'm sorry to
report, Sun's JRE *does* provide) I can take advantage of mutlicore
processors by splitting the solver thread into two or more threads
(assuming the final algorithm I settle on does allow for this), each
of which will be mapped to one such processor core, thus speeding
up the whole resolution.
> I feel dirty to mention this on c.l.c, but my way would be Python +
> wxPython (GUI) and later rewriting the core algorithm to C for speed.
Thanks for the plug :-)
Best Regards.
--
JFB (Still marveling at the innards of OpenMCL :-)
On 2005-10-23 09:33:58, beza1e1 wrote:
> I'm more a Python guy and currently looking at Lisp from the distance.
> I feel a bit sorry for you, because this really shows the arrogant
> behaviour of the Lisp community. They may be right about Lisp as a
> language transcends Java IDE, but nobody seems to have the social
> skills to tell.
Funny. One of the reasons I haven't tried Python yet are the "social
skill" of the Python users.
> I feel dirty to mention this on c.l.c, but my way would be Python +
> wxPython (GUI) and later rewriting the core algorithm to C for speed.
Sure. Python is the �ber-Language and every problem must be solved
in Python.
beza1e1 wrote:
> I'm more a Python guy and currently looking at Lisp from the distance.
> I feel a bit sorry for you, because this really shows the arrogant
> behaviour of the Lisp community. They may be right about Lisp as a
> language transcends Java IDE, but nobody seems to have the social
> skills to tell.
Social skills? PWUAHAHA. Your mistake is thinking we give a rat's ass
about being liked by trolls like verec. Real Programmers do what they
have to do to get their jobs done, and that never includes a slamming
whine job "why I hate XXX" on a language's NG.
If you need a hug, I recommend group therapy, not Lisp, and certainly
not The Savages of CLL.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
> and that never includes a slamming
> whine job "why I hate XXX" on a language's NG.
I especially like the cluelessness inherent in the complaints.
The trolls seem to have no idea that a language design is a
social compromise among thousands of users and implementors.
*Of course* for any particular individual that compromise may
involve features he won't like, even if most of the rest
of the community doesn't mind.
There are things in CL that a larger fraction of the
community thinks are flawed or could use improvement, but
the trolls rarely mention those.
Paul
On Mon, 24 Oct 2005 08:15:22 +0200, Kenny Tilton <·······@nyc.rr.com>
wrote:
>
>
> beza1e1 wrote:
>> I'm more a Python guy and currently looking at Lisp from the distance.
>> I feel a bit sorry for you, because this really shows the arrogant
>> behaviour of the Lisp community. They may be right about Lisp as a
>> language transcends Java IDE, but nobody seems to have the social
>> skills to tell.
>
> Social skills? PWUAHAHA. Your mistake is thinking we give a rat's ass
> about being liked by trolls like verec. Real Programmers do what they
> have to do to get their jobs done, and that never includes a slamming
> whine job "why I hate XXX" on a language's NG.
>
> If you need a hug, I recommend group therapy, not Lisp, and certainly
> not The Savages of CLL.
>
rlol.. And incedentally I liked the crossword problem.
When I am finished with it look at my web cite :)
http://home.chello.no/~jthing/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 24 Oct 2005 06:15:22 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>Social skills? PWUAHAHA. Your mistake is thinking we give a rat's ass
>about being liked by trolls like verec. Real Programmers do what they
>have to do to get their jobs done, and that never includes a slamming
>whine job "why I hate XXX" on a language's NG.
Well, I for one wish I had just stayed out of it.
>If you need a hug, I recommend group therapy, not Lisp, and certainly
>not The Savages of CLL.
:-)
--
Jack
> Social skills? PWUAHAHA. Your mistake is thinking we give a rat's ass
> about being liked by trolls like verec.
Does "verec" give "a rat's ass" about being liked by God Kenny Tilton?
"verec" doesn't think that posts made by Kenny Tilton had any relevance
to the thread, and would, thus, qualify His Majesty Tilton, Kelly, hopefully
first and only, not as a troll but as real life deprived, and thus
needing to exist by rambling on usenet.
"verec" by his conspicuous absence of regular posts, shows, at least,
that he has other things to do in life than not responding to questions
that arrise, here and then.
Real Programmers ... program. They don't haunt usenet as Saint Tilton does.
A few years back, here in c.l.l, we had a bug called "Naggum". I just wonder
if Tilton, Kelly Fish is not just his re-incarnation?
Not too good for your carma, Sir Tilton.
Being an arrogant imbecile uttering "troll! troll! troll!" three times
a sentence doesn't bode too well... Show us your (setq ...) and (defmacro ...)
instead.
And if you can't stand seeing your little toy being "attacked" by "trolls",
just get out of here: there's nothing for you.... unless that's the only
thing you've got in life, which I wouldn't find that surprising.
Good Bye Mr Tilton. Hope to not see you soon.
--
JFB (Still marveling at the innards of OpenMCL :-)
verec <·····@mac.com> writes:
> > Social skills? PWUAHAHA. Your mistake is thinking we give a rat's ass
> > about being liked by trolls like verec.
>
> Does "verec" give "a rat's ass" about being liked by God Kenny Tilton?
... etc...
Just out of curiosity, why are you so insecure?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
verec wrote:
> On 2005-10-23 06:05:16 +0100, Kenny Tilton <·······@nyc.rr.com> said:
> - I develop on Mac, but the target is Win (and possibly Linux)
> => portable
> - My client has 80 cross-words to publish per week. I have to
> provide him with filled grids (he provides the templates
> 15x15 to 25x25) from a 100,000 words dictionary
> - Once the product is finished, I expect to only provide a
> "do-it" button and just write 80 files to the file system
Try LTK / WxCL. (LTK has some problems with specific tray apps in
windows,
but should actually do that job).
(since your final app needs only a simple button, doing it in CLX
shouldn't
be such a big deal..(Its portable across Linux and most unixes.) If you
can handle the ugliness of Swing I guess CLX shouldn't bother you.. and
since you are ok to code in Java, CLX (which according to me is a
transliterations of XLIB is as verbose as java anyway.. that shouldn't
deter you either..)
> (format not decided now, but relatively unimportant)
> - But before the product is finished, it has to work! Which
> means that until such time *I* am the user. And as the user
> of that product while it is being developped I need:
> - a "GUI" to diplay the grids and *see* the successive attempts
> at filling it, so as to develop a "feel" for what sort
> of algorithm works and what doesn't.
> - I need threads because I want to be able to run/suspend/resume
> the solver at any time, without cluttering the solver code
> with GUI stuff.
Hmm.. Ok.. threading models of concurrency are overrated (but thats a
CS rant, so really don't need to get hyper over that.) But I guess
thats something Scheme can excell in. Read about continuations. (Sort a
does exactly what you want..) and since you only want it to work for
yourself, I guess developing the alogorithm on scheme would be ideal
because it provides the run/suspend/resume feature you want. And since
you will be doing your development in shceme you might as well chose
Dr.Scheme which comes with a decent IDE and GUI Toolkit.
I am ofcourse assuming that you won't be needing that when you actually
deploy your application. Also there are lots of programs out on the net
that can mechanically convert Scheme code -> CL code (if you insist on
deploying in CL).
> - I've done it in Java this far, precisely because of the above
> problems (thread+GUI)
>
I can see why you need a portable GUI but I still don't get your rants
about portable threads, when you only want threads during the
development stage and not during your deployment stage.
> The combinatorial explosion just rules out any brute force
> approach.
I am not an expert on these things, but I guess your usual standard
Tree search techniques won't really help. My take is start with a few
basic hueristic rules on constraints on the placements, etc.. and then
use tree search at each level.
I am assuming you are doing symmetric grids,i.e more constraints so
might reduce the search tree a bit. If its a free form grid then I
guess you can fit it anyway you want.
My best advice is sit and try to do atleast a 15x15 symmetric crossword
by hand and it will give you a lot of ideas about reducing your search
tree.I have done this a couple of times and its not very easy, but
worth it.
> Obviously, as soon as I get something that I deem acceptable,
> I just don't want to switch language _at that point_ and recode
> what I will have needed so many experiments to get right. So
> the prototyping language must be the deployment langauge.
That might be the case if you are say prototyping in CL and deploying
in JAVA, but its not so difficult with close relatives like Scheme/CL.
And finally, if java fits all your purposes, why even post this at
c.l.l? Why not just use java and get it over with?
Cheers
Vishnu
Am 23.10.2005 7:48 Uhr schrieb "verec" unter <·····@mac.com> in
·························@news.aaisp.net.uk:
> - I develop on Mac, but the target is Win (and possibly Linux)
> => portable
> - My client has 80 cross-words to publish per week. I have to
> provide him with filled grids (he provides the templates
> 15x15 to 25x25) from a 100,000 words dictionary
> - Once the product is finished, I expect to only provide a
> "do-it" button and just write 80 files to the file system
> (format not decided now, but relatively unimportant)
> - But before the product is finished, it has to work! Which
> means that until such time *I* am the user. And as the user
> of that product while it is being developped I need:
> - a "GUI" to diplay the grids and *see* the successive attempts
> at filling it, so as to develop a "feel" for what sort
> of algorithm works and what doesn't.
> - I need threads because I want to be able to run/suspend/resume
> the solver at any time, without cluttering the solver code
> with GUI stuff.
> - I've done it in Java this far, precisely because of the above
> problems (thread+GUI)
>
> I've reached 92% completion of the grid in about 7 minutes.
> That's my best result so far, and, obviously, I'm not done.
> Nothing less than 100% is acceptable of course. And preferably
> in an amount of time suitable to produce 80 such filled grids
> per weeks, so it can take many minutes, but not many hours.
Above applications should be doable in LispWorks, so that you
can port your code to multiple platforms (Win, Linux, Mac OS X)
without much (any?) work. You need LispWorks on those three
platforms though to generate the application to deliver.
Sounds like a nice little project for LispWorks.
verec wrote:
> On 2005-10-23 06:05:16 +0100, Kenny Tilton <·······@nyc.rr.com> said:
>
>>> - their "IDE" is a joke. Period.
>>
>>
>> Agreed. When you get bored with trolling, try AllegroCL.
>
>
> No need to be insulting to suggest AllegroCL.
>
>> But that still will not be the match of Java IDEs.
>
>
> If you say so, it must be true :-)
I happen to have been playing recently with both the latest VC++ IDE
(express?) and the NetBeans IDE on win32. This because I happen to have
C and Java versions of a rather hairy educational math app. The Java
version was meant to be an applet but then I lost interest. This all
goes back like ten years. I was toying with saving effort by making the
C version a DLL and redoing the GUI in my portable Cello GUI. But there
would be new work on the engine, and just trying to get a clean compile
of the C version under VC++ I saw enough to remind me I would rather
work in Lisp. And a relatively literal translation to Lisp will be
straightforward, mostly typing since I am pretty comfortable with both
languages. Also, I used the C preprocessor a lot so I just have to port
C macros and voila. And I can grind it out for a month.
Anyway, having seen those two IDEs I am both impressed and less
interested in living with them.
>
>> The big point being, wow, Lisp must be insanely great that huge
>> IDE investments can simply be skipped.
>
>
> Nobody else can dictate how *I* am productive. If Emacs fits
> your bill, the best to you. It doesn't fit mine.
You are mistaken. I hate the EMACS+SLIME thing. I edit in AllegroCL in
emacs mode.
>
>> Meditate on that for six months and get back to us.
>
>
> Yes, Dad!
>
>> Understood though if you want to troll on for a few mor
>> weeks to deal with your loneliness.
>
>
> That's pretty lame.
>
>> We always know a troll when we see a long list of interesting
>> requirements stated in the abstract. What is your application? (Ha!)
>
>
> - I develop on Mac, but the target is Win (and possibly Linux)
> => portable
I plan on distributing on both mac and windows. Linux will be possible
since my candidate portable GUIs run on all three. Depends on how much
more trouble it is to support.
> - My client has 80 cross-words to publish per week. I have to
> provide him with filled grids (he provides the templates
> 15x15 to 25x25) from a 100,000 words dictionary
> - Once the product is finished, I expect to only provide a
> "do-it" button and just write 80 files to the file system
> (format not decided now, but relatively unimportant)
> - But before the product is finished, it has to work! Which
> means that until such time *I* am the user. And as the user
> of that product while it is being developped I need:
> - a "GUI" to diplay the grids and *see* the successive attempts
> at filling it, so as to develop a "feel" for what sort
> of algorithm works and what doesn't.
> - I need threads because I want to be able to run/suspend/resume
> the solver at any time, without cluttering the solver code
> with GUI stuff.
> - I've done it in Java this far, precisely because of the above
> problems (thread+GUI)
>
> I've reached 92% completion of the grid in about 7 minutes.
> That's my best result so far, and, obviously, I'm not done.
> Nothing less than 100% is acceptable of course. And preferably
> in an amount of time suitable to produce 80 such filled grids
> per weeks, so it can take many minutes, but not many hours.
>
> The combinatorial explosion just rules out any brute force
> approach.
Sounds like you have some interesting work ahead. That argues for a
language that lets you explore without fussing over the language's
limitations. (Hint.)
>
> Obviously, as soon as I get something that I deem acceptable,
> I just don't want to switch language _at that point_ and recode
> what I will have needed so many experiments to get right. So
> the prototyping language must be the deployment langauge.
I do not know about the threads issue. If you can afford AllegroCL I
believe you will be good to go, since their stuff runs on all three and
I believe with the same API for threading and more. If you have to
switch Lisps, you might get by with a relatively small amount of
conditional compilation. Then question is where you want to put your
effort, on a finite task generating an ad hoc portable threading
package, or on a never-ending effort coding in Java.
You have accurately identified some small downsides in using Lisp. Now
tell us again how the language is otherwise so great you wish you could
use it for your project.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
On Sun, 23 Oct 2005 05:05:16 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> verec wrote:
>
>> As a matter of fact, I do have LispWorks. And OpenMCL.
>> - their "IDE" is a joke. Period.
>
> Agreed.
Kenny, could you please stop denigrating other Lisp implementations
while you're on your childish crusade for AllegroCL? I'm pretty sure
this won't be helpful - neither for CL in general nor for Franz in
particular.
You used to write something interesting or at least funny on c.l.l
every now and then but in the last months I've only seen hogwash
coming from your direction.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Sun, 23 Oct 2005 05:05:16 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>verec wrote:
>>
>>
>>>As a matter of fact, I do have LispWorks. And OpenMCL.
>>>- their "IDE" is a joke. Period.
>>
>>Agreed.
>
>
> Kenny, could you please stop denigrating other Lisp implementations
I gave my opinion. Others have given theirs. What is the hard part?
> while you're on your childish crusade for AllegroCL?
I honestly consider AllegroCL to be far superior to every other Lisp IDE
(but with commercial MCL as a bearable silver medalist), and people come
here for help with Lisp development, so I tell them the best IDE.
This is in the same spirit as helping struggling in-line skaters in
Central Park. I love skating and want them to enjoy it, too, not
struggle needlessly (and perilously) when ten minutes of pointers can
move them well down the path to happy skating.
ie, the crusade is to help other developers, not Franz. Likewise with
Lisp advocacy in general. Or are you in the Graham School of keeping
good tools to yourself as a competitive advantage?
> I'm pretty sure
> this won't be helpful - neither for CL in general nor for Franz in
> particular.
The only problem is when folks such as yourself misconstrue my praise
for the ACL IDE as anything other than an honest appraisal by a solid
Lispnik who has probably written more, harder Lisp than anyone else on
this NG. (Dinosaurs like Joe might give me a run for my money, tho.)
The last person upset by my praise for ACL like you ignored the facts of
the matter and resorted to personal defamation. My response was (mostly)
to list the features of ACL I like, including mostly that they are all
so well integrated. Google it. Try "paid shill".
I respond with facts about ACL because I am not the issue. ACL rocks,
get over it. Or, more accurately, the other IDEs suck and they could
easily be improved, so I think your recommendation that we all toe the
party line and pretend everything is wonderful in Lispland is a big
mistake that only hinders needed progress. How much energy going into
Slime (and McCLIM) comes from people trying to shut me up? Bingo.
btw, the only thing I have heard from Franz was a backchannel leak that
the folks in sales wish I would stop adding "Others here swear by
Lispworks" to my ACL recommendations. But, hey, they are in sales.
>
> You used to write something interesting or at least funny on c.l.l
> every now and then but in the last months I've only seen hogwash
> coming from your direction.
You're just mad because you forgot about apropos when someone came here
looking for something like apropos. :)
peace. out.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
It's probably useless to respond but I'll try anyway...
On Mon, 24 Oct 2005 18:53:39 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> I honestly consider AllegroCL to be far superior to every other Lisp
> IDE (but with commercial MCL as a bearable silver medalist), and
> people come here for help with Lisp development, so I tell them the
> best IDE.
That's fine. But see below.
> ACL rocks, get over it. Or, more accurately, the other IDEs suck and
> they could easily be improved, so I think your recommendation that
> we all toe the party line and pretend everything is wonderful in
> Lispland is a big mistake that only hinders needed progress.
That wasn't my suggestion - of course not everything is wonderful. I
just wanted to make sure you understand there's a difference between
"I think A is better than B" and "B sucks completely."
FWIW, I've also tried the AllegroCL IDE several times and I simply
don't like it. Period. I think the LW IDE is far better although
it's not perfect - I wish it would borrow some features from SLIME.
Anyway - having said that, I would never say that AllegroCL's IDE
"sucks."
> You're just mad because you forgot about apropos when someone came
> here looking for something like apropos. :)
Yeah... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Kenny Tilton wrote:
> verec wrote:
>
<snip>
> >
> > As a matter of fact, I do have LispWorks. And OpenMCL.
> >
> > - their "IDE" is a joke. Period.
>
> Agreed. When you get bored with trolling, try AllegroCL. But that still
> will not be the match of Java IDEs. Necessity is the mother of
> invention, and Java necessitates a lot. (hint.)
<snip>
>
> --
> Kenny
Netbeans and Eclipse, for some reason, bring the word BLOATWARE to my
mind and I cringe every time I have to start one of them. Half my 512mb
RAM is probably taken up while they load their "modules". [of course
I'm exaggerating, but not too much :-) ]. I have seldom seen my
desktop get that sluggish when starting up an IDE. The latest yahoo
mesenger gives off the same vibe.
Am I the only one who thinks so? Of course I am only learning Java now.
Should one be thinking algorithmic size/time complexity be damned since
memory is "cheap". Or is it that those IDEs provide so much
functionality with their modules, it is only natural?
I haven't tried LispWorks IDE. Allegro's is fast and neat.
-- Aravindh
········@mail.utexas.edu wrote:
> Kenny Tilton wrote:
>
>
>>verec wrote:
>>
>
> <snip>
>
>>>As a matter of fact, I do have LispWorks. And OpenMCL.
>>>
>>>- their "IDE" is a joke. Period.
>>
>>Agreed. When you get bored with trolling, try AllegroCL. But that still
>>will not be the match of Java IDEs. Necessity is the mother of
>>invention, and Java necessitates a lot. (hint.)
>
>
> <snip>
>
>>--
>>Kenny
>
>
> Netbeans and Eclipse, for some reason, bring the word BLOATWARE to my
> mind and I cringe every time I have to start one of them. Half my 512mb
> RAM is probably taken up while they load their "modules". [of course
> I'm exaggerating, but not too much :-) ]. I have seldom seen my
> desktop get that sluggish when starting up an IDE. The latest yahoo
> mesenger gives off the same vibe.
> Am I the only one who thinks so? Of course I am only learning Java now.
> Should one be thinking algorithmic size/time complexity be damned since
> memory is "cheap". Or is it that those IDEs provide so much
> functionality with their modules, it is only natural?
So much functionality? You missed my hint: Java necessitates a lot.
Don't feel bad. Edi "Lisp Legend" Weitz missed it, too. Those IDEs are
not delivering functionality, they are compensating for impossible
languages. Crappy Lisp IDEs mostly matter to the extent that they
alienate newbies looking for the familiar feature set required to get
anything done with other languages. Any newbie who shrugs off that
discomfiture soon enough looks up and realizes, omigod!, I just wrote
this wicked stuff without more than a few IDE tricks. Meanwhile, they
are so orgasmic of the language per se that they never consider looking
back, and instead toss off in half a day their own IDE tools. They would
be better off with AllegroCL or commercial MCL, but in the grand scheme
of things what matters is using Lisp. That is why the yobbos end up
frothing at the mouth over my denigration of their pathetic tool choices
: this time the language Lisp compensates for their lame IDEs, so they
think they have it good.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
> So much functionality? You missed my hint: Java necessitates a lot.
> Don't feel bad. Edi "Lisp Legend" Weitz missed it, too. Those IDEs are
> not delivering functionality, they are compensating for impossible
> languages. Crappy Lisp IDEs mostly matter to the extent that they
> alienate newbies looking for the familiar feature set required to get
> anything done with other languages. Any newbie who shrugs off that
> discomfiture soon enough looks up and realizes, omigod!, I just wrote
> this wicked stuff without more than a few IDE tricks. Meanwhile, they
> are so orgasmic of the language per se that they never consider looking
> back, and instead toss off in half a day their own IDE tools. They would
> be better off with AllegroCL or commercial MCL, but in the grand scheme
> of things what matters is using Lisp. That is why the yobbos end up
> frothing at the mouth over my denigration of their pathetic tool choices
> : this time the language Lisp compensates for their lame IDEs, so they
> think they have it good.
>
> --
> Kenny
Actually, I did get your hint :-)
What I am wondering about is why Netbeans takes up 100mb of RAM
(idling) on Windows XP when I start it up and looks like these IDEs
won't be getting any smaller as time goes by. Of course, they are
providing functionality or features that increase programmer
productivity ..... you think they are really paying attention to
keeping it as small, compact and efficient as possible?
Allegro's IDE (trial version) takes up about 25mb (i'm not comparing
since they are different languages).
People in c.l.l. ARE putting up patiently with trolls in newbie
guise. Funny that some people are complaining or commenting about Lisp
IDEs available in market without having coded much. I suppose they
haven't yet 'seen the light' in the editor/listener interactiveness.
-- Aravindh
Kenny Tilton <·······@nyc.rr.com> wrote:
+---------------
| Any newbie who shrugs off that discomfiture soon enough looks up
| and realizes, omigod!, I just wrote this wicked stuff without more
| than a few IDE tricks. Meanwhile, they are so orgasmic of the language
| per se that they never consider looking back, and instead toss off
| in half a day their own IDE tools.
+---------------
Indeed. I wrote my first substantial CL app with nothing more than a
web browser and two XTerm windows: one running "vi" and another with
a Lisp REPL in it. Not *once* did I *ever* miss having a fancy "IDE".
Quite the contrary -- I was too busy getting stuff done with Lisp!!
Oh, I admit that some of what I did might fall under Kenny's "half a
day [on] their own IDE tools" rubric, e.g.: setting up "detachtty"
to front-end the app's REPL; setting up the web server config so an
ASDF:LOAD gets done every time any server page was accessed [do a
write in "vi" and hit "Reload" in the browser, and Voila! -- instant
recompilation of whatever's changed and their dependencies]; maybe a
few other tiny conveniences. But nothing major. A half-day sounds
about right, actually.
Might someone using Emacs+SLIME or a commercial IDE been faster?
Maybe, for the very tiny fraction of the total effort that *might*
have been sped up with those tools. But frankly, for me personally,
I probably would have lost more time trying to get some "better" tool
running than I ever would have made up by using it. IMHO. For me.
Give me *any* editor with which I'm already comfortable [that does
basic paren matching & shifting, which "vi" does], a Lisp REPL with
APROPOS & DESCRIBE, and some minimal build tools (ASDF, MK:DEFSYSTEM,
or a "half-day toss-off") and I'm ecstatic.
"We don' need no stinkin' IDE!"
-Rob
p.s. NOTA BENE: This was *NOT* a "favorite editor" flame!! As I have
said here many times before, I wish nothing but the best for those of
you lucky enough to have fingers/minds that can hack Emacs. Mine don't
seem to be able to... not that it matters much. When I'm programming
Lisp, the editor that I'm using simply isn't ever an obstacle, AFAICT.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
+---------------
| ····@rpw3.org (Rob Warnock):
| > Might someone using Emacs+SLIME or a commercial IDE been faster?
|
| How can you work without M-. ?
+---------------
Mostly I just use DESCRIBE in the REPL and depend on good doc strings,
but if it ever became a problem [which it hasn't yet] I'd probably use
either "ctags" or even just "grep".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Juliusz Chroboczek wrote:
> ····@rpw3.org (Rob Warnock):
>
>
>>Might someone using Emacs+SLIME or a commercial IDE been faster?
>
>
> How can you work without M-. ?
AllegroCL's editor has M-., if you select "Emacs mode" as a preference.
Commercial MCL's editor is called Fred. Why I do not know, but it
resembles Emacs so much it must be deliberate.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton <·······@nyc.rr.com> writes:
> Juliusz Chroboczek wrote:
>
>> ····@rpw3.org (Rob Warnock):
>>
>>>Might someone using Emacs+SLIME or a commercial IDE been faster?
>> How can you work without M-. ?
>
> AllegroCL's editor has M-., if you select "Emacs mode" as a preference.
>
> Commercial MCL's editor is called Fred. Why I do not know, but it
> resembles Emacs so much it must be deliberate.
;-)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Kenny Tilton <·······@nyc.rr.com> writes:
> That is why the yobbos end up frothing at the mouth over my
> denigration of their pathetic tool choices : this time the language
> Lisp compensates for their lame IDEs, so they think they have it
> good.
So we actually have it bad? I kind of like Eamcs + SLIME.
Although it did take me forever and a half to get going with Lisp.
But I'm not sure that's the fault of the tools. Ooooo! Shiny!
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
On Thu, 27 Oct 2005 00:17:54 +0200, <········@mail.utexas.edu> wrote:
>
> Kenny Tilton wrote:
>
>> verec wrote:
>>
> <snip>
>> >
>> > As a matter of fact, I do have LispWorks. And OpenMCL.
>> >
>> > - their "IDE" is a joke. Period.
>>
>> Agreed. When you get bored with trolling, try AllegroCL. But that still
>> will not be the match of Java IDEs. Necessity is the mother of
>> invention, and Java necessitates a lot. (hint.)
>
> <snip>
>>
>> --
>> Kenny
>
> Netbeans and Eclipse, for some reason, bring the word BLOATWARE to my
> mind and I cringe every time I have to start one of them. Half my 512mb
> RAM is probably taken up while they load their "modules". [of course
> I'm exaggerating, but not too much :-) ]. I have seldom seen my
> desktop get that sluggish when starting up an IDE. The latest yahoo
> mesenger gives off the same vibe.
> Am I the only one who thinks so? Of course I am only learning Java now.
> Should one be thinking algorithmic size/time complexity be damned since
> memory is "cheap". Or is it that those IDEs provide so much
> functionality with their modules, it is only natural?
>
> I haven't tried LispWorks IDE. Allegro's is fast and neat.
>
>
> -- Aravindh
>
I won't develop or use Java applications for that reason.
It only takes a few bad experiences to put you off.
If it was only during loading it was bad I suppose I could live with it.
But actually only a small (if you can call a 100 Mb small) of the
application that get's loaded at load time.
Soon the matter get's far worse.
After a half day of work you are using half a gigabyte of RAM.
Java get's worse by the fact that SWING leaks memory like a sieve.
(garbage collection does not force you to dislocate memory in
functions further down in the call hierarchy.)
You try to select a option in a combo box and find yourself waiting
10 minutes while your disk goes mad. Soon you realize that when
the going get's tough the Java app. goes out of memory...
I look at Java's memory consumption with a bit of disbelief.
Then I realize that XSLT, XML, XMLRPC, SOAP etc.. are about to
make it a lot worse. It must be a order from the hardware producers..
'We need to find a way to run current software in a way that is 4 times
slower and takes 10 times as much space to justify buying our new
hardware' :) sun....
These day's when I see the 'using Java'.. I choose something else..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> I won't develop or use Java applications for that reason.
> It only takes a few bad experiences to put you off.
> If it was only during loading it was bad I suppose I could live with it.
> But actually only a small (if you can call a 100 Mb small) of the
> application that get's loaded at load time.
> Soon the matter get's far worse.
> After a half day of work you are using half a gigabyte of RAM.
> Java get's worse by the fact that SWING leaks memory like a sieve.
> (garbage collection does not force you to dislocate memory in
> functions further down in the call hierarchy.)
> You try to select a option in a combo box and find yourself waiting
> 10 minutes while your disk goes mad. Soon you realize that when
> the going get's tough the Java app. goes out of memory...
> I look at Java's memory consumption with a bit of disbelief.
> Then I realize that XSLT, XML, XMLRPC, SOAP etc.. are about to
> make it a lot worse. It must be a order from the hardware producers..
> 'We need to find a way to run current software in a way that is 4 times
> slower and takes 10 times as much space to justify buying our new
> hardware' :) sun....
> These day's when I see the 'using Java'.. I choose something else..
>
Phew, I am not the only one wondering what's with Java and it's heavy
weight IDEs.
From what I read, Lisp also apparently faced similar criticism in
early days - too big and too slow. Java, being similar in certain ways,
is probably going through that phase. Pretty soon, the Java camp also
will start focusing on efficiency and keeping things small I suppose.
Or not.
-- Aravindh
On 2005-10-28 12:07:17 -0400, ········@mail.utexas.edu said:
> Pretty soon, the Java camp also
> will start focusing on efficiency and keeping things small I suppose.
> Or not.
Not as long as Sun, a big iron manufacturer, is footing the bill.
They'll want to keep the requirements nice and beefy for a long as
possible. ;^)
········@mail.utexas.edu wrote:
> From what I read, Lisp also apparently faced similar criticism in
> early days - too big and too slow. Java, being similar in certain ways,
> is probably going through that phase. Pretty soon, the Java camp also
> will start focusing on efficiency and keeping things small I suppose.
> Or not.
No, if a Java app is huge, slow, and bloated, that's not something to
worry about and to improve; it's professional, as in "Real software
engineers use Java and Design Patterns."
Building something like Eclipse in Lisp, by contrast, would be
inacceptable, and a clear sign of the incompetence and slowness of Lisp.
--
The road to hell is paved with good intentions.
Am 23.10.2005 5:18 Uhr schrieb "verec" unter <·····@mac.com> in
·························@news.aaisp.net.uk:
> As a matter of fact, I do have LispWorks. And OpenMCL.
>
> - their "IDE" is a joke. Period.
Why don't you like the LispWorks IDE? I think
it is quite acceptable. Maybe you can name
some of the problems? If you have some
valid points, it would be good to know them. Since
they (LispWorks LLC.) are working on a new release to be
published next year, they might be interested in some good
suggestions for improving their product.
I've tried in the past to list some areas where Lisp
can be improved for Mac OS X (
http://lispm.dyndns.org/news?ID=NEWS-2005-04-30-2 ).
Don't know if any vendor has read that, but I wish
they would have. ;-)
It would be better if we can get away from 'is a joke'
to more substantial ideas what should be improved
in what way and let vendors know about it. They are
also often interest in good ideas, especially when it generates
some real sales...
> - the CL that is within is certainly as close to CLTL2
> as any other, but that misses the entire point.
>
> The point is not about *implementation* X, Y or Z of CL,
> but about *the spec* that DOES NOT allow me TODAY to
> write portable+GUI+threaded code in CL. This, Java gives
> it to me now. CL doesn't.
On 2005-10-23 08:33:23 +0100, Rainer Joswig <······@lisp.de> said:
> Why don't you like the LispWorks IDE? I think
> it is quite acceptable.
The idea of outputing answers of your evaluation rightly where
you just wrote four definition is simply bogus.
PowerLisp (Roger Corman) did it right not so long ago: output
is directed to _another_ window wich contains the whole transcript
of the REPL session *without cluttering* the file/listener you
are typing from.
Also, eons ego, MPW "enter" key was a real blessing.
And not being able to recall whatever last expression you just
typed (using up and down arrows as even tcsh has learnt to provide)
is s bit lame.
But that's just the editor! Where's the right-click that allows me
to
- refactor (rename/move/extract body/convert to macro/
inline/outline/move to super type/etc...)
- explore (type hierarchy/caller tree/callee tree/find references/
find definition)
- source (import "require", import symbols from selected package,...)
> Maybe you can name
> some of the problems? If you have some
> valid points, it would be good to know them. Since
> they (LispWorks LLC.) are working on a new release to be
> published next year, they might be interested in some good
> suggestions for improving their product.
Simple! Provide me with a Lisp that fully integrate within Eclipse!
And that's no joke! Eclipse is "language agnostic" even though
they started by supporting Java, and later C++.
Anyone can write a set of plugins (yes, plugin: binary form, not
source form) for whatever language they chose.
Integrating well a REPL like language (Lisp, Forth) is certainly
a (small) challenge, but would expand Lisp awareness beyond the
confines of usenet ...
> I've tried in the past to list some areas where Lisp
> can be improved for Mac OS X (
> http://lispm.dyndns.org/news?ID=NEWS-2005-04-30-2 ).
> Don't know if any vendor has read that, but I wish
> they would have. ;-)
I read the IDE bits. Some of them are nowhere to be found
anywhere, even in Eclipse, so I guess that whoever would
actually tackles that problem would make quite a splash.
Best Regards
--
JFB (Still marveling at the innards of OpenMCL :-)
On Sun, 23 Oct 2005 13:40:26 +0100, verec <·····@mac.com> wrote:
> The idea of outputing answers of your evaluation rightly where you
> just wrote four definition is simply bogus.
Huh?
> And not being able to recall whatever last expression you just typed
> (using up and down arrows as even tcsh has learnt to provide) is s
> bit lame.
I'm beginning to believe that you haven't tried anything at all and
are really just trolling. Of course there's a history in the REPL.
> But that's just the editor! Where's the right-click that allows me
> to
> - refactor (rename/move/extract body/convert to macro/
> inline/outline/move to super type/etc...)
Most of this isn't there. I'm not sure what of these features would
really make sense for Lisp, though.
> - explore (type hierarchy/caller tree/callee tree/find references/
> find definition)
It's all there. See above - you didn't bother to check but preferred
to troll right away.
> Simple! Provide me with a Lisp that fully integrate within Eclipse!
> And that's no joke! Eclipse is "language agnostic" even though they
> started by supporting Java, and later C++.
>
> Anyone can write a set of plugins (yes, plugin: binary form, not
> source form) for whatever language they chose.
From what I've seen Eclipse is heavily biased towards static
languages.
Bye,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·························@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> On 2005-10-23 08:33:23 +0100, Rainer Joswig <······@lisp.de> said:
>
> > Why don't you like the LispWorks IDE? I think
> > it is quite acceptable.
>
You really need to look closer. The deep stuff needs
some manual reading. But you really did miss
most of the basic stuff that is right
upfront.
> The idea of outputing answers of your evaluation rightly where
> you just wrote four definition is simply bogus.
>
> PowerLisp (Roger Corman) did it right not so long ago: output
> is directed to _another_ window wich contains the whole transcript
> of the REPL session *without cluttering* the file/listener you
> are typing from.
I agree that this can be useful. But I've never used Lisp
that way. I either evaluate/compiler my code from
the editor (do "c-h a eval" or "c-h a compile" for
a command overview) or I use the listener (like
the one in LispWorks).
What you are missing are the commands in the
LispWorks listener. See below.
> Also, eons ego, MPW "enter" key was a real blessing.
I have set something like that in my LispWorks.
> And not being able to recall whatever last expression you just
> typed (using up and down arrows as even tcsh has learnt to provide)
> is s bit lame.
meta-p gives you the previous expression. meta-n gives you
the next expression.
See "c-h a history" for some commands manipulating
the history. Also not that there is a history
menu in the menubar and history navigation in the
listener window by using the left, down and right
buttons in the button row.
> But that's just the editor! Where's the right-click that allows me
> to
> - refactor (rename/move/extract body/convert to macro/
> inline/outline/move to super type/etc...)
There is nothing like that in LispWorks.
> - explore (type hierarchy/caller tree/callee tree/find references/
> find definition)
This is on the right-click menu. Example: say
you have a function name, click-right on it and
select >Expression>Function Calls.
> - source (import "require", import symbols from selected package,...)
>
> > Maybe you can name
> > some of the problems? If you have some
> > valid points, it would be good to know them. Since
> > they (LispWorks LLC.) are working on a new release to be
> > published next year, they might be interested in some good
> > suggestions for improving their product.
>
> Simple! Provide me with a Lisp that fully integrate within Eclipse!
> And that's no joke! Eclipse is "language agnostic" even though
> they started by supporting Java, and later C++.
>
> Anyone can write a set of plugins (yes, plugin: binary form, not
> source form) for whatever language they chose.
> Integrating well a REPL like language (Lisp, Forth) is certainly
> a (small) challenge, but would expand Lisp awareness beyond the
> confines of usenet ...
>
> > I've tried in the past to list some areas where Lisp
> > can be improved for Mac OS X (
> > http://lispm.dyndns.org/news?ID=NEWS-2005-04-30-2 ).
> > Don't know if any vendor has read that, but I wish
> > they would have. ;-)
>
> I read the IDE bits. Some of them are nowhere to be found
> anywhere, even in Eclipse, so I guess that whoever would
> actually tackles that problem would make quite a splash.
>
> Best Regards
> --
> JFB (Still marveling at the innards of OpenMCL :-)
verec wrote:
> Provide me with a Lisp that fully integrate within Eclipse!
> And that's no joke! Eclipse is "language agnostic" even though
> they started by supporting Java, and later C++.
>
> Anyone can write a set of plugins (yes, plugin: binary form, not
> source form) for whatever language they chose.
> Integrating well a REPL like language (Lisp, Forth) is certainly
> a (small) challenge, but would expand Lisp awareness beyond the
> confines of usenet ...
Any development environment requires people to invest some time in
learning it before they can actually use it. You had to learn Eclipse as
well - Eclipse is definitely not straightforward to use! (Nice quote
from James Noble: "Eclipse, the 'guess-the-button' environment." ;)
Don't base your comparison of Lisp IDEs on expectations you have gained
over a long period of time using other IDEs. Rather expect the need to
invest an equal amount of time before you have the same degree of knowledge.
The fact that there is no Common Lisp plugin for Eclipse can be
interpreted as a lack of need for such a thing in the Common Lisp
community. Furthermore, writing plugins for Eclipse is a rather complex
undertaking. If you disagree in that respect, why don't you write that
plugin yourself?
Having said that, there is an Eclipse plugin for Scheme - see
http://schemeway.sourceforge.net/ Maybe this can serve as that starting
point for some Common Lisp support...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
verec wrote:
> The point is not about *implementation* X, Y or Z of CL,
> but about *the spec* that DOES NOT allow me TODAY to
> write portable+GUI+threaded code in CL. This, Java gives
> it to me now. CL doesn't.
Neither the Java language specification nor the JVM specification say
anything about GUIs either.
It doesn't seem to me that Java's multithreading model is a particularly
good one. Something based on the notion of Actors would be nicer, I
think. (I don't know what Common Lisp implementations provide in that
regard.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Sun, 23 Oct 2005 14:54:16 +0200, Pascal Costanza wrote:
> (I don't know what Common Lisp implementations provide [w/respect to
> advanced threading models] in that regard.)
Not much as far as I can tell. I've posted before about code I've written
using a home-brewed thread trampoline. Using "real" threads for
pervasively multi-threaded code is usually frustrating, as most OS-level
thread implementations don't deal well with spawning thousands of threads.
As long as we're trolling for features that aren't likely to get
implemented: how 'bout a portable thread runtime that can
automatically load balance between logical and actual (multiprocessor)
parallelism a la cilk (http://supertech.lcs.mit.edu/cilk/).
I've actually implemented a version of fork in sbcl that matches the
spawn/sync semantics in cilk, but it gets bogged down for the usual
reasons (see above).
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
verec <·····@mac.com> writes:
> On 2005-10-22 23:47:15 +0100, Wade Humeniuk
> <··················@telus.net> said:
>
>> WHY are you whining? Get a spine and try a real CL like
>> Lispworks.
>
> As a matter of fact, I do have LispWorks. And OpenMCL.
>
> - their "IDE" is a joke. Period.
> - the CL that is within is certainly as close to CLTL2
> as any other, but that misses the entire point.
>
> The point is not about *implementation* X, Y or Z of CL,
> but about *the spec* that DOES NOT allow me TODAY to
> write portable+GUI+threaded code in CL. This, Java gives
> it to me now. CL doesn't.
Great, use ABCL. It's common lisp on top of the jvm. Sounds like it
will be perfect for you.
-russ
verec wrote:
> On 2005-10-22 23:47:15 +0100, Wade Humeniuk
> <··················@telus.net> said:
>
>> WHY are you whining? Get a spine and try a real CL like
>> Lispworks.
>
>
> As a matter of fact, I do have LispWorks. And OpenMCL.
>
> - their "IDE" is a joke. Period.
> - the CL that is within is certainly as close to CLTL2
> as any other, but that misses the entire point.
>
> The point is not about *implementation* X, Y or Z of CL,
> but about *the spec* that DOES NOT allow me TODAY to
> write portable+GUI+threaded code in CL. This, Java gives
> it to me now. CL doesn't.
>
> Is it possible to have an adult conversation, and not start
> flames just because you cannot correctly parse a sentence?
So you spread misinformation because you are too lazy to
spend some time learning something like LW? No wonder
your co-workers during the day do not trust you. Get over
yourself, you are not the center of the universe.
Wade
On Sun, 23 Oct 2005 04:18:03 +0100, verec wrote:
> On 2005-10-22 23:47:15 +0100, Wade Humeniuk
> <··················@telus.net> said:
>
>> WHY are you whining? Get a spine and try a real CL like Lispworks.
>
> As a matter of fact, I do have LispWorks. And OpenMCL.
>
> - their "IDE" is a joke. Period.
> - the CL that is within is certainly as close to CLTL2
> as any other, but that misses the entire point.
>
> The point is not about *implementation* X, Y or Z of CL, but about *the
> spec* that DOES NOT allow me TODAY to write portable+GUI+threaded code
> in CL. This, Java gives it to me now. CL doesn't.
To the best of my knowledge Sun's Java Runtime Environment is the only
complete Swing implementation available. You are likely to have
portability problems moving to any Java implementation that doesn't
license Sun's JRE. The present situation is similar to being tied to a
single implementation of Common Lisp. GNU Classpath developers are still
working upon implementing all the standard Java class libraries, and will
be for years to come.
SWT is portable across multiple JVM implementations but incomplete, and
it's not possible to run an untrusted SWT application over the web. With
respect to being incomplete, Eclipse can't bring up a GTK print dialogue
on Linux: <http://www.eclipse.org/swt/faq.php#printOnGTK>
Printing on GTK has not been implemented yet. You can use the External
Tools support in Eclipse to print files using lpr or some other
printing utility.
You could consider integrating Java and Common Lisp. Try out ABCL:
<http://armedbear.org/abcl.html>. Note: Since ABCL generates JVM bytecode
via a custom classloader you will not be able to run an untrusted/unsigned
ABCL application over the web.
Regards,
Adam
On 2005-10-23 06:53:58 +0100, Adam Warner <······@consulting.net.nz> said:
>> The point is not about *implementation* X, Y or Z of CL, but about *the
>> spec* that DOES NOT allow me TODAY to write portable+GUI+threaded code
>> in CL. This, Java gives it to me now. CL doesn't.
>
> To the best of my knowledge Sun's Java Runtime Environment is the only
> complete Swing implementation available. You are likely to have
> portability problems moving to any Java implementation that doesn't
> license Sun's JRE.
That's entirely true. But the targets I'm interested in all have
Sun's JRE available.
> You could consider integrating Java and Common Lisp. Try out ABCL:
> <http://armedbear.org/abcl.html>. Note: Since ABCL generates JVM bytecode
> via a custom classloader you will not be able to run an untrusted/unsigned
> ABCL application over the web.
I hadn't thought of this.
Many thanks for the suggestion.
--
JFB (Still marveling at the innards of OpenMCL :-)
"Adam Warner" <······@consulting.net.nz> wrote in message
··································@consulting.net.nz...
> You could consider integrating Java and Common Lisp. Try out ABCL:
> <http://armedbear.org/abcl.html>. Note: Since ABCL generates JVM bytecode
> via a custom classloader you will not be able to run an untrusted/unsigned
> ABCL application over the web.
>
This is a very interesting idea, not just the GUI, but having
access to both Common Lisp and Java public library code.
Only last night, I installed and started testing ABCL.
It is safe to say that it is slow (the docs indicate that CLOS is
nearly unusuably slow), but it is not unusable for many things.
A trivial (recursive) Fibonnaci (fib 32) tooks 50+ seconds
while the same code in CLisp took 24 seconds, and similar
code (near as practical) in PTLScheme took near 0
seconds (as close as 'time' measured.)
ABCL compiled OnLisp book code immediately (although I have
done no significant testing to determine compliance.)
It is an early product (0.0.9) but probably better than that
"version number" estimates.
The interesting step will be to see how easy it is to integrate
Java and Lisp, especially to take advantage of the Java GUI
and other library support....
[Caveat: I am no Lisp expert, but I hope to be when I grow
up, even though my experiences with Lisp likely predate 95%
of those who post here. Really.]
--
Herb Martin
Herb Martin wrote:
> "Adam Warner" <······@consulting.net.nz> wrote in message
> ··································@consulting.net.nz...
>
>>You could consider integrating Java and Common Lisp. Try out ABCL:
>><http://armedbear.org/abcl.html>. Note: Since ABCL generates JVM bytecode
>>via a custom classloader you will not be able to run an untrusted/unsigned
>>ABCL application over the web.
>>
>
>
> This is a very interesting idea, not just the GUI, but having
> access to both Common Lisp and Java public library code.
>
There is also FOIL (http://foil.sourceforge.net/) which allows access to
Java and .Net objects from a standard lisp process. The existance of
this project is one of the reason i always laugh at the "Lisp has not
libraries" threads. Not only can we access all the C libraries with FFI,
but with foil we can access all the .net and java libs as well.
--
Drew Crampsie
drewc at tech dot coop
"... the most advanced use of lisp in the field of bass lure sales"
-- Xach on #lisp
"Herb Martin" <····@LearnQuick.com> writes:
> "Adam Warner" <······@consulting.net.nz> wrote in message
> ··································@consulting.net.nz...
> > You could consider integrating Java and Common Lisp. Try out ABCL:
> > <http://armedbear.org/abcl.html>. Note: Since ABCL generates JVM bytecode
> > via a custom classloader you will not be able to run an untrusted/unsigned
> > ABCL application over the web.
> >
>
> This is a very interesting idea, not just the GUI, but having
> access to both Common Lisp and Java public library code.
>
> Only last night, I installed and started testing ABCL.
>
> It is safe to say that it is slow (the docs indicate that CLOS is
> nearly unusuably slow), but it is not unusable for many things.
>
> A trivial (recursive) Fibonnaci (fib 32) tooks 50+ seconds
> while the same code in CLisp took 24 seconds, and similar
> code (near as practical) in PTLScheme took near 0
> seconds (as close as 'time' measured.)
Did you compile your Fibonnaci function? ABCL is not particularly
fast, but it's not *this* slow even on my ancient hardware. (And
neither is CLISP.)
>
> ABCL compiled OnLisp book code immediately (although I have
> done no significant testing to determine compliance.)
>
> It is an early product (0.0.9) but probably better than that
> "version number" estimates.
I think so, too.
> The interesting step will be to see how easy it is to integrate
> Java and Lisp, especially to take advantage of the Java GUI
> and other library support....
http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar may help.
Andras
>
> [Caveat: I am no Lisp expert, but I hope to be when I grow
> up, even though my experiences with Lisp likely predate 95%
> of those who post here. Really.]
>
>
> --
> Herb Martin
From: Michael Stewart
Subject: Re: Still clinking to Java? --- more about ABCL
Date:
Message-ID: <m2ll0j3s7h.fsf@saaz.cs.gsu.edu>
Andras Simon <······@math.bme.hu> writes:
> "Herb Martin" <····@LearnQuick.com> writes:
>
> > A trivial (recursive) Fibonnaci (fib 32) tooks 50+ seconds
> > while the same code in CLisp took 24 seconds, and similar
> > code (near as practical) in PTLScheme took near 0
> > seconds (as close as 'time' measured.)
>
> Did you compile your Fibonnaci function? ABCL is not particularly
> fast, but it's not *this* slow even on my ancient hardware. (And
> neither is CLISP.)
I'm something of a Lisp newbie and a complete newbie to this group, so
I'll offer my apologies in advance in case I mess something up.
However on CMUCL on my PC these do not seem like reasonable times even
for an interpreted function. They are comparable to what I get with
an interpreted version of the following exponential-time-in-n function
(defun fib-slow (n)
(cond ((= n 0) 1)
((= n 1) 1)
(t
(+ (fib-slow (- n 1)) (fib-slow (- n 2))))))
Compiled, (fib-slow 32) runs in .75 seconds on my PC. Interpreted,
it runs in 49 seconds.
Returning two Fibonnaci sequence values gets rid of one of the
recursive calls
(defun fib (n)
(cond
((= n 1) (values 1 1))
((= n 0) (values 1 0))
(t
(multiple-value-bind (a b) (fib (- n 1))
(values (+ a b) a)))))
Even as an interpreted function (fib 1000) runs in .01 seconds.
---
Michael Stewart
····@mastewart.org
From: Robert Uhl
Subject: Re: Still clinking to Java? --- more about ABCL
Date:
Message-ID: <m3slup5j8f.fsf@4dv.net>
"Herb Martin" <····@LearnQuick.com> writes:
>
> A trivial (recursive) Fibonnaci (fib 32) tooks 50+ seconds while the
> same code in CLisp took 24 seconds, and similar code (near as
> practical) in PTLScheme took near 0 seconds (as close as 'time'
> measured.)
*boggle*
How fast is your machine? SBCL and a highly inefficient FIB took .319
seconds; clisp uncompiled took 13.72 seconds, but compiled took but 2.13
seconds.
Maybe Armed Bear interprets by default? Did you try COMPILE?
--
Robert Uhl <http://public.xdi.org/=ruhl>
Here I am, brain the size of a planet, and they ask me `Can I add this
machine to the DNS?' It gives me a headache just trying to think down to
their level. --Gary Barnes
On 2005-10-25 18:23:28 -0400, Robert Uhl <·········@NOSPAMgmail.com> said:
> "Herb Martin" <····@LearnQuick.com> writes:
>>
>> A trivial (recursive) Fibonnaci (fib 32) tooks 50+ seconds while the
>> same code in CLisp took 24 seconds, and similar code (near as
>> practical) in PTLScheme took near 0 seconds (as close as 'time'
>> measured.)
>
> *boggle*
>
> How fast is your machine? SBCL and a highly inefficient FIB took .319
> seconds; clisp uncompiled took 13.72 seconds, but compiled took but 2.13
> seconds.
>
> Maybe Armed Bear interprets by default? Did you try COMPILE?
Not Herb Martin here, but the following form:
(progn (compile (defun fib-slow (n)
(cond ((= n 0) 1)
((= n 1) 1)
(t (+ (fib-slow (- n 1)) (fib-slow (- n 2)))))))
(time (fib-slow 35)))
results in the following:
sbcl:
Evaluation took:
2.067 seconds of real time
2.038339 seconds of user run time
0.005878 seconds of system run time
0 page faults and
24 bytes consed.
14930352
openmcl:
(FIB-SLOW 35) took 1,625 milliseconds (1.625 seconds) to run.
Of that, 1,612 milliseconds (1.612 seconds) were spent in user mode
6 milliseconds (0.006 seconds) were spent in system mode
7 milliseconds (0.007 seconds) were spent executing other OS
processes.
14930352
lispworks:
Timing the evaluation of (FIB-SLOW 35)
user time = 0.645
system time = 0.001
Elapsed time = 0:00:00
Allocation = 6884 bytes
0 Page faults
14930352
abcl:
15.61 seconds real time
29860703 cons cells
14930352
So Armed Bear really is an order of magnitude slower than other common
lisp implementations on this one.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> Not Herb Martin here, but the following form:
>
> (progn (compile (defun fib-slow (n)
> (cond ((= n 0) 1)
> ((= n 1) 1)
> (t (+ (fib-slow (- n 1)) (fib-slow (- n 2)))))))
> (time (fib-slow 35)))
>
> results in the following:
>
> sbcl:
> Evaluation took:
> 2.067 seconds of real time
> 2.038339 seconds of user run time
> 0.005878 seconds of system run time
> 0 page faults and
> 24 bytes consed.
> 14930352
>
> openmcl:
> (FIB-SLOW 35) took 1,625 milliseconds (1.625 seconds) to run.
> Of that, 1,612 milliseconds (1.612 seconds) were spent in user mode
> 6 milliseconds (0.006 seconds) were spent in system mode
> 7 milliseconds (0.007 seconds) were spent executing other OS
> processes.
> 14930352
>
> lispworks:
> Timing the evaluation of (FIB-SLOW 35)
>
> user time = 0.645
> system time = 0.001
> Elapsed time = 0:00:00
> Allocation = 6884 bytes
> 0 Page faults
> 14930352
>
> abcl:
> 15.61 seconds real time
> 29860703 cons cells
> 14930352
>
> So Armed Bear really is an order of magnitude slower than other common
> lisp implementations on this one.
Yes, if you don't consider CLisp a Common Lisp implementation. The
results are 4.498/32.118767/43.405/51.201 seconds for
SBCL/CLisp/Java (using BigInteger)/ABCL on my 733MHz PIII.
What I find interesting here is that ABCL is not much slower than
Java, and that moving from my old HW to yours results in a much bigger
speedup for ABCL than for SBCL. (There's also the x86 -> PPC jump, so
this may not mean much.)
Andras
On 2005-10-26 07:13:04 -0400, Andras Simon <······@math.bme.hu> said:
>>
>> So Armed Bear really is an order of magnitude slower than other common
>> lisp implementations on this one.
>
> Yes, if you don't consider CLisp a Common Lisp implementation.
Read it again: "slower than other common lisp implementations," not
"slower than *all* other common lisp implementations."
> The
> results are 4.498/32.118767/43.405/51.201 seconds for
> SBCL/CLisp/Java (using BigInteger)/ABCL on my 733MHz PIII.
> What I find interesting here is that ABCL is not much slower than
> Java, and that moving from my old HW to yours results in a much bigger
> speedup for ABCL than for SBCL. (There's also the x86 -> PPC jump, so
> this may not mean much.)
>
This may be to do with Java - you're using HotSpot if you're on Mac OS
X so this may just be due to ABCL running on a faster Java.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2005-10-26 07:13:04 -0400, Andras Simon <······@math.bme.hu> said:
>
> >> So Armed Bear really is an order of magnitude slower than other
> >> common
> >> lisp implementations on this one.
> > Yes, if you don't consider CLisp a Common Lisp implementation.
>
> Read it again: "slower than other common lisp implementations," not
> "slower than *all* other common lisp implementations."
I'm not a native speaker, so I may be wrong, but I sense an implicit
universal quantifier here. Cf. "other things being equal" == "all
other things being equal", "others did it better" == "all the others
did it better", "these people are crazy" == "all these people are
crazy", etc.
> > The
> > results are 4.498/32.118767/43.405/51.201 seconds for
> > SBCL/CLisp/Java (using BigInteger)/ABCL on my 733MHz PIII.
> > What I find interesting here is that ABCL is not much slower than
> > Java, and that moving from my old HW to yours results in a much bigger
> > speedup for ABCL than for SBCL. (There's also the x86 -> PPC jump, so
> > this may not mean much.)
> >
> This may be to do with Java - you're using HotSpot if you're on Mac OS
> X so this may just be due to ABCL running on a faster Java.
I think you're using HotSpot *everywhere*, unless you work hard not
to. Besides, I don't really care if ABCL gets faster because of Peter
Graves' or Sun's effort.
Andras
On 2005-10-26 11:26:56 -0400, Andras Simon <······@math.bme.hu> said:
> I'm not a native speaker, so I may be wrong, but I sense an implicit
> universal quantifier here.
I am a native speaker, so here goes:
"I'm taller than other people," or "I'm a good six inches taller than
other people," are not claims that I am the tallest person on the
planet. They're just claims that I'm taller than most other people.
In English, claims of universality will include an explicit quantifier
indicating such - for example, "all" or "any" ("in the world") or
"every":
"That model is faster than all other cars," or "He is older than
any/every other living person," etc.
In other words, in colloquial English, a generic comparative without
qualification ("baz-er than other foos") means "most foos"or "many
foos" but not "all foos."
So I think your response was mostly a result of your misunderstanding
me as having made some universal claim about abcl relative to all other
common lisp implementations. I was simply pointing out that abcl, even
compiled, is indeed about an order of magnitude slower than common lisp
can be and usually is for this particular function - a naive doubly
recursive fibonacci.
In any event, in the past I have posted a review of available common
lisp implementations for Mac OS X which served as the starting point
for a wiki page on the topic
<http://lisp.tech.coop/Which%20Common%20Lisp%20for%20Macintosh> so,
yes, I am aware that there exist other common lisp implementations
besides abcl, openmcl, sbcl, and lispworks for Mac OS X - in addition
to clisp there are also allegro, cmucl, and MCL (the commercial carbon
based ide and compiler) that I have used. I just didn't happen to have
these running at the time when I posted.
regards
verec wrote:
> Or why haven't I entirely switched to Lisp yet?
>From where I sit, you have two options.
1) You can post your desires here. Presumably, during our next
International Usenet Lisp meeting, someone will bring up the agenda
point that Verec explained to us that he won't switch to Lisp from Java
until we meet his bullet points for a crossplatform GUI system.
This will likely cause an immediate stir and impassioned debate, deals
and new enemies will be made, and your proposal may squeak through by
just a couple votes.
The only problem with this scenario is there is no Usenet Lisp cabal.
Or so we like to say.
http://openmap.bbn.com/hypermail/clim/0226.html
2) Figure out what you want to do and do it. Maybe you believe people
are misled about the ease of adopting Common Lisp. In that case, you
could usefully make a l'il wiki page honestly describing the potholes
you drove over, in your three weeks of installing implementations. This
is ephemeral info so it should probably be on a Lisp wiki. It would
serve to help others not hit the same bumps you did.
I mean, there are reasons why CL is in this state. There is little
government funding. This means you rely on things like markets and gift
economies.
Tayssir
Disclaimer: This sad attempt at levity is what I do when I'm bored
waiting for a build to complete, and don't feel like going out. No
insult is intended. Etc.
On Sat, 22 Oct 2005 22:30:52 +0100, verec <·····@mac.com> wrote:
>Or why haven't I entirely switched to Lisp yet?
>
>Let's look at the "symetric difference"
>
>Lisp
>full lexical closure
>unequalled macro support
>unequalled MOP
>
Java is good not because of this what is possible to do in Java.
Java is good, because some things are not possible to do in Java.
You listed these things above.
A.L.
A.L. wrote:
> On Sat, 22 Oct 2005 22:30:52 +0100, verec <·····@mac.com> wrote:
>
>
>>Or why haven't I entirely switched to Lisp yet?
>>
>>Let's look at the "symetric difference"
>>
>>Lisp
>>full lexical closure
>>unequalled macro support
>>unequalled MOP
>
> Java is good not because of this what is possible to do in Java.
> Java is good, because some things are not possible to do in Java.
Java has anonymous inner classes that close over final variables of the
lexical environment. This is similar to lexical closures, except that
full lexical closures can close over any binding of the lexical
environment. Anonymous inner classes that close over non-final variables
would be straightforward to implement - in fact, Sun already had a full
implementation before making the restriction. The restriction was only
made because in some cases, variables had to be allocated on the heap
that were previously guaranteed to be allocated on the stack, so the
full version was deemed "inefficient". On the other hand, the
restriction now makes programmers run agains walls for no apparent
reason. It escapes me what is "good" about this.
Java has annotations and provides ways to transform source code based on
those annotations. Annotations can only be associated with classes,
fields and methods, not with arbitrary statements. This is a restriction
that results from the way the Java class file format is specified,
otherwise annotations would provide a similar kind of extensibility that
macros provide (at least from a user's point of view). It's harder to
implement program transformations than to implement macros, and it's
harder to create language extensions that really work (tm). Instead,
Java programmer have to fight against half-baked solutions. (At least
they don't have to use program transformation tools anymore that depend
on correctly formatted, but otherwise unchecked comments.) It escapes me
what is "good" about this.
Java has an introspection facility and provides dynamic proxies for
interceding method calls and providing your own dispatch mechanisms. In
order to be able to use dynamic proxies, you have to use interfaces, you
have to know which interfaces you have to implement, you have derive the
dynamic proxy classes from the correct superclasses, and you have to
know some coding tricks in order dispatch methods in a way so that you
don't get excessive execution overhead. A "real" MOP, similar to a CLOS
MOP, would allow you to better localize new behavior and better use the
default dispatch mechanisms provided by the base language to get decent
performance. It escapes me what is "good" about the very naive proxy
mechanism in Java.
My impression is that people who claim that certain features are not
available in Java have never implemented any considerably sized Java
program, otherwise they would know that everything _does_ exist in Java,
only typically in restricted and/or braindead variants, so that the
impression can be held up that it is still the simple language that it
used to be in the beginning. However, the end result Java has arrived at
with version 5.0 is a language that is much more complex to use than if
it had been designed with those features in mind from the very
beginning. All that Java proves is that such features are ultimately
necessary, otherwise they wouldn't bother adding them.
Here is a rationale why languages should be extensible:
http://homepages.inf.ed.ac.uk/wadler/steele-oopsla98.pdf
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Thanks to all of you who provided me with answers or
corrected my misconceptions.
To the others: have a nice day.
--
JFB (Still marveling at the innards of OpenMCL :-)