Type declarations problematic?

Type declarations problematic?

[Maciej Sobczak]

Hi,

http://www.joelonsoftware.com/items/2006/10/12.html

"[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? ;-)

Comments are welcome.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Type declarations problematic?

[Dmitry A. Kazakov]

On Fri, 24 Nov 2006 09:17:35 +0100, Maciej Sobczak wrote:

> http://www.joelonsoftware.com/items/2006/10/12.html
> 
> "[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? ;-)
> 
> Comments are welcome.

It is difficult to judge about a book not having read it! (:-))

The argument that explicit typing makes things more difficult is an obvious
and common rubbish (when taken literally, but see below). If types are
accepted then what's difficult about specifying them? Clearly a total
inference were far more difficult for both the programmer and the compiler.
Because instead of dealing with types you would have to deal with the rules
of inference of those. These rules constitute a higher-level language,
inherently, a more complex one.

But probably the answer to the riddle lies in the key turn of speech - "to
express data..." You know, there is no data without types! Data are
meaningless in a typed framework. So the whole argument goes back to the
idea of getting rid of the types, be they explicit or implicit. I wouldn't
reject it from the start, think about a kind of hyper functional language,
if they showed a way. But I doubt they did.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type declarations problematic?

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Hi,
>
> http://www.joelonsoftware.com/items/2006/10/12.html
>
> "[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? ;-)

I don't know.  But note that the opposite of "programmer is asked to
declare the type of things" is not necessarily dynamic typing.  There's
also type inference, as in SML, OCaml, Haskell, all of which are strong
statically-typed languages where you don't have to declare the types of
all the variables.

- Bob

Re: Type declarations problematic?

[adaworks]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:ek69qv$oo0$1@cernne03.cern.ch...
> Hi,
>
> http://www.joelonsoftware.com/items/2006/10/12.html
>
> "[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
of classes.

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
languages.

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.

A type:

       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.

Richard Riehle