By that time, C had long been a popular language, in spite of demanding that, just like in Pascal, local variables have to be defined at the opening of a new block scope, after which only statements follow.
This is actually a good idea; I avoid mixed declarations and statements in C programming.
Also, mixed declarations and statements are against the Linux kernel coding guidelines and are diagnosed. Yet countless people hack on the Linux kernel for fun and profit.
When I really need some tightly scoped local variable in C, I introduce a little scope with a new braced compound statement, just like `(let` in Lisp. This has the advantage that you determine where the scope ends, not only where it begins. You know: from line 27 this 75 line function, down to line 53, and that's it, not all the way down to line 75.
The mainstream dialect of lisp known as Scheme has a define construct which lets you create new scopes with local variables at the same level of nesting. (Scheme compilers transliterate these defines-s to nested let for you). Yet Scheme is not taking over the world. This aspect rarely even comes up as a topic.
You can have more than one value in a let and it typically does not cause problems. If you do find it causes problems, it is trivial to change the language and invent your own, expression for defining local variables.
Its fine to have your reasons for hating lisp, but if this is the only thing that puts you off, I recommend giving it another try.
There is this one: simple statistics. People have created an astonishing number of programming languages, of which only a vanishing minority are popular. If you pick a language randomly out of all of the ones that have been ever created, you will with a very high probability close to 1 land on something that is not used at all.
Given the age of the first versions of Lisp, it is astonishing that the descendants are still here and that there is a lot of resemblance.
(defun foo (a &aux b (c 1))
(list a b c))
is (defun foo (a)
(let (b (c 1))
(list a b c)))If I had to use a Lisp-like language, I'd choose Clojure so I can interoperate with the JVM. (I use Scala already, so I could interoperate with that, too.)
Suppose that we have used (cddr x) to test whether the list x continues after the second item. It is then unnatural to have (third x) to retrieve the third item! It is like "faulty parallelism" in your English essay. :)
If the condition (and (cdr x) (consp (cddr x))) holds, then the proper way to get that item is (caddr x). This is easy to verify: If cddr is a cons, then its car is given by tacking on an "a": caddr.
In any case, car, cdr and the rest are an absolute must in a Lisp dialect. They are instantly understandable; there is no good reason to break with this important convention. A Lisp dialect will not achieve anything by breaking cultural compatibility with other dialects in this regard; it will just be shunned by Lisp people yet still disused by everyone else. Although CAR and CDR come from IBM 704 machine language, which means nothing to pretty much anyone over fifty years later, the people who allowed these names to infect the higher level language weren't idiots. They discovered that the names just work and so used them. Borrowing some mnemonic that works from the IBM 704 is no worse than borrowing some equally arbitrary greek letter like lambda from a branch of mathematics. If the mathematics of anonymous functions had been called "Tau Calculus" we would be writing (tau (x y) + x y) instead of lambda; it's just a historic accident. All names are historic accidents: one person calls it water, another one aqua, a third one mizu.
I also love the star convention and have used it in many places. for instance mapcar* is a lazy mapcar: it can take infinite lists as its arguments and returns the resulting lazy list immediately. Leslie Lamport picked up on this star notation in LaTeX; that's where I first encountered it. When I got into Lisp years later it was like, hello, is that where Lamport got it from?
I don't like verbosity, so I made my dialect slick and ergonomic. It can "code-golf" side by side with the so-called "modern" scripting languages, while remaining clear.