From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Promoting CL Was: What I want from my Common Lisp vendor and the Common Lisp community References: <3208226254834485@naggum.net> <867kvke4iz.fsf@gondolin.local.net> <3208254606019619@naggum.net> <1f4c5c5c.0108311044.2399e124@posting.google.com> <1f4c5c5c.0108312034.1b1e140a@posting.google.com> <1f4c5c5c.0109011022.72a56a2b@posting.google.com> <1f4c5c5c.0109012324.43d24c7@posting.google.com> <3208404998010473@naggum.net> <87itf1a2fh.fsf_-_@piracy.red-bean.com> <99fb3972.0109021504.bba92d0@posting.google.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3208475381413624@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 200 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Sep 2001 03:09:48 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 999486588 193.71.66.49 (Mon, 03 Sep 2001 05:09:48 MET DST) NNTP-Posting-Date: Mon, 03 Sep 2001 05:09:48 MET DST Xref: archiver1.google.com comp.lang.lisp:15427 * Erann Gat > However, let's remember how this whole thing started: it began when John > Foderaro expressed his dislike of the Loop macro in some pretty uncertain > terms. When will it dawn on you sluggards that it is not the macros that are the issue? John Foderaro expresses a very strong hatred for the standard as such, and the standardization process in particular. This undermines the whole _legitimacy_ of Common Lisp qua language, and he's doing this as a representative of a vendor who claims to produce a conforming Common Lisp implementation. I am _amazed_ that the people who regard his behavior as excusable have to excuse some silly little trivialty. There is a marked difference between being personally opposed to abortion and working to overturn Roe vs Wade. If you are working for an abortion clinic and you post "private" arguments that could _really_ help those who want to overturn Roe vs Wade, do you expect anyone to consider any _lesser_ issues than the biggest possible and most damaging issue? Well, only if you expect people to be really stupid or you are manipulating the issues so it looks like a harmless non-issue to people you do not want to care. Nobody, and I mean _nobody_, cares what John Foderaro's personal opinion on the loop macro is, or the if/when/unless nonsense he only hurts himself by ranting so abjectly and manifestly _irrationally_ about, but when he is arguing that people have to do so much stuff outside the standard, anyway, that it does not matter whether they use non-standard stuff, and he argues very strongly that it is _bad_ that the committee is guilty of a bunch of _compromises_, he is arguing against the community concensus-shaping process, and promises that he will _not_ lay issues to rest, but continue to fight for his way forever, which only destabilizes the community and never lets us move on, to, say, standardize more stuff. Since you suffer from the exact same "can't get over this"-syndrome, Erann Gat, you probably do not see this is the mark of a lunatic, but that is what it is, and that lunatic is a central figure at a Common Lisp vendor. That is the damage he is doing. That damage cannot be undone by "success stories" or any trivialties. Undermining the legitimacy of a standard is not met with "but I did good with it". That is no more a valid argument than quipping "but it felt good" about a drug that the FDA revokes from the market. > You must be confusing me with someone else. All I'm asking for is for > people to stop bashing everyone who says something negative about Lisp > over the head, and instead put that energy into publicizing how Lisp > helped them win. Is that asking for considerable changes in reality? As usual, you argue as if you have _zero_ clue what is at stake. Why? Is it because you so adamantly refuse to show that you understand an issue _I_ raise? I have my doubts that you do not _actually_ fail to understand the issues involved here. You are far too sinister for that. > The wall I always ran up against was the question: "Who uses it?" The > answer to that question for C++, Java and Perl is: everyone. As long as you think in those terms, you have set yourself up to lose. Nobody can help you when the reality you live in is not sufficient for you to form your opinions. "Everyone"!? What is _wrong_ with you? > What's the answer for Lisp? You clearly imply that success stories do not work, and that one more would not help. The critical mass that you are obviously looking for does not exist, cannot exist. We simply do not have the infrastructure to support it in the Common Lisp community. Cities that expand have to cope with water, electricity, sewage, roads, telecoms, law enforcement, health care, etc, before they can let people move in, and politicians and civil engineers know how complicated and costly this is. Even the most rabid liberatarians understand that this infrastructure has to be in place and that everybody who live in that society has to help pay for it. To make this kind of infrastructure-building work, you need both a large tax base and the ability to borrow _vast_ amounts of money. The same is true of a user community that grows to be very large -- it has to devote a good chunk of its profits to building and maintaing its infrastructure. Microsoft has figured this out, and they build the infrastructure _first_ these days. Sun figured it out with Java, too, and the spent a godawful lot of money on building the infrastructure before anyone even saw Java. The XML crowd has done the same thing with more politics and manipulation than most people are willing to think about. The Common Lisp community does not make enough profit to grow enough to fund its own infrastructure and it has insufficient volunteer effort to help build it. Therefore, Common Lisp must of necessity confine itself to a growth pattern that is completely incompatible with your fake desire to see it used sufficiently for "people use it" to be a self-propelling and self-fulfilling argument. We are at a point in the Common Lisp community where only those who think Common Lisp is truly great both for personal and professional reasons are _likely_ to use it. Just pointing to others will _necessarily_ have to answer the question _why_ they used Common Lisp. That cannot be a silly deferred answer like "oh, somebody else also used Common Lisp" because we simply do not have the automatic credibility of critical mass. This is why it hurts Common Lisp to have people tell stories about why they do _not_ use Common Lisp, why they hate or dislike Common Lisp, but more importantly, why they do not think a standard is a even good idea. Again, just to reiterate this point: There is a huge difference between saying that the standard is solving only part of the whole problem (of building an application) and saying that the standard is _not_ solving a part of the problem (of being a complete programming language). If you argue that the standard set of conditionals are _bogus_ and should not be used, you are undermining the _usability_ of the standard qua standard. If you argue that some construct in the standard should be avoided "like the plauge", that is not a statement about the macro, it is a statement about the trust in the stamp of approval that a standard is supposed to have: the process that created that standard managed to include something that is "like the plague". How can you possibly trust the _rest_ of it when it has let something like that in? And let us not forget the case issue. The standard is more than _wrong_, according to the same voice, for using upper-case symbol names. The whole point with a standard is that it be the basis for our ability to cooperate on _other_ things. It is not unlike accepting the outcome of an election instead of bringing legal action against the election process -- if you communicate to the electorate that you do not trust the process after you lost, you do not challenge just the specific outcome, you challenge the concept of holding an election to determine a whole class of outcomes. If you really wanted to improve the election process, you would _not_ have sued to alter the outcome, but would have respected the outcome whatever it was under the current set of rules and practices, and fought for changes independently. What I want the Common Lisp community to tell every newcomer and every vendor of a (purportedly) conforming product to tell every customer is that Common Lisp the Standard is not only good enough, it _does_ work as the basis for cooperation on other things we want to accomplish. It is massively unproductive to argue against the standard unless you are doing so in the context of the standards process -- because just by doing so, you are saying that the standard is both _unfinished_ and _unsuitable_ to base further work on. Those who cannot put their lost fights behind them and move on, are keeping _everyone_ back. The inability of some people to move on has been marring the Common Lisp community forever, and from my long and considerable experience with standardization processes (ISO, IETF, ANSI, national), I have to say that the willingness of some members of the standards committee for Common Lisp to respect the process and the reults of its votes is far lower than in any other process I have been part of or whose work I have tracked. This is reflected in the lagging implementation of conforming Common Lisp systems, too. From what I have seen of the existing implementations, conformance is basically a non-issue compared to the rest of the work that it necessary to make a system work, provided that you start off with a working system, and GCL, CMUCL, CLISP, and a few others have a working system. Moreover, it is _not_ conformance that should set the vendors apart. They should _all_ conform. This leads to a pretty interesting situation in that we all know that a lot of the standard functionality in Common Lisp can be expressed with other standard functionality. It _should_ therefore be possible to implement what some call a "core" Common Lisp and then use a free implementation of the rest of the language on top of that core to get a first approximation to a conforming Common Lisp system. Then, as you need better _performance_, not _conformance_, you implement more "native" support for things that turn out to be slow. This should make the difference in cost of implementation of a non-conforming and a conforming implementation close to zero, and free systems that today lack full conformance are prime candidates for working _together_ on this to save considerable time. In order for people to want to base their investments, time or money, in Common Lisp, they need to _know_ that the standard will be supported. The reason people clamor for other features to be standardized before they are willing to do any work in Common Lisp is precisely the same: The very lack of standardization introduces a higher risk of failure: What if your chosen platform is not suitable by your users? This is the same issue as building and releasing a Linux version of a Common Lisp system when you are uncertain what signal management your users will be using, or worse, suppose you want to make it available for the very popular IA32 (80x86), and you think Windows must be it, but _all_ your users hate Microsoft, yet cannot agree on which OS to use instead. This is the kind of risk Common Lisp users are facing today, and they are not only facing it with non-standard extensions, they are facing it with _standard_ features and facilities. This is the really intolerable part. And while Paul Graham whines unproductively about the lack of a tight OS interface in Common Lisp compared to Perl (is he clueless? it is a language _defined_ independently of operating systems -- Perl was married to its operating systems (Unix) from the start, and only managed to make a more abstract interface late in its development, such that it can be used under Windows), the obvious solution is to figure out what Perl did right in this department and provide similar operating system interfaces. Common Lisp does not need to be changed for this -- we just add at least one package with solid, native Unix support. However, this is just the kind of infrastructure work I alluded to above. Like, can we use foreign function interface definition _builders_ that produce FFI glue for each of the existing implementations such that we can feed it ANSI C header files and get back implementation-dependent FFI declarations, instead of having to agree on the FFI code itself? That would come a long way to obviate the need for humans to write FFI glue. Can we afford to do this? When I read Erann Gat's rather vacuous "but people do not use it" whine and implicitly invite lots of people to the great new Common Lisp City, he does so without recognizing the need for water, electricity, sewage, roads, telecoms, law enforcement, health care, etc, to be in place. I believe we can get people to help build that stuff if and only if they believe enough in the place they are going to move to, and that belief is based in a strong desire to see some of your values realized. I call it love for your language. If Erann Gat wants to bicker over "love" versus "some other motivation", let him bicker. It is all he does these days, anyway, regardless of _past_ merits. > A recent query to this newsgroup asking people what they used Lisp for > garnered only a *single* response. Why? It's certainly not for lack of > participation in the newsgroup as a whole. Was it you who asked? ///