Ousterhout and Tcl lost the plot with latest paper

[Chris Bitmead]

ch...@adi.COM (Franklin Chen) writes:

> I've looked at the paper, and found it extremely misleading for its
> omissions and factual inaccuracies. In particular, I was baffled that
> there was no mention _whatsoever_ of advanced languages such as
> Scheme, ML, and Haskell--languages that to me seem most promising as
> foundations for safe, efficient, and expressive prototyping/scripting
> as well as general purpose programming.
>
> If anyone is interested, I can go into detail about everything I found
> misleading about Ousterhout's paper. I encourage anyone else who
> cares to do the same; perhaps an eventual unified response to
> Ousterhout is called for.

The essence of Ousterhout's argument seems to be this... What is the
ultimate sports car (programming language)? A '59 Cadillac complete
with fins and powerful engine (C++) or a VW beetle with it's elegant
simplicity (Tcl). John puts forward a strong argument that the beetle
is the ultimate sports car, while conveniently ignoring that it is
possible to combine the powerful engine of the Caddy with the elegance
of the VW and come up with a Porche 959 (Scheme or Lisp or ML or many
others).

These are my comments on his paper. Remember that Sun is pushing Tcl
for some obscure reason, and Ousterhout is apparently working for Sun
now, so I guess we'd expect something like this, but we can't let him
get away with this. Imagine... C and TCL. The worst of all possible
worlds.

My comments are interspersed with his paper below...

>Scripting: Higher Level Programming
> for the 21st Century
> John K. Ousterhout
>
> Abstract Scripting languages such as Visual Basic and Tcl
>represent a very different style of programming than system
>programming languages such as C or Java. Scripting languages are
>designed for "gluing" applications; they use typeless approaches to
>achieve a higher level of programming and more rapid application
>development than system programming languages. Increases in computer
>speed and changes in the application mix are making scripting
>languages more and more important for applications of the
>future. Whereas object-oriented approaches have largely failed to
>increase software reuse or reduce development costs, scripting
>languages have succeeded.
>
>1 Introduction
>
>As we near the end of the 20th century a fundamental change is
>occurring in the way people write computer programs. The change is a
>transition from system programming languages such as C or C++ to
>scripting languages such as Visual Basic or Tcl. Although many people
>are participating in the change, few people realize that it is
>occurring and even fewer people know why it is happening. I am writing
>this paper to call attention to the change and to explain why
>scripting languages will handle many of the programming tasks of the
>next century better than system programming languages.
>
>Scripting languages are designed for different tasks than system
>programming languages, and this leads to fundamental differences in
>the languages. System programming languages were designed for
>building data structures and algorithms from scratch, starting from
>the most primitive computer elements such as words of memory. In
>contrast, scripting languages are designed for gluing: they assume the
>existence of a set of powerful components and are intended primarily
>for connecting components together. System programming languages are
>strongly typed to help manage complexity, while scripting languages
>are typeless to simplify connections between components and provide
>rapid application development.
>
>Scripting languages and system programming languages are
>complementary, and most major computing platforms since the 1960's
>have provided both kinds of languages. However, several recent trends,
>such as faster machines, the increasing importance of graphical user
>interfaces and component architectures, and the growth of the
>Internet, have greatly increased the applicability of scripting
>languages. These trends will continue over the next decade, with
>scripting languages used for more and more applications and system
>programming languages used primarily for creating components.
>
>2 System programming languages
>
>In order to understand the differences between scripting languages and
>system programming languages, it is important to understand how system
>programming languages evolved. In the earliest days of computing,
>computers were programmed by entering instructions and data directly
>into the computer in binary form. This approach was quickly replaced
>by symbolic assembly languages. Assembly languages represent a program
>textually with one statement for each machine instruction. The fields
>of the instruction are specified symbolically: for example, the symbol
>ADD might be used to represent the opcode for an addition instruction
>and SP might be used to specify the register that serves as stack
>pointer. An assembler reads the statements, converts symbols to the
>corresponding binary values, and generates a binary program suitable
>for execution.
>
>The use of textual symbols in assembly language makes programs
>substantially easier to write than binary approaches while still
>providing complete control over the machine. However, assembly
>language suffers from three defects. First, it requires the programmer
>to write one line of code for each instruction or variable, which
>becomes tedious as programs grow in size. Second, assembly language
>forces programmers to deal with many low-level details such as
>register allocation and procedure calling sequences. Third, assembly
>language provides almost no structure; for example, all instructions
>have roughly the same appearance and integer and floating-point
>variables are declared in the same way. As a result, it is difficult
>to write and maintain large programs in assembly language.
>
>By the late 1950's higher level languages such as Fortran and Algol
>began to appear. In these languages statements no longer correspond
>exactly to machine instructions; a compiler translates each statement
>in the source program into a sequence of binary instructions. Over
>time a series of system programming languages evolved from Algol,
>including such languages as PL/1, Pascal, C[4], C++[7], and
>Java[1]. System programming languages allow large applications to be
>developed much more quickly than assembly languages while providing
>nearly the same level of efficiency. As a result, they have almost
>completely replaced assembly language for the development of large
>applications.

A brave beginning! Ousterhaut tries to characterise Tcl as some sort
of next generation language that is some sort of higher level
abstraction above non-scripting languages.

Talk about turning a bug into a feature! Apparently because Tcl lacks
fundamental language concepts such as data structures, and a type
system, it is now superior because it is "simple". I guess that makes
BASIC another superior language of the future. NOT!

>System programming languages differ from assembly languages in two
>ways: they are higher level and they are strongly typed. The term
>"higher level" means that many details are handled automatically so
>that programmers can write less code to get the same job done. For
>example:

Where did this very dubious definition of a "system programming
language" come from?? I don't think there is any official definition,
but these are the attributes I personally would use to describe a
systems language. They certainly don't include Ousterhout's
definition...

A system programming language should be...
* Capable of being compiled for efficiency
* Suitable for building complex data structures and algorithms.
* Suitable for accessing the full capabilities of the operating
system in a convenient fashion.

> Register allocation is handled by the compiler so that
>programmers need not write code to move information between registers
>and memory. Procedure calling sequences are generated automatically
>so that programmers need not worry about moving arguments to and from
>the call stack. Programmers can use simple keywords such as while and
>if for control structures; the compiler generates all the detailed
>instructions to implement the control structures.
>
>On average, each line of code in a system programming language causes
>about five machine instructions to be executed, compared to one
>instruction per line in assembly language.

And then Ousterhout goes on to argue that because a one line Tcl
command can create a GUI button, therefore it is a higher level
language. What a lot of rot! One line of C code can cause 10 billion
instructions to be executed if it is a function call. And the Tcl
button creation command is basicly a function call. Absolutely no
difference. Very misleading.

>Various studies have shown
>that programmers can write roughly the same number of lines of code
>per year regardless of language[2], so system programming languages
>allow applications to be written much more quickly than assembly
>languages.
>
>The second difference between assembly languages and system
>programming languages is typing. The term "typing" refers to the
>degree to which the meaning of information is specified in advance of
>its use.

Ousterhout conveniently excludes the whole spectrum of dynamically
typed languages, not to mention strongly typed languages with type
inference like ML.

>In a strongly typed language the programmer declares how each
>piece of information will be used and the language prevents the
>information from being used in any other way. In a weakly typed
>language there are no a priori restrictions on how information can be
>used: the meaning of information is determined solely by the way it is
>used, not by any initial promises.

A fairly vague assertion, which he continues to repeat over and over
without examples.

>Modern computers are fundamentally typeless at heart: any word in
>memory can hold any kind of value, such as a character, an integer, a
>pointer, or an instruction. The meaning of a value is determined by
>how it is used: if the program counter points at a word of memory then
>it is treated as an instruction; if a word is referenced by an integer
>add instruction then it is treated as an integer; and so on. The same
>word can be used in different ways at different times.

Modern computers are not "typeless"! While I find this whole argument
meaningless anyway, if you want to make the comparison, you would say
that computers are dynamically typed, but nevertheless typed. In that
respect they compare better to dynamically typed languages like
Lisp. While a piece of computer memory can hold data of any type,
(Like a lisp variable), computer instructions only operate on the
correct type. You can't use an add instruction and pass it a string
with some ascii numbers in it (Similar to Lisp).

>Today's system programming languages are strongly typed. For example:

Are they? First Ousterhout defines a strongly typed languages as
system programing languages. Now he tells us that systems languages
are strongly typed. Well I guess if you define it that way in advance
it must be so.

> Each variable in a system programming language must be declared
>with a particular type such as integer or pointer to string, and it
>must be used in ways that are appropriate for the type. In assembly
>languageany variable can be used in any way. Data and code are
>totally segregated in system programming languages, whereas they are
>interchangeable in assembly languages; it is difficult or impossible
>to create new code on the fly in a system programming language.
>Variables can be collected into structures or objects with
>well-defined substructure and procedures or methods to manipulate
>them; an object of one type cannot be used where an object of a
>different type is expected.
>
>Typing makes large programs more manageable by clarifying how things
>are used and differentiating between things that must be treated
>differently. Compilers can use type information to detect certain
>kinds of errors, such as an attempt to use a floating-point value as a
>pointer.
>
>To summarize, system programming languages are designed to handle the
>same tasks as assembly languages, namely creating applications
>starting from scratch. System programming languages are somewhat
>higher level and much more strongly typed than assembly
>languages. This allows applications to be created more rapidly and
>managed more easily with only a slight loss in performance. See Figure
>1 for a graphical comparison of binary code, assembly language, and
>several system programming languages.
>
>
>3 Scripting languages
>
>Scripting languages such as Perl[8], Tcl[6], Visual Basic, and the
>Unix shells represent a very different style of programming than
>system programming languages. Scripting languages assume that there
>already exists a collection of useful components written in other
>languages. Scripting languages aren't intended for writing
>applications from scratch; they are intended primarily for plugging
>together components. For example, Tcl and Visual Basic are used to
>arrange collections of user interface controls on the screen while
>Unix shell scripts are used to assemble filter programs into
>pipelines. Scripting languages are often used to extend the features
>of components but they are rarely used for complex algorithms and data
>structures; features like these are usually provided by the
>components. Scripting languages are sometimes referred to as glue
>languages or system integration languages.
>
>In order to simplify the task of connecting components, scripting
>languages tend to be typeless: all things look and behave the same so
>that they are interchangeable. For example, in Tcl or Visual Basic a
>variable can hold a string one minute and an integer the next. Code
>and data are often interchangeable, so that a program can write
>another program and execute it on the fly. Scripting languages are
>often string-oriented, since this provides a flexible representation
>for many different things.

As we all know, "proper" programming languages like Lisp can also
generate and execute code on the fly. What Lisp programmers also know
is that in most situations, doing so is a sign of a bad design. In the
case of Tcl, the ability to do so is just a band-aid for the
limitations of the language, that Lisp style languages generally don't
need, but nevertheless do have.

>A typeless language makes it much easier to hook together
>components. There are no a priori restrictions on how things can be
>used, and components and values are represented in a uniform
>fashion. Thus any component or value can be used in any situation;
>components designed for one purpose can be used for totally different
>purposes never foreseen by the designer. For example, in the Unix
>shells, all filter programs read a stream of bytes from an input and
>write a string of bytes to an output so any two programs can be
>connected together simply by attaching the output of one program to
>the input of the other.
>
>The strongly typed nature of system programming languages discourages
>reuse. Programmers are encouraged to design a variety of incompatible
>interfaces. Each interface requires objects of specific types and the
>compiler prevents any other types of objects from being used with the
>interface, even if that would be useful. In order to use a new object
>with an existing interface, conversion code must be written to
>translate between the type of the object and the type expected by the
>interface. This in turn requires recompiling part or all of the
>application, which isn't possible in the common case where the
>application is distributed in binary form.

A fairly poor attempt to gloss over the issues here. Converting
everything to strings does not solve anything except in the most
trivial cases. Just because you encode some complex concept into a
single string doesn't mean that the type information isn't still
there. The simplest case is of course passing a string to an add
function. At run time you've still got to know that the string
contains a number. Again Ousterhout conveniently ignores the
dynamically typed languages and glosses over the real issues.

