Ambiguity and Precision
(Here's the high-falutin' essay that I mentioned on Friday.)
"How shallowly can you model?"
Here is a long discussion thread on
LtU.
Despite the thread's name, it turned into a discussion
about static vs dynamic typing (as do so many threads there).
Frank Atanassow made a key observation:
[Static typing] does not limit what you can model;
instead, it limits how shallowly you can model it.
(Here is a little more context:
Almost every time I've cursed Haskell's static typing [...]
because it got in my way, I found that the redesigned program
which obeys static typing has advantages over the old one.
[...]
After studying category and proof theory, I sort of
discovered why this was true. It's because typing [...]
does not limit what you can model; instead, it
limits how shallowly you can model it,
and what set of primitives [...] you can use to express the
problem. In other words, typing forces you to look more carefully at
the problem you're trying to solve, and it forces you to use a
particular language to express it in.
)
I use Python and agree with Patrick Logan about
much of what he says, but I think Frank has it
dead on here.
different definitions of "program"
I think some of the disagreement comes from different
definitions of what we mean by the noun "program".
In another LtU thread last September,
Frank asked me: "If two programs do not at least satisfy the
same specification, you can hardly call them the "same", can you?"
I responded in my weblog ...
Yes, Frank. We still call gcc "gcc", though it meets distinctly
different specs now than it did in 1986. We still call you
"Frank", though you probably meet few of the specs that you
met in 1970. )
In a strict sense, Frank is right.
What the rest of us call "a program" or "a piece of software",
would more precisely be called "a series of similar
programs". But in common usage, "program" has that latter
meaning.
In most programming work today, a program is not a static
thing that meets a static spec.
A program — or rather, the development of a program —
is a process.
It's a process of continuing
change (usually continuing improvement, but MS Word
is a counterexample): an early version will attempt to
meet a vague, initial spec; the developer will
get some feedback from the customer, tighten up or
change the spec; later versions of the same program will
meet that revised spec; more feedback will be received,
repeat until you get rich or run out of funding.
I think that both static typing and dynamic typing
have reasonable roles here, and would love to see
some languages that attempt to make more harmonious
combinations of them. Multi-methods (as in Nice or
Cecil) help, optional explicit static typing (as in Dylan)
helps, and I think even Haskell's type classes help, though
I haven't quite figured them out.
loglan/lojban
To get back to my title: ambiguity and precision are related.
As you specify something with less precision, you admit more
possibilities that will meet your spec; and once those
possibilities get far enough apart, we call your spec
ambiguous.
Decades ago, I worked a little on loglan and
lojban.
One goal of that family of "constructed
languages" was to make the language "less ambiguous" than
English is. One result of that, as I struggled with learning
a bit of lojban, was that it took more thought and effort to
construct a sentence than in natural languages. Even when I
speak (my native Californian) English, I expend more thought
and effort to construct sentences than the average English
speaker does, but for lojban it went much further.
I think one reason was that the precision level was just
too detailed, and didn't provide enough higher-level,
less precise, possibly-ambiguous words for certain concepts.
English struggles with this in certain cases, e.g., the use
of "they" as a pronoun denoting one person of unknown gender.
Lojban struggles with it constantly.
As
Anton van Straaten wrote: "sometimes shallow modeling of
a problem is perfectly reasonable". Indeed, sometimes a shallow
model is all you can say about something. In spoken language, we need to
be able to choose how deeply we model our subject, in part because
our information is so often incomplete.
In programming languages, many static typing systems make it
difficult to be half-vague — e.g., in Java, you end up
falling up to "Object" way too often.
testing ... for what?
In another part of
Anton's post, he writes
"Studies of this aren't necessary,
because formal proofs exist."
Here, I think Anton may be missing the point of the tests.
In the formal view, static typing "proofs" help with the
confidence that a program meets its (this week's) spec,
with respect to typing.
In the world where Dynamic Typing is popular, the tests
help with the confidence that a program does what the
customer wants it to do. Different purposes, and the
proofs that a program meets a spec quickly become less
interesting when the spec changes often.
Earlier, Frank wrote "The place where a DT language can
theoretically beat an ST language is in reuse, because static
typing inherently limits it".
I agree with Anton, that one of the places where DT languages
beat ST languages is in development of prototypes,
especially in fluid situations with changing specs.
11:33:58 PM
Random radio Weblog