RE: another take on hackers and painters

["Anton van Straaten" <address@hidden>]

Dan Sugalski wrote:

> At 9:06 AM -0500 5/21/03, Matt Hellige wrote:
...
> >Wow... That just makes me cringe... And sets off my "perl proximity"
> >alarm. By the same token, why not have 1 + "3" produce the string "13"?
>
> It could, sure, but + generally notes addition, and both sides *are*
> numbers, after all. Why not coerce to types based on value? Seems the
> logical extension to dynamic typing to me.

You say "both sides *are* numbers, after all" - hmmm, methinks you've been
using that language for too long!  ;oP

As an aside, if I were forced to pick a rule for implicit coercion, I'd say
that the type of the first (leftmost) value should determine the type of the
coercion: so 1 + "3" would be 4, but "1" + 3 would be "13".  But I'd rather
be more explicit about my intent, because:

How do you (or the language) know that "3" is a number?  It could be
intended to represent something entirely different.  The only type
information we have about it, says that it's a string.  The type of the
value which the string "contains" or represents is essentially unknown and
can only be determined by inference, or by explicit instruction from the
programmer.  Perl has a rule for inferring the type of numbers contained in
strings.  Only in that sense, can the string "3" be said to "be" a number.

This highlights one of the major things types are supposed to do in the
first place: they give context to values, in the same sort of way that
physical quantities have units like meters or grams.  This is important
information, which if it isn't encoded in the language, is nevertheless
encoded in the programmer's mind (or if it's not, will be after the
resulting debugging sessions).

When dealing with objects in the OO sense, even dynamically typed languages
respect this issue: values are tagged with their type, and if you make a
type error, the language implementation will tell you.  What is it about
simple values like numbers and strings that makes them exempt from this
issue?

I think the answer, from a high level perspective, is that languages that
use duck typing are attempting to use some very simple heuristics to
simulate the human ability to give meaning to values based on context - the
whole DWIM thing.

The problem with this, at least in this case, is that it trains people to
think loosely about types, and then they end up debugging the indirect
consequences of their typing errors.  I'm basing this on some experience:
I've seen programmers with prior Perl experience make these exact mistakes -
for example, testing values as strings which should be tested as numeric,
causing incorrect program behavior when the string wasn't formatted as
expected.

In these cases, instead of getting a type error on the line where the
invalid test took place, the program runs and they get something unexpected
in the final output.  Since no error is produced, the problem might not even
be noticed during development and testing, unless your tests are good enough
to catch it - not necessarily easy, if the problem only manifests on a GUI
form.

So I would argue that one reason to avoid duck typing for anything "mission
critical" - i.e. anything where it's important to catch problems before they
hit production - is that stricter typing (even if dynamically checked)
trains programmers to think more clearly, and helps to automatically detect
certain classes of errors.  To me, it's a no-brainer tradeoff for the minor
syntactical convenience of implicit coercion.

An acceptable alternative, to me, is if a language provides strict operators
that don't do automatic coercion, and then provide other operators that do.
Oh yes, and the auto-coercing operators should look something like this: 1
!+! "3", so you can't miss them.  ;)

Anton