FAQ terminology harmonisation
Thu Apr 3 11:28:43 CEST 2003
--- Rick Pettit <rpettit@REDACTED> wrote:
(First, I agree that the word 'crash' is possibly
unfortunate for getting exceptions.)
> > 4. Dynamic typing combined with "don't be
> defensive" ==Most static
> > typing theory junkies== just can't work.
> Not sure how to address this one. I have worked too
> much with C++ and not enough
> with Erlang to make a good call on this. Static
> typing has helped me a great
> deal with my C++ code. Working in languages like
> Perl in the past (intern days)
> without strict type checking I managed to get myself
> into trouble as the code
> got really big and I failed to [re]factor it into
> manageable units (especially
> since Perl insists on there being "more than one
> way" to do anything). Is the
> same not true with Erlang/OTP?
> Has anyone ever written an OTP application that
> crashed as the result of
> passing the wrong type into a function or by
> misspelling a variable?
Misspelled variables are caught by the compiler. (Esp.
if you use warn_unused_vars.)
> Could someone explain why static typing is
> considered so "bad" or "unnecessary"?
> I think I could be sold on this (I _do_ consider
> myself to be open-minded), I
> just need to hear the right argument.
Here's my opinion at least.
My basic train of thought is this:
* The main benefit of Erlang, Lisp, Prolog, SML and so
on is _type_safeness_: there is no way that you can
accidentally confuse one value's type with another.
This (along with GC and pureness) gets rid of the
majority of errors.
(This is also known as 'strong typing', not to be
confused with 'static typing'.)
* Static typing a la Hindley-Milner (SML, Haskell,
etc) probably helps most when you use higher-order
Erlang programs typically do not employ combinators
and suchlike, so the need for such checking is less
Furthermore, static typing does not check concurrency
properties that might be of greater interest to our
sort of applications.
(Model checking etc. seems to be waiting in the wings
for checking that sort of thing.)
* Finally, static typing in the sense above is
prescriptive: it will reject programs that are okay
because it can't prove they are (e.g., heterogenous
lists were rejected for a long time; not sure about
whether it's handled well these days). This may mean
you have to 'code around' the problem, though a static
typing guy might say you are removing a latent bug.
Also, the programming language designers will have to
restrict programs to enable checking (e.g., receive
... end is hard to check in its current form, since
any process can potentially send to any process, as is
hot code loading, for obvious reasons).
Basically, prescriptive typing means you have to
sacrifice some convenience and slow down language
evolution, so that the type checker can keep up. (Some
may think this is a good thing, of course.)
The other, less common, approach is descriptive
typing: permit any program but flag any strangeness. A
sort of "lint-like" approach. This is harder to do
(since the checker has to *follow* difficult code
rather than reject it, and since there is a problem
with false positives due to inaccuracy). Still, I
think it's an interesting approach.
There have been at least four attempts to do this for
Erlang that I know of, but none has really gotten 'out
of the gates'.
* An aside: an interesting difference between Erlang
and SML (say) seems to be that SML programmers appear
to talk more about types and how they should be
designed before coding. This is something I seldom
encounter in writing Erlang programs :-) I haven't
seen a good summary of the differences, though. (This
thinking seems to be more recent than last time I
really looked at FP.) Maybe it's a "Smalltalk-Java"
Personally, I find that static typing in its current
form adds little value to my Erlang programming.
Errors due to type mistakes do appear, but not so
frequently as to make it a major problem. The
consequences are exceptions, not core dumps or quiet
madness, so debugging is easier than in the C++ case.
(An opinion: Making Erlang even easier to test would
probably be more pragmatically beneficial than adding
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
More information about the erlang-questions