From ... From: Erik Naggum 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 | 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