Subject: Re: What obstacles do Common Lisp programmers face?
From: Erik Naggum <erik@naggum.net>
Date: Sat, 12 Jan 2002 00:16:40 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3219783396565211@naggum.net>

* cubicle584@mailandnews.com (Software Scavenger)
| In the past most of us used other programming languages, and usually poor
| implementations of those languages.  We spent vast portions of our time
| fighting bugs and limitations in our programming languages and
| development environments.  It seemed like those obstacles were the main
| reasons why we didn't get our work done almost as soon as it was assigned
| to us.  Even those who used Common Lisp in the past faced obstacles of
| imperfect implementations and weak hardware.  But now those obstacles are
| gone, and we can all proceed full speed with Common Lisp on modern
| hardware.

  Really?  Which is the fully conforming, bug-free implementation of ANSI
  X3.226-1994 Common Lisp?  I keep finding annoying discrepncies all the
  time, leading me to believe it is safe to depend only on a small subset
  of Common Lisp unless you install a direct line to your vendor's support
  department _and_ you get their attention when you say "conformance", the
  one word which leads some of them to ignore your bug report completely if
  they can think up a work-around or another way to accomplish your goal,
  but that is precisely what I do _not_ want, as it means different ways of
  doing the same thing in different implementations when we have a single
  specification that the vendors purport to implement.

  If car manufacturers made cars according to spec the same way software
  vendors make software according to spec, all five wheels would be of
  widely differing sizes, it would take one person to steer and another to
  work the pedals and yet another to operate the user-friendly menu-driven
  dashboard, and if it would not drive straight ahead without a lot of
  effort, civil engineers would respond by building spiraling roads around
  each city.

  I know I am in the small minority that reads documentation and standards
  and the like, but the operational definition of "conformance" can be
  stated very simply: If you read about something in the standard or in an
  accurate textbook and you can trust that it is always your own fault if
  it does not work as expected, the system is fully conforming.  But this
  is predicated on people reading the standard or that someone has written
  similarly accurate textbooks and that readers of either pay attention to
  the details, are willing to _listen_ and _understand_

| Thus it seems that we should now get our work done the same hour we
| decide to do it.  If not, why not?  What obstacles do Common Lisp
| programmers still face, which make the work continue to take longer than
| that?

  The fact that writing robust Common Lisp code in the Common Lisp spirit
  still takes considerable effort.  Let me give an example.  Suppose you
  develop a socket interface and think it is of sufficiently high quality
  that you want to share it.  You could develop a class, service, that
  contained a host (with name, address family, address) and a port and a
  protocol (tcp or udp at this point), decide on a syntax and write
  functions to read and write objects of this class, and then include some
  easy-to-use designators like strings in this syntax, but internally, you
  always use your class.  You would therefore develop a solid framework to
  refer to network services instead of, say, just using integers for IP
  addresses and ports, and these more complex things would be the end
  points of your socket interface, rather than more or less magic integers.
  This would offer something substantial above the "everything is really a
  machine integer" view that C and Unix has foisted upon the world and
  would afford an abstraction that allows people to refer to these services
  uniformly regardless of changes in the underlying implementation, such as
  we face when transitioning from IPv4 to IPv6, which some socket code has
  made more than painful.  This would require some thought and more code,
  but it would produce a fully reusable piece of code, with a specification
  that would be worthy of standardization.

  But suppose instead you are the kind of engineer who really do not really
  believe in the value of Common Lisp, but just like its syntax while you
  still think in basic C terms and prefer meaningless integers instead of
  typed objects.  Then you would force the user to engage in a tremendous
  amount of silly work, just like you would in C, but maybe half as much
  just to be nice, to refer to and use, not to mention set up, a network
  service.  It would appear "nice" to those used to the bare-bones C stuff,
  but it would still suck relative to other Common Lisp functionality.
  This would take _much_ less time to write than Common Lisp standard-like
  functionality, and it may be "documented" enough to be useful for others,
  but it is not the kind of code you write specifications for.

  That is, you would be inclined to _re-implement_ something that was not
  written to specification quality rather than read the specification and
  use it as specified.  Lots of code is written like this in languages that
  have fairly bad specifications in themselves, communities that do not
  care much about their specifications in the first place, and whose code
  sharing traditions usually are at the "it works for me" level, but Common
  Lisp has a specification that sets a standard for what new contributions
  should look like, as well.  Good library design in C++ is said to be 25
  times more expensive and complex than a simple user-level implementation
  that should be thrown away and re-implemented the next time it is needed.
  I would estimate that good library design in Common Lisp is about 10
  times more expensive and complex than throw-away implementations, but
  that it is possible to make throw-away implementations "reusable" in
  Common Lisp with considerable effort, while it is not possible not in
  C++, so those who have not _designed_ for standard-library quality will
  think that additional libraries for Common Lisp need not be different
  from user code with documentation.  This, again, unfortunately means that
  the ability to use other people's code in Common Lisp is much lower than
  that in other languages -- ironically because the effort to create good
  code is so much lower than in other languages that the extra effort to
  design top-notch quality does not seem worth it to many.

///
--