[ruby-talk:5712] Re: Dynamic languages, SWOT ?

Hugh Sasse Staff Elec Eng wrote:

> There has been discussion on this list/group from time to time about
> Ruby being a dynamic language, rather than one with strong typing.
> This is said to give greater flexibility.  I'd like to understand this
> idea better, and maybe then I can make better use of it.
>
> One of the many examples given by Object Oriented practitioners, at
> least some years back, was that OO would make programming safer, because
> in the example of an aircraft control system, conventioaally one might
> have written:
>
>         seatbelt_light = 1;  /* turn on seatbelt light */
> and
>         deploy_undercarriage = 0; /* retract undercarriage */
>
> but one could assign 0 to the wrong variable, raising the undercarriage
> when one wanted to turn off the seatbelt light, which after landing
> would be expensive.  With objects
>
>         seatbelt_light.retract()
>
> could be easily detected by the compiler as being meaningless, so
> the mistake (a bizarre one, but this was only an example) would be
> detected really early.
>
> That is fine.  However, with dynamic languages one cannot say what
> methods an object has at compile time, because we can extend objects
> at run time.  This makes our code more flexible, because if objects
> don't do what we want we add or override methods.  But it also means
> that we cannot have things like design by contract, because a method
> cannot say much about what it will get as parameters.
>
> Looking at Martin Fowler's book on refactoring, I see that one thing that
> OO programmers are encouraged to avoid is case statements based on the
> type or other property of another object.  It is recommended that
> polymorphism be used, because the different types can be made subclasses
> of another type, and each object in that hierarchy can respond to certain
> methods in its own appropriate way.  This is clearly more OO in approach.
> It also assists in avoiding duplication of code, and makes things
> extensible as more "subtypes" may be created. But the case statement has
> an "else" (or "default") clause, so unknown types can be picked up.  If
> one has thrown out the case statement, presumably one has to add some kind
> of assertion to check the incoming type, but that would break the dynamic
> nature of the software.  Or would it?
>
> So is this situation just "one of those trade-offs one has to accept",
> and it can be said that dynamic languages are better at different things
> from strongly typed languages, but they are equally valid, just different?
> Or is there some huge advantage that I have missed, which would make
> the loss of these automatic checks a price worth paying?
>
> As I have said, I'm not pushing for any one side, I'm trying to understand
> the issues better.
>
>         Thank you,
>         Hugh
>         [e-mail]

Sorry, I feel the need for clarification here.  Ruby is strongly typed AND
dynamic.
Weakly typed, statically bound languages are things like Fortran60.  There the
language couldn't tell the type of the item upon which you were operating, so
it made assumptions based on the name.
Strongly typed, statically bound languages are like Eiffel and Ada.  The
language knows what the type MUST be at compile time (except when unusual
procedures are invoked).
Weakly typed, dynamically bound languages are ... well, there's assembler.
Can't think of anything else off the top of my head.
Strongly typed, dynamically bound languages are, among others, Ruby, Python,
Common Lisp, Smalltalk, ...
Java seems to sit (un?)comfortably in the center, leaning towards sort of
strongly typed, and sort of dynamically bound.

-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically
prohibited