« prev · plain text · next »       2001 · Erik Naggum comp.lang.lisp archive       search · random

Subject: Re: Promoting CL Was: What I want from my Common Lisp vendor and the Common Lisp community
From: Erik Naggum <erik@naggum.net>
Date: Mon, 03 Sep 2001 03:09:48 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3208475381413624@naggum.net>

* 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?

///