My experience with the Eiffel-type-system is quite good. Errors are
caught at a very early stage (by the compiler), so you don't have to
expect any big surprises when the compiler has accepted a program.

Another advantage of this type-system is, that it forces you to think
about your class-structure befor your implement it. Languages like
Smalltalk or CLOS give you more freedom to implement poor designs.
And what I have seen is, that people use this freedom! The importance
of good analysis and design is rated very low and since the language
permits it, implementation is begun very early. Some people consider
this early code production as a success, because they can show
something at an early stage (anlaysis and design produces just some
diagramms ;) ). The difficulties with this code show up
only in the long run, when the system is changed and when it grows.

Another problem with CLOS and Smalltalk are the hardware resources
they need. The Eiffel-project I've done was implemented on a PC-386 (16 MB)
using Unix V4.0 with acceptable performance, whereas the CLOS- and the
Smalltalk-projects run on Sun-SPARCstations with large amounts of main
memory and especially the CLOS-system was only acceptable on a
SPARCstation10.

Roland

- Paul

If we have two similar logical systems, one that is inconsistant and
one that is consistant then the inconsistant system is in some twisted
sense more "powerful" because you can express things that you can't
with the other system. The question is whether the extra flexability
that results from dynamic typing, as found in say Smalltalk, lets
us express things that may not be restructured and expressed in
Ada, C++ or Eiffel, and that is "worth expressing".

- Robb Nebbe

If you have done a reasonable amount of analysis and design
then ideally you should be able to express a signifigant
portion of you design constraints in a statically typed
language and use the language as a tool to verify what you
consider to be a good consistant design.

- Robb Nebbe

Perhaps you are talking about the fact that Smalltalk methods will
accept objects with the right functionality whereas C++ methods
want objects of a certain declared type.  Even here, the corresponding
type constraint could be stated and checked statically.

Satish

To be sure, there are implicit dependencies.   i.e.  when you send a
message to an object, the lack of that interface will not be detected
until run time.  But, for many application domains, this is a tenable
situation and the simpler static dependency structure is a good trade
off.

--
Robert Martin       | Design Consulting   | Training courses offered:

2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

--
Robert Martin       | Design Consulting   | Training courses offered:

2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

That depends on what kind of static type system we are talking about and
what other facilities exist in the language.  I think statically typed
OO languages that base OO polymorphism on inheritance do pose problems
for reuse.