>To see the advantages of a typeless language, consider the following
>Tcl command:
>
>button .b -text Hello! -font {Times 16} -command {puts hello}
>
>This command creates a new button control that displays a text string
>in a 16-point Times font and prints a short message when the user
>clicks on the control. It mixes six different types of things in a
>single statement: a command name (button), a button control (.b),
>property names (-text, -foreground, and -command), simple strings
>(Hello! and hello), a font name (Times 16) that includes a typeface
>name (Times) and a size in points (16), and a Tcl script (puts
>hello). Tcl represents all of these things uniformly with strings. In
>the button example the properties may be specified in any order and
>unspecified properties are given default values; more than 20
>properties were left unspecified in the example.
>
>The button example requires about 25 lines of code in three procedures
>when implemented in C++ with Microsoft Foundation Classes. Just
>setting the font requires 7 lines of code:
>
>LOGFONT lf;
>
>memset(&lf, 0, sizeof(lf));
>
>lf.lfHeight = -16;
>
>strcpy(lf.lfFaceName, "Times New Roman");
>
>CFont *fontPtr = new CFont();
>
>fontPtr->CreateFontIndirect(&lf);
>
>buttonPtr->SetFont(fontPtr);

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

>Almost all of this code is a consequence of the strong typing:
>variables lf and fontPtr must be declared, fields in the font
>descriptor structure lf must be filled in individually, then a new
>object of type CFont must be created from lf in order to match the API
>of the button's SetFont method. In Tcl, the essential characteristics
>of the font (typeface Times, size 16 points) can be used immediately
>with no declarations, intermediate structures, or
>conversions. Similarly, in C++ the behavior for the button must placed
>in a separately declared method, whereas in Tcl it can be included
>directly in the command that creates the button.
>
>It might seem that the typeless nature of scripting languages could
>allow errors to go undetected, but in fact scripting languages are
>just as safe as system programming languages. For example, an error
>will occur if the font size specified for the button example above is
>a non-integer string such as xyz.

Huh??? Presumably he is refering to the line...
lf.lfHeight = -16;

Surely this would give a type error if it were changed to...
lf.lfHeight = "xyz";

>The difference is that scripting
>languages do their error checking at the last possible moment, when a
>value is used. Strong typing allows errors to be detected at
>compile-time, so the cost of run-time checks is avoided. However, the
>price to be paid for this efficiency is more conservative restrictions
>on how information can be used: this results in more complex and less
>flexible programs.
>
>Another key difference between scripting languages and system
>programming languages is that scripting languages are usually
>interpreted whereas system programming languages are usually
>compiled.

"Usually" perhaps, but not always. Surely the best solution is a
language which can easily accomodate both options? Tcl does not at all
easily support compilation. C++ does not easily support
interpretation. There are many languages which readily support both.

>Interpreted languages provide rapid turnaround during
>development by eliminating lengthy compile times. Interpreters also
>allow powerful effects to be achieved by generating code on the
>fly. For example, a Tcl-based Web browser can parse a Web page by
>translating the HTML for the page into a Tcl script using a few
>regular expression substitutions. It then executes the Tcl script to
>render the page on the screen. Or, an application can be extended by
>downloading code into it.
>
>Scripting languages tend to be less efficient than system programming
>languages, in part because they use interpreters instead of compilers
>but also because their basic components are chosen for power and ease
>of use rather than an efficient mapping onto the underlying
>hardware. For example, scripting languages tend to use variable-length
>strings in situations where a system programming language would use a
>binary value that fits in a single machine word, and scripting
>languages often use hash tables where system programming languages use
>indexed arrays.

But why? If we accept that scsh is a scripting language (which clearly
it is), it suffers from neither of these drawbacks.

>Fortunately, the performance of a scripting language isn't usually a
>major issue. Applications for scripting languages are generally
>smaller than applications for system programming languages, and the
>performance of a scripting application tends to be dominated by the
>performance of the components, which are typically implemented in a
>system programming language.

This is an often put forward argument that falls over time and time
again when reality hits. Applications might start off small, but then
people want more features, more performance, more
everything. Eventually using the poor scripting languages break down
because they don't give you the performance or data structures or
abstraction mechanisms to support what you're doing. Things become
more and more messy. You keep having to go back and rewrite things in
your "systems" languages.

Sure Tcl and C can be a lot faster than C alone. But then C is an
appalling benchmark against which to make judgements.

>Scripting languages are higher level than system programming
>languages, in the sense that a single statement does more work on
>average. A typical statement in a scripting language executes hundreds
>or thousands of machine instructions, whereas a typical statement in a
>system programming language executes about five machine
>instructions. Part of this difference is because scripting languages
>use interpreters, which are less efficient than the compiled code for
>system programming languages. But much of the difference is because
>the primitive operations in scripting languages have greater
>functionality. For example, in Perl it is about as easy to perform a
>regular expression substitution as it is to perform an integer
>addition. In Tcl, a variable can have traces associated with it so
>that setting the variable causes side effects; for example, a trace
>might be used to notify a control whenever the value of a variable
>changes, so that the variable's value can be displayed continuously on
>the screen.

At this stage the argument gets to the utterly riduclous
stage. According to Ousterhout, because Scheme has only 5 "primitive"
operations which execute only a few instructions, therefore to do
anything in Scheme must be orders of magnitude more verbose than in
Tcl which has lots of primitive operations. NOT!

The convenience of performing complicated tasks is partly because of
the elegance of the language, but mostly has a lot to do with the
design of the libraries it has associated with it. Naturally Tcl can
do a lot of things with a few lines of code, because it is supported
by truckloads of library code doing the real work. But that is a
benefit of Tk. Not Tcl.

>Because of the features described above, scripting languages allow
>very rapid development for applications that are gluing in
>nature. Table 1 provides anecdotal support for this claim. It
>describes several applications that were implemented in a system
>programming language and then reimplemented in a scripting language,
>or vice versa.

This supposed comparison has a lot of flaws.

- It only makes comparison with C, C++ and Java. Hardly a wide enough
selection to draw the sweeping conclusions he then goes on to draw.

- comp.lang.tcl is hardly an unbiased source of information.

- It's not clear how much advantage was drawn from having the code
already implemented in the "systems" language

- There is no mention about whether the "systems" language
implementation used an extensive set of libraries such as that which
comes with Tcl, or whether they decided to reinvent every wheel
themselves, as so often happens on C and C++ projects.

- While the Java comparison makes a better one than C and C++, Java is
a far from mature technology with as yet poor library support.

In summary, the table is completely meaningless without further
information.

>The scripting versions typically required 5-10x less code or
>development time than the system programming versions. Applications
>that involved more complex algorithms or data structures, such as the
>last example in the table, benefit less from a scripting language than
>applications that are mostly gluing.
>
>To summarize, scripting languages are designed for gluing
>applications. They provide a higher level of programming than assembly
>or system programming languages, much weaker typing than system
>programming languages, and an interpreted development
>environment. Scripting languages trade off execution efficiency for
>speed of development. Figure 1 compares scripting languages with
>system programming languages graphically.
>
>4 Different tools for different tasks
>
>A scripting language is not a replacement for a system programming
>language or vice versa. Each is suited to a different set of
>tasks. For gluing and system integration, applications can be
>developed 5-10x faster with a scripting language; system programming
>languages will require large amounts of boilerplate and conversion
>code to connect the pieces, whereas this can be done directly with a
>scripting language. For complex algorithms and data structures, the
>strong typing of a system programming language makes programs easier
>to manage. Where execution speed is key, a system programming language
>can often run 10-20x faster than a scripting language: the flexibility
>provided by the scripting language results in more run-time checks.
>
>In deciding whether to use a scripting language or a system programming language for a particular task, consider the following questions:
>
> Is the application's main task to connect together pre-existing components?
> Will the application manipulate a variety of different kinds of things?
> Will the application's functions evolve rapidly over time?
> Does the application need to be extensible?

Pretty much all programming tasks have the above attributes. Go and
ask a programmer working on a project if...

- They will save time by using pre-existing components.
- The application has to do different things
- The application will change over time
- The application needs to be extensible.

Of course these statements are the definition of a normal evolving
software project.

>"Yes" answers to these questions suggest that a scripting language will work well for the application. On the other hand, "yes" answers to the following
>questions suggest that an application is better suited to a system programming language:
>
> Does the application implement complex algorithms or data structures?
> Does the application manipulate large datasets (e.g. all the pixels in an image) so that execution speed is critical?
> Are the application's functions well-defined and changing only slowly?

Here is the problem with scripting languages. Most applications start
off with a simple model and structure, a modest sized dataset, and a
well-defined problem. But then guess what? People want more features
leading to more complex algorithms and the need for data
structures. People start to feed larger and larger datasets into the
program. And the requirements of the program start to change and
change. Then you have to start all over from scratch because you find
that Tcl doesn't scale.

>Most of the major computing platforms over the last 30 years have
>provided both system programming and scripting languages. For example,
>one of the first scripting languages was JCL (Job Control Language),
>which was used to sequence job steps in OS/360. The individual job
>steps were written in PL/1, Fortran, or assembler language, which were
>the system programming languages of the day. In the Unix machines of
>the 1980's, C was used for system programming and shell programs such
>as sh and csh for scripting. In the PC world of the 1990's, C and C++
>are used for system programming and Visual Basic for scripting. In the
>Internet world that is taking shape now, Java is used for system
>programming and languages like JavaScript, Perl, and Tcl are used for
>scripting.
>
>Scripting and system programming are symbiotic. Used together, they
>produce programming environments of exceptional power: system
>programming languages are used to create exciting components which can
>then be assembled using scripting languages. For example, much of the
>attraction of Visual Basic is that system programmers can write VBX
>components in C and less sophisticated programmers can then use the
>components in Visual Basic applications. In Unix it is easy to write
>shell scripts that invoke applications written in C.

While Unix shell scripts are a big improvment on what existed
pre-Unix, they still have a lot of problems which could be better
solved using a different paradigm. For example, a lot of shell script
work involves parsing and re-parsing the text streams. One can imagine
a paradigm where objects instead of strings are passed around. Let's
imagine an "ls" directory lister which generates a collection of
directory entry objects. Each entry object has a print method which
prints the same as the Unix style "ls". Thus typing "ls" at the
keyboard does the same thing. And if there is some special reason why
you want to use the pure text version in a script you can do so. But
much more typically you want to use some of the fields in the "ls"
output to do calculations. "Which directory entries are older than
12/Feb/1997?" VERY difficult to do with Unix shell. Trivial in a scsh
or CLOS style language. One can imagine writing something like (map
(lambda (d) (< (file-time d) "12/Feb/1997")) (ls))

>One of the
>reasons for the popularity of Tcl is the ability to extend the
>language by writing C code that implements new commands.
>
>5 Scripting is on the rise
>
>Scripting languages have existed for a long time, but their importance
>has increased in recent years because the application mix has shifted
>more towards gluing applications. Three examples of this shift are
>graphical user interfaces, the Internet, and component frameworks.
>
>User interfaces are fundamentally gluing applications: the goal is not
>to create new functionality, but to make connections between a
>collection of graphical controls and the internal functions of the
>application. Scripting languages have always been the primary vehicle
>for creating user interfaces, whether the user interface was a card
>deck as in OS/360, a command line on a terminal as in Unix, or a
>graphical user interface as with Tcl or Visual Basic. With the arrival
>of graphical user interfaces (GUIs) in the 1980's the richness of user
>interfaces increased dramatically, as did the development effort
>required to create them. The GUI accounts for half or more of the
>total effort in many programming projects.
>
>I am not aware of any rapid-development environments for GUIs based on
>a system programming language.

Since Ousterhouts world view only includes "system" languages and
"scripting" languages, and his definitions of these excludes lots of
better and much more viable alternatives, his whole argument amounts
to a straw man.

