Re: Obstacles for Tcl/Tk commercial application development ?

Darren New <dnew@xxxxxxxxxx> writes:

Óscar Fuentes wrote:
Lets suppose you are developin the Rally Big Piece of Software, and at
certain point you decide that certain data location, that until now
holded a bare integer, it's better represented as pair of integers. You
have a problem: locating and changing an undetermined amount of code
that makes use, directly or indirectly, of that data.

On static type systems, this is no problem: the compiler will refuse to
give you an executable until you fix all cases. In dynamic type systems,
you must resort to runtime tests (which are not conclusive) to do the
work, case by case, until you fix everything.

Actually, this isn't all that true.

Say you define a data structure that contains two coordinates.

struct Point {int x; int y;}

You have many places in your code where you calculate
distance = sqrt(p.x*p.x + p.y*p.y);

You then change struct Point to be a 3D point. Now you need
distance = sqrt(p.x*p.x + p.y*p.y + p.z*p.z);

The compiler isn't going to give you type errors. You *still* need to
encapsulate stuff so your distance calculations can be found.

Now, with a sufficiently statically-typed language, you might be able
to ask the IDE to point out all the places you have variables of that
type whose members you access or some such, sure. But you're not going
to get a compiler error if you for miss one of the distance
calculations.

Bad style? Sure. But that's the point. Encapsulating changes is how
you make dynamic typing work.

You use bad style on a bad language to demonstrate your point, then
advocate that good style, design and discipline is the solution for not
falling on that trap on dynamic typing.

You insist on using examples from C/C++. On a proper modern static-type
language, you define a function that takes a 2D point and returns a
distance. If you convert your Point to 3D, that function will cease to
work. Of course you can do things on a way that this does not happen,
because there is a possibility that that is the right thing (think of
the lenght of the projected vector over the XY plane).

I come to the conclusion that *every* feature of software development
is targeted at reusing code or putting everything you need to know in
one place.

Static typing is targeted at neither of that goals, although it can help
up to some point. Static typing is about correctness.

--
Oscar
.

Relevant Pages

  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... Static typing doesn't give you *any* guarantees of correctness. ... If my assumption of LISP was wrong based on syntax, why do you dismiss my arguments based on syntax? ... Three paragraphs up, you dismiss my example because you think I'm using C syntax, in spite of that code being completely valid in at least three and possible many more languages with different type systems, and the *ideas* being present in pretty much every language since COBOL. ...
    (comp.lang.tcl)
  • Re: Python from Wise Guys Viewpoint
    ... When I talk about the power of static typing, ... >> be true is extremely easy. ... So even though writing the statement with a proof seems ... The claim of people who favor static type systems is that ...
    (comp.lang.python)
  • Re: Python from Wise Guys Viewpoint
    ... When I talk about the power of static typing, ... >> be true is extremely easy. ... So even though writing the statement with a proof seems ... The claim of people who favor static type systems is that ...
    (comp.lang.lisp)
  • Re: SoA Vs OO
    ... With respect to static typing, ... I'm talking about type systems of existing languages, ... whether you call it downcasting or escaping to dynamic typing or what. ... I prefer to have extensibility in both dimensions, ...
    (comp.object)
  • Re: Python from Wise Guys Viewpoint
    ... >> I fail to see how dynamic typing can confer any kind of advantage here. ... Good type systems are /far/ better. ... >> declaration and definition will be immidiately flagged by the compiler. ... > that have been written without static type systems. ...
    (comp.lang.python)