ouster@tcl.eng.sun.com (John Ousterhout) writes:
> Come on! All this shows is the inconveniece of using the MFC
> classes. An interface exactly the same as the Tcl one could easily be
> written in C++.
>I invite anyone who believes this to try to do it, and post the results.
>I've had this argument before, and when people do this, one of two things
>happens: either they eventually concede that this is hard to do in C++, or
>they define new C++ APIs that are essentially untyped (e.g. they use
>strings for everything). This just supports my arguments that types get
>in the way of gluing. You can build untyped APIs in strongly typed
>languages, but they tend to be clumsy because the languages are designed
>to encourage strong typing. If you need an untyped approach, you might
>as well use a language designed for that.
Another conclusion that could be drawn is that the type systems of C++, Java
etc. don't allow the convenience that can be achieved using untyped languages.
Type systems are advantageous. The white paper states that TCL/Tk is safe
in that errors are caught. This is a great improvement over C. However, the
problem is *when* the errors are caught -- with a dynamically typed language
errors can easily turn up after the product is delivered. With a statically
typed language there is a *guarantee* that certain classes of errors can not
occur in running programs.
The best of both worlds would be a language that allows (most) of the
convenience of a dynamically typed language but has a static type system.
One such language is TkGofer
http://www.informatik.uni-ulm.de/abt/pm/ftp/tkgofer.html
By using a more advanced type system than C++ or Java it enables convenient
programming which is checked at compile time.
For example, a program which creates a yellow label and a button can be written
as
(taken from
http://www.informatik.uni-ulm.de/fakultaet/abteilungen/pm/ftp/tkgofer/user.html)
ex_button :: IO ()
ex_button = start $
do w <- window [title "My Example2"]
l <- label [text "hello world", background "yellow"] w
b <- button [text "press me", command quit] w
pack (l << b)
This is not far from being as readable as the TCL/Tk equivalent:
toplevel .w
wm title .w "My Example2"
label .w.l -text "Hello World" -bg yellow
button .w.b -text "Press me" -command exit
pack w.l w.b -side left
The packing mechanism provided in TkGofer is actually *more* readable than
TCL/Tk's.
Whereas in TCL/Tk an attempt to write "button .b -command 12" will not be
caught until the button is actually hit, the equivalent TkGofer code will
not be accepted by the compiler.
There is little doubt that so called "scripting" languages are significantly
more productive than traditional "system" languages (C, C++, possibly Java)
for appropriate application domain. The interesting question is which aspects
of "scripting" languages helps in achieving this advantage.
The white paper suggests that dynamic typing is the source of the higher
productivity. I feel that it is more accurate to say that the sort of static
typing used in traditional "system" languages is a disadvantage.
Cheers,
Michael
winikoff@cs.mu.oz.au
http://www.cs.mu.oz.au/~winikoff
--
Michael Winikoff winikoff@acm.org http://www.cs.mu.oz.au/~winikoff
Computer science research fellow. University of Melbourne, Australia.
"Computer Science is no more about computers than astronomy is about
telescopes." -- E. W. Dijkstra
|