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. :)
"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
> 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.
>> 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)
> 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.
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.
Carl Shapiro <cshapiro+s...@panix.com> writes: > Kenny Tilton <ktil...@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.
>>>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. :)
"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
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.
"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 <ktil...@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.
"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
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.
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?
> > 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.
"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."
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.
"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
> > > 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.
> "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.
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:
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.
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).
> 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.
"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 <ktil...@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.
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. :pserver:anonym...@common-lisp.net:/projects/climacs/cvsroot/ - password 'anonymous'. Check out the module "climacs" for the code and "papers" for the paper and presentation.
>>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.
"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