There are alternatives, however, that preserve many of the advantages
of dynamic typing while giving you type safety.  Some that I am familiar
with are:

        (1) OO polymorphism based on signatures rather than inheritance:
            this exists as a C++ extension (among others) and means that
            any object that has the right methods and types can be
            substituted for one another (some consider this a risk,
            but in practice it doesn't seem to be a problem)

        (2) Use closures in a statically typed language: similar to (1),
            but even more powerful and general.

        (3) Use existential type quantification: similar to (2), but
            some additional power.

        (4) Use parameterized modules that don't replicate code: NJ/SML
            has those.  They provide a superset of the functionality of
            C++ template classes but without the code bloat.

        (5) Use Milner-style polymorphism: similar to C++ template
            functions, but much easier to use and without the code
            bloat.

I have used (2), (4), and (5) extensively (in the programming language
SML) and find that they provide much better reuse than any approach
based on objects (I have used both C++ and CLOS extensively as well).

I suspect that (1) would be a good compromise for staying within the
OO paradigm, while giving the programmer some extra power.

Also, what makes life with a statically typed language much more
convenient is type inference in the compiler.  Many people using a
statically typed language with type inference initially don't even
realize that it isn't a dynamically typed language, since they don't
have to add type declarations.  And yet, the compiler makes certain
that only type-correct programs get executed.

                                        Thomas.

Theory is very nice, but the practice Roland describes has to be
considered, in typing, class hierarchies and everywhere else.  Down
with the "an int for all purposes" C library!  Down with
thoughtlessly extended-ten-times struct/class definitions!  Down
with overused multiple inheritance!  Down with similar-but-different
methods/functions/variables!

--Arnt (frustraded implementer)

--
Emmanuel Baechler.                        | Tel.: ++41-21-314-29-06
Etat de Vaud                              | Fax:  ++41-21-314-45-55


Les Allieres                              | Standard Disclaimer
CH-1011 Lausanne        Switzerland

Political correctness = the replacement of historical biasses in the language
                        by new ones that are more suitable for the speaker's
                        purposes
Gun control laws don't die, people do.
Ban the bomb. Save the world for conventional warfare.

|> ....
|> It would appear, that for applications with lots of human interaction, where
|> the run-time overhead cost is acceptable, dynamically typed languages such
|> such as Objective-C, Smalltalk, or CLOS, offer superior productivity
|> enhancement, and superior re-use, at the cost type safety.
|>
|> Does anyone have experience that would confirm or contradict this?  For
|> instance, that type safety leads to greater enhancement of productivity and/or
|> re-use?  Any insights, or ideas are appreciated!

Having done work in CLOS, C++ and Smalltalk, I find that the freedom
and flexibility provided by dynamic typing is quite helpful.  I would
also point out that type safety can be obtained in dynamically-typed
languages by appropriate use of explicit type checks.

|> ....
|> Another advantage of this type-system is, that it forces you to think
|> about your class-structure befor your implement it. Languages like
|> Smalltalk or CLOS give you more freedom to implement poor designs.

They give you more freedom, period.

|> And what I have seen is, that people use this freedom! The importance
|> of good analysis and design is rated very low and since the language
|> permits it, implementation is begun very early. Some people consider
|> this early code production as a success, because they can show
|> something at an early stage (anlaysis and design produces just some
|> diagramms ;) ).

What you are describing is a people problem, not a language problem.
Failure to do effective analysis will lead to bad code in any language.
Deferring selected design decisions until some implementation is done,
on the other hand, can be extremely beneficial.  I can provide concrete
examples of this for you if you want.

|> .... The difficulties with this code show up
|> only in the long run, when the system is changed and when it grows.

I'm having a little trouble with this statement.  Since the code
grows and changes most rapidly during its initial development, wouldn't
the problems show up almost immediately?  This fits with my experience.

|>
|> If we have two similar logical systems, one that is inconsistant and
|> one that is consistant then the inconsistant system is in some twisted
|> sense more "powerful" because you can express things that you can't
|> with the other system.

The question wasn't about logic systems, and a language with dynamic
typing capability is not in some way "inconsistant" [sic].  

 Bill> I'm having a little trouble with this statement.  Since the code grows
 Bill> and changes most rapidly during its initial development, wouldn't the
 Bill> problems show up almost immediately?  This fits with my experience.

I think the concern here is that it is quick and easy to get the first 80 or
90% of the job done, but that last 10 or 20% will be extended, due to the the
lack of type safety.  For instance, run time bugs that make it out to the
customers will be more prevalent.  Integration and debugging of large systems
will be tougher, and more time consuming, etc.

I don't know that this is so, it just seems likely.

        Don

 Robb> My opinion is that if your thinking is fuzzy about a problem then a
 Robb> language like Smalltalk can be a big help. Static typing can be more of
 Robb> an obstacle to exploring the solution space than anything else.

This makes sense.

 Robb> If you have done a reasonable amount of analysis and design then
 Robb> ideally you should be able to express a signifigant portion of you
 Robb> design constraints in a statically typed language and use the language
 Robb> as a tool to verify what you consider to be a good consistant design.

This makes sense in a static world.  In my world, the analysis and design I do
today, are great, and can lead to very clean systems, but sales will come up
with something unexpected tomorrow.  It is in this fluidity of handling
software evolution, that (I hope) dynamic typing & binding win.

I never know as much today as I will tomorrow.  Static typing seems to force
me to try to make more decisions today, that will effect what I can do
tomorrow, (without going back and re-working).  Dynamic typing seems to let me
leave things more open, so that the classes I design today don't need so much
explicit information about the classes I will design next week, and they don't
constrain those classes so much.

What do you all think?

        Don