[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5705] Dynamic languages, SWOT ?

From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-10-20 10:00:06 UTC
List: ruby-talk #5705
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
	hgs@dmu.ac.uk


In This Thread

Prev Next