Subject: Re: Query About Lisp Use
From: Erik Naggum <erik@naggum.net>
Date: Sun, 07 Oct 2001 20:26:30 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3211475185647471@naggum.net>

* "Wayd Wolf" <waydwolf@hot(spam)mail.com>
| 1. Where do you see Lisp as being put to best advantage in IT?

  Where (Common) Lisp programmers can prosper.

| 2. If you know of Ruby as well, how do you see it in comparison for areas
| of application?

  Languages often come with communities that collectively decide to solve
  certain problems.  I find it rather pointless to compare communities.
  The Common Lisp community has decided to solve and to not solve certain
  problems.  Some people seem to be very strongly dissatisfied with the
  choice of problems that the Common Lisp community has decided to solve.
  It is, however, clear that other communities have decided to solve more
  "modern" problems, meaning, in essence, that they retreat to a level that
  Common Lisp left 40 years ago and try to invent something better than the
  favorite point of reference: C.  The amount of energy poured into solving
  yet another set of problems caused by choosing C as the reference is very
  impressive, but you will often find that people who have been through it
  a couple of times are much less impressed with yet another new language
  with a only few new significant features over the prevailing crop is not
  worth the effort to create a whole new language and support infrastructure
  -- Common Lisp people seem to behave in a way that is akin to the Borg:
  they study the various new things that people do with interest and then
  find that it was eminently doable in Common Lisp all along and that they
  can use these new techniques if they think they need them.

  There is no application area for which I think Common Lisp is unsuited.
  There will, however, always be a number of areas that have a very low
  entry threshold with any particular tool-oriented development process,
  but application development never stops just over the threshold.  If you
  have any real business developing a new application, that first threshold
  frequently turns out to be a very serious problem.  The siren song of low
  thresholds cause people to choose the easiest of the choices confronting
  them at every junction.  Only if you have a pretty good idea where you
  are going and your grasp of the reality of real application development,
  will you be able to sum the threshold you know you will have to cross and
  choose one that is not the lowest at a particular point.  The Common Lisp
  community has done very little to present a low threshold at any junction
  that normal programmers are likely to meet, but once you cross the high
  threshold to Common Lisp, most programmers find that all other threshold
  become taller while the new thresholds in their Common Lisp world are so
  low as not to be perceived as thresholds, anymore.

| 3. What do you see as the best path to get on for a career using Lisp to
| a major extent, that is, what industry would it be best applied in?

  Excellent programming is about solving fundamental problems for people
  who did not konw they had them.  Common Lisp excels in this part of the
  application domain in any industry.  If you are really good at what you
  do and are not afraid to spend a _lot_ of time learning from people who
  are not programmers, Common Lisp will be the language of choice when you
  desire to build an advanced programming environment for any industry.
  
  That is to say, Common Lisp is currently, and may remain, unsuitable for
  "tinkering" with any particular "hot" industry.  E.g., people today think
  that application development will always involve the WWW and "optimized"
  tools for generating web pages.  This is wrong, but those who think they
  need to have super-easy access to web tools are likely not to think that
  Common Lisp can offer anything despite the very strong evidence of a much
  lower sustained average effort per new feature in an evolving Common Lisp
  system than in a comparable Perl or PHP or Ruby or whatever environment.

///