Re: Obstacles for Tcl/Tk commercial application development ?

Óscar Fuentes wrote:
The "error" is at a level that no compiler can catch.

Yes. Thank you for agreeing with me. I'm not sure why you seem to keep agreeing with me then telling me I'm wrong.

declaration/definition that it works on Point2D, so it would reject
working on Point3D.

Cool. Of course, if you never expected "Point" to ever be anything but Point2D, you wouldn't really name it that way. I mean, when you define a string type, do you really call it "StringCharactersUTF8", or do you just call it "String"? When you define a distance in kilometers, do you note that it's "kilometers as defined at the start of the 20th century, in case someone decides to call some other difference kilometers 10 years from now"?

If you define Point, without more information, and
then redefine it so you doesn't break any type check or another
constraint, the compiler is happy.

Thank you for agreeing with me.

Of course, it could break *some* type checks and not others. If it breaks *every* place you use it, then you might as well just define a whole new type. But then how do you track down all the places where you're using the old Point and should be using the new one?

> Why should it care about not using
the third coordinate on the `distance' function? Of course that function
is loosely defined: it should say that it operates on 2D points.

Sure. But this would predict every possible future enhancement. Of course, the year function should mark that it acts on only 2-digit years, and the airline database code should make clear it's an *airplane* customer instead of just a customer, in case the airline ever buys Greyhound, right?

I imagine when the Ariene-5 went down, it was very clear from the name of every type in the code that this was an Ariene-4 acceleration measurement, and not an Ariene-5 acceleration constant.

And of course, if you *do* define it as explicitly a Point2D, and then later decide parts of your program need a Point3D, this still doesn't help you figure out what to change. You've added a new type with new features - you have to examine every use of Point2D anywhere to determine whether the calculations will also work for a Point3D.

Your example is unacceptable on the real practice of a modern
language that uses strong static typing.

1) It was an example.

2) I disagree that you're correct here for non-example 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?

This is an instance of the same problem as your example. There is no
type information,

Oh? So you looked at every piece of code involved in the Y2K cleanup to ensure this? How do you know? If *every* date in the program and everything it talks to is two digits, why would you declare it that way? Do you declare dates in your program as being AD, Gregorian, Earth? Do you declare integer literals to be using Arabic notation? Do you note that in 15E12, the "E" stands for powers of 10 instead of powers of 12?

My software uses diverse types of dates, and there is
zero chance to mess that up.

I'm sure you do. Until you move it to a system with constraints you hadn't been aware of when you created all your date types.

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.

That's because you are using C++, and using it badly.

I already explained: No I'm not. Tell me if it's C, C++, C#, or Unreal Engine.

You can't say "static typing provides guarantees of X", and then
complain that when I show a counter-example it's bad style.

The guarantees that static typing offers are based on the rules you give
to the compiler. No rules, no guarantees. Some languages forces you to
give rules, up to some point, but it's impossible to know that your
rules are consistent, or have sense at all.

Thank you for agreeing with me.

It's not a guarantee *I* can count on if *you* can break it by being a
bad programmer.

If bad programmers are involved, are bets are off :-) The best you can
do is to use tools that helps you to detect and fix the breakage.

Yes! @WOOT! That's my point.

Static typing doesn't give you *any* guarantees of correctness. Maybe it helps good programmers be better, but it doesn't give you any guarantees. That's exactly 100% what I'm saying. Why are you arguing with me? ;-)

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?

For the same reason you inferred that a previous example of mine was
Lisp :-) (it was not Lisp, BTW).

You make my point for me. If my assumption of LISP was wrong based on syntax, why do you dismiss my arguments based on syntax? Really, I'm trying to understand. 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. Yet here, you tell me my faux-dismissal of your point for using LISP is mistaken.

Ok, use Haskell for your examples and you will see how it makes more
difficult to show the limitations of static typing :-)

Are you telling me I can't do exactly the same thing in Haskell that I did in C syntax? Sorry, I don't believe you. I'll ask on the newsgroup I read where there are a couple of Haskell fanatics hanging out what the equivalent syntax would be, but I'm pretty sure there's a way to find the square root of the sum of the squares of the first two values of two three-tuples. :-)

On real production code, things would be a bit more subtle and way more
cool (the system can deduce properties from other properties, etc), but
you can get the idea. `distance' only operates on the types its
constraints permits. Haskell has a very different approach, but in
essence it does (part of) the same. See how you must expose things to
the compiler.

