Reading "A Programmer's Guide to Common Lisp" (journal.paoloamoroso.com)

http://clhs.lisp.se/Body/s_tagbod.htm#tagbody

http://clhs.lisp.se/Body/s_go.htm#go

   (progn <form>)

    <form>

No. Explicit scoping is a huge plus.

> This is why languages die, when the old guard refuses to see that there are better ways of doing things than what they are used to.

Don't mistake this for not being able to see beyond your nose.

https://fare.livejournal.com/189741.html

  (if (cond)
      (progn
          (preamble)
          (let ((a 5))
              (do-stuff a)))
      (do-stuff 6))

  (if (cond)
      (let ((a 5))
          (preamble)
          (do-stuff a))
      (do-stuff 6))

Racket also allows it and encourages it in the style guide, using the "less nesting" (and thus shallower indentation ) rationale you bring up.

https://srfi.schemers.org/srfi-245/srfi-245.html

    (if (cond)
        (begin
          (preamble)
          (define a 5)
          (do-stuff a))
      (do-stuff 6))

> Common Lisp wants you to declare every set of intermediate variables in a nested scope

Lisp programmers edit code by list operations. For example, I can set the cursor between (preamble) and the (let ...) form. control-meta-t transposes the lists. The let form is moved upwards and the enclosed body is moved, too. Try that in the C code. Code transformations are vastly easier with explicit scopes.

JavaScript has introduced a LET for a reason: block scope is clearer than VAR (function / global scope).

    (defun foo (a)
      (if a
        (var b a))
      (print b))   ; what's the value here?

I would need to write:

   (defun foo (a)
     (let (b)
       (if a
          (setf b a))
       (print b)))

  (if (cond)
    (let ((a 5))
      (preamble)
      (do-stuff a))
    (do-stuff 6))

  (let* ((x (progn (widget-lock w)
                   (widget-x w)))
         (y ...))
     (...)
     (widget-unlock w))

  (let* ((w (widget-lock w))
         (x (widget-x x))
         (y ...))
    ...
    (widget-unlock w))

with `let` you can say

    (let ((x y) (y x)) ...

    (let ((case-fold-search t) (outer-case-fold-search case-fold-search))
       ...
       (let ((case-fold-search outer-case-fold-search)) (f))
       ...)

with `let*` you implicitly have an execution sequence over the binding forms, but in most cases that's something you're specifying by accident. `let` strongly suggests to the reader that she can consider any one of the binding forms in the list in isolation; she doesn't have to read through the first n-1 bindings to understand the nth one

it's true that, in most cases, all three of them do the same thing, and this is not the most parsimonious approach

Lisp's design, I find, is best understood through the lens of how we might most straightforwardly interpret the semantics of the syntax, i.e., how we might write an evaluator for the language. It's a large part of the appeal of using Lisp; it's possible to understand the language—from parsing to execution—so well that you could in principle write a conforming interpreter for even something like Common Lisp without Herculean effort. Having such an understanding of the language has a variety of practical benefits even if you're just using the language.

A construct that you suggest like

    (VAR <variable> <value>)

Even then, if we do make a variety of decisions about syntax and scoping rules to allow VAR, we have additional questions to answer in the context of Lisp specifically. For example, are macros allowed to expand into VAR statements? Is this allowed?

    (defmacro bind ()
      '(var x 5))

    (defun f (y)
      (bind)
      (+ x y))

    (defmacro bind (&body b)
      `(let ((x 5))
         ,@b))

    (defun f (y)
      (bind
       (+ x y)))

So we might ban macros expanding into VAR statements. So then how do we write binding macros? Introduce a dedicated SCOPE special operator?

    (defmacro bind (&body b)
      `(scope
         (var x 5)
         ,@b))

    (defun f (y)
      (bind
       (+ x y)))

Languages with very complicated grammars also typically come with comparatively complicated scoping rules (e.g., Python). Lisp's LET maybe seems gratuitous in a world of "var x = 2" syntax, but it's also abundantly clear what it means and how it works at all times, regardless of nesting or context.

To leave the reader with one last thing to ponder: What should this do in a compiled implementation of Common Lisp with VAR?

    (defun what? ()
      (tagbody
          (if (= 0 (random 2))
              (go :bind)
              (go :print))

        :bind
          (var x 1)

        :print
          (print x)))

The unstarred let is a destructuring bind of an entire tuple.

For example (let ((x 1) (y 2) (z 3)) ...) does the entirety of x := 1, y := 2, z := 3 at once, the right hand sides in the old frame and the left hand sides in the new frame.

So let introduces a new frame BUT only after all three substitutions are done.

For example in order to rotate x y z (from the surrounding frame) to the right:

    (let ((y x) (z y) (x z))
      ...)

    ((lambda (y z x)
       ...)
     x y z)

    (let ((x 1) (y 2) (z 3))
      (let ((y x) (z y) (x z))
        (list x y z)))
    => (3 1 2)

    (let* (A B C) ...) is defined to be (let (A) (let* (B C) ...). And so on. (let* (C) ...) is (let (C) ...), the base case.

    (let* (A B C) ...) is (let (A) (let (B) (let (C) ...)))). Does that look natural to you?

>If a programmer ever falls in the habit of sometimes using unstarred LET, then it's likely he'll make a mistake by using it where starred LET* was the right thing.

Never happened to me so far and I'm using Lisp for 8 years now.

>It seems reasonable that when I write code, I shouldn't have to stop and worry about which of the gazillion different LET forms is appropriate

You do you, but you seem to think that this is an aesthetic choice rather than what the mathematics automatically gives. Lisp was not really designed, it was discovered. As long as you don't break any of the mathematical properties, go ahead and make it like you want it to be.

One thing you could safely do is remove the automatic tuple destructuring on let, basically removing the ability to have parallel-track bindings. Then you'd end up with something like Haskell:

    main = let x = 1
               y = 2
               z = 3
               in let y = x
                      z = y
                      x = z
                      in x
    => <<loop>>