> > (let ((*x* 'second)) (setf *x* 'third) (symbol-value '*x*)) => THIRD > > (symbol-value '*x*)) => FIRST
> > If you count out that there are no lexicals in the top level, and > > ignore the effects of scope and extent, this looks quite like the same > > behaviour as lexicals have to me
I think the observation was that the property of special variables saving and restoring their values looked a lot like the behavior of lexical variables in nested scopes.
You can, for example, get the above behavior with lexical variables as follows:
To me, at least, this is the point of special variables, and what makes them different from purely global variables. In other words, globals are dangerous, because any random code can diddle with them and wreak havoc. Lexicals are safer, but you can't use them to set global parameters. Specials have the property of providing bindings for any free variables that reference them, as well as automatically saving and restoring values when you want that behavior. You don't have to remember to do it yourself.
The fundamental difference between special and lexical variables is that free variables when lexical get closed over their bindings while free variables when special find their bindings on a (conceptual) stack.
Here is my example that shows the fundamental difference between how special and lexical variables work:
First, with special declarations:
* (let ((x 'first)) (declare (special x)) (flet ((foo () (print x))) (foo) (let ((x 'second)) (declare (special x)) ; Without this x is lexical here. (foo)) (foo) (values)))
CMU Lisp notes that the (let ((x 'second)) ...) in the second example creates an unused variable. This illustrates lexical closures --- foo's free variable will no longer take a new binding.
-- Fred Gilham gil...@csl.sri.com It is also well to note that there are probably not ten hand-grenades in the entire philosophical community. -- John Lange
In article <fz7k93gea2....@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
<m_mom...@yahoo.com> wrote: > > > If you want to attract more users, how about contributing to > > > the free lisps? Writing a C00l portable editor?
> > I don't think I have the expertise to do that. I've never written an editor.
> there's always a first time :)
At my age one begins to realize that life is far too short to do everything that one would like to do, or even just all the worthwhile things, even for the first time.
> > > I've not been into this business for so long (and the post isn't > > > addressed to me either), but in any case I would say you get the > > > statistics wrong. Specials definately *aren't* keeping people off.
> > That may be, but I still maintain that people do get confused about them. > > Whether this puts them off CL or not is debatable, and also beside the > > point.
> Is it? Wasn't that your whole point? Let's change specials so that > people flock to CL?
No. My point is: let's change specials because people get confused about them, lots of time gets wasted explaining them, and they are a barrier to entry. Whether they are a *decisive* barrier I don't know. Probably not. But changing them is easy (easier than documenting them -- I know because I've done both), I saw what I thought was a good answer, so I thought I'd try for what seemed to me to be low-lying fruit.
In article <kwel3brnul....@merced.netfonds.no>, Espen Vestre
<espen@*do-not-spam-me*.vestre.net> wrote: > In fact, I think lisp is in a better position than ever. I've used > common lisp for 'business critical' server applications for 4 years
Would you be willing to make some details of your experience available so the rest of us can cite your experience as a success story?
> (But I don't think I want Common Lisp to be _the_ most popular language,
Neither do I. I just want it to be popular enough so that I can use it again.
g...@jpl.nasa.gov (Erann Gat) writes: > In article <fz7k93gea2....@cupid.igpm.rwth-aachen.de>, Mario S. Mommer > <m_mom...@yahoo.com> wrote:
> > Is it? Wasn't that your whole point? Let's change specials so that > > people flock to CL?
> No. My point is: let's change specials because people get confused > about them, lots of time gets wasted explaining them, and they are a > barrier to entry.
I am just thinking about how much time of my life I've wasted explaining integrals to students...
Regards, -- Nils Gösche "Don't ask for whom the <CTRL-G> tolls."
OK, Kent, you've convinced me that this is a bad idea. I am hereby dropping it. I'd like to clarify a few things though:
In article <sfwznlyx3y9....@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote: > Why preferably Common Lisp given that you appear to dislike it so,
I don't dislike it. I have spent most of my career programming in CL. I have made significant career sacrifices in order to be able to continue to program in CL. And now I fear I may have burned a few bridges here in a failed attempt to try to continue to be able to program in CL. I am actually quite offended that anyone even remotely familiar with my record could think that I dislike CL.
> Why not make a new dialect that (a) changes what you > want to change for whatever reasons you want [there's no sin in change, > even gratuitous change, if you do it without foisting it on the unwilling], > and (b) has a new name that is not tainted in whatever way you perceive > it to be tainted? I don't really think Paul Graham is doing the right thing > with Arc, but he's certainly entitled to do what he's doing.
Like I said (and as you well know because I hired you to help me with it) I am pursuing this avenue as well. But I am not doing this because I want to. I am doing it beause I do not have any other viable choice (other than becoming a C++ programmer).
> > I completely agree. But we're not making any progress on these > > issues either.
> Progress on this does not require changes to the base language.
I never said it did.
> > > Yes. It must address issues that define the modern workplace. > > > Handy support for hash tables or a clearer definition of what it > > > is to bind a variable does not characterize the modern workplace.
> > Again, I completely agree. And again I say we don't seem to be making any > > progress.
> Progress does not require a change in the spec. It requires extension. > Extension can be done compatibly.
And 90% of the BIND proposal could be done compatibly (as evidenced by the fact that the proposal contained an implementation). The remaining 10% could be done with a backwards-compatible extension.
> > If you disagree, if you think we are making progress, would you please > > point me to what you consider that progress to be?
> Irrelevant.
Why?
> The problems of the 'fragile base class' (need to recompile entire > world when a minor change is made in one class) and of the improper > conceptual application of methods (based on static typing rather than > dynamic typing) are 'surmountable' but the syntax for special > variables in Common Lisp is not 'surmountable'?
I never said the problems caused by special variables were insurmountable.
> If all that is needed to make people use CL is to add a few macros, add the > few macros and call it something else and see if people flock to your new > dialect. You don't need anyone's help.
For the nth time: what I need is to be able to answer the question "who uses it?" (And I need the answer to be something other than "a handful of universities.") I can't do that by myself.
> What CL lacks, if anything, > is finished applications. And what is stopping people from getting there > is NOT special variables. Except perhaps in the sense that it's too much > fun for some people to tinker on special variables (or anything else) > and too little fun to work on finished applications.
No. What CL lacks is users. The lack of applications is a consequence of the lack of users (which is to say, programmers), not the root problem.
> > Are you OK knowing that there are lots of people out there who > > would like to use Lisp but can't?
> They are not kept from doing so by the semantics of the special variables.
I never said they were.
> > > Both of these can be done without affecting the standard.
> > Right, but I don't see any way to solve *my* problem without affecting the > > standard. (That effect could be to extend it, not necessarily to change > > it in non-backwards-compatible ways.)
> I don't think your problem would be solved by changing the standard.
Yes, you've convinced me that I was wrong about this.
> Whether you mean to be or not, I think you are just lonely. And I think > you are trying to rally support by raising the level of discontent with > CL.
It is rather lonely being a Lisper at JPL. But my intention was not to raise the level of discontent or to fragment the community. If that was the effect of what I did, I'm sorry.
> I also think the community is not determined by who shows up and says > "serve me". I think the community determined by who the language > designers say they seek to serve.
Franz, Harlequin, Digitool and Hypermeta have all accepted my money at one time or another. That is IMO enough of a credential for me to consider myself at least one time to have been part of the community.
> The community has had many fewer users in the past and is presently on > the upswing.
I see no evidence of this, but if someone could provide me with some data that would help me out a lot.
> > It is ironic that we are at loggerheads about this because I think > > we both want the same thing: for CL to be a commercial success so > > that we can make money using it.
> I agree with this remark. I just think the things you are suggesting > will squeeze the precious lifeblood out of a small but vaiable community.
OK. You have made a convincing argument, I respect your views, and so I am dropping it.
I would like it understood that my motives were not to cause trouble. My proposal may have been misguided, but it was not malicious.
> Nevertheless, while I share your goal, we differ in one important respect: > I do not see the sky as falling. The situation is not NEARLY as dire as it > was a decade ago.
Once again, some data to support this would be very helpful to me. From where I sit things appear to be much more dire than they were ten years ago.
>> Then I wonder what you envision as Lisp's future. > Layered standards.
That would definitely be a good thing, IMHO. There isn't going to be a new ANSI Common Lisp anytime soon, if we want one or not. That shouldn't stop us from going forward in areas where this is possible.
The question is, how do we get such a thing going? Substandards.org doesn't seem to be too successful, to say the least. I recently noticed the Standards page at the ALU cliki (http://alu.cliki.net/Standards). What's up with that? (And, by the way, what's up with ALU anyway? The only trace of it's existence are the ILCs, or so it seems. Is there any kind of activity? Should there be?)
> > >> Then I wonder what you envision as Lisp's future. Do you think it > > >> will experience a renaissance? If so, what will drive it?
> > > Moore's law.
> > Unlikely. Lisp is faster than a lot of more popular languages > > today. Perfomance doesn't seem to be the problem (prejudices > > concerning performance may be, but they will not go away just because > > of Moore's law).
> The memory usage of most lisp implementations was a real problem until > quite recently, so I'd say that the increase in the standard amount > of installed RAM has made lisp much more usable for mainstream > applications during the last 5 years. (My lisp applications now > typically uses about 32MB of RAM, which is acceptable today, but > which could have been problematic 3 or 4 years ago).
Well, this really depends on the implementation. For Unix CLs, I think this has been an acceptable memory usage (for non-pipeline tools) for at least 8 years. But it's been quite possible to run Lisp in more memory-starved situations. From "Getting Started with MCL":
MCL 4.0 Memory Requirements The MCL 4.0 size resource is set for a *generous* partition showing approximately 4.8 mb with virtual memory and 5.1 mb without.
[emphasis mine]
> It's more fun than ever to be a lisp programmer, and I actually > think we'll see an increase in usage and popularity!
> (But I don't think I want Common Lisp to be _the_ most popular language, > just think what certain big software companies could do to it...)
I'm in 100% agreement here.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
g...@jpl.nasa.gov (Erann Gat) writes: > > I also think the community is not determined by who shows up and > > says "serve me". I think the community determined by who the > > language designers say they seek to serve. > Franz, Harlequin, Digitool and Hypermeta have all accepted my money > at one time or another.
(Note, though, that the work HyperMeta is doing for you is not exactly "programming in CL", certainly not 'per se'. Rather, speaking loosely, we are working with you as you explore non-CL-ish alternatives. So mention of us is perhaps a bad example.)
Also, and importantly, I'm NOT trying to make you feel like an outcast personally. I'm making serious suggestions that I think would make you happier. I'm trying to merely explain why people are not rushing to cater to you. It's a business decision. Yes, those companies (including mine) have taken your money, but that doesn't mean those companies have committed to going your way. It means that every time they make a decision, they have to decide "is it worth risking losing you", or is the bulk of money in another direction. And the fact is that every time I post to this newsgroup a statement in opposition to what you're saying, I have to risk losing you as a customer, too. That's not my desire. Just a known risk.
That is, you might read my remarks as hypocritical because I have both suggested you're not part of the market and I've taken your money. Another way to read it, though, is that I am doubly serious. Because I am risking receiving no further money from you in order to make my point. I consider making my point to be sufficiently important that I am willing to risk that. And don't think I don't think of this issue every time I respond. My credibility in this market is about all I have to my name some days, and I just can't say I agree with you merely because you are a customer. If you understood how empty my bank account was right now, you'd understand just how seriously that means I feel what I am saying.
Look, a lot of friends come to me with personal troubles. I'm not the sort to tell them (as some people do) what _I_ would do in their circumstance. I am not them, and most people would not go my way. What I try to do when they have troubles is listen to what they are saying to me, and tell them what I hear. Sometimes people are bad at hearing themselves. So I just repeat back to them what they are saying in different words, hoping that it will help them do what some little voice in them is saying. I know you think you like CL, but there are cues all over everything you write that say you are unhappy with it. You want it to be what it is not.
If someone came to me and said "I really love Fred (or Sally, depending on their gender and preference), but I wish he were a business executive instead of a school teacher." I'm going to say "Are you sure you love this person? You want to change him to be something else before you are satisfied. Is that what love is?" If someone says "I love Fred (or Sally), but I seem to prefer spending time with Bill (or Jane)." In my experience, usually the primary assertion is just something one is "used to saying" or a way they are used to thinking about themselves, and usually the recurring action or nagging thought is a little voice crying out in them saying "Consider a change." That doesn't mean the change will be right. But it means you have a choice to make and it's you, not me, who keeps coming back to the need for that choice. Loud and clear we hear you say "Do x or this is no good." If this was no good, you'd be gone. So maybe this really isn't no good and you're lousy at articulating what you like. Or maybe this is no good, in which case you do not belong here. This is not ME making these assertions. I'm telling you what I hear you telling me.
Something is not intolerable if you merely say it. It's intolerable if you refuse to tolerate it. Something is not valueless if you find value in it. It's valueless if you find it devoid of value. Something is not inferior to something else if you still continue to use it in preference to the something else. It is inferior if you stop using it because of the something else.
The reason I sometimes disappear from comp.lang.lisp is to make the point that some things that happen here are intolerable. It is an unfortunate truth that I cannot make that point while staying and tolerating...
> I would like it understood that my motives were not to cause trouble. My > proposal may have been misguided, but it was not malicious.
I have not suggested that your proposal is malicious.
I do think that with all the energy you spend on the things you do take up, that you could be doing more good in other ways.
I cited the example of the so-called "Idiot's Guide" as an example. It takes work to write an intro. But you are both moving things ahead and setting them back (IMO) by choosing the approach you do, which reinforces the standard myths by repeating them. At least some of your reader may never have heard of those myths, and your intro should not be the first time.
At old-Symbolics, a report was commissioned of how expensive it was to merely receive a release of new software from Symbolics. Not how much we charge people, but how much do they pay out of pocket to accept the release in terms of having to upgrade code.
One of the releases was estimated to cost multiple tens of thousands of dollars per customer to accept. That is, between ten and a hundred thousand dollars. Why? That was the release that was going to change the element-type of strings from integer to character. Just that one change was to cost, across the community, money on the order of a million dollars. Maybe half a million. Maybe 5 or ten million. I'm not sure what the size of the installed base was. But that wasn't money someone was going to make (except the consultants doing the changes and/or the employees who were already on staff who would do the changes rather than something else), it was money that was just "down the tubes" and did not contribute to any product rolling out. It was deemed that this was a necessary cost, but we tried to get all of ANSI CL's incompatible changes in on that release so that we wouldn't have to do that to customers again. It was eye-opening to me and others to think in terms of cost to the community of a "helpful change".
I believe ANY change to the standard will cost "lost millions". After that, the incremental cost of change will be less.
You have expressed the view that there is a desire not to make change. That's right. For exactly that reason. CERTAINLY it is the case that if we make one change, others will be easier. In part because some can piggy back on the first incompatibility. Someone's already going to hire a programmer to fix legacy applications that won't recompile, so they might as well pay that programmer to do a few extra things. But every time we churn the market, there's a big cost again. And I don't want to see that happen. Because those are dollars lost to Lisp. Lost not in the sense that they aren't spent on Lisp programmers, but lost in the sense that they aren't spent on making Lisp succeed in the business world so that even larger dollars will flow our way. If there was a million dollars to be had paying Lisp programmers for anything, I'd rather see it spent on making something than maintaining something that used to work but now has been gratuitously changed.
As such, I think the best thing that can be done is to try to work in good faith toward using CL compatibly. Stress it. Find out if it really can't stand up. The reports so far are promising. There are a few areas that are not as good as they could be, but so far the flaws have not been shown to be fatal.
> > Nevertheless, while I share your goal, we differ in one important > > respect: I do not see the sky as falling. The situation is not > > NEARLY as dire as it was a decade ago.
> Once again, some data to support this would be very helpful to me. From > where I sit things appear to be much more dire than they were ten years > ago.
During the onset AI Winter, the chief problem was that we had spent so many years rolling in dough that we had not had to keep track of what the real world wanted. LispMs were sold by saying "abandon all other things. come use this. do things on our terms." Customers did and we lost track of the needs of the heterogeneous environment. When AI Winter struck, we were diverged a lot and we didn't have the idea that we neeed to compile "linkable libraries", the common thing that all other languages yielded. People almost didn't recognize a 'fasl' file as anything meaningful. Even those who did recognize it couldn't use it. Also, Lisp was big and at the time needed to be small. Lisp was expensive and needed to be cheaper. We had lots to do and vendors had no money to do it with, so it took a long time.
The vendors focused on things that mattered. The need for statically linkable libraries yielded to a need for DLLs, and several vendors met that challenge. CORBA came up and was met. COM was met. Vendors added and tuned multitasking support. Users demanded interfaces that were color. Vendors added that. Users wanted window toolkits (other than CLIM). CAPI and Common Windows and the MCL toolkit (not sure its name) all addressed the need for native application interfaces. We didn't shrink Lisp's size hugely (a few vendors did some tricks to help a little) but we held constant on size while most other programs and languages grew big, so we came into line with the norm and are probably now smaller than normal or at risk of soon being so.
Users complaining about low cost options were met with free(as in beer) versions of LispWorks and Allegro, and numerous free(as in gnu) other whole implementations. Plus Corman appeared and added an extra low-cost commercial option.
Henrik Motakef <henrik.mota...@web.de> writes: > > Layered standards. > The question is, how do we get such a thing going? Substandards.org > doesn't seem to be too successful, to say the least.
Well, it's just delayed in starting. The nightmare of my house and how some bad decisions about renovation has consumed all of my life savings (including retirement accounts) is hardly worth going into in detail here. But it's winding down and I hope to return to Lispy endeavors soon, something that I haven't had time to do for quite a lot of months because of the intrusion of stupid administrative issues. Anyone with money to contribute toward getting substandard.org going is welcome to contact me about that.
> At old-Symbolics, a report was commissioned of how expensive it was to > merely receive a release of new software from Symbolics. Not how much > we charge people, but how much do they pay out of pocket to accept the > release in terms of having to upgrade code.
> One of the releases was estimated to cost multiple tens of thousands > of dollars per customer to accept. That is, between ten and a hundred > thousand dollars. Why? That was the release that was going to change > the element-type of strings from integer to character. Just that one > change was to cost, across the community, money on the order of a > million dollars. Maybe half a million. Maybe 5 or ten million.
Since the source code was avail. the user could implement the change at a low cost provided that the user was a Lisp programmer. And, who else would even want to use a Lispm? The big selling point to people who like Lisp is all the Lisp code that comes with one. This is another reason I choose to get a used one.
Most other systems implement the OS in hairy assembler code, or pointery C code.
I like exploring the Lispm OS to see how an OS not just a Lispm OS any OS could be built.
> > At old-Symbolics, a report was commissioned of how expensive it was to > > merely receive a release of new software from Symbolics. Not how much > > we charge people, but how much do they pay out of pocket to accept the > > release in terms of having to upgrade code.
> > One of the releases was estimated to cost multiple tens of thousands > > of dollars per customer to accept. That is, between ten and a hundred > > thousand dollars. Why? That was the release that was going to change > > the element-type of strings from integer to character. Just that one > > change was to cost, across the community, money on the order of a > > million dollars. Maybe half a million. Maybe 5 or ten million.
> Since the source code was avail. the user could implement the change at a > low cost provided that the user was a Lisp programmer.
You miss my point. The change was ALREADY made. There was no work to the implementation required. But users had tons of their own code that was broken by the change -- that is, code that would not compile or would not load in the new release. This had to be upgraded. In some cases, the programmer who had written the code was not still on staff and that meant ramping up a replacement just to keep existing code working.
> And, who else would even want to use a Lispm? The big selling point > to people who like Lisp is all the Lisp code that comes with > one. This is another reason I choose to get a used one.
User code did not come with the release. User code was written by users.
>> At old-Symbolics, a report was commissioned of how expensive it was to >> merely receive a release of new software from Symbolics. Not how much >> we charge people, but how much do they pay out of pocket to accept the >> release in terms of having to upgrade code.
>> One of the releases was estimated to cost multiple tens of thousands >> of dollars per customer to accept. That is, between ten and a hundred >> thousand dollars. Why? That was the release that was going to change >> the element-type of strings from integer to character. Just that one >> change was to cost, across the community, money on the order of a >> million dollars. Maybe half a million. Maybe 5 or ten million.
> Since the source code was avail. the user could implement the change > at a low cost provided that the user was a Lisp programmer.
No, I don't think you understand what was happening here.
It's not a question of "having users who are Lisp programmers;" it's a question of having system changes that impose code changes on those that already have software deployed.
The point is that if Symbolics makes a change to functions' behaviour that leads to already-deployed systems having to change to cope with those changes, there is some cost to "fixing broken code."
That is, Symbolics changes functions FOO, BAR, and FROBOZZ, and you, the user, have to revise your own programs A, B, and C to conform to the new behaviour. And this has some cost.
It's just the same as if Microsoft deploys a new version of Win32 that breaks some code, forcing developers to revise /their/ code.
It's just the same as if Linus Torvalds puts a change into the Linux kernel that causes existing code to break, forcing developers to revise /their/ code.
Or if the GNOME/KDE graphical infrastructure projects do new releases, requiring some recoding to use the new functionality.
The issue has very little to do with Lisp; it can occur just as easily with other sorts of systems, and has NOTHING to do with licensing costs, and only a little to do with the language being used.
> And, who else would even want to use a Lispm? The big selling point > to people who like Lisp is all the Lisp code that comes with > one. This is another reason I choose to get a used one. > Most other systems implement the OS in hairy assembler code, or > pointery C code. > I like exploring the Lispm OS to see how an OS not just a Lispm OS > any OS could be built.
What you're talking about are other issues that have little to do with what Kent is talking about.
Changing Common Lisp to conform with your expectations would lead to a /huge/ cost of existing code breaking, which is a sufficiently staggering cost to pretty successfully prevent most changes to it. -- output = reverse("gro.mca@" "enworbbc") http://cbbrowne.com/info/lisp.html "So you don't want to hear about my ideas for Cliche Programming? (Basically, the unit of abstraction is a Stereotype; instances of Stereotypes interact by exchanging Hype.)" -- Peter Lewerin
Henrik Motakef <henrik.mota...@web.de> wrote in message <news:87y91jm1xt.fsf@interim.henrik-motakef.de>... > today. Perfomance doesn't seem to be the problem (prejudices > concerning performance may be, but they will not go away just because > of Moore's law).
Moore's law is a continuous process, not a sudden event. The higher up the curve we get, the higher the ratio of the power and utility of Lisp to those of other languages. When it finally reaches the point where it becomes glaringly obvious and can no longer be denied, there may be a herd effect, like that keeping people away from Lisp now, causing it to suddenly become many times more popular than it ever was before. And even then, Moore's law would continue, eventually bringing a future we can hardly imagine.
Whether most of us can earn a living from Lisp right now has nothing to do with whether we could in the past, nor with whether we can in the future. At each point on the Moore's law curve, the conditions are different. The only thing that seems sure is that once it finally becomes easy to earn a living from Lisp, it should continue after that to get easier and easier. Whether the time is ripe yet is not knowable until some time after large numbers of people are indeed earning their livings from Lisp so we would have a history of such success.
> A lot of the change in attitude I'd attribute to Java. Java has made > GC popular again, and actually probably improved people's desire for a > working one. Heh. It has also made people aware of the need for > integers bigger than so-called ints. And it has improved the > understanding of 'message passing' / 'genericity'. It has popularized > some data structures that matter to us. While it's statically typed > in some ways, it's dynamically typed in others, and this is to our > benefit. It has introspection. It even has a primitive condition > system (more powerful than other languages, not as good as ours) Not > to say these things are all done right, but this introduces the > ability for us to merely say "we have a better way" on a topic people > have seen, rather than a missionary project of teaching people they > want the feature in question.
Good point. Python at a much smaller scale is also unwittingly drawing people towards Lisp, and as you say creating the demand for that which CL supplies in spades.
> Lisp was ahead of its time and was a bit of a memory glutton. With 80gb > disks around, few begrudge a few megabytes any more. That's a major thing > all in itself.
> I don't know why you don't see any of these as positive unless you've just > been in one place for too long.
I guess those who have led the charge in vain for so long are entitled to a little battle fatigue. I've whined myself before about others' negativity, but hey, maybe this is a Good Thing. Someone comes to CLL and finds us engaged in honest self-scrutiny, not lockstep rah-rah CL evangelism.
What we need now are testimonials and advocacy not from the old guard but from the young tigers discovering now the oldest new language on the block. Especially folks who turned to Lisp /after/ doing good things in C/C++/Java/Python. I'm one of those (young only in that I have less than ten years Lisp experience), and Lispnyc has been joined by another. Here are some more data points:
[Anyone young or new to Lisp not already up there, plz add your story ASAP.]
A perhaps subtle point is that new Lispniks don't just like CL, they flip over it. And we know that that is not infatuation, that is simply an accurate assessment of CL's superiority.
With an edge like that, with obstacles like expensive RAM removed, and with the establishment in disarray ("C++! No, Java! Hang on, Perl! Wait, Python!") what can stop CL?
M$ stopped the Mac by providing (eventually) a similar-enuff GUI experience in a DOS sit-atop, aka Windows, sufficiently close that other barriers to switching sufficed to protect their monopoly. Will some current established player steal Lisp's thunder? With untyped variables, interactivity, macros, GFs, MI, specials, while being compiled and stable and backed by an ANSI standard? I can't think of one.
--
kenny tilton clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "Everything is a cell." -- Alan Kay
A minor nitpick on one of the most interesting threads in a while...
> Users complaining about low cost options were met with free(as in beer) > versions of LispWorks and Allegro, and numerous free(as in gnu) other > whole implementations.
Please don't lump all the free implementations into the gnu camp. CMUCL is 90% public domain, 10% BSD'ish--in fact, people have taken the entire implementation and commercialized it: http://www.scieneer.com. "Free (as in gnu)" sounds to me like "Free (as in Cuba)"...
In article <3EB9946B.3030...@nyc.rr.com>, Kenny Tilton <ktil...@nyc.rr.com> wrote:
> A perhaps subtle point is that new Lispniks don't just like CL, they > flip over it. And we know that that is not infatuation, that is simply > an accurate assessment of CL's superiority.
Yesss - and they also work behind the scenes to do something about increasing the popularity of Common Lisp. I also agree with Kenny that the scrutiny the community applies to its language is a good thing. We learn a lot from discussions about, for example, new proposals for special variables. The question whether Common Lisp still lives up to its promise is a legitimate one, and it's a good idea that we learn about some arguments that we can use in discussions outside of c.l.l.
> With an edge like that, with obstacles like expensive RAM removed, and > with the establishment in disarray ("C++! No, Java! Hang on, Perl! Wait, > Python!") what can stop CL?
exactly
> M$ stopped the Mac by providing (eventually) a similar-enuff GUI > experience in a DOS sit-atop, aka Windows, sufficiently close that other > barriers to switching sufficed to protect their monopoly. Will some > current established player steal Lisp's thunder? With untyped variables, > interactivity, macros, GFs, MI, specials, while being compiled and > stable and backed by an ANSI standard? I can't think of one.
::: : 2003-05-03 - Yes, Bob, I too want to work in a dynamically typed language : Bob Martin's post on statically typed languages reminds me of both Chris' and my own migration from the C++ view of typing to a less static view of the world.
: I agree with Bob that having language support for dynamic typing is a real boon to productivity.
: I'm not so sure that test driven development (TDD) is the only tool for making dynamic typing "industrial strength." I think we (the industry that is) can do more if/when enough people wake up from the Java-induced haze.
: Maybe Bob should come up to Redmond and help us out! :::
As far as I understand this is mainly an effect of the popularity of Extreme Programming.
So let me dream a little: In a year, or so, Microsoft has extended .NET in a way that Smalltalk can be fully implemented on top of it. Since Apple always tries to stay ahead of its competition in technological terms, they will buy Digitool and make Macintosh Common Lisp their answer to MS Smalltalk. Then everybody can buy an Apple PowerBook including a full Common Lisp implementation with a Cocoa bridge, and have the coolest machine that ever existed on this planet! ;-)
Pascal Costanza wrote: > There are some signs that surprising things may happen. For example, Don > Box (an influential guy in the Microsoft world, AFAIK) has started to > like dynamic typing. Here is a quote from his weblog at http://www.gotdotnet.com/team/dbox/default.aspx#nn2003-05-03T11:15:53Z
Nice find! I followed it to the article to which /he/ was reacting:
" I've been a statically typed bigot for quite a few years....When C++ came out, I was an avid adopter, and rabid enforcer of strong typing. I scoffed at the smalltalkers who whined about the loss of flexibility. ...
"Four years ago I got involved with Extreme Programming. ....
"About two years ago I noticed something. I was depending less and less on the type system for safety. My unit tests were preventing me from making type errors. ...
"... So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose. ...
"I also realized that the flexibility of dynamically typed langauges makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler.
"Now I am back programming in Java because the projects I'm working on call for it. But I can't deny that I feel the tug of the dynamically typed languages. I wish I was programming in Ruby or Python, or even Smalltalk.
"... Will we all be programming in a dynamically typed language in 2010?"
Check out the full article, then check out the responses. Wow.
Wow #2 is that Lisp does not get mentioned (until very recently <g>), tho someone did provide a link to Graham's 100yr piece.
--
kenny tilton clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "Everything is a cell." -- Alan Kay
> > > I also think the community is not determined by who shows up and > > > says "serve me". I think the community determined by who the > > > language designers say they seek to serve.
> > Franz, Harlequin, Digitool and Hypermeta have all accepted my money > > at one time or another.
> (Note, though, that the work HyperMeta is doing for you is not > exactly "programming in CL", certainly not 'per se'. Rather, speaking > loosely, we are working with you as you explore non-CL-ish alternatives. > So mention of us is perhaps a bad example.)
I'm just going by your definition. You said that the community is defined by "who the language designers say they seek to serve." You are one of the language designers and you have sought to serve me. (Well, actually I sought you out, but you agreed to serve me.) That makes me a member of the community on the definition you gave.
In fact, I can only think of two definitions that would exclude me from the Common Lisp community: a requirement that one be currently programming in CL, or a requirement that one refrain from advocating changes to the standard. (And on the latter view, I am no longer advocating changes to the standard so I hope you'll have me back :-)
> Also, and importantly, I'm NOT trying to make you feel like an outcast > personally.
That may not be your intent, but you are having that effect. Using phrases like "the language was designed to protect itself against people like you" doesn't exactly make me feel welcome. I understand what you were trying to convey (I think) but you took me to task for the damage I've done for putting negative spins on things. That train runs both ways.
> I'm making serious suggestions that I think would make > you happier. I'm trying to merely explain why people are not rushing > to cater to you.
Making suggestions and explaining are two very different things. The only suggestions I remember hearing from you in this discussion is that I go use Scheme, which again could be interpreted as a thinly veiled, "Get lost. You are not welcome here."
> It's a business decision. Yes, those companies > (including mine) have taken your money, but that doesn't mean those > companies have committed to going your way.
Of course not. All I expected was a respectful hearing.
> That is, you might read my remarks as hypocritical because I have both > suggested you're not part of the market and I've taken your money.
Indeed.
> Another way to read it, though, is that I am doubly serious. Because > I am risking receiving no further money from you in order to make my > point.
FWIW, nothing you have said in this thread has had any negative impact on my desires to work with you in the future. (In fact I appreciate your candor.)
> If you understood how empty my > bank account was right now, you'd understand just how seriously that > means I feel what I am saying.
Your sincerity was never in doubt.
> Look, a lot of friends come to me with personal troubles.
I don't know what prompted you to say that, but these aren't personal troubles, they are professional troubles, and I am not your friend (which is not to say that I wouldn't like to be, but we hardly know each other, and you haven't been particularly friendly). I am your customer, perhaps your colleague if I may be so bold. And you don't know me. At best you know my usenet persona.
> I know you think you like CL, but > there are cues all over everything you write that say you are unhappy > with it. You want it to be what it is not.
You are absolutely wrong about this.
> I do think that with all the energy you spend on the things you do take > up, that you could be doing more good in other ways.
Well, I'm not really spending all that much energy on this. But I am and always have been open to suggestions. (And please don't suggest that I go use Scheme. I don't want to use Scheme. T maybe, but not Scheme.)
> I believe ANY change to the standard will cost "lost millions". After > that, the incremental cost of change will be less.
> You have expressed the view that there is a desire not to make change. > That's right. For exactly that reason.
Your argument applies only to non-backwards-compatible changes. Backwards-compatible changes do not incur this cost. And a blind resistance to change irresepective of whether or not they are backwards-compatible and irresepctive of any potential benefits also has a cost.
[Snip]
> I don't know why you don't see any of these as positive unless you've just > been in one place for too long.
All of this sounds very positive, and a lot of it is news to me. From where I sit the situation seems much bleaker (and has for some years now).
But what you tell me is encouraging. I am reassessing my position in light of this new information.
g...@jpl.nasa.gov (Erann Gat) writes: > In article <sfwk7d28rbw....@shell01.TheWorld.com>, Kent M Pitman > <pit...@world.std.com> wrote:
> > I believe ANY change to the standard will cost "lost millions". After > > that, the incremental cost of change will be less.
> > You have expressed the view that there is a desire not to make change. > > That's right. For exactly that reason.
> Your argument applies only to non-backwards-compatible changes. > Backwards-compatible changes do not incur this cost.
Backwards-compatible changes do not require change at all. Extensions can be added as layers. Being monotonic in nature, they are by definition not changes.
> And a blind resistance to change irresepective of whether or not > they are backwards-compatible and irresepctive of any potential > benefits also has a cost.
My resistence is not blind. I at no time have said "the standard must never be changed". I have said that the cost is very high and that the need must be equally high in order to justify it.
Btw, there is an additional cost. Opening the standard to change is _not_ a controlled process. It would be a free-for-all. You expect that somehow if changes were made, they'd all be ok with you. But many things you _like_ might change, too. Change due to open design is not a predictable process.
The best advice I ever heard on this came from an attendee of X3J13 from (then) NBS (now NIST), who said that standards processes are not design processes and you must not confuse the two. You want come to the table with something nearly right and propose it for adoption only when you're pretty sure it's going to be accepted "as is" or close to it. We simply got lucky in the ANSI CL process that we did not wreck the language.
When I say "go design your own language" I am not trying to be mean nor tell you to get lost. I am saying "this is the intended way". Only a completed and tested design should be accepted for moving forward. Because it can be evaluated in its entirety. If you bring in a half-done thing and think a committee can fix it, you're deluding yourself. What is needed is a single-minded vision of where to go. That's not a guarantee the community will accept it, but it's the minimal requirement for the community considering it (IMO).
Left to their own devices, everyone will want to dabble. And that's just dangerous. Everyone wants to leave their mark. Everyone has a hobby horse. And everyone, because of much deployed code, is now conscious of how any change will affect them personally.
They say for this same reasons it's a _bad_ idea to have a second constitutional convention in the US. Not that it's not easy to come up with a reason why some changes would improve things--but because getting the good changes that the process might offer is not guaranteed. Simply opening a democratic process does not guarantee an outcome.
I watched in unsurprised horror a few years back when the Libertarian party was having a meeting and wanted to break for lunch. Some wanted a 30 minute lunch and some a 45 minute lunch. Before they knew it, someone had invoked parliamentary process and it took more than 15 minutes to resolve the matter. (I don't even remember which way it came out, but you see the problem.) Once the process had begun, everyone could see that it was doomed to lose, but respect for process meant they were all obliged to stand there and suffer through it. Because to admit that process could be avoided by simple application of fiat was a dangerous precedent. The moral? Keep things informal as long as you can...
Gabe Garza <g_ga...@ix.netcom.com> writes: > Kent M Pitman <pit...@world.std.com> writes:
> A minor nitpick on one of the most interesting threads in a while...
> > Users complaining about low cost options were met with free(as in beer) > > versions of LispWorks and Allegro, and numerous free(as in gnu) other > > whole implementations.
> Please don't lump all the free implementations into the gnu camp. > CMUCL is 90% public domain, 10% BSD'ish--in fact, people have taken > the entire implementation and commercialized it: > http://www.scieneer.com. "Free (as in gnu)" sounds to me like "Free > (as in Cuba)"...
Ah. I didn't mean to do that. To be honest, I didn't know the facts you're citing, so I appreciate the correction... and I'm very happy to hear there's diversity in this regard.
g...@jpl.nasa.gov (Erann Gat) writes: > > In fact, I think lisp is in a better position than ever. I've used > > common lisp for 'business critical' server applications for 4 years
> Would you be willing to make some details of your experience available so > the rest of us can cite your experience as a success story?
Sure. I presented a 'success story talk' on the server stuff I did for my previous employer on the ELUGMs in 1998 and 1999, and on the JLUGM-2000. You can download the paper from the JLUGM proceedings page:
Pascal Costanza <costa...@web.de> writes: > Since > Apple always tries to stay ahead of its competition in technological > terms, they will buy Digitool and make Macintosh Common Lisp their > answer to MS Smalltalk.
then Apple would have to admit that they were terribly wrong when they closed down MCL and their other lisp activites years ago... -- (espen)
t...@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> But it's been quite possible to run Lisp > in more memory-starved situations. From "Getting Started with MCL":
Don't tell me: 12 years ago I programmed computational linguistics software in MCL on a Mac SE (8Mhz 68k) with only 2,5 MB RAM (in total!)- and it wasn't painful at all! I deliberately said 'most lisp implementations', and the exception I had in mind was MCL.
> 6. You folks (cll) aren't nice to newbies. (This year things have > gotten notably better)
Hmm. I wonder how long this works out. Without Erik filtering out trolls by exposing them I already see that I have to do more work myself scoring the threads.
> > 6. You folks (cll) aren't nice to newbies. (This year things have > > gotten notably better)
> Hmm. I wonder how long this works out. Without Erik filtering out trolls > by exposing them I already see that I have to do more work myself scoring > the threads.
