[ruby-talk:03456] Re: Static Typing( Was: Waffling between Python and Ruby)

Hi,

Andrew Hunt wrote:

> Okay, first of all, please note that when I started this off
> by saying "static typing is for people with weak minds" I
> put a SMILEY at the end of it :-)  That means it's a joke, folks.

Well, some people don't think static typing is a joke. ... Oh, you meant your
comment. :-)

> There are no types in Ruby in the way you think.  A class is
> a collection of methods and variables, both of which may be altered
> from time to time and at anytime.  Individual objects may be
> extended with different methods from other objects of that class.
> So what is a type in this environment?

Something that changes a lot; but I suspect Ruby knows under the covers. A static
type (which may be something of a misnomer in this context) would be (very loosely
speaking) classes, methods, and variables that are in some sense made constant or
frozen--in other words where the dynamic characteristics you mention are in some
sense switched off.

>     >"Thaddeus L. Olczyk" wrote:

I wrote:

>     >>I think a major benefit was support for "programming by contract". There
>     >>has previously been a little discussion of how to do this in Ruby.
>
>     >And if you were to ask an Eiffel adherent, most would reply that
>     >" programming by contract" includes static typing. Indeed what is
>     >meant by contract? According to OOSE the contract is the interface
>     >and the constrictions on the interface ( pre and postconditions,
>     >invariants ). This definition implies that a contract requires static
>     >typing.
>
> I disagree strongly.  While Meyer is an advocate of static typing, I
> see no reason that DBC cannot be effective in a dynamically typed
> environment -- in fact, it seems to me that DBC could be even *more*
> useful in a dynamic environment than in a static one.
>
> A precondition asserts a routine's expectations of the state of the
> world.  A poscondition verifies the results of the operation.
> Why do you feel that static typing has *anything* to do with expressing
> the semantics of an operation in this manner?  I would argue that
> DBC in a dynamic language gives you the best of both worlds -- some
> guarantee that you're doing the right thing (the objects you are
> dealing with honor the semantics you expect, regardless of type),
> along with the flexibility of dynamic types.

Well, IIRC, he originally brought up static typing in the context of  compile time
type safety and someone also mentioned the possible utility for Ruby C code
generation under such conditions. I think that DBC that made use of both static
and dynamic typing would more likely be the "best of both worlds"--if there is a
reasonably convenient way to naturally extend Ruby to specify optional static
typing (perhaps more aptly termed constant classes).

    >As for dynamic typing, I know of several programmers who have worked
    >on Smalltalk projects. In each case the story is the same: we spent
    >two weeks writing the code and five and a half months getting it to
    >work write ( due to dynamic typing ).

> >As for dynamic typing, I know of several programmers who have worked
> >on Smalltalk projects. In each case the story is the same: we spent
> >two weeks writing the code and five and a half months getting it to
> >work write ( due to dynamic typing ).

> That speaks more of the programmers than the language, I think.

> The contrasting story goes like this: it took five months to
> write the code in C++, get it to compile without warnings, not
> core dump, link in under a day, etc., and then only five months
> to get it to work right.

One thing missing in the preceding discussion is what types of applications were
being done in Smalltalk and C++; AFAIK, Smalltalk has not earned a reputation for
dynamic booby traps. Given that Matz invented Ruby rather than live with
Smalltalk, it's not clear how much of the Smalltalk problem would generalize to
Ruby. Perl is extremely dynamic and Ruby is extremely dynamic, but I don't expect
that Perl's major user problems generalize to Ruby on that account.

I don't think things are (typically) all that grim for C++ either, but many of the
world's most common PC desktop applications (among other things) make use of C++,
and are notorious for being buggy. This of course is not all the fault of C++ by
any means; the point here is rather that in the face of these other chronic fault
factors, the effective utility of static typing is substantially diminished.

In any case, The 2 recurring SE study results that seem to withstand some scrutiny
is that (with some provisos), (1) the number of bugs are a crude function of the
length of code involved, and (2) that people on the average very roughly tend to
produce the same amount of code per week irrespective of the language involved.
This may be why Ruby (and Python) could well be substantially more productive (in
appropriate cases) than C++ under similar conditions.

>     >>> So why not do this? Make Ruby a
>     >>> language with both static and dynamic type.
>
> An interesting thought, but one for another language.

Rumored to be Python 3000. But I still have not seen convincing arguments that
some form of constant/frozen class (aka static typing) couldn't be a worthwhile
extension of Ruby. Of course it might well turn out to be too troublesome to
implement. But I think the idea is worthy of consideration. After all, it wasn't
so long ago that most people thought the only viable alternative to Perl was
Python. Maybe there's a better way to do optional static typing than Python 3000
as well--i.e. in Ruby.

> Fatal flaws of most languages seem to get introduced by committees :-)

I think he was hoping that Matz might take this up.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)