Re: how to prevent bugs without static type checking?

[steve donovan <steve.j.donovan@...>]

On Fri, Oct 26, 2012 at 5:36 AM, Andrew Starks <andrew.starks@trms.com> wrote:
> target audience. Ruby's mission was "programmer happiness" and was picked up
> by a crowd that at least professed to strive for quality code. Ruby's
> testing culture boarders on nauseating.

Yes, testing isn't so happy-making, but part of life. But I'd say that
the first generation of dynamic programmers were smart hackers, e.g
Unix shell, Tcl and Perl.  In the hands of masters, these hotrods
could do marvelous things, but less careful people tend to make
messes. (Which fits with the car analogy)

As an example of different language culture, Ruby tolerates
duck-typing and so people get into messes which are hard to reason
about. Lua people are much more reluctant to do that, even though it's
trivial to redefine string.match say.

> I think that there is a sense of false security that people _can_ gain from
> all of the bells and whistles that an IDE can provide and that type checking
> provide.

Formal guarantees of type correctness aren't a good indication of
program correctness! [1] Still, there are rules of thumb about errors
in dynamic languages - force them to happen as early as possible, and
crash noisily - a type assertion is a good example. And these dynamic
type assertions can be as intelligent as we need them to be.

I've been doing Android programming in Lua, and feel that a dynamic
solution has to give a big productivity boost to offset the loss of
the intelligent IDE support one gets with Java.  In particular, a REPL
is a fantastic thing for learning a platform and experimenting without
having to rebuild, reinstall and relaunch.[2]

> On a related note, I really wish that nil was not false, although I know I'm
> in the minority on that one. :)

Well, nil came before false in Lua's evolution ;)

steve d.

[1]  (Haskell people tend to say otherwise but then they have an
incredibly powerful type system which gives non-masters headaches.
Certainly for me).
[2] which can involve a number of seconds, which is a long time in a
programmer's head.