From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date: 2000/04/25
Message-ID: <3165647335532305@naggum.no>#1/1
X-Deja-AN: 615413191
References: <390371F0.36455F4E@makif.omer.k12.il>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 956659431 8588 195.0.192.66 (25 Apr 2000 10:43:51 GMT)
Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
Mime-Version: 1.0
NNTP-Posting-Date: 25 Apr 2000 10:43:51 GMT
Newsgroups: comp.lang.lisp

* Peaker <peaker@makif.omer.k12.il>
| I have been thinking a lot about language design lately.

  it is important to have an explicit goal when thinking about language
  design.  your goal seems implicit, given that you don't mention it at
  all.  could you talk a little bit about what you want to accomplish?

| This has made me doubt the real necessity of macros, as they always seem
| to cover up for one or another language deficiency.

  yes, that's what they do.  the problem is, however, that _solving_ all
  those deficiencies is impossible, and without macros, they would merely
  be visible deficiencies, instead of covered-up deficiencies.  now, macros
  may cover up deficiencies so well that it would take an inordinate amount
  of deconstructionism to find the deficiency, but I take this as evidence
  that "cover up" is misapplied: the deficiency no longer _exists_ because
  of the macro solution.

  in short, macros are about building languages.  _any_ such facility would
  be messy if it were able to do its job well, and it would only be "neat"
  if it were able to build things people had thought of while designing it.
  trust me on this: we don't want that.

  the core problem I sense in your approach to your language design has
  been discussed at times, but seldom directly, so I'll summarize my
  position on it and see if you recognize it: (Common) Lisp is such an
  obviously elegant solution to the programming language problem that when
  people look carefully at it, they get disappointed by warts and spots
  with a rough finish, and then they start to think about how the language
  would be if it were _all_ elegant.  other languages are equally obvious
  inelegant solutions to the programming language problem, and individual
  features are hailed as elegant (or "cool hacks") when discovered, which
  means that digging deeper uncovers isolated inelegances in Common Lisp
  and isolated elegances in most other languages.  since we all appreciate
  more elegance rather than less, users of inelegant languages learn by the
  rewards they get from doing it that digging deeper in particular ways is
  a good way to _improve_ their language appreciation, and so they continue
  with this habit when they come to Common Lisp, only to be disappointed.
  if you don't realize the ramifications of this reversal, you will lose
  track of the big picture: you should not need to dig deep into a language
  to find its elegance, and it doesn't matter whether the innards that you
  don't know about are inelegant.

#:Erik