Kenny Tilton <ktil...@nyc.rr.com> writes: > BTW, show me a URL to a Python with good GC, macros, C+20% performance, > generic methods, special variables, an ANSI standard, and which has the > stability of a forty-plus year old language.
> Now which is harder, whipping up interfaces to the latest toys or > finishing Python?
Yeah, Lisp is the greatest language in the world. No one here, myself included, is going to disagree with you.
That doesn't change the fact that, to many users, those things are all completely irrelevant if they can't easily open a socket, connect to a database, spawn a process, stat a file, open a pipe, send a datagram, throw a window on the screen, match a string against a regular expression, encrypt a string, use the syslog facility, parse CGI environment variable values, parse urls, send mail, read mail, send a file via ftp, read a file via ftp, start an nntp session, parse an xml file, manipulate image files, manipulate sound files, ...
Different people are going to judge languages based on different sets of criteria. Lisp is tops by my criteria, but only because I know enough about computers to either roll my own support for the above if I have to or write ffi bindings. Could you honestly recommend Lisp to someone to whom being able to easily do some of those things was important? What about someone who was just begining to program, but needed to be able to write useful programs fairly soon?
If you want Lisp to appeal to more people--and I'm not saying that you should, or that I do, or that it's even a worthy goal--there are more helpful things then being disdainful of criticism (and it was actually pretty *light* criticism).
> there are more > helpful things then being disdainful of criticism...
Look, the criticism sucks, what can I do? :)
There are two questions. (a) How good is a language? (2) How much glue is there to today's hot toys? All this yammering lumps the two together. That is a godawful mistake. Good languages are hard, glue is easy. Also, popularity generates glue as much as glue generates popularity. if glue is your design goal you should end up with glue but unless you are extending CL the language invented to provide the glue will likely be a slow, unstable hack in need of years of refinement.
the criticism reaches for finality based on a few years' history. "Wouldn't it be great if CL had seamless access to VSAM, JCL, RMS, DCL, and Pascal?!" oops... what is that rule of thumb about how long one has to wait before writing the history of something? What really gives me a pain where I sit is folks like Norvig and Graham pulling their chins and pronouncing "what's wrong" with a language which kicked ass before they had written a line of code and will continue to kick ass long after they are pushing up daisies, all because of a little excitement this week (in geological time) over a few toy languages.
This is like dissecting the general manager's off-season trades when the division leader loses five games in a row.
If they are through with CL, fine, they can have Python or Arc and leave CL to the young tigers who are picking up the flag. I just wish they'd spare us the lame 30-second-history parting shots at the language that made them.
:)
Here is what would be helpful: if the fanatics sawing away at extending Python, Perl and Ruby would close up shop and learn CL. Helpful also would be Graham or Norvig coding up the CL interfaces they miss. Helpful in actuality are the people starting to share CL stuff.
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
In article <3CE9BFDD.90FB3...@nyc.rr.com>, Kenny Tilton <ktil...@nyc.rr.com> wrote:
> Here is what would be helpful: if the fanatics sawing away at extending > Python, Perl and Ruby would close up shop and learn CL.
That's not going to happen as long as people with experience in said languages (and other not mentioned, such as Smalltalk, Dylan, Scheme, OCaml) who come to this newsgroup get as chilly a reception as they do at present.
Kenny Tilton <ktil...@nyc.rr.com> wrote: > BTW, show me a URL to a Python with good GC, macros, C+20% > performance, generic methods, special variables, an ANSI > standard, and which has the stability of a forty-plus year old > language.
Which one of those things are required for writing, for example, a simple web server? You can do it in Python using a few lines of code. The same code will work with Jython was well. How many lines of CL does it take?
Yes, the GC in sucks. I know. I wrote it. Yes, Python is agonizingly slow when compared to C++ or compiled CL. You know what else? It doesn't matter. Python gets the job done. It's got a large, well documented stardard library. It's got a free, very portable, fairly bug free implementation. It plays well with other languages and libraries.
> Now which is harder, whipping up interfaces to the latest toys or > finishing Python?
Harder is not the question. The question is will anyone do it? Lots of CL users seem to have the attitude that CL is king and all other languages are inferior. They seem to think that no advancement of the language is necessary. The ANSI CL standard was an awesome technical feat but progress cannot stop there. A standard network socket interface would be nice, for example. Is the CL community working on one?
I feel sad. CL is a great language. However, if it doesn't grow its standard library (even if it's only a de facto standard) then it's going to eventually die. The community needs to realize this and start working on it. Denying the problem does not help.
Kenny Tilton <ktil...@nyc.rr.com> writes: > There are two questions. (a) How good is a language? (2) How much > glue is there to today's hot toys? All this yammering lumps the two > together.
Yes, and I think Norvig did a good job of describing what the issues were, and keeping them separate. Both are pretty important when you want to write code.
As for libraries, their importance also depends on the application. For less demanding problems, the availability of libraries can outweigh the intrinsic power of the language. Where is the breakeven point? Hard to say exactly, but wherever it is, it is short of anything you'd be likely to call an application. If a company considers itself to be in the software business, and they're writing an application that will be one of their products, then it will probably involve several hackers and take at least six months to write. In a project of that size, powerful languages probably start to outweigh the convenience of pre-existing libraries.
I think the following statement is hard for anyone in comp.lang.lisp to deny (but I sure expect to be surprised):
Lisp is definitely a better language than most (though it's not as far ahead as it once was) and the state of lisp libraries is definitely not as good as that of many other languages.
Let's just admit it's a problem (for some, maybe not for everyone) and work on it.
Actually, people are *working* on the problem of making it easy to create, distribute, find and install lisp libraries right now--the Comprehensive Common Lisp Archive Network (CCLAN) is developing the required infrastructure, which is a lot of work.
There's also the issue of writing good, portable libraries, which is a lot of work. I believe that common interfaces for sockets and threads (and maybe user-extensible streams) would make it *much* easier to write portable versions of a certain class of library that happens to be popular right now.
For myself, I'm close to deciding that anything I write will use the APIs for these things as defined by Allegro Common Lisp, mostly because they're the best I've seen, but also because it seems like there's some movement toward accepting them as de facto standards (E.g., OpenMCL's implementing the ACL socket API, the Portable AllegroServe project's acl-compat files, maybe even some recent cmucl and sbcl development.)
> > Helpful in actuality are the people starting to share CL stuff.
> sharing was around even before CL, dude.
? You must have misparsed my godawful sentence.
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
> In article <3CE9BFDD.90FB3...@nyc.rr.com>, > Kenny Tilton <ktil...@nyc.rr.com> wrote:
> > Here is what would be helpful: if the fanatics sawing away at extending > > Python, Perl and Ruby would close up shop and learn CL.
> That's not going to happen as long as people with experience in said > languages ... who come to this newsgroup get as chilly a reception
I have heard that theory before, but I am not sure it holds water. I try to imagine myself getting stoked over some new language but then abandoning it because of a feisty NG... nahhhh.
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
> > > Here is what would be helpful: if the fanatics sawing away at extending > > > Python, Perl and Ruby would close up shop and learn CL.
> > That's not going to happen as long as people with experience in said > > languages ... who come to this newsgroup get as chilly a reception
> I have heard that theory before, but I am not sure it holds water. I try > to imagine myself getting stoked over some new language but then > abandoning it because of a feisty NG... nahhhh.
Well you might not, and I clearly aren't, but I see plenty of people pop up here, get abused and insulted, and they're never seen again. Which, apparently, the long term Lisp people here are happy to see happen.
> However, if it doesn't grow > its standard library (even if it's only a de facto standard) then > it's going to eventually die.
The only way Lisp will die is the same way the mac gui lost to the microsoft dos command line, ie when some other language matches Lisp and goes it one better. That would be fine by me, if not CL vendors. :)
> The community needs to realize > this and start working on it. Denying the problem does not help.
Hey, I'd like lotsa libraries, I just do not see it as a problem. Then again, I tend to develop applications in which what I write is the beef. Sounds like these other languages are more like scripting languages, connecting libraries that supply the beef.
These scripting languages are not technical threats to CL. As for the popularity threat, well, unpopularity may be fatal to some languages, but Lisp clearly is not one of them, precisely because it is so fundamentally excellent. COBOL was popular, Pascal was popular, C++ was popular... live by popularity, die by popularity.
My crystal ball says: The explosion of new languages means C++ is spent and is falling back to Earth. CL is the answer, witness the excitement over CL features reintroduced by the new languages. These new languages will serve as stepping stones for a few refugees from C++ to CL. This new blood needs reach only a very low threshhold before the old blood, discouraged by years of unpopularity, takes heart and returns to action. In /very/ short order CL has more libraries than anyone, precisely because of CL's fundamental strength. Popularity follows incidentally, not vitally.
You heard it here first. Now where's my fiddle...
:)
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
Neil Schemenauer <nas-use...@arctrix.com> writes: > [..] Lots of CL users seem to have the attitude that CL is king and > all other languages are inferior. They seem to think that no > advancement of the language is necessary. The ANSI CL standard was > an awesome technical feat but progress cannot stop there.
Actually I don't think most CL users (at least not myself) believe CL to be the end of history, only that most emerging competitors are giant leaps backwards rather than steps forward. The Python language certainly is a leap backwards in every respect, with the possible exception of C-world integration (and some might count the whitespace syntax a win, but I at least consider it a failed experiment).
So no advancement of the CL language would be necessary to outclass the competition, which of course is not to say that advancement wouldn't be a good thing.
I agree that having loads of defacto-standardized libraries would be nice, but in actuality I personally don't have any great need for any library functionality in particular, which again is probably why I haven't contributed much to any such library. And this might be the case for others too.
Bruce Hoult wrote: > Well you might not, and I clearly aren't, but I see plenty of people pop > up here, get abused and insulted, and they're never seen again. Which, > apparently, the long term Lisp people here are happy to see happen.
I suspect a major problem is that the "new generation" of news readers don't know what a killfile is.
In article <yBmG8.7372$04.21...@news.iol.ie>, David Golden <david.gol...@oceanfree.net> wrote:
> Bruce Hoult wrote:
> > Well you might not, and I clearly aren't, but I see plenty of people pop > > up here, get abused and insulted, and they're never seen again. Which, > > apparently, the long term Lisp people here are happy to see happen.
> I suspect a major problem is that the "new generation" of news readers > don't know what a killfile is.
Who do you suggest should be killfiling whom?
Besides, what does a "new generation" have to do with anything? I've been on usenet for more than a decade, I've always used software with a killfile ([[s]t]rn, then NewsWatcher) but have never killfiled anyone, and I'm not about to start now.
* Bruce Hoult | Well you might not, and I clearly aren't, but I see plenty of people pop | up here, get abused and insulted, and they're never seen again.
You do? You see, to people who observe _before_ they judge, this is simply not in the evidence. Just because you feel like it _should_ be true, because that would be much more fun for you, for whatever perverse reason, does not _make_ it true. However, there is some truth to the idea that perception makes reality. In this sense, you are the one who keeps making this story stick to people's memory, much to the annoyance of other people. Could you please stop? You are scaring the newbies. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
In article <3230965513765...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> * Bruce Hoult > | Well you might not, and I clearly aren't, but I see plenty of people pop > | up here, get abused and insulted, and they're never seen again.
> You do? You see, to people who observe _before_ they judge, this is > simply not in the evidence. Just because you feel like it _should_ be > true, because that would be much more fun for you, for whatever perverse > reason, does not _make_ it true. However, there is some truth to the > idea that perception makes reality. In this sense, you are the one who > keeps making this story stick to people's memory, much to the annoyance > of other people. Could you please stop? You are scaring the newbies.
You might have some sort of point if there was a factual basis to your claims. As usual there isn't. I have never before made the observation that people pop up here, get abused and insulted, and are never seen again. Not once. Check the archive on google.
I suggest you read what you wrote above and understand that it applies best to youself.
* Bruce Hoult | You might have some sort of point if there was a factual basis to your | claims. As usual there isn't.
Christ, dude. So you had no arguments. Just checking.
| I have never before made the observation that people pop up here, get | abused and insulted, and are never seen again. Not once. Check the | archive on google.
The point, Bruce, was that you have never made that observation at all.
| I suggest you read what you wrote above and understand that it applies | best to youself.
Yeah, yeah. Apply to yourself. Yadayada. How much RAM do you really need to do that thing?
Incidentally, have you considered how much the first two sentences above might apply to yourself? I guess not. "Apply to myself" does not compute.
Just for the record: You are not a newbie. You are only incredibly annoying and won't go away, and you feel abused much more than you are, and then you abuse in return. This is doubly annoying. Usually, this kind of behavior is associated with newbiehood, but you have been around a long time, so you cannot use yourself as evidence of your claim, OK? -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
I have the basis for an nntp library somewhere on my home disk. I played around with it in order to build myself a CL-based news reader (more as a toy than anything else) and (possibly) as use for a gateway between nntp and other media.
If there is enough interest, I could probably dust it off and see what I can do about getting it downloadable from somewhere.
//Ingvar -- When the SysAdmin answers the phone politely, say "sorry", hang up and run awaaaaay! Informal advice to users at Karolinska Institutet, 1993-1994
Neil Schemenauer <nas-use...@arctrix.com> writes: > Kenny Tilton <ktil...@nyc.rr.com> wrote: > > Now which is harder, whipping up interfaces to the latest toys or > > finishing Python?
> Harder is not the question. The question is will anyone do it?
This reminds me of a psychology experiment to find the difference between the problem-solving approaches of physicists and mathematicians.
They set up a room with a wastebasket in the middle, and a chair on the side with a fire extinguisher underneath. They set fire to the wastebasket and then sent the physicist in the door. She looked at the fire, looked at the extinguisher, went over to the chair, picked up the extinguisher and put out the fire.
They repeated the same experiment with a mathematician. He exhibited the exact same behavior.
For the next experiment, they moved the wastebasket between the doorway and the chair. They set it on fire and sent in the physicist. She looked at the fire, saw the chair on the other side, and walked around to get the extinguisher. Then she put out the fire.
They set up the experiment again, but this time sent in the mathematician. He looked at the fire, saw the chair on the other side, and walked over to the wastebasket. Using his foot, he shoved the burning wastebasket into the center of the room. Then he sat in the chair and did nothing.
When the psychologists interviewed him, he explained, "I saw that the new problem was similar to the one I'd previously solved, so I reduced the new to the old problem and was done."
This is experiment is, of course, fictional. However, the mode of thinking is real. As long as the CL community ignores problems that are boring and straightforward, they won't get solved. Standardizing interfaces is one such problem. It involves working with people, not just code, so it's not as fun as the usual things you do with CL.
Those of you who just want to see CL not die have nothing to worry about. But those of you who want to use CL more in your day jobs will have to see some boring, straightforward problems solved before it will happen.
-- <brlewis@[(if (brl-related? message) ; Bruce R. Lewis "users.sourceforge.net" ; http://brl.codesimply.net/ "alum.mit.edu")]>
> I have the basis for an nntp library somewhere on my home disk. I played > around with it in order to build myself a CL-based news reader (more as > a toy than anything else) and (possibly) as use for a gateway between > nntp and other media.
> If there is enough interest, I could probably dust it off and see what I > can do about getting it downloadable from somewhere.
I'm interested Ingvar. The currently available nntp library is GPLed which means you must GPL your software in order to be able to distribute a software product combined with the library. Not only does this effectively preclude all proprietary software from accessing the library but it also stops any combined products being released under a more liberal licence.
I guess this code is effectively public domain. Do what you like with the code without bothering the author. I think a GPL-compatible BSD/MIT-style license would be a better choice than telling lawyers to learn an honest trade.
If you want people to be required to provide any changes to the library when they release code that uses this library consider the LLGPL. If you want people to be free to modify the library without being required to provide their code consider the MIT or no advertising clause (i.e. GPL-compatible) BSD licence, e.g.:
On Mon, 20 May 2002 01:18:23 GMT, Gabe Garza <g_ga...@ix.netcom.com> wrote: > If anything, the proliferation of free Common Lisp implementations is > a sign of fragmentation and wasted effort--we have communities > actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
Is GCL still supported? Is it still the primary platform for Maxima deployment?
I seem to understand that the ECLS developer community includes a single individual.
As for CMUCL and SBCL, both developer communities recently had and exchange of ideas about merging back the projects. It looks like there may be interest in this, and it may be technically possible. But don't hold your breath.
> > I have the basis for an nntp library somewhere on my home disk. I played > > around with it in order to build myself a CL-based news reader (more as > > a toy than anything else) and (possibly) as use for a gateway between > > nntp and other media.
> > If there is enough interest, I could probably dust it off and see what I > > can do about getting it downloadable from somewhere.
> I'm interested Ingvar. The currently available nntp library is GPLed which > means you must GPL your software in order to be able to distribute a > software product combined with the library. Not only does this effectively > preclude all proprietary software from accessing the library but it also > stops any combined products being released under a more liberal licence.
OK, if I remember correctly, the current code is tied to CMUCL's socket-opening code, but I imagine compatibility wrappers to be easy(ish) to find/write (there *may* be ACL compat code, depending on when in time it was written).
[SNIP]
> Thanks again for your potential offer of code.
Not a problem, it's been collecting virtual dust on my disk since a few years abck. As for what license I will release it under, I don't know, but my gut feeling right now is "here is the code, do what you will, if it breaks, you keep both parts, should you want to submit a fix, here's my mail address".
//Ingvar -- When C++ is your hammer, everything looks like a thumb Latest seen from Steven M. Haflich, in c.l.l
On Tue, 21 May 2002, Bruce Hoult wrote: > In article <3CE9BFDD.90FB3...@nyc.rr.com>, > Kenny Tilton <ktil...@nyc.rr.com> wrote:
> > Here is what would be helpful: if the fanatics sawing away at extending > > Python, Perl and Ruby would close up shop and learn CL.
> That's not going to happen as long as people with experience in said > languages (and other not mentioned, such as Smalltalk, Dylan, Scheme, > OCaml) who come to this newsgroup get as chilly a reception as they do > at present.
Just to provide a counter-data-point, I come to this newsgroup with experience in Smalltalk, and I fairly often mention Smalltalk and Smalltalk issues, and I don't feel that I've gotten a very chilly reception.
OTOH, I don't think people will give up on Perl, Python, Ruby, etc. just because they get a warmer reception in comp.lang.lisp. I mean *really*.
Even if you just meant that it's a *necessary* condition (which wasn't obvious from your rhetoric), I would think that tarting out comp.lang.lisp is *far* down the list of things to be accomplished ;)
On Tue, 21 May 2002, John Wiseman wrote: > Kenny Tilton <ktil...@nyc.rr.com> writes:
> > There are two questions. (a) How good is a language? (2) How much > > glue is there to today's hot toys? All this yammering lumps the two > > together.
> Yes, and I think Norvig did a good job of describing what the issues > were, and keeping them separate.
If you go back in this three, you'll see that I think almost exactly the opposite. I think Kenny's formulation hides that (a) generally is a feater of the *langauge* whereas (2) [weird numbering scheme Kenny!] is generally a feature of implementations.
It may sound like a Schemely reponse to say, "Oh, but the there are *implementations* that have what you need." but I'm not clear that is. But, in point of fact, it's *much* harder to get portable-over-all-implementation libs than to get *one* implementation with all the functionality. If the latter is what's *really* needed for success, pursuing the former will slow things down. A lot.
That's what I mean by Norvig's "double standard". *No one* disputes the use of being able to take socket or thread or...code and drop it into almost any CL implementation and have it just work. I do dispute that *that's* what makes CL "lose ground" to Python (for the most part).
Finally, I think a *lot* of care must be taken when claiming that the Python (or better, the Ruby) standard libs are so great. Ruby's a very young language. Very young. But, afaict, it's *never* had this sort of whinging thrown at it.
A lot of the issues of between implementation porting crop up (though perhaps not as serverely) for between version of Python.
> Both are pretty important when you > want to write code.
Sure. As no one denies. But when python is lacking in some area (SVG support anyone?) folks just code it up.
[snip]
> I think the following statement is hard for anyone in comp.lang.lisp > to deny (but I sure expect to be surprised):
> Lisp is definitely a better language than most (though it's not as far > ahead as it once was) and the state of lisp libraries is definitely > not as good as that of many other languages.
I don't know why you thing this is hard. The real question is *which* libraries? AFAICT, LispWorks has *excellent* libraries (for *lots* of things). As does Allegro. As does MCL. Etc.
Try to replicate the KnowledgeWorks stuff in Python!
Ok, maybe not everyone needs that, but that's at least part of the point, yes?
Sure, there's no *standard* for sockets...but there's not *standard* for sockets in python, just a canonical implemenation.
> Let's just admit it's a problem (for some, maybe not for everyone) and > work on it.
Well, let's admit the *right* problem.
Or better, let's just work on useful, portable libraries. Since we *all* admit they're a good, we can be positively driven rather than negatively.
*But*, given scare resources, it makes sense to prioritize, yes?
> Actually, people are *working* on the problem of making it easy to > create, distribute, find and install lisp libraries right now--the > Comprehensive Common Lisp Archive Network (CCLAN) is developing the > required infrastructure, which is a lot of work.
Yep. Yay for them.
But the Vendors do good too.
[snip]
> For myself, I'm close to deciding that anything I write will use the > APIs for these things as defined by Allegro Common Lisp, mostly > because they're the best I've seen, but also because it seems like > there's some movement toward accepting them as de facto standards > (E.g., OpenMCL's implementing the ACL socket API, the Portable > AllegroServe project's acl-compat files, maybe even some recent cmucl > and sbcl development.)
* Neil Schemenauer wrote: > Which one of those things are required for writing, for example, > a simple web server? You can do it in Python using a few lines > of code. The same code will work with Jython was well. How > many lines of CL does it take?
I think my original one was about 60 - its current descendent is 250 or something (of profusely commented code) but it has lots more stuff (most of which is over-design I never used, sigh). The original one never made it into CVS so I'm working from memory. I do know that it took under an hour to write, including learning about the socket interface in the implementation I'm using. The current one has 25 or 30 lines of implementation-dependent code depending on which implementation you're using. Porting it took less long than I've spent on this article.
If people are put off by the effort required to do this, then, well, they're probably going to be put off by getting up in the morning. In the application that used (uses) this little web server I spent *hundreds of times* longer doing application-specific HTML-generating code than I ever did in the web server.
I think most of the `not standard so I can't use it' complaints are work avoidance. So there's a standard interface to HugeComplicatedInteroperabilityStandard, say. What has this bought you, since you are still two years away from understanding HugeComplicatedInteroperabilityStandard well enough to use it, and in that time it will either have died, or spawned four new versions and fifteen other things you need to understand to use it. Look at XML: can anyone *read* fast enough to keep up with the new standards it's spawning?
--tim (please CC any followups to me if you want me to see them, I don't read news very often, sorry to be rude.)
