Subject: Re: (not really about) MCL
From: Erik Naggum <>
Date: 1998/03/08
Newsgroups: comp.lang.lisp
Message-ID: <>

* Raymond Laning <>
| I am curious why there is such pressure to enforce tool choices - with
| the adoption of CORBA and/or ActiveX, and Lisp vendor support of such
| standards, why should a particular application be concerned with which
| language it is written in, apart from its suitability to the task at
| hand?

  in brief: the blue-collarization of programming.  managers don't need
  _programmers_, anymore, they need coders, lots of them.  programming is
  not an art, it's just skilled labor.  lots of coders sitting at an
  assembly line putting together some bulky, crappy application in C/C++ is
  cheap, easy to manage, and fits right in with how MBAs have learned to
  run factories.

| BTW, I wrote an application in ACL for a PC - my client was very nervous
| because "Lisp is slow, a memory hog, yada, yada, yada."  My initial
| software package was as he feared - it took 7 minutes to process a 6 MB
| file, but when I spent two weeks doing memory management and strong data
| typing, that time fell to 40 seconds - a time that would have been
| considered fast in C/C++.  My point here is not to toot my own horn, but
| to point out that Lisp should be able to hold its own in the market place
| if it is evaluated on its merits, not on someone's prejudice.

  this parallels my experience.  initial cuts on solutions are developed
  fast, run slow, and allow the customer (or the developer) to assess the
  various designs and approaches.  then I profile, rewrite, and shine the
  code up, and it runs faster than the dumb C code some cheap labor would
  have written.  at lower costs.  of course, some management gets nervous
  just because the development cycle is different from that of C/C++ -- and
  there are usually enough unknowns in the development process already to
  give anybody good reason to be nervous, especially since it's no fun to
  do what already has a known, simple solution.

  there _are_ managers out there who care more about the results than about
  being control freaks and reducing irrelevant uncertainty factors, but
  they aren't in the majority.  the majority optimize for costs and time
  schedules prematurely.  come to think of it, that's just what C/C++
  programmers do, too...  I guess they deserve each other.  :)

  God grant me serenity to accept the code I cannot change,
  courage to change the code I can, and wisdom to know the difference.