>Whether the environment is Windows,
>Macintosh Toolbox, or Unix Motif, GUI toolkits based on languages like
>C for C++ have proven to be hard to learn, clumsy to use, and
>inflexible in the results they produce. Some of these tools have very
>nice graphical tools for designing screen layouts, but things become
>difficult as soon as the designer begins writing code to provide the
>behaviors for the interface elements. All of the best
>rapid-development GUI environments are based on scripting languages:
>Visual Basic on the PC, HyperCard on the Macintosh, and Tcl on
>Unix. Thus scripting languages have risen in popularity as the
>importance of GUIs has increased.
>
>The growth of the Internet has also popularized scripting
>languages. The Internet is a gluing environment. It doesn't create any
>new computations or data; it simply makes a huge number of existing
>things easily accessible. The ideal language for most Internet
>programming tasks will be one that makes it possible for all the
>connected components to work together, i.e. a scripting language. For
>example, Perl has become popular for writing CGI scripts and
>JavaScript is popular for scripting in Web pages.
>
>The third example of scripting-oriented applications is component
>frameworks. Although system programming languages work well for
>creating components, the task of assembling components into
>applications is better suited to scripting. Without a good scripting
>language to manipulate the components, much of the power of a
>component framework is lost. This may explain in part why component
>frameworks have been more successful on PCs (where Visual Basic
>provides a convenient scripting tool) than on other platforms such as
>Unix/CORBA where scripting is not included in the component framework.
>
>Another reason for the increasing popularity of scripting languages is
>the ever-increasing speed of computer hardware. It used to be that the
>only way to get acceptable performance in an application of any
>complexity was to use a system programming language. In some cases
>even system programming languages weren't efficient enough, so the
>applications had to be written in assembler. However, machines today
>are 100-500 times faster than the machines of 1980. Many applications
>can be implemented in an interpreted language and still have excellent
>performance (for example, a Tcl script can manipulate collections with
>hundreds or thousands of objects and still provide good interactive
>response). As computers get faster, fewer and fewer applications will
>need to be implemented in a system programming language to get
>adequate performance.
>
>One final reason for the increasing use of scripting languages is a
>change in the programmer community. Twenty years ago most programmers
>were sophisticated programmers working on substantial
>projects. Programmers in that day expected to spend several months to
>master a language and its programming environment, and system
>programming languages were designed for such programmers. However,
>since the arrival of the personal computer, more and more casual
>programmers have joined the programmer community. For these people,
>programming is not their main job function; it is a tool that they use
>occasionally to help with their main job. Examples of casual
>programming are writing macros for a spreadsheet or writing a simple
>database query. Casual programmers are not willing to spend months
>learning a system programming language, but they can often learn
>enough about a scripting language in a few hours to write useful
>programs. Scripting languages are easier to learn because they have
>simpler syntax than system programming languages and because they omit
>complex features like objects and threads.

Oh really?? Scripting languages are simpler and easier to learn than
systems languages? That is a very broad claim to make. It is also a
lot of rot. Take perl for example. A difficult language to truely
understand and master. Each language has it's own unique
characteristics and difficulties. It has nothing to do with whether it
is a supposedly "systems" or "scripting" language.

>For example, compare Visual
>Basic with Visual C++; few casual programmers would attempt to use
>Visual C++, but many have been able to build useful applications with
>Visual Basic.

Yeah right. Use C++ as a comparison against BASIC. Why not compare
Perl to Scheme? Who wins then?

>Even today the number of applications written in scripting languages
>is much greater than the number of applications written in system
>programming languages. On Unix systems there are many more shell
>scripts than C programs, and under Windows there are many more Visual
>Basic programmers and applications than C or C++. Of course, most of
>the largest and most widely used applications are written in system
>programming languages, so a comparison based on total lines of code or
>number of installed copies may still favor system programming
>languages. Nonetheless, scripting languages are already a major force
>in application development and their market share will increase in the
>future.
>
>6 The failure of object-oriented programming
>
>Scripting languages have received little attention in the programming
>language community or in the press; instead, most of the attention has
>been focused on object-oriented programming languages such as C++ and
>Java. Object-oriented programming is widely believed to represent the
>next major step in the evolution of programming
>languages. Object-oriented features such as strong typing and
>inheritance are often claimed to reduce development time, increase
>software reuse, and solve many other problems including those
>addressed by scripting languages.
>
>Unfortunately, there is not much evidence that object-oriented
>programming produces the benefits claimed for it. Some projects have
>claimed success with object-oriented languages, but others have
>reported that languages like C++ actually made software management
>problems worse.

So object oriented technology is condemned because of the failure of
C++? Yeah right.

>I do not know of any studies showing substantial
>reductions in development costs due to object-oriented programming,
>and some language experts are now beginning to speak out against
>object-oriented programming [3].
>
>The reason why object-oriented programming has not lived up to
>expectations is that it doesn't raise the level of programming or
>encourage reuse. Programmers still work with small basic units that
>must be described and manipulated in great detail. In principle,
>powerful library packages could be developed, and if these libraries
>were used extensively it could effectively raise the level of
>programming. However, not many such libraries have come into
>existence.

Oh really?

>The strong typing of object-oriented languages encourages
>narrowly defined packages that are hard to reuse. Each package
>requires objects of a specific type; if two packages are to work
>together, conversion code must be written to translate between the
>types required by the packages.

Again this argument about "conversion code". Hard to argue with since
he gives no examples. A vague argument is an unassailable argument.

>Another problem with object-oriented languages is their emphasis on
>inheritance. Implementation inheritance, where one class inherits part
>of its implementation from another, is simply a bad idea. It binds the
>implementations of classes together so that neither can be understood
>without the other: the subclass cannot be understood without knowing
>how the inherited methods are implemented in the superclass, and the
>superclass cannot be understood without knowing how its methods are
>inherited in subclasses. In a complex class hierarchy, no individual
>class can be understood without understanding all the other classes in
>the hierarchy. Even worse, a class cannot be separated from its
>hierarchy for reuse. Multiple inheritance only makes these problems
>worse. Implementation inheritance causes the same intertwining and
>brittleness that have been observed when goto statements are
>overused. As a result, object-oriented systems suffer from complexity
>and lack of reuse.

Here we have proof that Ousterhout has totally lost the plot with this
paper. It's hard to know where to start in critisizing such a brazen
set of lies and foolish claims.

The simplest way of pulling all this stupidity to the ground seems to
be to point Ousterhout to his own work in Tcl/Tk.

I would describe the essence of object oriented programing as 2
things...

- Polymorphism and/or interface inheritance... The ability for
different types of objects to react to the same message in different
but appropriate ways.

- Implementation inheritance... The ability to re-use part of an
already existing class'es implementation to make newer and more
complex and more specific classes.

NOW LOOK AT TK!!!! It's object oriented!!!!!!! It's based on all the
principles that Ousterhout is deriding. I must say this makes him look
like a fool.

>Scripting languages, on the other hand, have actually generated
>significant software reuse. They use a model where interesting
>components are built in a system programming language and then glued
>together into applications using the scripting language. This division
>of labor provides a natural framework for reusability. Components are
>designed to be reusable, and there are well-defined interfaces between
>components and scripts that make it easy to use components.

Apparently "well-defined interfaces" and the assembling of
"interesting components" are the sole domain of untyped scripting
languages. Amazing.

>For
>example, in Tcl the components are custom commands implemented in C;
>they look just like the builtin commands so they are easy to invoke in
>Tcl scripts. In Visual Basic the components are VBX or ActiveX
>extensions, which can be used by dragging them from a palette onto a
>form.
>
>7 What will happen to system programming languages?
>
>It might seem from the above arguments that scripting languages will
>eventually replace system programming languages entirely. After all, a
>similar effect occurred with assembly language. In the early 1960's,
>most serious programming was done in assembly; higher level languages
>like Fortran and Algol were widely viewed as too slow for serious
>programming tasks. But the quality of compiled code improved and
>machines got faster, so the performance differences were less
>important. At the same time, it became clear that programmers were
>substantially more productive with high level languages than with
>assembly. Over time, more and more people decided that it was worth
>giving up a little speed to get faster application development. Today,
>assembly language is rarely used, even for the most
>performance-critical code. The same arguments might be made for
>scripting versus system programming: scripting does not use the
>computer as efficiently as system programming, but it enables much
>faster development.

Spare me!! A world where Tcl rules, and data structures are the sole
realm of specialized "systems programmers".

>However, I doubt that system programming languages will disappear to
>the same extent that assembly languages have. Scripting languages are
>not designed to serve all purposes. They work particularly well for
>gluing together components, but they are not as suitable for creating
>the components. The strong typing of system programming languages
>makes it easier to build complex data structures and algorithms; for
>example, trees and other pointer-rich structures are easier to
>implement in a system programming language than a scripting
>language. A scripting language is great for writing a database query,
>but if you're writing a database engine you're better off with a
>system programming language.
>
>Thus system programming languages will continue to play an important
>role in computers, but they will be used primarily for creating
>components and fixed-function applications such as database
>servers. Many of the more glue-like areas where system programming
>languages are used today, such as GUIs and enterprise applications,
>will come to be dominated by scripting languages.
>
>8 Conclusion
>
>Scripting languages represent a different set of tradeoffs from system
>programming languages. Scripting languages give up execution speed and
>strength of typing relative to system programming languages but
>provide significantly higher programmer productivity and software
>reuse. This tradeoff makes more and more sense as computers become
>faster and cheaper in comparison to programmers. System programming
>languages are well suited to building complex data structures and
>algorithms from scratch, while scripting languages are well suited for
>gluing applications such as graphical user interfaces and component
>assembly. Gluing tasks are becoming more and more prevalent, so
>scripting will become an even more important programming paradigm in
>the next century than it is today.

[Erik Naggum]

* Bill Eldridge
| I don't know where Oesterhout's reference on MFC comes from
| (I'm just looking at Brain & Lovette's book).

considering that bad code can be written in any language, any language
comparison performed using examples must be judged by the quality of the
examples in each language. it can't be all that hard to write a bad
example in language A and a good example in language B, and then proclaim
language B to be the winner -- this is how people compare languages all the
time, so either those who read them are bad programmers in any language (or
are not programmers at all) and don't know how to reject the bad examples,
or they already agree with the author of the comparison that language B is
better than language A. in either case, it's a waste of anything but
marketing money. it appears to me that this is indeed how Tcl is marketed.

in other words, prepare to see Tcl claim a significant market share. also,
I'm sure people who read a paper with such a pompous title are unable to
detect any amount of false marketing. "Scripting: Higher-Level Programming
for the 21st Century", indeed.

a language is only as good as the worst example in languages it claims to
win over.

#\Erik
--
I'm no longer young enough to know everything.

[Bill Eldridge]

> >Various studies have shown
> >that programmers can write roughly the same number of lines of code
> >per year regardless of language[2], so system programming languages
> >allow applications to be written much more quickly than assembly
> >languages.

This is pretty doubtful - you can write and debug the same amount
of assembler & Python code in a year, including debugging? How
about developing new related programs based on earlier work?
How about modifying/debugging someone else's code? And completely
unrelated to the task you're trying to do? (device drivers,
numerical methods, GUI's, databases, etc.)

> >information from being used in any other way. In a weakly typed
> >language there are no a priori restrictions on how information can be
> >used: the meaning of information is determined solely by the way it is
> >used, not by any initial promises.

Occasionally, "weakly-typed" languages are actually "programmer-typed":
"Oh, it screwed up an interpreted this as an integer, well, I'll just
throw an ascii conversion function around it".

Actually, I thought C++ allows pretty generic function mapping on
whatever types you throw into a function.

> > Scripting languages are often used to extend the features
> >of components but they are rarely used for complex algorithms and data
> >structures;

I thought Perl was quite good at complex data structures.
Maybe I'm confusing something (perhaps Perl really does nothing,
it's all just Unix/C at heart. Alas, we were fooled all along).

> >button .b -text Hello! -font {Times 16} -command {puts hello}
> >
> >This command creates a new button control that displays a text string
> >in a 16-point Times font and prints a short message when the user
> >clicks on the control. It mixes six different types of things in a
> >single statement: a command name (button), a button control (.b),
> >property names (-text, -foreground, and -command), simple strings
> >(Hello! and hello), a font name (Times 16) that includes a typeface
> >name (Times) and a size in points (16), and a Tcl script (puts
> >hello). Tcl represents all of these things uniformly with strings. In
> >the button example the properties may be specified in any order and
> >unspecified properties are given default values; more than 20
> >properties were left unspecified in the example.
> >
> >The button example requires about 25 lines of code in three procedures
> >when implemented in C++ with Microsoft Foundation Classes. Just
> >setting the font requires 7 lines of code:
> >
> >LOGFONT lf;
> >
> >memset(&lf, 0, sizeof(lf));
> >
> >lf.lfHeight = -16;
> >
> >strcpy(lf.lfFaceName, "Times New Roman");
> >
> >CFont *fontPtr = new CFont();
> >
> >fontPtr->CreateFontIndirect(&lf);
> >
> >buttonPtr->SetFont(fontPtr);

