Subject: Re: Java is really convenient. Re: Sun thinks about switching Java 	 to S-expression syntax: Lava
From: Erik Naggum <>
Date: 1999/02/17
Newsgroups: comp.lang.lisp
Message-ID: <>

* (Christopher R. Barry)
| The specification for C's "int" and CL's "FIXNUM" are virtually identical.

  I'm baffled.  have you _read_ the specifications?  a fixnum is simply a
  more efficient integer, and some implementation-defined limits are less
  than or equal to MOST-POSITIVE-FIXNUM, but you have know your compiler
  real well before (+ fixnum fixnum) does not cause a bignum when needed.
  what, precisely, is you gripe with the size of FIXNUM, anyway?  methinks
  you just have a fixation that you're trying blame Common Lisp for.

| > | Why can't Lisp become more popular?
| > 
| >   why can't opera be more popular?  why can't football be less popular?
| I think your analogy is not the most suitable one. I think using Lisp
| over C or Java boils down to more than just personal taste and factors
| analogous to your analogy.

  my point was that you ask a useless question that has no useful answer.
  it is rare that you can explain why something is popular at any given
  time.  (and "marketing" begets the question "why did it work?", which all
  marketing people will tell you is not something you sit down and predict.)

| > | What's stopping it?
| > 
| >   people like you.
| Okay, what can I realistically do to make it more popular?

  you can stop posting drivel and actually go read the specification and
  ask questions instead of posting wrong answers to questions people don't
  ask.  you see, people are _detracted_ from a gravitation towards Lisp as
  they gain experience in their field and want self-improvement.  this is
  not at all the path you get if you ask about or measure popularity.

| Has anyone done this already?  Can I download a pre-done layer of
| documented macro definitions from somewhere that will at least work
| across CMUCL and Allegro CL?  If I have to do it myself, not a huge deal
| as long as I only do it for functions I use and not everything, but
| standardization just makes it *that* much easier.

  I think your doing it yourself is a valuable exercise in understanding
  (1) how this stuff should have been implemented, (2) the effort that goes
  into standardization, and (3) the effort that goes into sharing quality
  code with other people.  maybe then you will realize what you're asking
  for when you want everything for free.

| A little while back before my homework caught up with me I actually kinda
| started to work on making a uniform interface between the ext: and excl:
| file operation functions of Allegro and CMU Common Lisp which provide a
| lot of the same functionality so that I could write some intelligent
| Debian package management utilities for my personal use to make up for
| where Apt and dpkg don't get it right for my purposes.  I don't want to
| commit to using only CMUCL or Allegro CL for this or anything else just
| yet.

  this at least explains your problems.  what you're doing is a waste of
  time, although the purpose and goal is clear, so consider this: what you
  sit down and design because CMUCL and Allegro CL do not agree on some
  interface design is something you barely know how works and what you will
  actually need from it once it does work.  once it works well enough for
  you to build something on top of, you will need to redesign it after you
  have started to build something.  only if you chose one implementation
  and got enough stuff working to start feeding data back into the design
  process can you hope to get the design right.  what you're doign is
  premature abstraction without an actual purpose or goal.  "to make it
  work in both Allegro CL and CMUCL" should not be a goal, it should fall
  out your efforts as a result.

| It's just *that* much more of an (IMO) unnecessary inconvenience.

  programming is all _about_ "unnecessary inconveniences", and every step
  of progress tries to reduce their number.  that's why good programmers
  choose languages that have less unnecessary inconveniences than other
  languages, but if you think you can avoid unnecessary inconveniences, I
  think you should consider death and taxation first.

| Wasn't the whole point of Common Lisp that a lot of implementations were
| providing largely equivalent functionality with a slightly different
| interface?

  yes, historically, this was the motivation for the standardization, as it
  is with most good standardization, incidentally.

| Everyone does sockets and threads these days and a lot of the extension
| functions across implementations do almost the exact same stuff.

  also true, but standards are basically removing functionality from the
  market.  the issue changes from "do you support FOO" to "do you conform
  to the specification of FOO".  the former is a feature if true, but
  otherwise draws a blank.  the latter draws a blank if true, and is
  otherwise a reportable bug.  to make standards work, all vendors must
  agree to stop considering their features features, and start viewing them
  as requirements.  incidentally, this process parallels your Java vs CL
  attitude: you argue against CL because you regard features in Java as
  requirements of CL.  this is, to put it mildly, hopelessly naive.

| Are there any large, sophisticated, real-world apps that are written
| these days in CL that don't do threads?

  I cannot imagine otherwise.  why do you?

| I should mention that CL-HTTP includes a lot of functions and macros that
| unite some of the extension features found in all the CLs and I've found
| it very useful and it's saved me a lot of time already.  It was obviously
| a lot of work to put all of that together and it would be nice if this
| stuff could just always be relied upon to be there.

  well, you have the CL-HTTP sources, and it is apparently not a problem
  for you that you cannot use it commercially (which was a gripe you had
  with Common Lisp implementations, so I have a minor problem understanding
  what your actual and real concerns are).