Kenny Tilton <ktil...@nyc.rr.com> writes: > [apologies if this has materialised in similar form or does so soon > unbeknownst to me, but from where I sit it appears Google ate a > similar report posted yesterday via google groups.]
> Dr. McCarthy joined with Henry Baker, his predecessor at the > microphone, in bemoaning the standardization of Common Lisp as > stultifying if not mortifying, in that it ended innovation.
Well, other languages were standardized by the same heavyweight process as CL (C, C++, SQL, Fortran). While these languages sure evolve slower than Perl/Python/Ruby/etc there is development. The C++ standard is revised and extended every 5 years or so. The current version of Fortran is from 1995 and I believe there is a revision process going on right now.
For other languages there is, despite standardization, _no_ guarantee that 20year old code will run or compile with a current implementation. Changes to any standard usually break some code (in the simplest case by introducing a new keyword). So, this notion that "standard" implies "if my code runs now it will run forever" is wrong.
Peter Seibel <pe...@gigamonkeys.com> writes: > Pascal Costanza <p...@p-cos.net> writes: [...] >> As much as I like Common Lisp, I think he has a point here.
> As did Baker, or rather a dozen or so good points--can't wait until > his full slidedeck is available.
Any examples?
Paolo -- Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film Recommended Common Lisp libraries/tools: - ASDF/ASDF-INSTALL: system building/installation - CL-PPCRE: regular expressions - UFFI: Foreign Function Interface
> The more general question -- Did standardization produce > stultification? -- is quite provocative though.
[...]
> This brings up an interesting question: Is the binding constraint of > the standard, which was critical during the 1980s and 1990s, gonna > choke the community now that it is again showing signs of growth?
In my oppinion standards are only good for sellers but not for developers. It is very difficult to do something new only using standards. So in my trying, i through away any kind of standards. (sure there are some standards remaining, like a based-on bone-body).
Other viewpoint is that non-standards are hard to manage. They need a big part of describe and how to use and most of them are case specialized. (try to teach this, or search for on the web, brrr, see fortran survive story)
> Another possibility is that the community > will split in a healthy way, with business users adhering closely to > the standard in the interests of portability, and with academics again > experimenting with new features and birthing new dialects.
Instead of making a new dialect, let a module (interface) come in. While creating a new dialect one is forced to create all kinds of existing "standarts" too. This is not always a good solution.
It shows the necessary of listening to the users wishes (which takes some time) and enable them to quick-hack the actual needed tool (utility), a balance act between using one universal tool or tonnes of tools-boxes (sometimes this is called scripting).
More material will become available as soon as I collect the slides and receive permission to distribute it. Same goes for the audio we recorded during all of the conference tracks.
Kenny Tilton <ktil...@nyc.rr.com> writes: > Dr. McCarthy joined with Henry Baker, his predecessor at the > microphone, in bemoaning the standardization of Common Lisp as > stultifying if not mortifying, in that it ended innovation.
Okay, let's file this, we will arrange for a vote at ILC 2006:
Issue: COMMON-LISP-STANDARDIZATION-SUCKS
References: ILC 2005
Related issues: STANDARDIZATION-SUCKS
Category: DELETION
Edit history: Version 1, 24-Jun-05 by Paolo Amoroso
Status: For discussion and evaluation; not proposed for inclusion in the standard at this time.
Problem description:
The standardization of Common Lisp is stultifying if not mortifying, in that it ended innovation.
From http://lispmeister.com/blog/lisp-news/ILC05-rep-1.html: "If someone was to drop a bomb on this building, it would wipe out 50 percent of the Lisp community. That would probably be a good thing. It would allow Lisp to start over."
These passages are relevant to or affected by X3J13 Cleanup Issue COMMON-LISP-STANDARDIZATION-SUCKS:
* The whole ANSI Common Lisp specification
Note: It is possible that there are other passages affected by this cleanup issue. This list is not part of the specification, and has not been formally audited for completeness by X3J13.
> * McCarthy actually meant that very little code lasts ten years.
Be sure not to invite McCarthy and VisiCalc co-inventor Dan Bricklin at the same event:
The structure and culture of a typical prepackaged software company is not attuned to the long-term needs of society for software that is part of its infrastructure. This essay discusses the ecosystem needed for development that better meets those needs.
Paolo -- Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film Recommended Common Lisp libraries/tools: - ASDF/ASDF-INSTALL: system building/installation - CL-PPCRE: regular expressions - UFFI: Foreign Function Interface
"Sashank Varma" <sashankva...@yahoo.com> writes: >This is my great fear. In the Dynamic Language Wizards panel discussion >of a year ago, someone lamented that the current ACM model computer >science curriculum devotes on 5 hours to the study of programming >language design. Guy Steele said maybe this wasn't a bad thing, that >maybe computer science had passed beyond the time when new programming >languages had to be invented on a weekly basis. Maybe we really are at >some kind of language design plateau.
Plus, programming language research has moved on to languages more "fruitful" in theoretical results, i.e., functional languages like ML and Haskell, with strong type systems, where there are quite a few open problems still. Perhaps Lisp simply has become too boring for research with no really interesting problems left? Writing the nth object system, compiler, or garbage collector or what have you isn't going to cut it anymore. That's old, well understood stuff by now, that is, it has moved to mainstream. And you apparently cannot mathematically formalize a dynamic type system as well as a strict, inferential one, and this alone would make it quite unattractive for use in research papers.
On 24 Jun 2005 12:27:19 +0200, Matthias Buelow <m...@incubus.de> wrote:
> Plus, programming language research has moved on to languages more > "fruitful" in theoretical results, i.e., functional languages like > ML and Haskell, with strong type systems, where there are quite a > few open problems still. Perhaps Lisp simply has become too boring > for research with no really interesting problems left? Writing the > nth object system, compiler, or garbage collector or what have you > isn't going to cut it anymore. That's old, well understood stuff by > now, that is, it has moved to mainstream. And you apparently cannot > mathematically formalize a dynamic type system as well as a strict, > inferential one, and this alone would make it quite unattractive for > use in research papers.
Languages that are "fruitful" in this sense are good for researchers who have to publish papers or want to write a thesis. That doesn't necessarily mean they're good for real world applications as well.
Cheers. Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spamt...@agharta.de" 5) "edi")
Sashank Varma wrote: > This brings up an interesting question: Is the binding constraint of > the standard, which was critical during the 1980s and 1990s, gonna > choke the community now that it is again showing signs of growth?
I don't believe it will. Common Lisp has plenty of room for extension without doing violence to the current standard, and the flaws I see in the current standard can be tolerated or surmounted, IMO. The bigger question in my mind is whether the current organization of the lisp community will allow concensus to be reached on these extensions.
>>>>* McCarthy actually meant that very little code lasts ten years.
>>>That would suggest a serious disconnect with reality; >>>it's a little hard to believe.
>>Oh. please. You have no knowledge or experience of production code.
> I've been delivering production code since about 1976,
Then you know that bad systems get thrown out and good systems change over time because requirements change over time. If they are being thrown out, there you go. If they are being revised, there you go: a substantial new effort in which any change to the language probably only helps by making the language more expressive. This is the same reason that code quality matters and the fact code works does not: any successful system grows to take on new functionality and at least lasts long enough to see requirements change. Good code means it will see more work.
"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
>>>> [apologies if this has materialised in similar form or does so soon >>>> unbeknownst to me, but from where I sit it appears Google ate a >>>> similar report posted yesterday via google groups.]
>>>> Dr. McCarthy joined with Henry Baker, his predecessor at the >>>> microphone, in bemoaning the standardization of Common Lisp as >>>> stultifying if not mortifying, in that it ended innovation.
>>> As much as I like Common Lisp, I think he has a point here.
>> Please get back to us when you have some application functionality you >> cannot express in Common Lisp.
> ...only after you have made sure that you're not implicitly using a > Turing equivalence argument here. ;-P
Nope. Fire away. But I /am/ armed with DEFMACRO, so get those shields up. :)
"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
