This correspondent's chin hit the floor when he realized this speaker
was from Microsoft:
http://pdcbloggers.net/Question_and_Answer/PNL02/Patrick_Dussud.category
Mr. Dussud was favored with one of the closing plenary sessions of the
conference, and used it to suggest Common Lisp cripple itself in various
ways (help me, someone: static typing is all I remember) so it could
have the honor of running on Microsoft's CLR. Well, OK, the motivation
would be in the title of the paper "Re-inventing Lisp for Ubiquity".
Funny, I thought that word meant omnipresence, not Win32. Anyway, Mr.
Dussud indicated we had to do something or die, because other languages
were catching up with Lisp. When challenged on that, he indicated that
different languages were copying different features, not that any one
language was catching up with Lisp. That amounts to a retraction, yes?
JonL White went for the jugular and pleasantly asked how CL could
(paraphrasing) trigger Microsoft's anti-competitive mean streak and get
it to develop CL# the way they attacked Java with C#.
JonL is lucky looks cannot kill, as is your correspondent, who asked if,
given Lisp's growing popularity, Dussud also felt it was time for
mainland China to surrender to Taiwan.
This led one of the faithful to turn on me and say he was not aware of
any increase in Lisp's popularity, something I heard time and again at
ILC2005. I replied that he does not read comp.lang.lisp, of which I was
confident because no one else who had challenged me on that turned out
to be a c.l.l reader.
Afterwards I spoke to Mr Dussud and shook his hand, congratulating him
on his bravery. Strong guy. I was lucky to get all my fingers back. :)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Greg Menke
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <m3aclfgnh7.fsf@athena.pienet>
Kenny Tilton <·······@nyc.rr.com> writes:
> This correspondent's chin hit the floor when he realized this speaker
> was from Microsoft:
> http://pdcbloggers.net/Question_and_Answer/PNL02/Patrick_Dussud.category
>
> Mr. Dussud was favored with one of the closing plenary sessions of the
> conference, and used it to suggest Common Lisp cripple itself in various
> ways (help me, someone: static typing is all I remember) so it could
> have the honor of running on Microsoft's CLR. Well, OK, the motivation
> would be in the title of the paper "Re-inventing Lisp for Ubiquity".
Its the inevitable refrain from people not actually trying to do
something with Lisp, but flogging some abstract agenda which they think
relates. There must be a corollary to Greenspun that addresses the
consequences of trying to force high level languages into a C/C++
runtime. Either you shoot off your feet or you trip over your
shoelaces- either way your nose ends up in the dog poop on the sidewalk
in front of you.
Gregm
From: alex goldman
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <1816763.JWAt3uPIHs@yahoo.com>
Greg Menke wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> This correspondent's chin hit the floor when he realized this speaker
>> was from Microsoft:
>>
http://pdcbloggers.net/Question_and_Answer/PNL02/Patrick_Dussud.category
>>
>> Mr. Dussud was favored with one of the closing plenary sessions of the
>> conference, and used it to suggest Common Lisp cripple itself in various
>> ways (help me, someone: static typing is all I remember) so it could
>> have the honor of running on Microsoft's CLR. Well, OK, the motivation
>> would be in the title of the paper "Re-inventing Lisp for Ubiquity".
>
> Its the inevitable refrain from people not actually trying to do
> something with Lisp, but flogging some abstract agenda which they think
> relates. There must be a corollary to Greenspun that addresses the
> consequences of trying to force high level languages into a C/C++
> runtime. Either you shoot off your feet or you trip over your
> shoelaces- either way your nose ends up in the dog poop on the sidewalk
> in front of you.
I'll probably get flamed for this, but when I looked at the list of talks on
ILC2005's web site, it made me glad I wasn't there. At least half of what I
saw was either crapware, or peddleware, or reware. Reware is something
that's already been built a dozen times, but presented as brand new and
innovative. Lisp copiled to .NET? There are a dozen of those that compile
to JVM and/or .NET. Strictly typed Lisp?! - ML. Strictly typed Lisp
compiled to .NET? - SML.NET (sp?) and F#.
(I'm sure I've just offended a bunch of people, but hey, there's a 50%
chance they've already been offended by my earlier comments about their
fathood anyway)
Alex Goldman wrote:
> (I'm sure I've just offended a bunch of people,
> but hey, there's a 50% chance they've already been
> offended by my earlier comments about their fathood
> anyway)
I'm not offended. You'll have to try harder.
My interests are fairly academic and language-oriented,
and I attended less than half of the presentations, but
here were some of the speakers and talks I thought were
especially worthwhile:
John Allen. History, Mystery, and Ballast.
Jerry Boetje. Unicode 4.0 in Common Lisp.
Paul Dietz. The GNU ANSI Common Lisp Test Suite.
Bert Halstead. Curl: A Content Language for the Web.
James McDonald. Correctness-by-Construction is in your future.
J Strother Moore. A Mechanized Program Verifier.
Per Bothner. Mixing Lisps in Kawa.
Patrick Dussud. Re-inventing Lisp for Ubiquity.
Henry Baker. The Legacy Of Lisp.
Moore's presentation was outstanding. Baker didn't
have time to present more than a fraction of the ideas
on his slides, which I look forward to studying. It
was nice to hear John McCarthy, but the questions and
answers were the most interesting part of that session.
Will
From: alex goldman
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <1805321.JMP702J6Rl@yahoo.com>
William D Clinger wrote:
> I'm not offended. You'll have to try harder.
Hey, cowboy, where's your horse?
Well, this is the best I can do under the circumstances.
alex goldman wrote:
> > I'm not offended. You'll have to try harder.
>
> Hey, cowboy, where's your horse?
I couldn't bring him. The airlines have gotten too
picky about the size of carry-on baggage.
Here's a picture of my son I took while riding:
http://www.ccs.neu.edu/home/will/Personal/jed-horse.jpeg
Will
From: Christopher C. Stacy
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <uekaroy0v.fsf@news.dtpq.com>
If someone is looking for some ideas to steal or
be inspired by, something that might be relevent
to a large community, you might want to look at
what "Groove" is doing. I don't know anything
about it; this is just a suggestion for someone
to check it out and see what's going on there.
alex goldman wrote:
> I'll probably get flamed for this, but when I looked at the list of talks on
> ILC2005's web site, it made me glad I wasn't there. At least half of what I
> saw was either crapware, or peddleware, or reware. Reware is something
> that's already been built a dozen times, but presented as brand new and
> innovative. Lisp copiled to .NET? There are a dozen of those that compile
> to JVM and/or .NET. Strictly typed Lisp?! - ML. Strictly typed Lisp
> compiled to .NET? - SML.NET (sp?) and F#.
You must be pretty smart to be able to figure this out from the titles
of talks. I have the proceedings in my hand and in many cases the
published papers bear little resemblance to the talks I heard earlier
this week.
What you're calling "peddleware" talks were actually quite informative.
Hisao Kuroda garnered several rounds of applause as he demonstrated how
quickly and how well Lisp can solve difficult problems. Bert Halstead's
Curl talk was suggestive -- they are blazing a trail there's no reason
Lisp cannot follow. Roger Dannenberg's and John Amuedo's talks reminded
us how beautiful mathematics looks when rendered in functional Lisp.
Jan Aasman's AllegroCache made me want a persistent store for the first
time in life, and may just get me to brush up on my Prolog.
A cynic might say these guys were trying to sell something. But these
were the talks that made me want to rush out and build something big
and cool in Lisp so that I can share it at next year's conference.
From: alex goldman
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <8555343.WpLWkgg5ZY@yahoo.com>
Sashank Varma wrote:
> What you're calling "peddleware" talks were actually quite informative.
> Hisao Kuroda garnered several rounds of applause as he demonstrated how
> quickly and how well Lisp can solve difficult problems. Bert Halstead's
> Curl talk was suggestive -- they are blazing a trail there's no reason
> Lisp cannot follow. Roger Dannenberg's and John Amuedo's talks reminded
> us how beautiful mathematics looks when rendered in functional Lisp.
> Jan Aasman's AllegroCache made me want a persistent store for the first
> time in life, and may just get me to brush up on my Prolog.
I have no problem with commercial software, I'm not a RMS-worshipping
communist, but where have you heard of people paying hundreds of bucks to
listen to some sales pitch? On my planet, it usually happens the other way
around.
I could even understand it if they truly *just* invented something out of
this world, but do you know how old, say, Curl is?
alex goldman wrote:
> I could even understand it if they truly *just* invented something out of
> this world, but do you know how old, say, Curl is?
Yes, I do. I know about its origins at MIT as a research project, its
transfer to a start-up, their recent acquisition, etc. I also caught
the dynamic wizards panel where Mat Hostetter described the runtime
system.
But you know what? There's something categorically different about
seeing the code in action, running live in browser. It was only then
that their argument for having the same language span both the client
and serve side of the Web clicked for me. (I had the same aha
experience in Aasman's AllegroCache talk when he pulled up a Listener
and *showed* us all how naturally a persistent OO database interfaces
with Common Lisp.)
I didn't walk away from these talks wanting to ditch Lisp for Curl or
wanting to switch to Allegro. But the ideas embodied in these products
-- ideas that their developers think are good enough to make back their
investments, and then some -- are now ideas I want to implement and
extend and exploit in my own code.
FWIW, the conference was probably the least vendor-centric one I have
attended -- and I normally attend purely scientific conferences.
alex goldman wrote:
> I have no problem with commercial software, I'm not a RMS-worshipping
> communist, but where have you heard of people paying hundreds of bucks to
> listen to some sales pitch?
Nonsense. Sometimes commercial enterprises do theoretically interesting
stuff, and can talk for an hour about that without ever "pitching". In
fact, the only sales pitch I heard in three days was for open source,
some yobbo pretending that McClim was a hot technology, in a desperate
attempt to suck more developers into a lost cause. mastenbrook was
gracious enough to admit that Clim's design was so godforsaken that
getting it to do anything useful required months of study, but aside
from that I have seen less preposterous performances from actors in
infomercials. "Isn't this great?" "Can you believe how cool this is?"
"Just look at this astonishing trick!". Not one line of code, or any
indication of how long he slaved over his demo. Just trivial stupid pet
tricks accompanied by "Can you believe it?".
To tell you the truth, I think he faked all those screen shots and that
McClim does not actually exist. How sad.
:)
Of course you were too cool to go, so you would not know.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Brian Mastenbrook
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <Ru-dnRnbwMyICCDfRVn-oA@comcast.com>
Kenny Tilton wrote:
> Nonsense. Sometimes commercial enterprises do theoretically interesting
> stuff, and can talk for an hour about that without ever "pitching". In
> fact, the only sales pitch I heard in three days was for open source,
> some yobbo pretending that McClim was a hot technology, in a desperate
> attempt to suck more developers into a lost cause. mastenbrook was
> gracious enough to admit that Clim's design was so godforsaken that
> getting it to do anything useful required months of study, but aside
> from that I have seen less preposterous performances from actors in
> infomercials. "Isn't this great?" "Can you believe how cool this is?"
> "Just look at this astonishing trick!". Not one line of code, or any
> indication of how long he slaved over his demo. Just trivial stupid pet
> tricks accompanied by "Can you believe it?".
>
> To tell you the truth, I think he faked all those screen shots and that
> McClim does not actually exist. How sad.
Oh, Hi Kenny. I looked for you specifically in the audience at the start
of the presentation and you were not there. Did you sneak in later? I
don't remember seeing you at the end either.
If you hadn't been at the presentation this post would have been a bit
more defensible. If you were there, you seemed to have missed the entire
point of the presentation, which is about what syntax-aware editing can
do. We have a comprehensive framework for writing interactive
editor-parsers and using that information for display. Is this a neat
gimmick? Or is the combination of a bunch of things that most editors
can't do, let alone abstract to multiple syntax modes, a "trivial stupid
pet trick"? Perhaps if you had put your prejudices aside and actually
listened to the talk, you would have found things that could equally be
applied with your own GUI framework. CLIM wasn't even the point of the
presentation: I merely showed how Climacs integrates with CLIM.
I don't know how you heard the comment about CLIM being hard to learn -
but it was explicitly said in context of there not being enough tutorial
documentation to make it easy to learn. How easy would it be to learn
Common Lisp just given a copy of the HyperSpec, a buggy implementation,
and not even a decent library of example programs? That's where McCLIM
is today. Now I'd like to see that improve, but that's going to take
effort that I'm putting in in the quantity that I can provide.
If you'd like to see the code, it's all in Climacs CVS.
··················@common-lisp.net:/projects/climacs/cvsroot/ - password
'anonymous'. Check out the module "climacs" for the code and "papers"
for the paper and presentation.
Brian Mastenbrook wrote:
> Kenny Tilton wrote:
>
>> Nonsense. Sometimes commercial enterprises do theoretically
>> interesting stuff, and can talk for an hour about that without ever
>> "pitching". In fact, the only sales pitch I heard in three days was
>> for open source, some yobbo pretending that McClim was a hot
>> technology, in a desperate attempt to suck more developers into a lost
>> cause. mastenbrook was gracious enough to admit that Clim's design was
>> so godforsaken that getting it to do anything useful required months
>> of study, but aside from that I have seen less preposterous
>> performances from actors in infomercials. "Isn't this great?" "Can you
>> believe how cool this is?" "Just look at this astonishing trick!". Not
>> one line of code, or any indication of how long he slaved over his
>> demo. Just trivial stupid pet tricks accompanied by "Can you believe
>> it?".
>>
>> To tell you the truth, I think he faked all those screen shots and
>> that McClim does not actually exist. How sad.
>
>
> Oh, Hi Kenny. I looked for you specifically in the audience at the start
> of the presentation and you were not there.
> Did you sneak in later? I
> don't remember seeing you at the end either.
Far right, last row, next to Rahul, soup to nuts.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
> mastenbrook was
> gracious enough to admit that Clim's design was so godforsaken that
> getting it to do anything useful required months of study
You can do something useful in some days, at least I have done some very
small programs with it:
http://www.frank-buss.de/lisp/clim.html
Some ideas of Clim are very nice, for example every drawing command goes to
a stream and you can record and playback streams and the inherent
separation of GUI and data is nice. But you are right, the design of the
classes and the usage is sometimes a bit complicated and the GUI widgets
are not very close to what you expect from modern GUIs.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Kenny Tilton wrote:
>
>
>>mastenbrook was
>>gracious enough to admit that Clim's design was so godforsaken that
>>getting it to do anything useful required months of study
>
>
> You can do something useful in some days, at least I have done some very
> small programs with it:
>
> http://www.frank-buss.de/lisp/clim.html
>
> Some ideas of Clim are very nice, for example every drawing command goes to
> a stream and you can record and playback streams...
But if you specialize the rubber-meets-the-road rendering on the output
stream, you do not need to record/playback, you just render with a
different stream proxy instance on which you can specialize the
rendering code to select (via GF dispatch) the actual renderer.
Did Clim predate CLOS?
>... and the inherent
> separation of GUI and data is nice.
Sure, but how hard is that? View classes get instantiated to represent
model instances. Again, I get the feeling Clim either predated CLOS or
failed to understand it.
> ...But you are right, the design of the
> classes and the usage is sometimes a bit complicated
With first Strandh himself and now Mastenbrook freely admitting that
Clim is a bitch to learn, I guess this much has been settled. What
remanins unclear is why they do not see this as a Bad Sign.
> ..and the GUI widgets
> are not very close to what you expect from modern GUIs.
>
The story I got was that the design effort went into working out the
presentation (model / view) thing, not prettiness. But they have been at
it long enough that you would think the looks of the interface would
have been addressed by now. Instead, all that has been accomplished is a
terribly hard way to separate model and view.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton <·······@nyc.rr.com> writes:
> With first Strandh himself and now Mastenbrook freely admitting that
> Clim is a bitch to learn, I guess this much has been settled.
Whether Robert and Brian have actually said that, or you've simply
spun their words, I don't know (though given your love of hyperbole
I'd wager on the latter); even if they have, I'm happy to hold out and
say that it is simply different, such that previous experience of
other paradigms does not necessarily transfer across. Can anyone
think of other things which are, unjustifiably, accused of being hard
to learn, odd or unusual, yet are said by their devotees to confer a
qualitative increase in power?
> What remanins unclear is why they do not see this as a Bad Sign.
Is this an allusion to the usual Worse-is-Better argument, or
something with different substance? In any case, since I don't
believe your premises as stated, arguments based on them aren't going
to impress me.
Christophe
Christophe Rhodes wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>With first Strandh himself and now Mastenbrook freely admitting that
>>Clim is a bitch to learn, I guess this much has been settled.
>
>
> Whether Robert and Brian have actually said that, or you've simply
> spun their words, I don't know (though given your love of hyperbole
> I'd wager on the latter);
<g> Well, the female dog bit is definitely mine, but other than that,
no, I believe I have not exaggerated. Full marks to Brian, btw, for
coming clean on that score.
even if they have, I'm happy to hold out and
> say that it is simply different, such that previous experience of
> other paradigms does not necessarily transfer across.
My sense is that the problem is not any paradigm shift, rather it is the
awkwardness of programming the thing. As Strandh said:
"The "problem" with CLIM is that its
layered approach allows a sophisticated programmer to intervene at
lots of points in the way CLIM works internally. While this feature
is invaluable to sophisticated programmers, it is confusing to
beginners."
Cells presents the developer with a paradigm shift. The only thing hard
about learning Cells is making that shift. Even I tended for years to
slip out of declarativethink when writing new code, and I developed
Cells. But no user has ever indicated they could not figure out how to
program with Cells, despite the absence of documentation.
Can anyone
> think of other things which are, unjustifiably, accused of being hard
> to learn, odd or unusual, yet are said by their devotees to confer a
> qualitative increase in power?
OpenGL. :) But this is different. The programming does not suddenly get
easier because I have broken through some comprehension barrier, I just
eventually get really nice output. And it gets "easier" only as I
internalize the hundred gotchas it presents.
Strandh maintained that Lisp was also hard to learn, but was worth it. I
have watched several people including myself learn Lisp, and I must say
that the exact opposite is true. One /masters/ Lisp over a long time,
but is more productive from day one, and learning is easy because of the
interactive nature and sensible runtime errors.
The "increase in power" argument, btw, fails if, as I suspect, the
difficulty of learning Clim is an artifact of bad design, and not an
ineluctable part of interface programming. Having done an awful lot of
the latter, I can tell you there is nothing that hard about model-view
programming, with or without Cells.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton <·······@nyc.rr.com> writes:
> Christophe Rhodes wrote:
>> even if they have, I'm happy to hold out and
>> say that it is simply different, such that previous experience of
>> other paradigms does not necessarily transfer across.
>
> My sense is that the problem is not any paradigm shift, rather it is
> the awkwardness of programming the thing. As Strandh said:
>
> "The "problem" with CLIM is that its
> layered approach allows a sophisticated programmer to intervene at
> lots of points in the way CLIM works internally. While this feature
> is invaluable to sophisticated programmers, it is confusing to
> beginners."
Disregarding the fact that what you quote doesn't match your summary
of it, maybe this simply means that we don't yet know how to teach it?
Not even in my wildest dreams do I expect someone to absorb CLIM's
many layers in one sitting -- but I think that those who therefore say
that it's impossible to get started and do useful stuff (and sometimes
stuff that is hard to do elsewhere) are overstretching.
I will happily admit that there are things I don't know how to do with
CLIM: "ordinary" application layout with callbacks attached to buttons
is one of them. I don't believe that it's particularly hard, or even
terribly different from the facilities offered in other languages;
it's simply not what I do. (Also, you should take care not to turn
either of those sentences into a quote supporting your position: in no
way am I a CLIM expert -- but I'm learning, slowly, and am managing to
get the job done).
> Cells presents the developer with a paradigm shift. The only thing
> hard about learning Cells is making that shift. Even I tended for
> years to slip out of declarativethink when writing new code, and I
> developed Cells. But no user has ever indicated they could not figure
> out how to program with Cells, despite the absence of documentation.
I have to admire the way you make a tautology sound like an
endorsement. :-)
> The "increase in power" argument, btw, fails if, as I suspect, the
> difficulty of learning Clim is an artifact of bad design, and not an
> ineluctable part of interface programming.
What if it's neither: but simply a failure to teach it right?
Maybe a good analogy to the didactic materials available for CLIM
would be that we have the equivalent of AMOP available, and nothing
else but a few design documents and examples involving generic
functions returning "Hello, World". I think this is a good analogy of
what exists to teach CLIM at the moment, and it's not really
surprising that, in the absence of a structured way of understanding
things, people run against quite foreign concepts when they've hardly
crossed the threshold.
Nevertheless, as it would have been a shame to throw CLOS out simply
because people were introduced to metaclasses before they were
introduced to classes, so it may (I make no absolute claim: I admit my
ignorance) be a shame to throw CLIM out because of the absence of
teaching materials for it.
Christophe
On Sat, 25 Jun 2005 21:20:12 +0100, <·····@cam.ac.uk> wrote:
>
> What if it's neither: but simply a failure to teach it right?
Then perhaps the project is at the point that some time spent on
"teaching it" will bring the additional developers that they desire.
If the developers cannot separate out the important trees in the
McCLIM forest as tutorial guideposts, no one can.
--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.
Kenny Tilton <·······@nyc.rr.com> writes:
> But no user has ever indicated they could not figure out how to
> program with Cells, despite the absence of documentation.
Well, me, and I've casually listened to cell-speak since the days
where it was called semaphors and Kenny Tilton was still aiming at
enlightment :)
-- Now K.Tilton is going to Killton me.
More concretely, I did not groked the concept of "be". To be or
become, that is the question.
More precisely, I think I understand the abstract requirement, as it's
nothing new and seen in many places, e.g. the separation between
constructing parts of pipeline, clunging it together and finally have
something flow through the pipes, but the spare explanations in what
doesn't want to call itself cells documentation confuse me more than
help.
Regards, and enjoy life,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>But no user has ever indicated they could not figure out how to
>>program with Cells, despite the absence of documentation.
>
>
> Well, me, and I've casually listened to cell-speak since the days
> where it was called semaphors and Kenny Tilton was still aiming at
> enlightment :)
> -- Now K.Tilton is going to Killton me.
>
> More concretely, I did not groked the concept of "be". To be or
> become, that is the question.
And Kenny refused to answer your question when you emailed him? The bastard!
>
> More precisely, I think I understand the abstract requirement, as it's
> nothing new and seen in many places, e.g. the separation between
> constructing parts of pipeline, clunging it together and finally have
> something flow through the pipes, but the spare explanations in what
> doesn't want to call itself cells documentation confuse me more than
> help.
Well, the problem is making the quantum leap from not being in the
dataflow to being in the dataflow all at once. Some background:
One of the nice things about Cells is that the models which are driven
by them can vary in population without worrying much about those
transient moments when the model is only partially constructed or
destructed. For example, I can add instances A and B to the model, where
A has a slot with a rule which asks B for a slot with a rule which asks
A for a different slot value, and everything Just Works. This is
possible because of a certain JIT, on-demand quality of Cells, and
because entry or exit from the model by any given instance is managed by
to-be and not-to-be.
There is (or was) even some code in the internals that gave special
handling to the crucial "kids" slot of the Family class, which is what I
always use to build complex models. I think advances in Cells II
obviated the need for that special handling. I also think the special
handling of the kids slot /outside/ the internals should be generalized
so other slots with the same model-extending semantics can be easily
defined by non-expert users.
The main idea behind to-be is (a) taking care of initialization required
by Cells internals and (b) getting an instance across that quantum leap
from not being in the flow to being in the flow.
re the latter, suppose I push a new model instance onto the KIDS of some
Family instance in a working model. The idea behind Cells is automatic
state consistency, but we now have an instance whose rule-mediated slots
are unbound, and whose slot values, once calculated, have not been
manifested outside the model by any "output" methods which may exist.
to-be takes care of evaluating ruled slots and outputting all
cell-mediated slots.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
> Joerg Hoehle wrote:
>> More precisely, I think I understand the abstract requirement, as it's
>> nothing new and seen in many places, e.g. the separation between
>> constructing parts of pipeline, clunging it together and finally have
>> something flow through the pipes,
It occurs to me I did not answer your implicit question: Do I need to
worry about to-be?
If you use the Family class and the kids slot to build up your
application models, to-be and not-to-be get called on kids as they enter
and leave the model.
In my applications, I start with:
(setf *system* (to-be (make-instance 'system)))
Then, when I want a new window:
(push (make-instance 'cello-window :kids <whatever>) (kids *system))
The declarative model covers the rest.
The only thing you need to worry about is adding two instances to the
model when they care about each other. Then they have to get added
together, so:
(push A (kids *system*))
(push B (kids *system*))
...will fail if A cares about B. So:
(setf (kids *system*) (append (list A B) (kids *system*)))
From: Arthur Lemmens
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <opssxsgwuxk6vmsw@news.xs4all.nl>
Kenny Tilton wrote:
> Again, I get the feeling Clim either predated CLOS or failed to
> understand it.
Could give you concrete examples of places where CLIM doesn't use
CLOS properly?
> With first Strandh himself and now Mastenbrook freely admitting
> that Clim is a bitch to learn, I guess this much has been settled.
> What remanins unclear is why they do not see this as a Bad Sign.
Spoken like a true Schemer ;-)
In my experience most interesting and 'deep' subjects (e.g. music,
mathematics, foreign languages, Common Lisp programming) are a
bitch to learn. I don't see that as a bad sign.
--
Arthur Lemmens
Arthur Lemmens wrote:
> Kenny Tilton wrote:
>
>> Again, I get the feeling Clim either predated CLOS or failed to
>> understand it.
>
>
> Could give you concrete examples of places where CLIM doesn't use
> CLOS properly?
No, this is based on reading things like "presentation types make XXX
easy", and the way I use CLOS to handle XXX. Also, casual scans of the
CLIM doc and seeing opaque DEFWHATEVER forms that one has to internalize
over what seems to be a significant learning curve. I have created stuff
like that before realizing that if I just stuck to CLOS anyone could
figure out how to subclass or specialize methods to tweak behavior.
>
>
>> With first Strandh himself and now Mastenbrook freely admitting
>> that Clim is a bitch to learn, I guess this much has been settled.
>> What remanins unclear is why they do not see this as a Bad Sign.
>
>
> Spoken like a true Schemer ;-)
Aside: I think a CW is taking hold. The first thing a Schemer does is
rejoice over the tiny spec. The second thing they do is assemble their
own personal Common Lisp.
>
> In my experience most interesting and 'deep' subjects (e.g. music,
> mathematics, foreign languages, Common Lisp programming) are a
> bitch to learn. I don't see that as a bad sign.
That fails to address whether or not the difficulty is implicit in the
content being learned. Clim makes interfaces harder to build than
necessary. Whatever productivity levels Climmers eventually reach could
be had much more easily.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Arthur Lemmens
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <opssxwz0k0k6vmsw@news.xs4all.nl>
> No, this is based on reading things like "presentation types make
> XXX easy", and the way I use CLOS to handle XXX. Also, casual scans
> of the CLIM doc and seeing opaque DEFWHATEVER forms that one has to
> internalize over what seems to be a significant learning curve.
Apart from the lack of tutorials, I don't think that CLIM's learning
curve is worse than that of any other GUI library of a comparable power.
(No, I never tried Cello. I'll take a look when Cello's design and
documentation becomes half as stable, reliable and understandable
as CLIM's. Just let me know when that happens.)
> Aside: I think a CW is taking hold.
Sorry, I have no idea what a CW is and Google doesn't help.
> Clim makes interfaces harder to build than necessary. Whatever
> productivity levels Climmers eventually reach could be had much
> more easily.
OK, those are more interesting claims than the claim that CLIM is bad
because it's difficult to learn. I would still be very interested in
any evidence (even anecdotical) you can give to back up these claims.
On Sat, 25 Jun 2005 21:13:02 +0200, <········@xs4all.nl> wrote:
>
> (No, I never tried Cello. I'll take a look when Cello's design and
> documentation becomes half as stable, reliable and understandable
> as CLIM's. Just let me know when that happens.)
It already has. I've seen demos of both, but this is an apples and
oranges type of comparison, so pointing out that Cello has useful
abilities now doesn't mean much in the context of CLIM. The people
behind CLIM are not focused on 'useability for the novice' at the
moment (and probably never will be).
--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.
Arthur Lemmens wrote:
> Sorry, I have no idea what a CW is and Google doesn't help.
conventional wisdom.
>
>> Clim makes interfaces harder to build than necessary. Whatever
>> productivity levels Climmers eventually reach could be had much
>> more easily.
>
>
> OK, those are more interesting claims than the claim that CLIM is bad
> because it's difficult to learn. I would still be very interested in
> any evidence (even anecdotical) you can give to back up these claims.
Unlike most Lispniks, I do little else /but/ GUI work, from Apple II in
Integer Basic and even assembler to early Macs with C and native widgets
to a pre-windows DOS GUI to Think C's godawful TCL (which I actually
punted on because even its fans admitted it took a year to learn) to
Smalltalk to Lisp with MCLs OS9 gui wrappers to AllegroCL and Common
Graphics. Also rolling my own on win32 (didn't like CG) and OpenGL
(Cello) and I have at least ported Cells-GTK to UFFI if not develop
under it. So what can I say? Most GUIs are programmer friendly, allow
easy attainment of easy stuff and fancier stuff with reasonably more
effort. The Think C GUI library being a good counterexample, and its
author went on to CodeWarrior where I heard he tried to do better, so
looks like there is no argument there that the thing was a wreck. Again,
even its fans said it was a bear to learn.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: David Golden
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <4xcve.1647$R5.452@news.indigo.ie>
alex goldman wrote:
> I have no problem with commercial software, I'm not a RMS-worshipping
> communist,
ObFlame:
How about a return to free market capitalism in software: i.e. the
removal of the copyright (and sometimes patent) monopoly interference
in the software market. If you are a free market capitalism supporter,
you SHOULD have a problem with current copyright- and patent-supported
"commercial software" (note that Free-as-in-freedom i.e. Libre software
can be and has been profitable commercially, too). If microsoft were
competing in a real free market without the crutches of copyright and
patent law to prop them up, I doubt there'd be the problem with them we
have today.
So if you actually talk to Libre software supporters, while they tend to
range almost right across the economic and political spectrum, an awful
lot of them are european-liberal/american-libertarian, not communists,
taking the "Without copyright the GPL would be unenforceable. It would
also be unnecessary." line.
(while I'm not particularly communist myself, it is also important to
note that communist is not necessarily such a dirty word outside the
USA anyway).
From: alex goldman
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <2027913.MdO8f4p3VK@yahoo.com>
David Golden wrote:
> alex goldman wrote:
>
>
>> I have no problem with commercial software, I'm not a RMS-worshipping
>> communist,
>
> ObFlame:
> How about a return to free market capitalism in software: i.e. the
> removal of the copyright (and sometimes patent) monopoly interference
> in the software market. If you are a free market capitalism supporter,
> you SHOULD have a problem with current copyright- and patent-supported
> "commercial software" (note that Free-as-in-freedom i.e. Libre software
> can be and has been profitable commercially, too). If microsoft were
> competing in a real free market without the crutches of copyright and
> patent law to prop them up, I doubt there'd be the problem with them we
> have today.
>
> So if you actually talk to Libre software supporters, while they tend to
> range almost right across the economic and political spectrum, an awful
> lot of them are european-liberal/american-libertarian, not communists,
> taking the "Without copyright the GPL would be unenforceable. It would
> also be unnecessary." line.
>
> (while I'm not particularly communist myself, it is also important to
> note that communist is not necessarily such a dirty word outside the
> USA anyway).
I don't know what this has to do with the topic, but thanks, I'll be sure to
remember that!
--
I kill a communist for fun, but for a green card, I gonna carve him up real
nice - Tony Montana
alex goldman wrote:
> Greg Menke wrote:
>
>
>>Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>>This correspondent's chin hit the floor when he realized this speaker
>>>was from Microsoft:
>>>
>
> http://pdcbloggers.net/Question_and_Answer/PNL02/Patrick_Dussud.category
>
>>>Mr. Dussud was favored with one of the closing plenary sessions of the
>>>conference, and used it to suggest Common Lisp cripple itself in various
>>>ways (help me, someone: static typing is all I remember) so it could
>>>have the honor of running on Microsoft's CLR. Well, OK, the motivation
>>>would be in the title of the paper "Re-inventing Lisp for Ubiquity".
>>
>>Its the inevitable refrain from people not actually trying to do
>>something with Lisp, but flogging some abstract agenda which they think
>>relates. There must be a corollary to Greenspun that addresses the
>>consequences of trying to force high level languages into a C/C++
>>runtime. Either you shoot off your feet or you trip over your
>>shoelaces- either way your nose ends up in the dog poop on the sidewalk
>>in front of you.
>
>
> I'll probably get flamed for this, but when I looked at the list of talks on
> ILC2005's web site, it made me glad I wasn't there. At least half of what I
> saw was either crapware, or peddleware, or reware. Reware is something
> that's already been built a dozen times, but presented as brand new and
> innovative. Lisp copiled to .NET? There are a dozen of those that compile
> to JVM and/or .NET. Strictly typed Lisp?! - ML. Strictly typed Lisp
> compiled to .NET? - SML.NET (sp?) and F#.
>
> (I'm sure I've just offended a bunch of people, but hey, there's a 50%
> chance they've already been offended by my earlier comments about their
> fathood anyway)
ILC conferences are all about socializing and schmoozing and putting
faces on names. You might not learn much form the talks, but your social
skills might improve. :)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Carl Shapiro
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <ouyfyv7gm8a.fsf@panix3.panix.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> This correspondent's chin hit the floor when he realized this speaker
> was from Microsoft:
> http://pdcbloggers.net/Question_and_Answer/PNL02/Patrick_Dussud.category
FYI, this information has been posted on the conference website for
quite some time.
http://international-lisp-conference.org/speakers.html#patrick_dussud
> Mr. Dussud was favored with one of the closing plenary sessions of the
> conference, and used it to suggest Common Lisp cripple itself in
> various ways (help me, someone: static typing is all I remember) so it
> could have the honor of running on Microsoft's CLR. Well, OK, the
> motivation would be in the title of the paper "Re-inventing Lisp for
> Ubiquity".
I think you are missing the point. It is difficult to integrate Lisp
into an engineering environment where programmers are writing or
integrating software written in many different languages. The
suggested changes would make Lisp more easily hosted on top of a
contemporary runtime like the JVM or the CLR, in turn making it easier
to deliver the object code of applications written in Lisp. If you do
not think Lisp has a problem delivering applications, ask yourself why
Lisp completely missed the boat on component software.
From: Greg Menke
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <m34qbngkrj.fsf@athena.pienet>
Carl Shapiro <·············@panix.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> I think you are missing the point. It is difficult to integrate Lisp
> into an engineering environment where programmers are writing or
> integrating software written in many different languages. The
> suggested changes would make Lisp more easily hosted on top of a
> contemporary runtime like the JVM or the CLR, in turn making it easier
> to deliver the object code of applications written in Lisp. If you do
> not think Lisp has a problem delivering applications, ask yourself why
> Lisp completely missed the boat on component software.
So one of the fundamentally nice things about Lisp should be eviscerated
for the convienence of a mythical advantage in "integration with other
languages" where the "other languages" are warmed over C++ and Visual
Basic?
I've worked on projects integrating C and Ada on embedded operating
systems and the language integration issue has thus far been among the
least of the issues- pretty much at the same level as getting the
makefiles to work right. Its footprint as an issue pretty much extends
to getting the various vendors and users to share enough info to work
out the kinks down at the ABI. I'd approach a composite Common
Lisp/C/C++ situation with something like ECLS, or an adaptation of a
commercial vendor's product where I could host & control the Lisp
elements as tasks & resources in the OS. Nothing especially subtle.
Remember .NET isn't here to solve a technical problem, its to solve a
lack of monopoly problem for Microsoft.
The big long-term issues are interrelationships of control and data and
state, which is always the case. Sharing the types & classes is a 2nd
order issue at best, and is generally mitigated by being thorough with
the interface definitions- which you'd better have anyhow or you're
writing spagetti code.
Not that vm's are useless, but they don't solve the hard problems.
Gregm
Greg Menke wrote:
> Carl Shapiro <·············@panix.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > I think you are missing the point. It is difficult to integrate Lisp
> > into an engineering environment where programmers are writing or
> > integrating software written in many different languages. The
> > suggested changes would make Lisp more easily hosted on top of a
> > contemporary runtime like the JVM or the CLR, in turn making it easier
> > to deliver the object code of applications written in Lisp. If you do
> > not think Lisp has a problem delivering applications, ask yourself why
> > Lisp completely missed the boat on component software.
>
> So one of the fundamentally nice things about Lisp should be eviscerated
> for the convienence of a mythical advantage in "integration with other
> languages" where the "other languages" are warmed over C++ and Visual
> Basic?
>
I would kill (metaphorically speaking) for a good .NET version of Lisp.
:)
> Remember .NET isn't here to solve a technical problem, its to solve a
> lack of monopoly problem for Microsoft.
>
Looks like your one of those anti-Microsoft types, so perhaps you're
predisposed to dismiss anything that someone from Microsoft might say,
despite Patrick Dussud's strong Lisp background.
http://international-lisp-conference.org/speakers.html#patrick_dussud
"Before Microsoft, Patrick was the lead designer of the System
Internals of the TI Explorer workstation, and re-engineered most of the
rest of the runtime components, leading to a successful, stable Lisp
system. His work on TICLOS was notable for its innovative solutions,
and received accolades from other CLOS implementers. Later he worked at
Lucid as the Chief Architect of Energize, a C++ programming environment
motivated by Lisp-machine-like programming environments."
From: Greg Menke
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <m3y88yfxeu.fsf@athena.pienet>
"Super Spinner" <···········@gmail.com> writes:
> Greg Menke wrote:
> > Carl Shapiro <·············@panix.com> writes:
> >
> > > Kenny Tilton <·······@nyc.rr.com> writes:
> > >
> > > I think you are missing the point. It is difficult to integrate Lisp
> > > into an engineering environment where programmers are writing or
> > > integrating software written in many different languages. The
> > > suggested changes would make Lisp more easily hosted on top of a
> > > contemporary runtime like the JVM or the CLR, in turn making it easier
> > > to deliver the object code of applications written in Lisp. If you do
> > > not think Lisp has a problem delivering applications, ask yourself why
> > > Lisp completely missed the boat on component software.
> >
> > So one of the fundamentally nice things about Lisp should be eviscerated
> > for the convienence of a mythical advantage in "integration with other
> > languages" where the "other languages" are warmed over C++ and Visual
> > Basic?
> >
>
> I would kill (metaphorically speaking) for a good .NET version of Lisp.
> :)
But who gives a damn about .NET? Its not buying you anything but a
vague sort of integration with other languages. There aren't even
portability advantages to other architectures. Now if you need buzzword
conformance, then thats different- you have a marketing requirement.
>
> > Remember .NET isn't here to solve a technical problem, its to solve a
> > lack of monopoly problem for Microsoft.
> >
>
> Looks like your one of those anti-Microsoft types, so perhaps you're
> predisposed to dismiss anything that someone from Microsoft might say,
> despite Patrick Dussud's strong Lisp background.
>
Well I'll pay Microsoft more attention when they start taking their
engineering at least as seriously as they take their marketing. And
yes, as far as I'm concerned anyone from Microsoft has to meet a much
higher threshold of credibility than someone from Cisco or Sun.
> http://international-lisp-conference.org/speakers.html#patrick_dussud
>
> "Before Microsoft, Patrick was the lead designer of the System
> Internals of the TI Explorer workstation, and re-engineered most of the
> rest of the runtime components, leading to a successful, stable Lisp
> system. His work on TICLOS was notable for its innovative solutions,
> and received accolades from other CLOS implementers. Later he worked at
> Lucid as the Chief Architect of Energize, a C++ programming environment
> motivated by Lisp-machine-like programming environments."
Thats nice. But now Microsoft pays him to evangelize .NET, not to
develop & enhance Common Lisp.
Gregm
Carl Shapiro wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>This correspondent's chin hit the floor when he realized this speaker
>>was from Microsoft:
>> http://pdcbloggers.net/Question_and_Answer/PNL02/Patrick_Dussud.category
>
>
> FYI, this information has been posted on the conference website for
> quite some time.
>
> http://international-lisp-conference.org/speakers.html#patrick_dussud
Cool, thx. But that mentions only strong typing. I recall quite a list
of amputations he had in mind for CL.
>
>
>>Mr. Dussud was favored with one of the closing plenary sessions of the
>>conference, and used it to suggest Common Lisp cripple itself in
>>various ways (help me, someone: static typing is all I remember) so it
>>could have the honor of running on Microsoft's CLR. Well, OK, the
>>motivation would be in the title of the paper "Re-inventing Lisp for
>>Ubiquity".
>
>
> I think you are missing the point. It is difficult to integrate Lisp
> into an engineering environment where programmers are writing or
> integrating software written in many different languages.
I think you are forgetting that I come from a planet where Common Lisp
is only a few years away from pushing all other languages into the sea.
:)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Carl Shapiro
Subject: Re: ILC 2005: Microsoft Demands Surrender, CL Says It Has Not Yet Begun to Fight
Date:
Message-ID: <ouyaclfaxmo.fsf@panix3.panix.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Cool, thx. But that mentions only strong typing. I recall quite a list
> of amputations he had in mind for CL.
You'll find a copy of that list in your proceedings.
> I think you are forgetting that I come from a planet where Common Lisp
> is only a few years away from pushing all other languages into the sea.
>
> :)
Yeah, I wish I could live on that planet.
Carl Shapiro wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Cool, thx. But that mentions only strong typing. I recall quite a list
>>of amputations he had in mind for CL.
>
>
> You'll find a copy of that list in your proceedings.
Ah, there it is. He changed the title enough to throw me off.
Well, the list looks shorter, but I am reminded he wanted to cripple
CLOS as well.
>
>
>>I think you are forgetting that I come from a planet where Common Lisp
>>is only a few years away from pushing all other languages into the sea.
>>
>>:)
>
>
> Yeah, I wish I could live on that planet.
You do not look old enough to have to worry about not being around in
three years. :)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page