If topic-comment order is so natural, why don't more languages support it?
Perl does, of course, through
$_. This is really two features. One is anaphor —
$_ holds the result of a previous statement, or of a loop-control expression. That's a useful feature (and not only for topics), and it's easy to support in other languages, by turning
(progn a (b it) (c it)) into
(let* ((it a) (it (b it))) (c it)). It's nice because it encodes something more interesting than order of effects in the sequential order of code.
The other feature is that
$_ serves as a default argument to many operations. Perl implements it as a dynamically scoped variable, but sets it instead of rebinding it, so it's a little hazardous (see the cautions in perlvar). Rebinding instead would work better, but either way, it's easy to imitate.
ISTM that Smalltalk also supports topicalization, in two ways. One is the implicit
self argument. That doesn't help with topic-comment order, but it does save a little typing. The other is the
; operator, which allows sending several messages to one receiver:
a foo: b; bar; baz: c is
a foo: b. a bar. a baz: c. Effectively, you can separate statements with '.' to set a new receiver, or
; to keep the old one.
; isn't used much. Its low frequency illuminates why implicit anaphors aren't common in programming languages: they change their referents too rapidly. In programs as in speech, a topic may last a long time, even though it is rarely referred to. But implicit anaphors and argument-passing abbreviations have too short a memory to hold the topic. It's often necessary to fall back on the very ordinary mechanism of binding a variable, which also better handles irregular references.
The underlying difference is that natural languages benefit from topicalization in ways programming languages don't. Natural language is often ambiguous, and relies on context to deal with this — and topics are great for disambiguation. Topics also help convey the structure of discourse — how parts relate to each other, and why they matter, and what the listener can safely ignore. None of this is as important in programming languages. Topicalization may still be useful, but mainly as abbreviation.