Re: Obstacles for Tcl/Tk commercial application development ?

Darren New <dnew@xxxxxxxxxx> writes:

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

The "error" is at a level that no compiler can catch. Nor even another
programmer can say for sure that you introduced an error. It is up to
you to give hints to the compiler so it can catch the error. On this
cases, such hints are to explictly say on the `distance' function
declaration/definition that it works on Point2D, so it would reject
working on Point3D. 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. 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.

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.

On complex systems, you give as much information to the compiler as you
can, so it can ensure that your own code is written by your own
rules. Your example is unacceptable on the real practice of a modern
language that uses strong static typing.

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, nor type constraints, so the compiler can do almost
nothing about it. My software uses diverse types of dates, and there is
zero chance to mess that up.

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.

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. Other rules are implicit
(for instance, if you say that data X if of type T1, you can't use it
where data of type T2 is expected) but those are the simplest ones.

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.

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

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.

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

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.

This is from my own programming language (a real programming language,
it is used for production on some heavy-duty projects):

(defstruct Point () ;; This is a type template
(type cartesian void) ;; This says it is in cartesian coordinates.
(type dimension-2 void) ;; This says it is bidimensional.
(slot x 0.0)
(slot y 0.0))

(deftype <point> Point ()) ;; Here, the real type is created

(defun distance (from to)
(cartesian from) ;; `from' must be defined in cartesian coordinates
(dimension-2 from) ;; `from' must have 2 dimensions.
(type-match from to) ;; `from' and `to' must be the same type
(sqrt (... ;; Calculates and returns distance here

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.

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.

Instead of arguing with me, it would be more productive to learn Haskell
or Caml. 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.

[snip]

--
Oscar
.

Relevant Pages

  • Re: RAD vs. performance
    ... Thing if the compiler doesn't let you get away with this. ... command1 and command2 defined as before, and a lot of Common Lisp ... written compiler for a dynamic language isn't inherently slower than ... The difference is that, for static typing, you reject programs ...
    (comp.lang.misc)
  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... But the static type systems don't fix that when you already have external data, ... because the compiler is working for you. ... In the systems where this is rigorously enforced, the typestate is set to the meet of all typestates when you have a flow of control coming from two places. ... the authors of Hermes built declarative tables for each of the statements in the language and generated the compiler therefrom. ...
    (comp.lang.tcl)
  • Re: RAD vs. performance
    ... Thing if the compiler doesn't let you get away with this. ... command1 and command2 defined as before, and a lot of Common Lisp ... written compiler for a dynamic language isn't inherently slower than ... The difference is that, for static typing, you reject programs ...
    (comp.lang.misc)
  • Re: Use of script languages (Was: Tomcat user authentication question.)
    ... still wouldn't be a compiled language. ... for example one of the most dynamic language is LISP and there ... are very efficient compiler for LISP, I remember that, may 20 years ago, ... Static typing versus dynamic typing, ...
    (comp.os.vms)
  • Re: RAD vs. performance
    ... It depends on what the compiler can infer and optimize. ... rationals are another type, which are not supported in the cpu and would ... The difference is that, for static typing, you reject programs ... (rather than typed declarations based language with a class-based types ...
    (comp.lang.misc)