It looks like by the time you've done all that, you already know the possible directions the code is going to go. You haven't really prepared for the entirely unexpected. Of course, it's difficult to give an example of this, since anything I can think of now is likely something already thought of.

You could write routines for using dates, for example, and suddenly it stops working when you go to a country that uses the lunar calendar. Virtually nobody writes calendar software that will statically check that you're using *Earth* years.

Tell me honestly: Do *any* of your calendar package declarations account for relativistic time compression? Do any of your date/time structures have entries for velocity or altitude? :-)

I think your static typing is probably very specific (not sure of the right word - capable of being very precise). It's probably very safe. I disagree it is possible to specify every interesting assumption in advance so as to make the declaration 100% accurate. I also disagree that it would help, because if you pass in a Lorenz-transformed time to most any time math routine, you'll get the wrong answer, so you might as well rewrite all the time stuff from scratch anyway as soon as you find out NASA wants it for their mission to Alpha Centauri.

In other words, once you have Point2D completely and utterly specified, adding Point3D means not changing any Point2D code, so what does it gain you?

Instead of arguing with me, it would be more productive to learn Haskell
or Caml.

I've already read the books on them and played around. I haven't had an opportunity to use them seriously. Primarily because they're apparently so unpopular that nobody has written any of the libraries that make it possible for me to write modern systems in them.

And, of course, I've used that other language I talked about (Hermes, nee NIL), wherein you have not only 100% strict types, but also typestate that keeps you from using values at inappropriate times. Know what? It doesn't prevent you from having to comb through unrelated code when you change types.

What *does* prevent it is strong encapsulation. Hermes had no aliases and no shared code. Every value was in one and only one variable. There were no subroutines: you created a new process, started it running some code, sent that code a message, waited for the answer, and the process exited. *That* was how you did subroutines. Of course the compiler was way sophisticated, just as SQL doesn't really do cartesian products and then apply the selection criteria.

But the typing didn't really help you fix code when types changed all that much. Being able to search for every reference to everything using a particular type helped, but you still had to manually make sure it was still all correct when you were done.

Please note that I'm not trying to convince you that static is
"good" and dynamic is "bad", because things are not so simple. I'm happy
using Tcl on a scenario where its weak, dynamic type system actually is
an advantage. Neither I think static type systems are the absolute cure
for everything, nor for entire domains of problems. You already stated
that static typing can help sometimes, so we agree. Maybe we differ on
the level of RoI static typing has, but that is subjetive, so discussing
that would never reach agreement.

Yah. I'm just discussing in general. I like calling people on things when they make absolute statements that I think are inaccurate, because occasionally I learn a new absolute truth! :-)

What language *are* you using? It sure looks like something built on top of LISP.

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

Relevant Pages

  • Re: More static type fun.
    ... > a Lisp program the type checker can either prove that the ... you loose any advantage of static typing in all parts of your program ... are static type systems that don't get in the way like those of C and ... differ from language to language, so you choose the right one for the ...
    (comp.lang.lisp)
  • Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OO
    ... I certainly want more errors detected at compile time, ... > advocate reaching that goal through beefier type systems. ... in a procedural language, or in an object based language. ... Relativistic mechanics - solves the transaction thing, ...
    (comp.object)
  • Re: Which programming language is better to start
    ... It might be because English is not my native language, ... >> programmer I don't really care, I am not implementing a compiler. ... Yes, but I don't care about how difficult programming the compiler was, ... >> In that kind of situations, static typing gets in the programmer's way ...
    (comp.programming)
  • Re: Why I dont believe in static typing
    ... I blame this failure on the mindset that because the compiler ... Static typing didn't catch the error - no surprise here, ... So here's my litmus test for language testability: ... C++ doesn't qualify: no introspection and a syntax that requires several ...
    (comp.lang.lisp)
  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... holded a bare integer, it's better represented as pair of integers. ... On static type systems, this is no problem: ... falling on that trap on dynamic typing. ... Static typing is targeted at neither of that goals, ...
    (comp.lang.tcl)