"Maciej Sobczak" <firstname.lastname@example.org> wrote in message
> "[it] seems to be that it's explicit typing, where the programmer is asked to
> declare the type of things, that leads to most of the problems.
> [...] it's starting to look like type declarations are one of those accidental
> difficulties that good programming languages can eliminate."
> It is obvious that there is a place for dynamically typed languages, but the
> above statements seem to be a bit too far-fetched. Do they mean that
> "typeless" languages will just suck some of the Java audience (fine for me),
> or is it maybe a more general problem that will drive the evolution of
> programming languages further away from strongly typed systems?
> Do you plan a switch to Ruby? ;-)
A class is a type. It is a very special kind of type, but still a type.
Ruby, and other object-oriented languages do use classes. Just
as we create instances of types, so too do we create instances
Ruby, Python, and a lot of functional languages use reference
implementations of primitive types as well as for classes. Java
uses by value semantics for primitive types, and class objects
are implemented by reference.
Types are in place whether evaluated dynamically or statically. Perhaps
the question is better asked in terms of static typing. Also, one needs
to understand what is required of the problem space. Does safety
make a difference? Is it useful to use a type-safe language? How
type-safe do we need to be. C++ and Java are moderately type-safe,
but with lots of little surprises for the newbie or naive programmer.
Does the fact that a language is by-default type-safe (e.g., Ada) make
it difficult to relax the default? No. Ada has a lot of mechanisms
for relaxing type-safety. It is difficult to take a language where the
default is unsafe and make it safer. We have a continuum of typing,
well supported by Ada. Not as well supported by a lot of other
Assertions are a part of the type system. Invariants are part of
the type system. An invariant defines the legal set of states for
instances of a primitive type, abstract data type, or class.
1) has a name (explicit or implicit)
2) a set of legal states (values)
3) a set of legal operations
4 a set of rules (language defined) with regard
to relationships with instances of other types
The fact that an entity is not given a type name does not mean
it is not typed. Also, the four properties just described are
general enough that lots of instances of things can be included,
even things that seem to have no type at all.