Subject: Re: On Lisp
From: Erik Naggum <erik@naggum.net>
Date: Sat, 08 Sep 2001 11:22:46 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3208936964863906@naggum.net>

* Mark Hulme-Jones
> Surely part of the point of having a standardised Common Lisp is that I
> can reasonably expect to change my vendor without having to change too
> much of my source code?

  Yes, of course, but only that which has been standardized!  This is why I
  want standardized features to be implemented fully everywhere, with no
  stupid exceptions and reluctance and bugs -- we iron out the standard
  part and then we move on to new things.  As long as vendors and othes
  retard the common acceptance of the standard and the common trust in its
  implementation, it is so incredibly hard to move on.  As long as someone
  can sit in a corner and whine about his pet conditional, that means that
  the bloody _conditionals_ are still an open issue and common agreement on
  sockets will have to put in a bid for resources along with such stupid
  and petty issues.

  The parts are _not_ standardized will have to just as implementation-
  dependent as people are willing to _accept_ elsewhere.  In fact, the
  reason C and C++ have grown to such successes is that there are lot of
  implementation-dependent features that come with all systems that use
  those languages.  C and Unix is a veritable treasure trove of special
  implementation details.  C++ and Windows have the same relationship.  If
  people had been whining "this is not in the ANSI standad", neither of
  these languages would have succeeded at all.

> A standard should mean that I differentiate between different vendors
> implementations based on factors like efficiency, the usability or the
> development environment or the quality of their customer service.

  Yes, of course, but only for the standardized language.  The rest of the
  environment you need to build real applications cannot actually be fully
  standardized.  Just look around for the other language standards, to see
  how _little_ they actully standardize.  Common Lisp standardizes so much
  more than most other languages.  I refuse to consider the possibility
  that its high quality has turned Common Lisp programmers into spoiled,
  demanding brats, but some people make it so damn hard to stand fast on
  this refusal.

> With Perl or Python I'd have to settle for what I get.

  In practice, you have to settle for what you get in the Common Lisp
  implementations, too, but for some reason, it is acceptable to be unhappy
  about it.  The only part we have good reason _not_ to be satisfied with,
  is lack of conformance.  If somebody wants to sell me a Common Lisp
  system, they had better live up to their claims, but I _choose_ them
  because of the extra-standard features.  That is the point of having a
  standard -- both the specification and conformance should become a
  non-issue.

> For widely-used features like sockets and perhaps regexps, a standard is
> going to do much more good than harm, much as the CLIM does for user
> interfaces.

  Well, if you think so, why have you not submitted a specification to the
  committee?

> Non-adherence to such standards would make or break my choice of
> implementation, giving vendors an added incentive to co-operate.

  Real standards turn an issue into a non-issue.  You just use whatever is
  standardized.  The fewer questions are asked about the legitimacy of a
  standard, the more successful it is.  If you get a socket implementation
  that you have to fight when you need system-dependent socket options,
  have you really gained anything?  (Java sockets are fairly crippled in
  this regard.)

> It's just a question of which features you consider 'commoditised' enough
> to require a definition that vendors should follow.  For CL this means
> things like hash tables, vectors, structs and classes.  All I'm saying is
> that it would be even better if Regexps and Sockets were included too.

  I hate regular expressions.  Not because they are not powerful tools, but
  because they are too powerful tools, and everybody who makes a regular
  expression matcher has a different idea what kind of weird features
  should go in the regular expression syntax, with no way for users to
  extend this functionality without switching to a different regular
  expression package.  I want to stop this cramming of features into the
  syntax and get a real pattern-matching _language_ that I can deal with at
  a much higher level than this character-by-character limitation that all
  regular expression packackes I have seen enforce.  If regular expressions
  are such a boon to mankind why are they not built for sequences of all
  sorts of objects?  I mean, the standard function search does that.

> If by 'standard' you mean a written standard like that for ANSI CL, then
> basically none, and I consider this to be a problem (though when and if
> Microsoft's submission of C# and it's libraries gets standardised by the
> ECMA there might be one).  If on the other hand you mean a de-facto
> standard, like that dictated by Sun for Java or the implementors of
> languages like Rebol, Ruby and Python, then quite a few.

  By "standard" I mean a document that implementations are required to
  adhere to and which people other than the implementors have a say in
  developing.  If that document is documentation for an implementation, it
  is just that, not a standard.  There are many kinds of standards, but
  they have _one_ important thing in common: they are _specifications_.

  If a "de facto standard" has no specification that it can be held up to,
  I think it is a misuse of the term.

> Unfortunately many, many others do not agree with me, and are prepared to
> settle for de-facto standards like Java instead.  Creating a written
> standard for APIs/implementation of important new features could
> conceivably boost the attractiveness of CL in many people's eyes.
> Provided that attracting more users of the language is what one is trying
> to achieve, of course.

  Yes, standards are marketing tools, too, but if they become too much of
  that, they are generally quite horrible as specifications for people who
  are supposed to implement them faithfully.

  However, nothing stops you from implementing a Common Sockets library
  that takes care of presenting a common interface to the various ways
  people have implemented these things.  If you want this, build it.

> I'm not trying to hold Common Lisp to a different standard.  Perhaps what
> I'm really saying is that if you want to make sure that people realise
> how much better a standardised CL is than a de-facto standard like Java,
> you'd better make sure that CL includes standardised ways of doing the
> things that people want to do.

  You need an authority that people are willing to respect in order to get
  to this point.  When vocal forces in the community cannot even respect an
  authority on the conditionals, arguably the most important part of the
  language, forget any chance of respecting an authority on sockets.

  When some people stick to their legacy ways in numerous trivial areas
  when they could not get them into the standard and refuse to accept the
  standard and change their ways in the community interest, there is no
  reason to expect them to respect something as complex as a socket
  interface.  This is the insidiously infectious effect of quarreling over
  features in the standard.  Psychologically, whoever wants to spend any
  time and money standardizing new things when grumpy and bitter old farts
  at the vendors express a very strong disdain for the work you do even
  before you have started?

///