CButton* button1;
CButton* button2;
button1 = new CButton();
button1->Create("Push me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
101)
button2 = new CButton();
button2->Create("Pull you", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
102)
font = new CFont;
font->CreateFont(16,0,0,0,700,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,DEFAULT_PITCH|FF_DONTCARE,"times");
button1->SetFont(font)
button2->SetFont(font)

Basically 3 lines to create a font (reusable assuming you only
what a few types of fonts, set up a function to handle size changes
if it's the same, you can also create a simple function to handle
defaults for everything but the size and type.

3 lines to create a Button.

I don't know where Oesterhout's reference on MFC comes from
(I'm just looking at Brain & Lovette's book).

>

> >The reason why object-oriented programming has not lived up to
> >expectations is that it doesn't raise the level of programming or
> >encourage reuse. Programmers still work with small basic units that
> >must be described and manipulated in great detail. In principle,
> >powerful library packages could be developed, and if these libraries
> >were used extensively it could effectively raise the level of
> >programming. However, not many such libraries have come into
> >existence.

> >The strong typing of object-oriented languages encourages

> >narrowly defined packages that are hard to reuse. Each package
> >requires objects of a specific type; if two packages are to work
> >together, conversion code must be written to translate between the
> >types required by the packages.

If you define the interface well in OOL's, you can handle a variety
of typed inputs. It's much easier to extend that typing in OOL's than
with something like C (and have deterministic output). I would guess
serious programmers do develop their own libraries, or work with
corporate standard ones (what does Adobe use? they can't be rewriting
every graphics routine from scratch). Having classes inherit methods
and types is much nicer than having everything default to a string
and thinking that's sufficient. MFC is a help for OOP exactly by
defining libraries that simplify programming. The dangers on
simplification
include that it might come at the expense of too much speed, that
it might not provide the tools to do everything a lower level
approach would, or that in doing more complex tasks, the "simpler"
language actually becomes more obfuscated than the lower-level
languages.

[Joe English]

I thought Ousterhout's paper was a terrific piece of marketing.

He mentions Tcl and Visual Basic as the primary examples
of "scripting" languages, but since Visual Basic is Windows-only
and Tcl runs "everywhere" (i.e., on Windows, Macs *and* Unix --
other OSes don't have enough market share to really count),
that leaves Tcl as the quintessential scripting language.

Notice too how he presents Java as a "system programming language"
in the same class as C++, in contrast to its usual perception
as a niche language for creating Netscape applets. (Not that
I disagree with this -- Java _is_ a pretty good general-purpose
language, certainly better than C++.)

He further argues that the combination of a good "system" language and
a good "scripting" language is an effective way to develop programs.
(Not that I disagree with this, either; it _is_ a pretty good
development strategy). The (unstated) conclusion seems to be that
all you need for higher-level programming in the 21st century
are Tcl and Java. Guess who owns both languages?

On the whole I thought he made some pretty good points, though
the paper certainly has flaws -- the failure to even mention
Lisp and Scheme (both of which have all the qualities he
cites as desirable in a scripting language), and his description
of strong typing as "too restrictive" typical of those who
have never used a strongly typed programming language with a _good_
type system like Haskell or ML. But most of all, I couldn't
shake the feeling that I was reading an infomercial.

--Joe English

jeng...@crl.com

[Stefan Harms]

In article <s6y208um0...@aalh02.alcatel.com.au>, Chris Bitmead
<Chris....@alcatel.com.au> wrote:

> ch...@adi.COM (Franklin Chen) writes:
>
> > I've looked at the paper, and found it extremely misleading for its
> > omissions and factual inaccuracies. In particular, I was baffled that
> > there was no mention _whatsoever_ of advanced languages such as
> > Scheme, ML, and Haskell--languages that to me seem most promising as
> > foundations for safe, efficient, and expressive prototyping/scripting
> > as well as general purpose programming.
> >

I am surprised that NO reference is made to AppWare/MicroBrew, as a
parallel to Tcl. Am I the only one seeing an analog situation?

--
Stefan...@mbnet.mb.ca

[Chris Bitmead]

Jon Leech <j...@cs.unc.edu> wrote:

>In article <s6y208um0...@aalh02.alcatel.com.au> you write:
>>output to do calculations. "Which directory entries are older than
>>12/Feb/1997?" VERY difficult to do with Unix shell. Trivial in a scsh
>>or CLOS style language. One can imagine writing something like (map
>>(lambda (d) (< (file-time d) "12/Feb/1997")) (ls))
>

> One-liner with the shell, either assuming the existence of a file-time
>comparison program like the file-time predicate you assume, or just using
>'find'.

Ok, someone just pointed out that you can do this in the shell with
the following code....

touch -t 9702120000 /tmp/.zoot$$
find . -maxdepth 1 -a \! -newer /tmp/.zoot$$ -print
rm /tmp/.zoot$$

Like I said. Difficult!!

And even assuming you can remember the date layout of the touch
command, the obscure syntax of the find command and remember to remove
the temporary file, how can you store the result in a variable?? You
can stored all the resulting entries in one big shell variable perhaps
for later processing, but then you are subject to the vagaries of
IFS. Point proved as far as I'm concerned.

>>NOW LOOK AT TK!!!! It's object oriented!!!!!!! It's based on all the
>>principles that Ousterhout is deriding. I must say this makes him look
>>like a fool.
>

> Um, Tk has no inheritance mechanism.

Tk has no properly designed inheritance mechanism. But it does all the
same things, albeit in a horrible disorganised way.

My criteria for object oriented was that (1) different objects react
to the same message in the same way. Clearly different Tk widgets do
this. And (2), Different classes can share common code.

Admittedly Tk does poorly here, but it does have re-use, mostly
because common stuff is split off into utility functions. No, Tk
doesn't support _further_ inheritance without re-organising the code,
but the re-use is there through splitting off common stuff.

So Tk is a good example of how not to do OO. How much cleaner it would
be if it did OO properly.

Now look at Stk. They have put a layer on top making Tk appear to
fully support inheritance, and you can inherit and make
specialisations of widgets and everything. Infinitely more powerful
than Tcl/Tk can ever be.

[Thant Tessman]

Chris Bitmead wrote:

> [...] Remember that Sun is pushing Tcl for some obscure reason, and
> Ousterhout is apparently working for Sun now, [...]

I've been told (by friends who follow this stuff more closely than I do) that
Sun has already lost control of Java to the Evil Empire. This might explain it.

-thant

[Alaric B. Williams]

On 02 Apr 1997 15:57:57 +1000, Chris Bitmead
<Chris....@alcatel.com.au> wrote:

comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,
comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel

(Wince) isn't that a trifle over-crossposted? I'm crossposting it
still myself since I have a statement to make that's really for
everyone who got this... but, lads, can we limit it from now on?
Otherwise, there will be arguments about scheme/TCL in the
Python group, Python/TCL in the C group...

[...]

>NOW LOOK AT TK!!!! It's object oriented!!!!!!! It's based on all the
>principles that Ousterhout is deriding. I must say this makes him look
>like a fool.

[etc]

Ok, everyone has some valid points against JO's paper. I agree, it
does seem somewhat commercialised... but he hasn't had a chance
to respond to our criticisms yet! Therefore, I've mailed him
with a memo to draw his attention, and we'll see what he has to say.

Not that I want to "support" him, it's just that it seems a little
unfair to proclaim our hatred of the guy without hearing what he has
to say. How do we know he won't go "What? That's not my paper! Why,
the little b*****ds have hacked into my account again!"...

Maybe we're all wrong, maybe he's wrong; either way, let's
fight it out rather than merely argue with ourselves about who'd
win the fight :-)

Here's the reply I had:

-----B<-----

To: ala...@abwillms.demon.co.uk
Subject: Re: TCL uproar on comp.lang.scheme
Date sent: Wed, 02 Apr 1997 13:31:40 -0800
From: John Ousterhout <ous...@tcl.Eng.Sun.COM>

I've been totally swamped with email the last week so I'm running
way behind on everything, but I'll try to take a look at the
discussion
on comp.lang.scheme and reply. Thanks for your message.

-----B<-----

Okay... everyone to their trenches...

ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."

(Windows for Early Warning and Defence User's manual P26)

Alaric B. Williams Internet : ala...@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

[Scott Schwartz]

Chris Bitmead <Chris....@alcatel.com.au> writes:
| >>(map (lambda (d) (< (file-time d) "12/Feb/1997")) (ls))
|

| Ok, someone just pointed out that you can do this in the shell with
| the following code....
|
| touch -t 9702120000 /tmp/.zoot$$
| find . -maxdepth 1 -a \! -newer /tmp/.zoot$$ -print
| rm /tmp/.zoot$$
|
| Like I said. Difficult!!

Not at all. Perfectly straightforward. And---this is the best
part--- it doesn't take all your RAM to do it. Scsh takes 10M just to
start up, so you can forget about using it for routine tasks like
this.

On the other hand, I'd be inclined to write:

tmp=`tmpname`
setdate '12/Feb/1997' $tmp
for f in *
do
newer $f $tmp && echo $f
done
rm $tmp

given a few simple helper programs in the unix spirit.

[Scott Schwartz]

jeng...@crl.com (Joe English) writes:
| I thought Ousterhout's paper was a terrific piece of marketing.

And why not? He's had years of solid results with a good product, and
wants people to know about it.

| the paper certainly has flaws -- the failure to even mention
| Lisp and Scheme (both of which have all the qualities he
| cites as desirable in a scripting language)

What would be the point of mentioning them? Lisp's reputation for
inefficiency and immiscibility with other langauges would just scare
away people who would otherwise be turned on to a good idea.

[Paul Prescod]

Sun is pushing Java more than ever. The reason for their interest in TCL
seems to be this dichtomy between systems programming languages and scripting
languages.

Paul Prescod

[Cyber Surfer]

With a mighty <8gg1x7q...@galapagos.cse.psu.edu>,
schw...@galapagos.cse.psu.edu.NO-SPAM uttered these wise words...

> What would be the point of mentioning them? Lisp's reputation for
> inefficiency and immiscibility with other langauges would just scare
> away people who would otherwise be turned on to a good idea.

If myths about "efficiency" - or the lack of it - were could have this
effect, then VB would be dead. Actually, it's far from dead, even if a
few people might wish it were otherwise.

Note that I have no strong feelings for or against VB. It's just a
tool, and it appears to work well enough to please large numbers of
people. The "efficiency" issue only seems to matter to people who want
to tell you that something "can't be used for X", where X is some app
domain that either doesn't necessarily depend on any great quality of
efficiency, or is so specialised that few people will care.

The same is true for Lisp, and at least a dozen other languages. There
are even people who'll tell you how unsuitable C++ is for certain
tasks. As Bill House said, go figure.

My attitude is simple: use whatever works for you. The details should
be the business of only you, and whoever pays for your time. Ideally,
even they should take no interest in what you use, but this isn't the
case for all of us. This is what I mean by "whatever works for you".
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.

[Donal K. Fellows]

In article <s6y208um0...@aalh02.alcatel.com.au>,
Chris Bitmead <Chris....@alcatel.com.au> wrote:

Chris, please cut out the bits of message that you are not directly
responding to, especially with long posts. We don't all have optic
fibre connections to our newsservers... :^)

> ch...@adi.COM (Franklin Chen) writes:
>
> > I've looked at the paper, and found it extremely misleading for its
> > omissions and factual inaccuracies. In particular, I was baffled that
> > there was no mention _whatsoever_ of advanced languages such as
> > Scheme, ML, and Haskell--languages that to me seem most promising as
> > foundations for safe, efficient, and expressive prototyping/scripting
> > as well as general purpose programming.
> >
> > If anyone is interested, I can go into detail about everything I found
> > misleading about Ousterhout's paper. I encourage anyone else who
> > cares to do the same; perhaps an eventual unified response to
> > Ousterhout is called for.
>
>
> The essence of Ousterhout's argument seems to be this... What is the
> ultimate sports car (programming language)? A '59 Cadillac complete
> with fins and powerful engine (C++) or a VW beetle with it's elegant
> simplicity (Tcl). John puts forward a strong argument that the beetle
> is the ultimate sports car, while conveniently ignoring that it is
> possible to combine the powerful engine of the Caddy with the elegance
> of the VW and come up with a Porche 959 (Scheme or Lisp or ML or many
> others).

But then they stick the steering wheel to the ceiling, the accelerator
in the boot, and almost completely fail to advertise the fact that
they have this wonderful vehicle.

Rule 1: Technical superiority counts for virtually nothing if the
other person's system has many times more users and
developers. 'Doze is proof enough of this...

> These are my comments on his paper. Remember that Sun is pushing Tcl
> for some obscure reason, and Ousterhout is apparently working for Sun
> now, so I guess we'd expect something like this, but we can't let him
> get away with this. Imagine... C and TCL. The worst of all possible
> worlds.

Well, I reckon that the world should be ditching Scheme and Lisp in
favour of a more modern and superior language like SML. Doesn't mean
that it is going to happen though. Oh, and the worst of all possible
worlds doesn't come from Mountain View, but Redmond...

[ snippage - double-quoted stuff is from JO's paper:
http://www.sunlabs.com/people/john.ousterhout/scripting.html
]

> A brave beginning! Ousterhaut tries to characterise Tcl as some sort
> of next generation language that is some sort of higher level
> abstraction above non-scripting languages.
>
> Talk about turning a bug into a feature! Apparently because Tcl lacks
> fundamental language concepts such as data structures, and a type
> system, it is now superior because it is "simple". I guess that makes
> BASIC another superior language of the future. NOT!

Well, his paper is targetted at the C/C++/Java crowd. If you said
Scheme to them, they'd probably start plotting to overthrow the CEO...

> >System programming languages differ from assembly languages in two
> >ways: they are higher level and they are strongly typed. The term
> >"higher level" means that many details are handled automatically so
> >that programmers can write less code to get the same job done. For
> >example:
>
> Where did this very dubious definition of a "system programming
> language" come from?? I don't think there is any official definition,
> but these are the attributes I personally would use to describe a
> systems language. They certainly don't include Ousterhout's
> definition...

He pulled it out of the air, but it is his show, and he is allowed to
do that sort of thing. Quibbling with peoples' definitions is a
standard USENET debating techinque, I know, but it doesn't really
advance the discussion in this case.

> >Modern computers are fundamentally typeless at heart: any word in
> >memory can hold any kind of value, such as a character, an integer, a
> >pointer, or an instruction. The meaning of a value is determined by
> >how it is used: if the program counter points at a word of memory then
> >it is treated as an instruction; if a word is referenced by an integer
> >add instruction then it is treated as an integer; and so on. The same
> >word can be used in different ways at different times.
>
> Modern computers are not "typeless"! While I find this whole argument
> meaningless anyway, if you want to make the comparison, you would say
> that computers are dynamically typed, but nevertheless typed. In that
> respect they compare better to dynamically typed languages like
> Lisp. While a piece of computer memory can hold data of any type,
> (Like a lisp variable), computer instructions only operate on the
> correct type. You can't use an add instruction and pass it a string
> with some ascii numbers in it (Similar to Lisp).

You, sir, are wrong here. Completely wrong. Modern processors
wouldn't know the difference between a complex data structure
reference, a string, a floating point number, the code for a function
and a collection of line noise. They are all just (sequences of)
bytes/words. You can't generally look at a bit pattern and tell what
it means, even if you know the host architecture/OS. Eg. "gc[k" is a
word-sized portion of a file on my workstation, but you would be very
hard-pressed indeed to be able to tell the format of the file from
that (FYI, it is an Sun audio file that makes my workstation say
something sarcastic if I'm still logged in when I should be going to
catch my train home :^) since it could quite easily be from any number
of other formats - some binary and some textual. The key is that the
processor doesn't care. It is _software_ that cares - types are
implemented in software only.

One man's real issue is another man's insignificance. In terms of
important things like time-to-delivery/market, Tcl (along with the
other scripting languages) is at a tremendous advantage over languages
like C (Fortran, C++, etc.). This gives its users much greater
competitiveness in a world where change is ever more rapid. OK, so
the solutions may not be quite the most elegant possible, but they are
there far sooner, and are easy enough to maintain (especially given
that the cost of replacing substantial sections of the system is
fairly low).

If you want to really demonstrate how much better Scheme (or Lisp, or
ML, or whatever) is, perform a comparative coding test (such as
documented in JO's table #1) which, while anecdotal, does illustrate
the ability of scripting languages to make a huge difference to the
cost of major projects.

In my experience, some of the best features of scripting languages are
the ability to use them to perform separate testing of disparate
system components before the integration of them into a complex whole.

[ button example elided ]

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

Oh? I'd love to see you try it. (Clue: the configuration parameters
can be in any order, and there are a lot more that have been omitted.
C++ offers no good support for this at all.)

> >The difference is that scripting
> >languages do their error checking at the last possible moment, when a
> >value is used. Strong typing allows errors to be detected at
> >compile-time, so the cost of run-time checks is avoided. However, the
> >price to be paid for this efficiency is more conservative restrictions
> >on how information can be used: this results in more complex and less
> >flexible programs.
> >
> >Another key difference between scripting languages and system
> >programming languages is that scripting languages are usually
> >interpreted whereas system programming languages are usually
> >compiled.
>
> "Usually" perhaps, but not always. Surely the best solution is a
> language which can easily accomodate both options? Tcl does not at all
> easily support compilation. C++ does not easily support
> interpretation. There are many languages which readily support both.

Tcl8 does support JIT compilation to bytecode (though not separate
compilation or compilation to native code), and I have seen, though
not used in anger, interpreted C environments (from which interpreted
C++ is only a fairly small step).

> >Scripting languages tend to be less efficient than system programming
> >languages, in part because they use interpreters instead of compilers
> >but also because their basic components are chosen for power and ease
> >of use rather than an efficient mapping onto the underlying
> >hardware. For example, scripting languages tend to use variable-length
> >strings in situations where a system programming language would use a
> >binary value that fits in a single machine word, and scripting
> >languages often use hash tables where system programming languages use
> >indexed arrays.
>
> But why? If we accept that scsh is a scripting language (which clearly
> it is), it suffers from neither of these drawbacks.

Neither, strictly, does Perl or Tcl8. Your straw^H^H^H^H^Hpoint?

> >Fortunately, the performance of a scripting language isn't usually a
> >major issue. Applications for scripting languages are generally
> >smaller than applications for system programming languages, and the
> >performance of a scripting application tends to be dominated by the
> >performance of the components, which are typically implemented in a
> >system programming language.
>
> This is an often put forward argument that falls over time and time
> again when reality hits. Applications might start off small, but then
> people want more features, more performance, more
> everything. Eventually using the poor scripting languages break down
> because they don't give you the performance or data structures or
> abstraction mechanisms to support what you're doing. Things become
> more and more messy. You keep having to go back and rewrite things in
> your "systems" languages.

Not in my experience. Speed usually depends on two factors, the
algorithms, and the quantity of interaction with the external world
(particularly users or network resources). The implementation
language itself (in the hands of the skilled) tends not to make too
big a difference.

> Sure Tcl and C can be a lot faster than C alone. But then C is an
> appalling benchmark against which to make judgements.

Suggest a better one. Give concrete examples please (bearing in mind
"horses for courses" - languages, whether scripting or otherwise, tend
to be better at the areas that they were designed for, and I don't
think that anything is a solution for everything)

> At this stage the argument gets to the utterly riduclous
> stage. According to Ousterhout, because Scheme has only 5 "primitive"
> operations which execute only a few instructions, therefore to do
> anything in Scheme must be orders of magnitude more verbose than in
> Tcl which has lots of primitive operations. NOT!

JO's whole article doesn't mention Scheme (or Lisp or functional
programming) once. I checked. Try consuming less hallucinogens, or
at least give a reference.

> The convenience of performing complicated tasks is partly because of
> the elegance of the language, but mostly has a lot to do with the
> design of the libraries it has associated with it. Naturally Tcl can
> do a lot of things with a few lines of code, because it is supported
> by truckloads of library code doing the real work. But that is a
> benefit of Tk. Not Tcl.

Tcl was _always_ designed to be used with extension libraries, and it
goes out of its way to make things easy for them. That, together with
its regularity (it takes a couple of pages to describe Tcl.
Everything else, including control constructs like for and while,
belongs in libraries,) is what makes the language so good.

> - There is no mention about whether the "systems" language
> implementation used an extensive set of libraries such as that which
> comes with Tcl, or whether they decided to reinvent every wheel
> themselves, as so often happens on C and C++ projects.

Probably using Motif... :^)

