I’ve been trying to find exactly what Backus said about this, but couldn’t. Could you point me to it?
Just so it’s clear, the Strong v. Weak and the Static v. Dynamic axes really are orthogonal (independent of each other): Where a language sits on one has no bearing on where it sits on the other.
This is somewhat obscured by the fact a whole quadrant of the grid, the Weak Dynamic languages, has pretty much died out. These days, the main Weak languages are Static, as C and Pascal are. Back in the 1960s there were a few important Weak Dynamic languages, all of them boasting a single data type: The machine word. One of these languages, B, is a direct ancestor of C (via a couple other links in the chain). Those single-type languages really only allowed you to name storage locations, and each storage location is one machine word in size unless it’s an array of multiple machine words. You can treat a machine word as whatever you want, adding it like an integer one second and indirecting through it like a pointer the next and later treating it like a floating-point number. The compiler did no meaningful type checking and, basically, bits was bits.
In short, B was a gloss over machine language. There was no reasonable way to write a B program that would be portable to a computer with a different word size, a different convention for pointers, or a different bit-level floating-point format. B died the death when C and Unix took off in the 1970s. A different language of the same type, the BLISS dialects at DEC (later Compaq, then HP), survive to this day in the (small) VMS world, but the BLISS programs written for the 36-bit PDP-10 are not portable to the 32-bit VAX or the 64-bit Alpha.
You could talk about assembly language as being Weak Dynamic, but nobody expects assembly languages to have types so nobody does. Forth also qualifies, but Forth has fairly low mindshare these days and, again, nobody seems to talk about it that way.
As for why some people (Derleth ;)) prefer Dynamic to Static languages: In Common Lisp and Scheme, you don’t go through the batch-oriented Edit-Compile-Test loop. You type into an editor (Emacs*) and communicate with a Lisp Read-Evaluate-Print-Loop. Interactivity is the sword and the shield of the Lisp hacker. Your editor screen comes alive with dancing code and all of it can be evaluated on the fly. Constant testing replaces the assurances of Static type systems. Why bang my head against a wall of type checks when I know the function is good because I’ve tested it? Smalltalk is essentially the same way, only in Smalltalk the environment is a graphical system written in Smalltalk and the mouse has a much larger role.
*(Emacs isn’t just an editor. Emacs is a Lisp system in its own right and provides a whole environment distinct from the surrounding OS. Hooking Emacs to CMUCL means Emacs knows Common Lisp well enough to help you edit it at a structural level, as opposed to just knowing how to invoke a compiler or hand strings off to a REPL.)