Re: Obstacles for Tcl/Tk commercial application development ?

Cesar Rabak <csrabak@xxxxxxxxxxxx> writes:

Óscar Fuentes escreveu:
Are you teasing me? I guess not, as you write too much for this
discussion being a joke.

proc foo { a b } { return [expr { a + b }] ;# may bomb! }

This should be

proc foo { a b } { return [expr { $a + $b }] ;# may bomb! }

int foo(int a, int b) { return a + b; // just fine }


It depends on what kind of comfort you're after. The may bomb above at
run time against 'just fine' after a compilation step, right?

The distance for 'correctness' may be smaller than you seem to believe,
because in the Tcl example being a dynamic and interpreted language just
after the definition of foo you may run some other code and see the
'bomb' still an error to be corrected in the development. Whereas the C
equivalent would require compile and link before you can even think of
using the function foo.

Yes, if it were C. Statically typed languages are not required to be
"compiled" and linked. Just checked. So static typing does not preclude
exploratory programming the Tcl way.

Because most of the bugs due type system are not due errors on the
internal use of the types but due the conversions we as programmers have
to do in order our programs be useful.

In your oversimplified example above the most probable error will not
feeding something different than two ints in the foo function but
overflows due limited number of bits, misconversion from user entry to
the program, etc.

A failure on the routine that converts the data is out of the
application limits of type checking. After all, it does not magically
guarantees that a monkey punching the keyboard will produce correct
code, as Darren requires to take static type systems seriously. :-) So,
efectively, you always can return 42 from the routine that converts
strings to integers and the compiler will not complain.

As for the overflow, as explained on a previous message, you need to
think on the real type you are using. It is not "an integer", but a
signed integer modulo 2^32 (on some platform). If you want real
integers, you have them, either native or through libraries. This,
again, does not show a weakness on static type systems, as it affects
dynamic ones as well.

Assymptotically the type system becomes less and less useful until its
contribution to the robustness of the systems is marginal and the only
attempt of having a program with less errors is thorough testing and and
a lot of walkthroughs.

Precisely, as the program grows, static type systems comes more and more
handy. It is easy to remember that some data is represented by a three
element list on a 200 lines long Tcl program, but not on a 100,000 lines
one where ten programmers are involved, and years after the original
writers left the project. After all, static typing just provides a very
effective way of checking certain properties of the program. Without
this, for a large application, you'll need a very large number of test
cases.

Fair enough. From my part it seems that these discussions about
'advantages' of static type system in a forum for a non typed
language¹ tend to over advertise their 'advantages' not taking in
account the different approaches to development brought by the
paradigms.

Please read again my messages on this thread. I've never said that
dynamic typing is bad, wrong, or inferior. But if someone is attacking
the concept of static types and I'm defending it, it's easy to think,
from the outside, that I'm against dynamic type systems. That's not true
(I repeat it for the n-th time).

Yes exactly due the fact that for languages being reasonable useful
you need to get rid of an annoying 'type cop' otherwise you end up
programming by demonstrating theorems (like Haskell) that shines in
Computer Science but are not capable of producing a GUI type system so
you have to use the syntax to call external libraries without any
advantage and, worse, get crippled by the false expectation of the
automation of the language for catching errors.

I share your gripes about Haskell, up to certain point. OTOH, Haskell
is not only a statically typed language, but a pure functional language
too, and so it encloses the programmer on a straightjacket which may be
too restrictive for most people (including me). It is important to
distinguish from where the annoyance is coming, to avoid cursing the
wrong feature.

And for the `type cop', is like all cops. Sometimes you hate them,
sometimes they save your life. :-) There are some cops nicer than
others, and Haskell's one, although dressed in a really elegant uniform,
may be tough to deal with.

--
Oscar
.

Relevant Pages

  • Re: Questions about Common Lisp
    ... introduce bugs. ... Your paper, while interesting, does not show static type systems ... Type systems prove the absence of of a certain kind of error. ... languages are hard to reason about, ...
    (comp.lang.scheme)
  • Re: Questions about Common Lisp
    ... introduce bugs. ... Your paper, while interesting, does not show static type systems ... Type systems do not prove "correctness". ... languages are hard to reason about, ...
    (comp.lang.scheme)
  • Re: More static type fun.
    ... >> absence of certain behaviors by classifying program phrases ... With a static type system you can prove the absence of certain ... static type systems, you should choose a language that has one. ...
    (comp.lang.lisp)
  • 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)
  • 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.lisp)