> Here is the problem with scripting languages. Most applications start
> off with a simple model and structure, a modest sized dataset, and a
> well-defined problem. But then guess what? People want more features
> leading to more complex algorithms and the need for data
> structures. People start to feed larger and larger datasets into the
> program. And the requirements of the program start to change and
> change. Then you have to start all over from scratch because you find
> that Tcl doesn't scale.

An unfounded assertion. Please provide proof (in the face of a number
of very large commercial projects written in Tcl)

[ elided ]

> Oh really?? Scripting languages are simpler and easier to learn than
> systems languages? That is a very broad claim to make. It is also a
> lot of rot. Take perl for example. A difficult language to truely
> understand and master. Each language has it's own unique
> characteristics and difficulties. It has nothing to do with whether it
> is a supposedly "systems" or "scripting" language.

It depends what your background is. For people with lots of shell,
sed, awk and C experience, perl is quite easy. It all depends on your
background.

> >For example, compare Visual
> >Basic with Visual C++; few casual programmers would attempt to use
> >Visual C++, but many have been able to build useful applications with
> >Visual Basic.
>
> Yeah right. Use C++ as a comparison against BASIC. Why not compare
> Perl to Scheme? Who wins then?

OK. Why not perform that comparison in the area of CGI programming
with a web server running on NT? Who wins then?

> >Unfortunately, there is not much evidence that object-oriented
> >programming produces the benefits claimed for it. Some projects have
> >claimed success with object-oriented languages, but others have
> >reported that languages like C++ actually made software management
> >problems worse.
>
> So object oriented technology is condemned because of the failure of
> C++? Yeah right.

OOTech is good - it is just OOProgramming that seems to have come
unstuck. Analysing and designing using OO techniques is still a
really good idea.

Oops! I've got to catch a train. The rest of your message is just as
irritating though (especially the few hundred blank lines at the end :^)

Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) fell...@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| do...@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+

[Christopher Hylands]

----

Seems to me that the combination of Java and Tcl is _very_ powerful.
My point is that you have your lunch and eat the other guy's too :-)

