Re: Obstacles for Tcl/Tk commercial application development ?

Óscar Fuentes wrote:
You use bad style on a bad language to demonstrate your point,

No. Again, I'm using an over-simplified example to show that static typing doesn't save you from errors when you change the types of things. I'm hoping readers are smart enough to recognise that if the program only has this one function on points, it would be silly to miss converting it. I'm hoping readers are smart enough to be able to generalize to complex systems they've worked on and see that static typing doesn't mean you have no type-induced errors in your code.

Think "Y2K" if you want a big example. Changing dates to have four-digit years from two-digit years didn't make it easy to track down all the places that had to be changed in the code, did it?

Primarily, I'm thinking about where you said this two messages up:

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.

Here, I changed a 2-integer structure to a 3-integer structure. This is a problem, not "no problem". The compiler does *not* refuse to give me an executable until I fix all cases.

You can't say "static typing provides guarantees of X", and then complain that when I show a counter-example it's bad style. It's not a guarantee *I* can count on if *you* can break it by being a bad programmer. That's the difference between safe and unsafe features and languages. It's why any multi-user machine that runs C has to have memory protection hardware, even if *you* never run off the end of an array.

You insist on using examples from C/C++.

Oh? How do you know that's C? Because I use a commonly-understood syntax, you couldn't make the same sort of error in your own preferred language? You can't even tell if it's C, C++, or C#, or (for that matter) the Unreal Engine for video games, all of which have vastly different type systems.

Show me how to write that in the language *you* like, in a way that makes it impossible to forget to update the "distance" function when you add a third dimension. I'd like to see how that works, because that would be a cool bit of functionality to think about.

I'm 100% serious here. I like learning new language features like this, because they're often applicable to other languages too. I want to see how a sophisticated static typing system prevents you from failing to fix something that works with both the old and new types.

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.

Why would it cease to compile? In other words, how does the strong typing find at compile time the fact that this is wrong?

Of course it'll cease to work in the sense of no longer being correct, but it'll compile just fine, because your code still takes two points and still returns a distance. And that is precisely my point.

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

That's my point exactly. Static typing does *not* catch at compile time all errors introduced by changing types. So what difference does it make if I use C-like syntax to demonstrate a point? You're saying this is true of every language, here, aren't you?

My point is that static typing doesn't save you from all typing errors. It's helpful with correctness in only a very narrow way, and indeed is harmful to correctness in other ways, depending on how strict and sophisticated the typing system is.

Now, I'll admit that Tcl may go a bit far, letting you run the "then" part of an "if" without errors when there's an obvious-to-the-programmer "syntax" error in the else part, which is kind of annoying. But assuming you don't redefine "if" to take a string with unbalanced braces as the third argument, there are tools that can point out potential problems statically.

But if you change types in a big system that isn't sufficiently modular that you can track down the uses of those types and fix the calculations, it's not necessarily noticably more accurate than dynamic typing.

On the gripping paw, you could change your point structure to declare a, b, and c, and then you'd be guaranteed to catch all the references to p.x and p.y you'd need to change, and then you could go put it back to x and y and z when you found them all, so I guess it helps that way.

--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
.

Relevant Pages

  • Re: RAD vs. performance
    ... Then you're implementing static typing. ... type checking work to compile time as possible. ... that it is possible to invent dynamically typed languages that compile ...
    (comp.lang.misc)
  • Re: Any experience with "The Last One"?
    ... Certainly strong typing is a skill that should be understood. ... Smalltalk might be a good first language. ... > I've been doing some Python lately, ... most experienced programmers know that a clean compile is no ...
    (comp.lang.c)
  • Re: Any experience with "The Last One"?
    ... Certainly strong typing is a skill that should be understood. ... Smalltalk might be a good first language. ... > I've been doing some Python lately, ... most experienced programmers know that a clean compile is no ...
    (comp.programming)
  • Re: dynamic vs. static: the age-old debate
    ... considered soft typing, ... just lump that in with static typing, since it still goes against the ... Which, of course, is an implementation issue...when your language ... will overflow, leaving the "overflow behavior is undefined" ...
    (comp.lang.misc)
  • dynamic vs. static: the age-old debate
    ... This basically sums up my thoughts on dynamic and static typing. ... many programming language arguments. ... programmers from writing bad code by crippling the language, ...
    (comp.lang.misc)