> Is it because nil != false? Even McCarthy admitted that that was a random decision, and possibly a mistake. I think that code written where NIL is the sole f

> Is it because nil != false? Even McCarthy admitted that that was a random decision, and possibly a mistake. I think that code written where NIL is the sole false value tends to read better than code with a distinguished false value, but I'm open to the idea that uglier code is more reliable. > That's a common misconception, but it's not true: all but the most minimal implementations provide an imperative macro system. But they're not standardised. The manner in which they affect the runtime environment is not standardised. It's just not a sound basis for a portable project: in practise any large software project will run not on Scheme but on Guile Scheme, or Chicken Scheme. > Is it because it's lisp-1? Many lisps have been. Only mistakenly. I used to think that Lisp-1 is better: after all, I'm used to other languages like C or JavaScript where functions and variables share the same namespace. I've come to realise that 'because C & JavaScript do it' is hardly sufficient for something to be good grin It turns out that the multiple namespaces of Lisp are extremely useful for industrial-strength software. > Many people were on both standardization communities then Sure, there's lots of cross-pollination between Lisp & Scheme, because they are both good languages. I don't dislike Scheme: in its place, it's a very interesting way to learn certain concepts. It's Lisp-like, which means it's certainly not all bad. But it's not an actual descendant of a Lisp: it's its own independent language. It has flaws (continuations which make UNWIND-PROTECT impossible; nil ≠ #f; Lisp-1; worst of all: it's under-specified), but it's not bad. The world would probably be a worse place if there were no Scheme in it. But I think that emacs would be worse if it were implemented in Scheme rather than Lisp.