It seem like most Java GUIs are ugly as sin (misaligned entry boxes of
different lengths etc.). Tk GUIs are easy to tune because you can
keep evaluating a proc until it looks right. With Java, you usually
have to recompile and restart. (SpecJava might help here, I don't know)

However, the numerical performance of Tcl is rather abysmal, whereas
if you do big numerical operations in Java, then you can see a good
performance increase.

John Reekie here at UC Berkeley has shown some promising results of
combining Itcl with Java so that you can have easy access to Java
objects from Itcl. If anything, this seems to make testing Java
classes very easy.

I updated the tcljava0.4 interface to run with JDK1.1 under NT4
and it seems to be useful, check out:
http://ptolemy.eecs.berkeley.edu/~cxh/ptpub/tcljava.html

-Christopher
--
Christopher Hylands, Ptolemy Project Manager University of California
c...@eecs.berkeley.edu US Mail: 558 Cory Hall #1770
ph: (510)643-9841 fax:(510)642-2739 Berkeley, CA 94720-1770
home: (510)526-4010 (if busy -4068) (Office: 493 Cory)

[Donald Syme]

Chris Bitmead wrote:
>
> ch...@adi.COM (Franklin Chen) writes:
>

> >To see the advantages of a typeless language, consider the following
> >Tcl command:
> >

> >button .b -text Hello! -font {Times 16} -command {puts hello}
> >
> >This command creates a new button control that displays a text string
> >in a 16-point Times font and prints a short message when the user
> >clicks on the control. It mixes six different types of things in a
> >single statement: a command name (button), a button control (.b),
> >property names (-text, -foreground, and -command), simple strings
> >(Hello! and hello), a font name (Times 16) that includes a typeface
> >name (Times) and a size in points (16), and a Tcl script (puts
> >hello). Tcl represents all of these things uniformly with strings. In
> >the button example the properties may be specified in any order and
> >unspecified properties are given default values; more than 20
> >properties were left unspecified in the example.
> >
> >The button example requires about 25 lines of code in three procedures
> >when implemented in C++ with Microsoft Foundation Classes. Just
> >setting the font requires 7 lines of code:
> >
> >LOGFONT lf;
> >
> >memset(&lf, 0, sizeof(lf));
> >
> >lf.lfHeight = -16;
> >
> >strcpy(lf.lfFaceName, "Times New Roman");
> >
> >CFont *fontPtr = new CFont();
> >
> >fontPtr->CreateFontIndirect(&lf);
> >
> >buttonPtr->SetFont(fontPtr);
>

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

Trash. Show me C++ which is as succinct and I may believe you.

For example the O'Caml crowd (who I think are wonderful)
have to bend over backward to create O'Labl (again wonderful)
to achieve anything like the succinctness Ousterhout achieves
in Tcl/Tk, precisely because of the ML type system. Ousterhout
is right on this point at least: strong, static typing
does often mean cutting back on nifty syntactic tricks that
are played with untyped languages (like specifying a font
with just "Times 16", or allowing config parameters in any order).
At least until the language designers
add some features (like labelled optional arguments) to their
language.

Don

P.S. I think I must be the only person in the world who
is a Tk/Tcl fan *and* an ML/Scheme/Java fan. Different
horses for different courses!

-----------------------------------------------------------------------------
At the lab: At home:
The Computer Laboratory Trinity Hall
New Museums Site CB2 1TJ
University of Cambridge Cambridge, UK
CB2 3QG, Cambridge, UK
Ph: +44 (0) 1223 334688 Ph: +44 (0) 1223
505863
http://www.cl.cam.ac.uk/users/drs1004/
email: drs...@cl.cam.ac.uk
-----------------------------------------------------------------------------

[John Ousterhout]

Wow, there's been quite a party going on over here on comp.lang.scheme!
I'd like to respond to a few of the comments about my white paper on
scripting, but first a couple of introductory remarks:

1. The paper is not intended to be a complete taxonomy of all programming
languages nor is it intended to discuss every factor that contributes
to the usefulness of a language. The paper has a very narrow focus,
namely to explain what scripting is and why it's important. I
intentionally limited the discussion to a few issues such as system
programming vs. scripting, components vs. glue, and strongly typed
vs. untyped. Of course there are other issues in programming language
design. At the same time, I think that the issues in the paper explain
a lot about what's going on in real-world programming.

2. Many people objected to the fact that their favorite programming
was left out of the white paper. Yes, I have heard of Scheme,
Smalltalk, ML, etc. I left these languages out because they
didn't seem particularly relevant for the discussion. No offense
intended...

3. It's very hard to settle arguments about programming languages
because it's hard to produce meaningful quantitative evidence about
things like programmer productivity. I tried to illustrate my points
with historical examples and a few quantitative anecdotes, but I
admit that these are soft. I'd be delighted to see better
quantitative evidence either supporting or contradicting my
arguments. For example, if you know of any quantitative measurements
of productivity improvements caused by object-oriented programming,
please let me know.

When Alaric Williams told me about the flame-fest on comp.lang.scheme,
he proposed a set of counter-arguments for me to respond to. Here
they are, along with my responses.

- Typlessness, as evident in TCL, is not necessarily the best solution.
Dynamic typing is generally agreed to be far more powerful and safe.

Actually, I think Tcl is dynamically typed: everything is checked
at runtime for at least syntactic validity. I used a slightly offbeat
definition of "typing" in the paper: by my definition, "typing" means
declaring the nature of something in advance in order to restrict its
usage. You would probably call this "static typing", no?

- TCL does not scale well to large systems; it is fine for small
"glueing" applications, but in the "real world", such applications
are expected to grow with time, and soon proper typing becomes
necessary, more efficiency becomes necessary, etc.

When I started on Tcl I thought this would be true, but in fact many
people have built surprisingly large programs in Tcl. For example,
there is a real-time Tcl application containing several hundred thousand
lines of code that controls a $5 billion oil well platform and (much to
my shock) it seems to be quite maintainable. Sybase has something like
a million lines of Tcl code in their test suite.

I think it depends a lot on the application. The oil well application
actually subdivides into a whole bunch of small tasks, so it's really
more like 500 smaller programs. Also, if the application is
fundamentally gluing (i.e. the complexity is in the interconnections)
then switching to a more strongly typed language will just make things
worse. One final argument: suppose that Tcl code is harder to maintain,
line for line, than code in a more strongly typed language (I suspect
this is true). But if a Tcl application has only 1/5 or 1/10 the lines
of code of the equivalent program in a strongly typed language, it may
still be easier to maintain overall.

That said, I still suspect that as scripting applications grow it makes
more and more sense to implement parts of them in a system programming
language. The great thing about scripting languages is that this is
easy to do. You can take the performance-critical kernel of a Tcl
application and implement it in C or C++; ditto for any complicated data
structures or algorithms. The simple, non-performance-critical parts
can be left in Tcl. I knew when I started on Tcl that it wouldn't be
appropriate for all problems, so I designed it to work smoothly with
other languages. In contrast, most languages are egotistical: they
expect you to do *everything* in that language and make it very hard to
split the functionality of an application between multiple languages.
For example, I've been involved with several attempts to make C and Lisp
work together, and they all failed.

- It is possible to make languages with execution speeds like C or C++,
that use dynamic typing successfully, whilst being high-level enough
in the creation of abstractions to "glue" things together quite
nicely and easily.

Can you point to a specific language and identify a large community of
users who agree with this assessment? Many people have made claims like
this to me, but no one has been able to point to a good real-world
example. The white paper argues that you can't have a jack-of-all-trades
language. Either you have a strongly typed language, which gives high
speed and manageability but makes gluing hard, or you have a weakly
typed language with the opposite properties.

- Do you really think that object orientation has failed? C++ is a bad
OO
language, indeed, but what about Self, Java, and other such OO success
stories from... Sun Labs? Do I detect interdepartmental rivalry?

I overstated the arguments against OO programming in the paper and I'll
probably soften them a bit in the next draft. I actually think that
there are some good aspects of OO programming, and I use them myself
even when I'm not programming in an OO language. But I stand by the two
main points in the paper, which are that (a) OO programming hasn't
increased productivity dramatically because it doesn't raise the level of
programming significantly (it may improve things 20-30%, but I doubt
there's even a factor of 2, let alone 10) and (b) implementation
inheritance really truly is a bad idea that tends to reduce reuse and
productivity. I think you'll see substantial support for the second
claim even among OO enthusiasts.

As for Java, it's hard not to be envious of its success (aren't you
guys a bit envious too?), but Tcl is really symbiotic with Java, just
as Tcl is symbiotic with C. I look on Java as a better system
programming language that's particularly well-suited for creating
portable Internet components. Tcl is moving to the Internet itself,
and C isn't a good component language in that domain, so I'm delighted
to have Java around for implementing Internet components that Tcl
can then glue together.

By the time I found out about the discussion on comp.lang.scheme my news
server had already flushed some of the earlier articles, so I've missed
some of the arguments. I trolled the articles that were left for
comments to discuss, but didn't find a lot. Most of the articles seemed
to be discussing my motives and ancestors more than the ideas in the
paper; I'm not sure how to respond to a comment such as "he obviously
doesn't have a clue" except by saying "Hmmm, let me see... wait ...
here's one in my wallet! Whew..." You guys seem to have more
ad-hominem arguments than we do on comp.lang.tcl.

However, I did find a few comments that I'd like to respond to; here
they are (indented), along with my responses:

> I have only skimmed the article so far, but one thing struck me
> immediately. At one point he gives an "anecdotal" table where
> something is programmed originally in C or C++, at enormous expense
> in programmer hours, and then re-implemented in Tcl/Perl/whatever
> in ten or fifteen minutes. It would be interesting to see if the
> same skew existed for programs that were written in scripting
> languages (or for that matter, Lisp or Scheme or Python) first,
> and then re-implemented in C or C++. It's hard to believe the ratios
> would be as large.

Look carefully at the "Comments" column in the table: some of the
applications were written in C/C++ first, while others were written in
Tcl/Perl first. Indeed, scripting appears to have less benefit in the
cases where the scripting implementation was first. I believe the
caption in the table mentions this, and the 5-10x advantage I claimed
for scripting is the middle range of the table to try to compensate
for learning effects in the second implementation.

His arguments on "typeless" languages is useless.
You don't need a "scripting language" to
get usable abstractions without the need
to deal with low-level issues.

button .b -text Hello! -font {Times 16} -command {puts hello}

In Macintosh Common Lisp I'll write this as:

(make-instance 'button-dialog-item
:dialog-item-text "Hello"
:view-font '("Times" 16)
:dialog-item-action (lambda (item) (print "hello")))

I think this example supports my claim that scripting languages are a
lot easier to use when you need to mix and match lots of things of
different types. The MCL example is a lot more verbose and complicated
than the Tcl example.

He also gets confused when he talks about object oriented programming
being a failure. He attributes the short comings of one implementation
(C++) to the whole approach, much like people who reject Lisp/Scheme
because of one particular implementation.

Time will tell on this issue. Personally I think that the problems with
OO programming go beyond just C++.

>The button example requires about 25 lines of code in three procedures
>when implemented in C++ with Microsoft Foundation Classes. Just
>setting the font requires 7 lines of code:
>
>LOGFONT lf;
>
>memset(&lf, 0, sizeof(lf));
>
>lf.lfHeight = -16;
>
>strcpy(lf.lfFaceName, "Times New Roman");
>
>CFont *fontPtr = new CFont();
>
>fontPtr->CreateFontIndirect(&lf);
>
>buttonPtr->SetFont(fontPtr);

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.

> >The button example requires about 25 lines of code in three procedures
> >when implemented in C++ with Microsoft Foundation Classes. Just
> >setting the font requires 7 lines of code:
> >
> >LOGFONT lf;
> >
> >memset(&lf, 0, sizeof(lf));
> >
> >lf.lfHeight = -16;
> >
> >strcpy(lf.lfFaceName, "Times New Roman");
> >
> >CFont *fontPtr = new CFont();
> >
> >fontPtr->CreateFontIndirect(&lf);
> >
> >buttonPtr->SetFont(fontPtr);

CButton* button1;
CButton* button2;
button1 = new CButton();
button1->Create("Push me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
101)
button2 = new CButton();
button2->Create("Pull you", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
102)
font = new CFont;
font->CreateFont(16,0,0,0,700,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,DEFAULT_PITCH|FF_DONTCARE,"times");
button1->SetFont(font)
button2->SetFont(font)

Basically 3 lines to create a font (reusable assuming you only
what a few types of fonts, set up a function to handle size changes
if it's the same, you can also create a simple function to handle
defaults for everything but the size and type.

3 lines to create a Button.

I don't know where Oesterhout's reference on MFC comes from
(I'm just looking at Brain & Lovette's book).

I'm not an MFC expert, so I asked someone else, whom I consider to be
a good Windows programmer, to write this for me. Perhaps there is a
shorter way than the code I included. However, the 6 lines above
don't seem to be equivalent to the Tcl script. For example, there is
no code to respond to the button press, and I believe additional code is
needed to free resources when the button is deleted. Suppose that the
MFC code I used is off by a factor of two, and that it really only takes
12 lines of C++ to duplicate the functionality of one line of Tcl. Doesn't
that still illustrate my point?

[Michael Sperber [Mr. Preprocessor]]

>>>>> "JO" =3D=3D John Ousterhout <ous...@tcl.eng.sun.com> writes:

JO> - It is possible to make languages with execution speeds like C or=
C++,
JO> that use dynamic typing successfully, whilst being high-level enoug=
h
JO> in the creation of abstractions to "glue" things together quite
JO> nicely and easily.

JO> Can you point to a specific language and identify a large community of
JO> users who agree with this assessment?

The Scheme implementations Gambit-C and Bigloo achieve both pretty
satisfactorily. Their highly optimizing compilers get quite close to
the execution speed of C (I've seen both perform faster on some stuff,
slower on other stuff). Both have fully developed C interfaces. It's
not really a question of "agreement," as these are already language
*implementations* that fulfill the requirements stated above.
--
Cheers =3D8-} Mike
Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla

[Jack Jansen]

ous...@tcl.eng.sun.com (John Ousterhout) writes:
> For example,
>there is a real-time Tcl application containing several hundred thousand
>lines of code that controls a $5 billion oil well platform and (much to
>my shock) it seems to be quite maintainable.

> [...]

>The oil well application
>actually subdivides into a whole bunch of small tasks, so it's really
>more like 500 smaller programs. Also, if the application is
>fundamentally gluing (i.e. the complexity is in the interconnections)
>then switching to a more strongly typed language will just make things
>worse.

I find this very hard to believe. With languages like Python or Tcl, with
no interface definitions whatsoever, you can only *hope* that you use
every interface correctly. I work on a largish project in Python, and
the one thing that gives continuous headaches is the lack of interface
definitions. Whenever you change an interface it is very very
difficult to check that you haven't inadvertantly broken something.

--
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack....@cwi.nl | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

[Graham C. Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Donald" == Donald Syme <drs...@cl.cam.ac.uk> writes:

Donald> Trash. Show me C++ which is as succinct and I may believe
Donald> you.

How much do you want? I've found that STL makes my code incredibly
brief, and with the correct toolkit (I like Qt), windowing isn't that
hard, either. Better, you can subclass existing components so you can
create a new widget, something you can't do in Tcl/Tk without
resorting to C extensions.

This is an aside, however; the real issue is that Tcl/Tk is a
glorified macro processor, full of weird tricks. Try explaining why
you can't pass an array, or why 'set $$foo bar' doesn't work some
time. *This* is the reason why Tcl/Tk is ``concise''; everything is a
string. Where else can we find:

- lists where accessing anything is an O(n) operation
- numbers that autoconvert when you don't want them to (on
east coast area codes, for example)
- non-extensible mathematical expressions (think expr here)
- call by name
- dynamic scoping

and other assorted nastiness. Even Perl is a breath of fresh air
compared to this.

I have nothing but good things to say about Tk. Its incarnation in
other languages like Scheme, Python, Perl, and O'Caml are very nice,
and in the correct language (I know Python does this, not sure about
the others) you can even subclass widgets. Tcl, however, is something
else entirely, and I reject it for anything except trivial programs
out of hand.
- --
Graham Hughes http://A-abe.resnet.ucsb.edu/~graham/ MIME & PGP mail OK.
const int PGP_fingerprint = "E9 B7 5F A0 F8 88 9E 1E 7C 62 D9 88 E1 03 29 5B";
#include <stddisclaim>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM0eU1iqNPSINiVE5AQH7jgQAmWUpvQGnNmGUshzygBnonh+OrK7iO3Uq
+11DSwDQVsg9DsOfB3HNqD1H4qguNPe2DXZBHRS25DiYhBEXLr+1nWMibtyAvgD1
44xA+qPRyzzq2MQ31XCRjKqAMzQC7XCr7LUotRm5f3GbElouweATfRzrUfgZ+a32
px5rYhG001Y=
=J2TS
-----END PGP SIGNATURE-----

[James Lee]

] 2. Many people objected to the fact that their favorite programming

] was left out of the white paper. Yes, I have heard of Scheme,
] Smalltalk, ML, etc. I left these languages out because they
] didn't seem particularly relevant for the discussion. No offense
] intended...

Why were they irrelevant? Your paper concentrates on system and
scripting languages exclusively while ignoring an entire genre of
languages that may offer the features you're looking for in both.

] - It is possible to make languages with execution speeds like C or C++,
] that use dynamic typing successfully, whilst being high-level enough
] in the creation of abstractions to "glue" things together quite
] nicely and easily.
]
] Can you point to a specific language and identify a large community of
] users who agree with this assessment? Many people have made claims like

] this to me, but no one has been able to point to a good real-world
] example. The white paper argues that you can't have a jack-of-all-trades
] language. Either you have a strongly typed language, which gives high
] speed and manageability but makes gluing hard, or you have a weakly
] typed language with the opposite properties.

Gambit-C is an exceptionally effecient Scheme -> C optimising compiler.
I believe the author, Marc Freeley, also has a Tk interface in the works.

] His arguments on "typeless" languages is useless.

] You don't need a "scripting language" to
] get usable abstractions without the need
] to deal with low-level issues.
]
] button .b -text Hello! -font {Times 16} -command {puts hello}
]
] In Macintosh Common Lisp I'll write this as:
]
] (make-instance 'button-dialog-item
] :dialog-item-text "Hello"
] :view-font '("Times" 16)
] :dialog-item-action (lambda (item) (print "hello")))
]
] I think this example supports my claim that scripting languages are a
] lot easier to use when you need to mix and match lots of things of
] different types. The MCL example is a lot more verbose and complicated
] than the Tcl example.

I disagree entirely and would like to know what grounds you base your
reaction on. The MCL example is certainly no more "complicated" and
the verbosity of the classes and accessors is a symptom common to Lisp
programmers but not enforced by the language itself. This usually aids
in readability (and hence reusability) although the example given above
doesn't illustrate this aspect very well.

James Lee -- <jl...@math.purdue.edu>

[Cyber Surfer]

With a mighty <5i7euq$c...@engnews2.Eng.Sun.COM>,
ous...@tcl.eng.sun.com uttered these wise words...

> Wow, there's been quite a party going on over here on comp.lang.scheme!

Not just comp.lang.scheme...

[various arguments and your responses to them deleted]

[MFC code deleted]

While I'm reluctant to defend MFC and C++, I have a few comments to
make.

> I'm not an MFC expert, so I asked someone else, whom I consider to be
> a good Windows programmer, to write this for me. Perhaps there is a
> shorter way than the code I included. However, the 6 lines above

I'm not MFC expert, either, nor do I wish to be one, but I have used
it enoigh to know that I wouldn't write such code to create a button
or two, using a particular font. Instead, I'd create a dialog
resource, and if I wanted to place it within part of a window, then
I'd make it a child of that window and size it accordingly.

> don't seem to be equivalent to the Tcl script. For example, there is
> no code to respond to the button press, and I believe additional code is
> needed to free resources when the button is deleted. Suppose that the
> MFC code I used is off by a factor of two, and that it really only takes
> 12 lines of C++ to duplicate the functionality of one line of Tcl. Doesn't
> that still illustrate my point?

I think it's off by more than a factor of two. The amount of code used
to implement your example, needn't reflect the complexity of the user
interface. IMHO that's what an interface builder is for.

I guess the large number of development tools with interface builders
and their popularity supports my view, but I'm not sure that numbers
are relevant to this thread - if they were, we'd all be talking about
something else. For what it's worth, it's one way of looking at it.

Meanwhile, the code to create this dialog is just a couple of function
calls (one to create the dialog window, another to place it), and the
event handling code may be maintained for you by Class Wizard, if you
use VC++. (Other C++ compilers may provide similar tools.)

Of course, there are MFC features that aren't so easy to use, as the
resource editor won't know about them (e.g. resizable windows).
Buttons are just to trivial for a fair contest. Add some more complex
features, and things should get rather more interesting! The exact
_choice_ of features may favour Tcl or MFC/C++, it's up to you.

In other words, Your Mileage May Vary. A contest between VB and Tcl
might be more realistic, as it seems to me that their strengths are
very similar. However, we're assuming that the code is for Windows. If
you do that, then you've made it easy for a Windows develop to play a
trump card - unless Tcl supports ActiveX (please say that it does!)
and all the other features specific to Win32.

You'd do better by playing Tcl's trump card, which is much greater
portability than VB and VC++ will ever have. Again, YMMV.

Now I have to wash my mouth out for "defending" MFC. ;)

--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK

Please remove the "gubbish" if you want to email me.

[Fritz Heinrichmeyer]

James Lee <jl...@math.purdue.edu> writes:

> ] 2. Many people objected to the fact that their favorite programming
> ] was left out of the white paper. Yes, I have heard of Scheme,
> ] Smalltalk, ML, etc. I left these languages out because they
> ] didn't seem particularly relevant for the discussion. No offense
> ] intended...
>
> Why were they irrelevant? Your paper concentrates on system and
> scripting languages exclusively while ignoring an entire genre of
> languages that may offer the features you're looking for in both.

I agree! At least ML and Scheme (i dont know smalltalk very well ..) are
particulary relevant to this discussion. They at least are intended to
solve all the mentioned problems (terser code means shorter development
time and less errors, inheritance is not so important, the computer
should look for types etc.).

The last posting of J. Ousterhout is outing him as candidate for getting
an ML-fan!

[Mark Sterin]

Jack Jansen <ja...@cwi.nl> wrote in article <jack.86...@news.cwi.nl>...
> ...
> ...With languages like Python or Tcl, with

> no interface definitions whatsoever, you can only *hope* that you use
> every interface correctly. I work on a largish project in Python, and
> the one thing that gives continuous headaches is the lack of interface
> definitions. Whenever you change an interface it is very very
> difficult to check that you haven't inadvertantly broken something.

This what the regression testing is for, isn't it ?

-- Mark

--
Mark Sterin mst...@bmc.com
Patrol Core R&D.
BMC Software Inc. http://www.bmc.com

"Buy a Pentium/Pro 200 to reboot faster !"

[Paul Prescod]

In article <5i7euq$c...@engnews2.Eng.Sun.COM>,

John Ousterhout <ous...@tcl.eng.sun.com> wrote:
> His arguments on "typeless" languages is useless.
> You don't need a "scripting language" to
> get usable abstractions without the need
> to deal with low-level issues.
>
> button .b -text Hello! -font {Times 16} -command {puts hello}
>
> In Macintosh Common Lisp I'll write this as:
>
> (make-instance 'button-dialog-item
> :dialog-item-text "Hello"
> :view-font '("Times" 16)
> :dialog-item-action (lambda (item) (print "hello")))
>
>I think this example supports my claim that scripting languages are a
>lot easier to use when you need to mix and match lots of things of
>different types. The MCL example is a lot more verbose and complicated
>than the Tcl example.

Easier to use for people who are not knowledgable about the language? Yes.
Easier to use for people who are? No. The latter is certainly no harder
for a MCL programmer than the former is for a TCL programmer. It will also
be easier to maintain, for all of the usual reasons.

Paul Prescod

[Koen Claessen]

Don writes:

| ... Ousterhout

| is right on this point at least: strong, static typing
| does often mean cutting back on nifty syntactic tricks that
| are played with untyped languages

I don't think it is the strong typing that does it, it is just the lack of
abstraction. Strong typing, if rich enough, can even _help_ you making
better abstractions in a language.

Ousterhout is absolutely right: we need languages that provide better glue
than the languages he calls `system languages'. But that doesn't mean that
we have to give up strong typing!

| ... At least until the language designers

| add some features (like labelled optional arguments) to their
| language.

What do you think of type classes? The system `TkGofer' uses these, to do
a pretty good job combining the conciseness of Tcl with the strong typing
and expressiveness of functional languages (in this case Gofer).

An example of an expression in TkGofer is:

b <- button [ text "A button", command (puts "hello") ] w

This would create a button in window w with the specified options and puts
the result in the variable b. (This is a disadvantage of Tcl -- explicit
naming of widgets).

Strong typing is for example _used_ for configurations. A widget that has
no command, can't get a `command' configuration. For example:

l <- label [ text "A label", command foo ] w

Will give a _static_ type error:

Type checking.....
ERROR (line 7):
*** Required instance : HasCommand Label

Because labels don't have commands. But _both_ widgets can get the `text'
configuration, because they both have text. TkGofer use type classes to do
this.

My experience with TkGofer is that it is even more concise than Tcl, _due_
to the expressiveness of strong typing, type classes, and functional
programming in general.

TkGofer is one of the many examples that show how we can use strongly
typed (functional) languages as glue to provide interfaces to untyped
libraries.

References:

* Vullinghs, T., `TkGofer homepage', URL:
http://www.informatik.uni-ulm.de/abt/pm/ftp/tkgofer.html

* Claessen, K., Vullinghs, T. and Meijer, E., `Structuring Graphical
Paradigms in TkGofer', to appear at the ICFP '97, URL:
http://www.cse.ogi.edu/~kcclaess/Articles/tkgofer.ps

Regards,
Koen.

--
| Koen Claessen, ko...@cse.ogi.edu. |
| http://www.cse.ogi.edu/~kcclaess/ |
|------------------------------------------------------|
| Visiting student at OGI, Portland, Oregon, USA. |

[Cameron Laird]

In article <5i9eui$d...@mulga.cs.mu.OZ.AU>,
Michael David WINIKOFF <wini...@mundook.cs.mu.OZ.AU> wrote:
.
.
.
>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.
.
.
.
For better or worse, by the way, it's not clear
what your example exemplifies; it's possible in
Tcl for "12" to name a procedure. Aficionados
rate this a feature, of course.

Follow-ups deserve trimming, but I haven't the
energy.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 623 8000 #227
+1 713 996 8546 FAX

[Cameron Laird]

In article <MPG.db1e484e...@news.demon.co.uk>,
Cyber Surfer <cyber_...@gubbish.wildcard.demon.co.uk> wrote:
.
.
.

>very similar. However, we're assuming that the code is for Windows. If
>you do that, then you've made it easy for a Windows develop to play a
>trump card - unless Tcl supports ActiveX (please say that it does!)
>and all the other features specific to Win32.

.
.
.
Tcl does not support ActiveX.

OpTcl <URL:http://www.sys.uea.ac.uk/~fuzz/OpTcl.html> is one
of a number of projects which do.

I've slashed follow-ups.

[Cameron Laird]

In article <5i9o1b$g...@news.istar.ca>,
Hume Smith <hcls...@tallships.istar.ca> wrote:
>In article <01bc42ae$4fc84940$6b91...@odessa.bmc.com>, mst...@bmc.com says...

>
>>Jack Jansen <ja...@cwi.nl> wrote in article <jack.86...@news.cwi.nl>...
>>> ...
>>> ...With languages like Python or Tcl, with
>>> no interface definitions whatsoever, you can only *hope* that you use
>>> every interface correctly. I work on a largish project in Python, and
>>> the one thing that gives continuous headaches is the lack of interface
>>> definitions. Whenever you change an interface it is very very
>>> difficult to check that you haven't inadvertantly broken something.
>>
>>This what the regression testing is for, isn't it ?
>

>if by regression testing you mean running it over and over and hoping someone
>spots something going wrong - no.
.
[sad cautionary tale]
.
.
Now I'm curious; what *did* Mr. Jansen have in mind?
Was he saying that a language which enforces strict
(static?) typing promotes fewer mishaps in using
interfaces? By "interface definition", did he mean
something beyond the syntactic? Certainly there's a
lot of mayhem going on in typical developments just
at the syntactic level, and so improvement there is
significant, but I don't know whether that was all
that was intended. Is Eiffel the model for defini-
tions which are "as good as they get"?

I've sent a copy of this to Mr. Jansen. I've left
follow-ups alone, although I invite others to prune
them.

[Adam Sah]

Dear John,

I just finishing reading the scripting paper -- it's *really* good, imho.
I especially liked the app examples and the decision questions -- they're
dead on!

The USENET rebuttal definitely adds a lot. I also noticed a few things
that would be nice for draft 2:

- It would be nice to more rigorously define "typeless", "weakly
vs. strongly typed", "statically vs. dynamically typed" and "string
oriented". It should be easy enough to do, and it'll shut up a lot of
the whining.

- regexps in Perl, traces in Tcl, etc. are all examples of advanced language
features. In this vein, Java provides garbage collection, exceptions,
objects, safety, convenient concurrency primitives, etc. I think it's
pretty hard to (objectively) toss Java into the "systems language" camp,
at least without more rigorous definitions. A really useful chart would
be one that said what kinds of features are found in scripting languages.
For example, portability of scripts is probably very important.

- imho, a killer example of why you need dynamic code generation is "send".
Other things (ie. widget bindings) can be done with closures, as evidenced
by the various Scheme<-->Tk bindings. Closures can be easier to use than
string eval's because they avoid quoting hell.

- minor nit: Visual Basic is strongly typed and is probably not
"string-oriented" (depending on your definition). You have to declare the
types of all variables. Sure, it has a Dynamic data type, but so do
many ML implementations -- and you wouldn't call them dynamically typed.
Not sure if this hurts the argument.

- minor nit: "I am not aware of any RAD environments for GUIs based on
system programming languages." -- actually, Microsoft's Visual C and C++,
Borland's Turbo C and Pascal, and Symantec's Visual Cafe are all examples
of RADs for GUIs. I still agree with the basic argument, however.

adam
| Mariposa Database Res. Group | Technical Director
Adam Sah | 419 Soda Hall | Inktomi Corp.
as...@cs.Berkeley.EDU | UC Berkeley Dept of Comp. Sci. | http://www.inktomi.com
510-642-8072 | Berkeley, CA 94720-1776 | as...@inktomi.com

..tear.along.dotted.line......................................................

In article <5i7euq$c...@engnews2.Eng.Sun.COM> ous...@tcl.eng.sun.com (John Ousterhout) writes:

From: ous...@tcl.eng.sun.com (John Ousterhout)
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
Date: 6 Apr 1997 06:13:46 GMT
Organization: Sun Microsystems, Inc.
Path: agate!newsfeed.kornet.nm.kr!howland.erols.net!cam-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!venus.sun.com!news2me.EBay.Sun.COM!engnews2.Eng.Sun.COM!tcl!ouster
Lines: 261
Sender: ouster@tcl (John Ousterhout)
Distribution: world
References: <rcybba5...@redwood.skiles.gatech.edu> <1997032716...@menhaden.adi.com> <s6y208um0...@aalh02.alcatel.com.au> <334412fb...@news.demon.co.uk>
NNTP-Posting-Host: tcl.eng.sun.com
Xref: agate comp.lang.scheme:19397 comp.lang.scheme.scsh:474 comp.lang.lisp:26449 comp.lang.tcl:66129 comp.lang.functional:8719 comp.lang.c++:259329 comp.lang.perl.misc:72693 comp.lang.python:20580 comp.lang.eiffel:19437

Wow, there's been quite a party going on over here on comp.lang.scheme!

I'd like to respond to a few of the comments about my white paper on
scripting, but first a couple of introductory remarks:

1. The paper is not intended to be a complete taxonomy of all programming
languages nor is it intended to discuss every factor that contributes
to the usefulness of a language. The paper has a very narrow focus,
namely to explain what scripting is and why it's important. I
intentionally limited the discussion to a few issues such as system
programming vs. scripting, components vs. glue, and strongly typed
vs. untyped. Of course there are other issues in programming language
design. At the same time, I think that the issues in the paper explain
a lot about what's going on in real-world programming.

2. Many people objected to the fact that their favorite programming

was left out of the white paper. Yes, I have heard of Scheme,
Smalltalk, ML, etc. I left these languages out because they
didn't seem particularly relevant for the discussion. No offense
intended...

3. It's very hard to settle arguments about programming languages

because it's hard to produce meaningful quantitative evidence about
things like programmer productivity. I tried to illustrate my points
with historical examples and a few quantitative anecdotes, but I
admit that these are soft. I'd be delighted to see better
quantitative evidence either supporting or contradicting my
arguments. For example, if you know of any quantitative measurements
of productivity improvements caused by object-oriented programming,
please let me know.

When Alaric Williams told me about the flame-fest on comp.lang.scheme,
he proposed a set of counter-arguments for me to respond to. Here
they are, along with my responses.

- Typlessness, as evident in TCL, is not necessarily the best solution.
Dynamic typing is generally agreed to be far more powerful and safe.

Actually, I think Tcl is dynamically typed: everything is checked
at runtime for at least syntactic validity. I used a slightly offbeat
definition of "typing" in the paper: by my definition, "typing" means
declaring the nature of something in advance in order to restrict its
usage. You would probably call this "static typing", no?

- TCL does not scale well to large systems; it is fine for small
"glueing" applications, but in the "real world", such applications
are expected to grow with time, and soon proper typing becomes
necessary, more efficiency becomes necessary, etc.

When I started on Tcl I thought this would be true, but in fact many

people have built surprisingly large programs in Tcl. For example,

there is a real-time Tcl application containing several hundred thousand
lines of code that controls a $5 billion oil well platform and (much to

my shock) it seems to be quite maintainable. Sybase has something like
a million lines of Tcl code in their test suite.

I think it depends a lot on the application. The oil well application

actually subdivides into a whole bunch of small tasks, so it's really
more like 500 smaller programs. Also, if the application is
fundamentally gluing (i.e. the complexity is in the interconnections)
then switching to a more strongly typed language will just make things

worse. One final argument: suppose that Tcl code is harder to maintain,
line for line, than code in a more strongly typed language (I suspect
this is true). But if a Tcl application has only 1/5 or 1/10 the lines
of code of the equivalent program in a strongly typed language, it may
still be easier to maintain overall.

That said, I still suspect that as scripting applications grow it makes
more and more sense to implement parts of them in a system programming
language. The great thing about scripting languages is that this is
easy to do. You can take the performance-critical kernel of a Tcl
application and implement it in C or C++; ditto for any complicated data
structures or algorithms. The simple, non-performance-critical parts
can be left in Tcl. I knew when I started on Tcl that it wouldn't be
appropriate for all problems, so I designed it to work smoothly with
other languages. In contrast, most languages are egotistical: they
expect you to do *everything* in that language and make it very hard to
split the functionality of an application between multiple languages.
For example, I've been involved with several attempts to make C and Lisp
work together, and they all failed.

- It is possible to make languages with execution speeds like C or C++,

that use dynamic typing successfully, whilst being high-level enough
in the creation of abstractions to "glue" things together quite
nicely and easily.

Can you point to a specific language and identify a large community of
users who agree with this assessment? Many people have made claims like
this to me, but no one has been able to point to a good real-world
example. The white paper argues that you can't have a jack-of-all-trades
language. Either you have a strongly typed language, which gives high
speed and manageability but makes gluing hard, or you have a weakly
typed language with the opposite properties.

- Do you really think that object orientation has failed? C++ is a bad

His arguments on "typeless" languages is useless.

You don't need a "scripting language" to
get usable abstractions without the need
to deal with low-level issues.

button .b -text Hello! -font {Times 16} -command {puts hello}

In Macintosh Common Lisp I'll write this as:

(make-instance 'button-dialog-item
:dialog-item-text "Hello"
:view-font '("Times" 16)
:dialog-item-action (lambda (item) (print "hello")))

I think this example supports my claim that scripting languages are a
lot easier to use when you need to mix and match lots of things of
different types. The MCL example is a lot more verbose and complicated
than the Tcl example.

He also gets confused when he talks about object oriented programming

I'm not an MFC expert, so I asked someone else, whom I consider to be

a good Windows programmer, to write this for me. Perhaps there is a
shorter way than the code I included. However, the 6 lines above

don't seem to be equivalent to the Tcl script. For example, there is
no code to respond to the button press, and I believe additional code is
needed to free resources when the button is deleted. Suppose that the
MFC code I used is off by a factor of two, and that it really only takes
12 lines of C++ to duplicate the functionality of one line of Tcl. Doesn't
that still illustrate my point?

--
Thanks again,
Adam Sah | Mariposa Database Research Group
| 419 Soda Hall
as...@cs.Berkeley.EDU | UC Berkeley Dept of Computer Science
510-642-8072 | Berkeley, CA 94720-1776

[Michael David WINIKOFF]

ous...@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
wini...@cs.mu.oz.au
http://www.cs.mu.oz.au/~winikoff

--
Michael Winikoff wini...@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

[Hume Smith]

In article <