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 <MPG.db1e484e...@news.demon.co.uk>,
cyber_...@gubbish.wildcard.demon.co.uk says...

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

FWIW, i'll throw in that i gave up using builders with tk - it became as
easy/easier to write the code directly as use a builder and try to fit it to my
program.

XF was very handy intially, because i could play with the packer dynamically
and learn all its little quirks; but now, having sussed the packer and with the
addition of the gridder (and even the new useable placer), and a few procs of
my own for repetitive stuff (like double scrollbars), builder programs aren't
worthwhile. for me.

[Fergus Henderson]

wini...@mundook.cs.mu.OZ.AU (Michael David WINIKOFF)
gives us an example using TkGofer:

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

I'm pretty sure that that example is more verbose than it needs to be.
The type declaration in the first line is optional -- Gofer will infer
it if you leave it out.

--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.

[Hume Smith]

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.

i remember a program i had to keep interfaced with a library made by someone a
dozen VFPs away, in C. it had one function which took about 18 parameters in
version A, 20 in version B, and 25 in version C... and he didn't provide a
prototype in this header file. obviously he was a crap programmer, but that's
not the point; he wasn't using the features of the language which would have
told me "hey, your interface doesn't match"... the consequences of not setting
those parameters were minute and tended to affect things a long way away from
the function call itself. running the pgm over and over wouldn't tell
you exactly what went wrong, assuming it even *noticed* something wrong.

of course, my example also points out how the best typing features of a
language are pointless if they don't get used... perhaps, finally, it's a
people issue, not a language issue.

[Graham Matthews]

Koen Claessen wrote:
> What do you think of type classes?

> ...

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

I'll second this opinion. I wrote a GUI using TkGofer and it was most
concise and reliable. Far more so than similar things I have written in
Tcl and in Python. The type checking proved very useful -- I had no
problems with TkGofer's strong static typing (ie. it never got in the
way). It's just a pity that TkGofer is hooked up to Tk (I can't stand
the eventloop model of GUIs -- give me threaded GUIs any day!).

graham
--
I would gladly die for a man who was looking for the
truth, but would just as gladly kill a man who thought
he had actually found it -- Voltaire

[Steffen Beyer]

In comp.lang.perl.misc John Ousterhout <ous...@tcl.eng.sun.com> wrote:

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

Perl is very good at this; you can easily embed C code in Perl and vice-
versa (!!), Perl code in C.

If I'm not mistaken, FORTRAN libraries have also been linked in already.

And you can even compile Perl into plain C code.

> - 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?

Yes: Perl.

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

IMHO, "tertium non datur" doesn't hold for Perl...

Because the philosophy of Perl is quite distinct from all other programming
languages (see the interview of Larry Wall and Tom Christiansen in WebWeek -
a link to the article can be found by following links down from www.ora.com),
it combines high speed, manageability and maintainability (if so written,
that is), *and* easy gluing (see "How Perl saved the human genome project" in
"The Perl Journal", for instance).

And Perl actually *is* sort of a "jack-of-all-trades" language...

It's not for pure fun alone that Perl is also nicknamed "PERL = Pathologically
*Eclectic* Rubbish Lister"... :-)
^^^^^^^^

Yours sincerely,
--
|s |d &|m | Steffen Beyer <s...@sdm.de> (+49 89) 63812-244 fax -150
| | | | software design & management GmbH & Co. KG
| | | | Thomas-Dehler-Str. 27, 81737 Munich, Germany.
"There is enough for the need of everyone in this world,
but not for the greed of everyone." - Mahatma Gandhi

[Paul Wilson]

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

>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 suggest saying this right up front in the paper. You could say that
you're using Tcl as an example, but that many other languages, wit
minor modifications, might be comparably suitable for scripting,
or even more so. As it stands, it gives the impression that you're either
very ignorant of programming languages, despite having designed a popular
one, or just speciously hyping Tcl at the expense of languages that developed
many of the same concepts decades ago (and in my opinion, generally did them
better).

I'll grant that this wasn't your intention, but it is the way it comes
across.

This is partly due to the way you give a history of programming languages,
without even having mentioned the most directly relevant early programming
language---Lisp. Lisp has been around longer than any other noticeably
living language except FORTRAN.

(The lack of reasonable discussion of prior work is particularly striking
for a former Distinguished Professor of CS from Berkeley. Maybe it's not
fair because you're in industry now, but a lot of people respect your
technical opinions because they know something of your track record.
And you and Sun don't hide your academic credentials.)

> I intentionally limited the discussion to a few issues such as system
> programming vs. scripting, components vs. glue, and strongly typed
> vs. untyped.

These dichotomies have something to them, but the paper makes it sound like
the issues are very simple and clear-cut. They're not. For example,
Lisp- and Smalltalk-style dynamic typing have big advantages over
"untyped" conversions back and forth through a uniform string representation.
For common cases where you want coercions, you could code them into
the primitive operations. For uncommon cases, it's probably better to signal
type mismatches, so that bugs are easier to track down. Avoiding
continual coercions could also help keep a language from being dog slow.

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

Perhaps. But for sophisticated audiences, there's little that's new,
and much that's grating and seems wrong. For unsophisticated audiences,
it's heavily biased---given your fame, Joe Programmer may take this
kind of thing a little too seriously, and come up with the wrong
impressions.

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

Of course they're relevant, and you probably should know that by now.
(Surely people have complained about this kind of thing before. I
know *I* have heard it before, so I assume you have too.)

For example, a simple Scheme-like language might make a much better
scripting language, with a few minor changes. (E.g., terser names
for built-in procedures and special forms, some important automatic
coercions, and a foreign function interface.)

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

I can't help here.

>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 think it's somewhere in between untyped and dynamically typed.
With dynamic types, every value has a well-defined type, rather than
just "string" or whatever. Put in enough automatic (and unsaafe) coercions,
though, and the difference gets blurry.

>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?

Probably. But in a dynamically typed language, you do associate types with
values. By creating an object that's a general array, or one that's
a string of characters, you may restrict the ways that object can be used
later, without explicit coercions. This is often a good thing, amking
the code clearer.

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

I know some people who have scores of thousands of lines of Tcl in
their applications, but their code is a mess. Tcl simply doesn't
have good abstractions for programming in the large, or even in the
medium. Of course you can do it, given enough patience and care,
but I don't think it proves much in terms of the actual language design.

I'd bet that if those programs were written in a well-designed
general-purpose language, they'd be easier to maintain, and tons
faster to boot. (No, I don't have proof. But I don't think that
large Tcl programs are good evidence for the points you're making.
Often they're evidence against some of your points.)

The main benefits that the Tcl hackers I know get form Tcl are an
interactive command loop, and a standard way of gluing together code
in other languages, and a standard, fairly functional graphics toolkit.
Those are great things, and you're to be applauded for realizing they're
crucial for writing glue code before most other people did! (It certainly
should embarrass the hell out of the programming languages community, of
which I'm a part.)

An interactive command loop is incredibly valuable for increasing
productivity over the usual compile-link-run-crash cycle. What's
sad is how many Tcl programmers there are now who've never used
any other interactive language, and think Tcl is great because it
has that huge advantage over C++.

Other aspects of the language seem poorly motivated. The syntax is
bizarre, the type system (such as it is) is weak and kludgey, and
the idiomatic use of a general evaluator seems like a big mistake.
(You hardly ever need a general evaluator except at the top-level
command loop. Having normal code use it inhibits the ability to
compile to good code, and is error-prone. You're generally better
off using macros for most things that people try to do with eval
If you have hygienic macros a la Scheme, it's much safer, and
macros don't incur runtime overhead in compiled code.)

The lack of real data structures and garbage collection seems
like an equally big mistake.

You these are lessons that Lisp people learned a long time ago, and
many language designers have built on those lessons.

>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 pity them. :-)

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

I find this hard to believe. Maybe the oil well people are incredibly
lucky and their application decomposes wonderfully, but I've never seen
and interesting large application that did that. You generally need
some abstraction mechanisms to manage large programs, whether they're
provided by the language, or hand-kludged for the app.

I suspect that this app is divided into too many too-short Tcl scripts,
with too much flattening of data structures into strings and reconstructing
the structures later. Or worse, it doesn't use interesting data structures,
and is either much kludgier or vastly slower (or both) than it would be if
it did.

And speed is important. I believe that you point out in the intro to
your book that most Tcl programs, contrary to your expectations, are
coded entirely in Tcl. My understand is that interactive program
development is so much easier (and so much more fun) than using batch
languages that people get addicted to it---they're often willing to
sacrifice a lot of performance and important code- and data-structuring
facilities to be able to do it.

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

Maybe yes, maybe no. At the very least, true dynamic typing makes
communicating between modules much less error-prone---you'll usually
get a clear error message sooner than if you're just passing garbled
strings around.

And have a look at ML. Its polymorphic type system LOOKS dynamically
typed, but actually infers types automatically, and type-checks the
program automatically. Pretty spiffy. Most of the advantages of
static typing and most of the advantages of dynamic typing, too.

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

I think that you're oversimplifying here. Many of us will grant
that scripting languages are good to have, and many of us will
grant that something like dynamic typing is nice, at least compared
to having to declare everything all the time. But there's no reason
why a scripting language can't be a reasonable subset of a general-purpose
language (e.g., Scheme with objects), so that you can just COMPILE
your code to make it run pretty fast, rather than having to REWRITE it
in a different language.

There's no reason why a straightforward Scheme-style interpreter
for a Tcl-sized subset of Scheme can't have a similarly small footprint
and run much faster. And certainly you can compile it to vastly
faster code.

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

Why not just write it in a good all-around interactive, compiler-friendly
language in the first place?

>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 think you're really pushing a false dichotomy here. There's big difference
between simple and non-performance-critical, and each of those is a spectrum.
Tcl is not good for non-simple OR for performance-critical programming.
It's so incredibly slow that you're forced to write many simple things
in a different language to get decent performance. It's so incredibly
limited (e.g., in its datatypes) that it's awkward to write code which
may be somewhat sophisticated, e.g, using sophisticated data structures,
but is not time-critical.

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

This is incredibly reasonable, but the scope of things for which Tcl
is good is way, way smaller than it needs to be. You originally thought
that Tcl scripts would be a few lines, or tens of lines, and designed
the language accordingly. But now people are writing things orders of
magnitude larger than that. Either you made a mistake early on, or
they're making them now.

>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?

Depends on exactly what you're asking. I'm not saying there's a single
implementation that gives you everyting you want for Tcl-style apps,
but there's NOTHING hard about it.

Consider SIOD, George Carette's small interpretive implementation of most
of Scheme, which is is embeddable as a scripting language. You can
keep the footprint small by running the GC at a high rate, which will
slow things down a bit, but it'll still be a lot faster than Tcl.

You can write portable Scheme code using the SIOD interpreter, and then
run it through the Marc Feeley's Gambit compiler to get fast code.
Maybe not as fast as C on average, but sometimes faster, and generally
within spitting distance.

Similarly, if you want more scripting and process-control features,
you can use scsh, the Scheme shell. (Unfortunately, scsh is currently
a bit of a pig, because it's built on a fat implementation of Scheme,
but it doesn't have to be---somebody could extend SIOD a little
and port scsh to it, and you'd get the benefits of both. scsh
would run more slowly than it does now, but again, way faster than Tcl.)

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

I guess you haven't read the literature on Lisp and Scheme.
Don't be misled by the big-bag-of-features that Common Lisp became,
or the pigginess of the implementations of it. Lisp itself has
always been amenable to tiny implementations, if you care more about
footprint and startup times than running speed.

And even a small Lisp or Scheme is powerful enough to let you implement
an object system or a module system from within the language. You just
need a macro facility, which isn't much code.

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

I don't think most of us would put it that way. Implementation inheritance
CAN be a truly bad idea if you use it for the wrong things, but it's often
a good thing if you know what you're doing and don't confuse interfaces
with implementations.

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

One of the saddest things about Java is that it screams for an
interactive implementation, rather than batch compilation. (Unlike
C++, it's got enough checking by default to build an uncrashable
interaction environment.)

Once there are interactive implementations, the dichotomy between
scripting and systems languages will be less obvious.
(And if you made type declarations optional in scripts, that
would go much further.)

> [ ... ]

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

The MCL example is mostly more verbose because MCL uses longer identifiers.
If MCL were intended as a scripting language, the identifers could be changed
and some of them could be made more intuitive for non-Lispers. You
could also trivially define the instance-making macro (which I'll call new)
to coerce a font name string into whatever representation it uses for a
font spec.:

(new button :text "Hello" :font "Times 16" :cmd (proc (item) (print "Hello")))

There's nothing about Lisp that makes this much more verbose than
the Tcl version. It's just that MCL isn't mainly designed as a scripting
language, and Lispers usually like to write readable code. This verbosity
has little to do with anything deep about the language.

The nice thing about Lisp is that you can have your cake and eat it too.
You can define the things that are frequently used in scripts so that
they're terse, and the other things so that they're clear. (You can
do this from within the langauge, by defining procedures and macros
that are really just aliases for standard things, using abbreviated
names.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)

[Jack Jansen]

"Mark Sterin" <mst...@bmc.com> writes:

>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 ?

Regression testing is not good enough. The Python model is great
for small project and during the development stage of big projects,
but at some point you want to be able to cast the interfaces in
concrete, and have the compiler check that all uses and definitions of
the interface are correct.

One of the things regression testing will not catch is
misunderstanding over what the interface exactly is. If I create a
module with a function that sorts a list of integers, but my collegue
thinks that it sorts lists of any numbers, and this assumption is
correct for the first implementation but changed later regression
testing will not catch this.

I would dearly like a "companion language" to Python in which I can
specify what interfaces are. If such interface definitions are
available Python would enforce them, giving me a much safer language,
if they are not available Python would function as it currently does.

Unfortunately I have no idea whatsoever as to how one would design and
implement this:-(

[Donal K. Fellows]

In article <E88Ir...@undergrad.math.uwaterloo.ca>,
Paul Prescod <papr...@csclub.uwaterloo.ca> wrote:
[ JO's simple button example elided ]

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

OK, let's raise the stakes a little. :^)

toplevel .t
button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at (%x,%y)"}
pack .t.b -fill both -expand 1

The button now appears in a separate window to the main application
window, and reports where it was pressed. When this window is
resized, the button will occupy any extra space allocated. How much
extra Lisp would be needed to achieve this?

Unless you can do this in very few lines, the point about Tcl being
better for some things would seem to be made amply to me.

But then, I wouldn't write an AI system or theorem prover in Tcl
(though I might embed it within Tcl so I could integrate it with other
preexisting code... :^)

[Scott Draves]

<ja...@cwi.nl> said

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

<mst...@bmc.com> said

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

sure, but it's a lot faster and much less work
to have the compiler type-check your program.

you can do regression testing too if you have time
and really need to.

ob ouster bashing:

is a button a component?

what's the difference between a component and a function?

--
balance
equilibrium
death

http://www.cs.cmu.edu/~spot

[Tom Christiansen]

[courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc,
fell...@cs.man.ac.uk (Donal K. Fellows) writes:
: toplevel .t
: button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at (%x,%y)"}

: pack .t.b -fill both -expand 1
:
:The button now appears in a separate window to the main application
:window, and reports where it was pressed. When this window is
:resized, the button will occupy any extra space allocated. How much
:extra Lisp would be needed to achieve this?
:
:Unless you can do this in very few lines, the point about Tcl being
:better for some things would seem to be made amply to me.

Strange how often people seem to confuse Tk with Tcl. You aren't
talking about Tcl here.

--tom
--
Tom Christiansen tch...@jhereg.perl.com

"Your reality is lies and balderdash, and I'm glad to say that I have no
grasp of it." --Baron Munchausen

[Kelly Murray]

It's only because people can't seem to stop using C/C++
that there is demand for inefficient "scripting" languages.

Common Lisp has so much versatility that it can be used for both
low-level "system" programming as well as "scripting" languages.
Extensive type declarations and safety optimization settings can produce
highly efficient machine code similiar to C compilers.
Fully general purpose macros can be used to define very high level
language constructs, like rules in an expert system,
or also very low-level constructs, like "assembly" languages,
or bit-level array graphics commands, which can expand into
heavily type-declared and optimized "system" CL code.
It's the best of both worlds, and only one simple language and set
of tools needs to be learned.

No other (widely known) language in the world has as much flexibility.

-Kelly Murray k...@franz.com http://www.franz.com

[Carl Zmola]

On 06 Apr 1997 18:35:10 +0200, Fritz Heinrichmeyer
<fritz.hei...@fernuni-hagen.de> wrote:
>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!
>

This is clearly an Eastcoast-Leftcoast argument. Although it seems
that the leftcoast is pushing for conformity. :-)

Carl

[cano_jonathan]

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

>>>>> "CS" == Cyber Surfer <cyber_...@gubbish.wildcard.demon.co.uk> writes:

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

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

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

CS> In other words, Your Mileage May Vary. A contest between VB and
CS> Tcl might be more realistic, as it seems to me that their
CS> strengths are very similar.

IMHO, Ousterhout's paper isn't about how TCL is better than VB as a
scripting language (this bias may show through but it isn't the main
thrust) but how scripting languages have a definite role to play.
- From this standpoint having players who are on the same "team" compete
against one another is meaningless.

- From the point of the white paper, we should have contests between VB
and VC++ to illustrate the the paper's thesis in the Win-tel realm and
we should have contests between TCL and <insert your favorite *system
programming* language> to illustrate the thesis in the UNIX realm.

--

Changing the subject, I'd have to say that MFC used with MSVC++ is
much more productive than writing directly to the Win32 API (I'm not
going to quibble about the exceptions to this generalization). While
much of this could be attributed to MSVC++'s gui building
functionality, I think that *implementation inheritance* works well
for MFC (contradicting Ousterhout's proposition ...).

--

As for VB verses MSVC++, I know several windows developers who have
used both environments for professional development and they all rave
about how great VB is for creating (non computationally intensive)
applications.

I haven't heard one person slander VB's ability to build GUI
applications quickly and effectively.

This anecdotal evidence supports Ousterhout's claim that "scripting"
language are better at being "glue".

Cheers,
--jfc

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM0ljqdg65GR/Kx7xAQFNsgP+JppjeA9zcEejjnG1L3AR+WnAYW91+2+I
+GuydoGYKrZ1AWoOjFmLn53NIx1cgvI7KqsxZeMjMSd4Y3o0JtXhlyAVYIXGj300
EW6EeFNBJZhJSigwrJ5mBWcsIgYvbPuCYlhUMkIW/9Sd+Rr7FRXFnr16yMrQ0nSc
fgfUL4QRvQQ=
=oGKe
-----END PGP SIGNATURE-----

[Jeffrey Hobbs]

In article <5ibl1p$5et$2...@csnews.cs.colorado.edu>,

Tom Christiansen <tch...@mox.perl.com> wrote:
> fell...@cs.man.ac.uk (Donal K. Fellows) writes:
>: toplevel .t
>: button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at (%x,%y)"}
>: pack .t.b -fill both -expand 1

>:How much extra Lisp would be needed to achieve this?

>Strange how often people seem to confuse Tk with Tcl. You aren't
>talking about Tcl here.

Yes and no. Some of the discussion has wandered off the main thrust of JO's
paper, but Donal's point here is LOC (or perhaps more generally syntactic
simplicity). The use of Tk here proves a point because Tk has been grafted
onto so many other languages. The example above is written most "plainly"
(concisely / fewest chars with greatest clarity / ...) when written in Tcl.

That is not to say "Tcl is the best, everyone else bugger off". From
certain viewpoints, it is an advantage. As for other's arguments about JO's
horrible injustices for neglecting to mention <your lang here>, get a clue.
This was a white paper of ~10 pages, not some PhD thesis on languages. The
sum total of the comments alone so far are an order of magnitude longer.
Such a paper isn't just meant for language theorists or die-hard engineers,
but also managerial or business types who are being convinced to use a
scripting language.

Probably JO's worst infraction is the point that tchrist brought up about
portraying "systems" and "scripting" language features as absolutes instead
of breaking down the definitions further.

However, within the realm of JO's original paper, try the above example in
Java. Then try and make it look not so ugly.

--
Jeffrey Hobbs jho...@cs.uoregon.edu,@or.cadix.com
Software Engineer, Oregon R&D office: 541.683.7891
CADIX International, Inc. fax: 541.683.8325
URL: http://www.cs.uoregon.edu/~jhobbs/

[Mark Chu-Carroll]

fell...@cs.man.ac.uk (Donal K. Fellows) writes:

> In article <E88Ir...@undergrad.math.uwaterloo.ca>,
> Paul Prescod <papr...@csclub.uwaterloo.ca> wrote:
> [ JO's simple button example elided ]
> > 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.
>
> OK, let's raise the stakes a little. :^)
>

> toplevel .t
> button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at (%x,%y)"}
> pack .t.b -fill both -expand 1
>

> The button now appears in a separate window to the main application
> window, and reports where it was pressed. When this window is

> resized, the button will occupy any extra space allocated. How much

> extra Lisp would be needed to achieve this?
>

> Unless you can do this in very few lines, the point about Tcl being
> better for some things would seem to be made amply to me.

It's been a while since I've used STK, so I'll use a pseudo-syntax. This
is very close to how it would appear in STk using STklos:

(define top (make <Toplevel> :fill 'both :expand t))
(define but (make <button>
:font "Times 16"
:in top :fill 'both :expand t
:command (lambda (x y)
(display "Pressed at (" x "," y ")"))))
(pack but top)

There you go. Big deal.

At this level, we're discussing trivialities. Sure, TK is cool. But
*lots* of languages can be used to define TK bindings, and many of
them are as simple and succinct at TCL. We can play games with
comparing the number of lines of TCL/TK compared to other TK bindings
all day, and we won't learn anything interesting.

The question is, is Ousterhout's claim that TCL is a good glue
language for significant applications correct? These little 5 line
pissing contests do nothing to address that claim.

Personally, I believe, from my own experience, that TCL is *not* a
good glue language. I've been working, on and off, on a text
editor. The earliest was written in TCL. For that, TCL was really a
nightmare - the lack of real data structures was extremely painful;
the lack of encapsulation was extremely painful. It's my belief that
lacking any support for these two was a crucial mistake in the design
of TCL. The lack of support for data structures is particularly
damning when you realize how trivial it would have been to add some
kind of structure support like Lisps cons-cells.

<MC>

--
Mark Craig Chu-Carroll || "I'm not dumb,
IBM T.J. Watson Research Center || I just have a command of thoroughly useless
m...@watson.ibm.com || information." --- Calvin

[Tom Christiansen]

[courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc,
papr...@csclub.uwaterloo.ca (Paul Prescod) writes:
: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.

What dichotomy? Repeating something doesn't make it true. Perhaps you
missed this brief article I posted last week in response to an article
in comp.lang.python by j...@ks.uiuc.edu (Jim Phillips).

...

Jim Phillips wrote:
:This was an interesting paper, and I agreed with a lot of the comments on the
:advantages of scripting languages. I do, however, feel that the bashing of
:object-oriented programming was unjustified for two reasons:
:
:1) False separation of "scripting" or "typeless" languages from
:object-oriented languages. Objective-C and Python both use a single type for
:objects and do run-time member lookup allowing any object which can handle
:the necessary calls to be used with any package.

(As does Perl, Tom notes tactlessly.)

To me, the whole notion that there exist two kinds of languages:

TYPE A TYPE B

scripting system
interpreted compiled
typeless strongly-typed
glue components
string-based object-oriented
rapid-development product-oriented deliverables

is a facile oversimplification loaded with false dualism. Reality would
seem to be that items in those columns float freely back and forth
depending on many factors, and pretending that they are two sides of a coin
ignores many shades of grey as well as unrelated orthogonal axes.

Cannot compiled languages glue things together? Cannot interpeted
languages be used for systems programming (think of BASIC-PLUS and RSTS/E
for a non-Unix example)? Is there some reason why interpreters should
not have objects, or compilers dynamic/fluid types? I can compile awk
or Perl into C, and thence to assembler and machine language. Or I can
run C or Pascal in an interpreted environment. Does that all of a sudden
change what they are?

I don't think so.

Many of the other points are valid, but it just seems too much a case
of black and white.

--tom
--
Tom Christiansen tch...@jhereg.perl.com

X-Windows: Even your dog won't like it.
--Jamie Zawinski

[Mark A Harrison]

John Ousterhout (ous...@tcl.eng.sun.com) wrote:
: - 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 agree with John's sentiments, but would like to point out that
many (most?) of the sites with large Tcl projects use the extension
[incr Tcl] which adds an object system to Tcl. Class-based programming
seems to scale more gracefully both in terms of program size and
and the number of people working on a project.

Mark.

[Richard A. O'Keefe]

fell...@cs.man.ac.uk (Donal K. Fellows) writes:

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

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

I note that the way Limbo (the vaguely C-ish language used in the Inferno
network OS) handles its GUI interface is by creating window objects and
sending Tk strings to them. There is no TCL there; just their completely
fresh implementation of Tk. What precisely is there about C++ that would
prevent equally direct use of a Tk clone from C++?

--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

[Richard A. O'Keefe]

ous...@tcl.eng.sun.com (John Ousterhout) 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...

Lisp having been used as a scripting language for a lot longer than TCL,
it was a *relevant* omission. (Yes, I have used Lisp as my command and
scripting language, and yes, it was before TCL.)

> - 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?

But restricting it to a large community smuggles in another criterion:
marketing. SELF, for example, has dynamic typing, and published benchmarks
show it close to C or C++. I imagine people at Sun would understand more
about SELF than I do. I've certainly had Scheme code perform close to C
(with the aid of comilers that do a fair amount of type inference, admitted.)

I would also expect someone from Sun to be aware of the awesome ease of
interoperability with C/C++ offered by ESH.

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

This is clearly false. You can have a language with *optional*
declarations which can be checked and relied on if they are there.
Mercury programs, for example (a statically typed language) can usually
by run by NU Prolog (a dynamically typed language) if you erase the
declarations. Common Lisp type information is optional. There are
people currently designing a type system for Erlang (Ericsson's
functional + concurrent language); that will be yet another example
of a system with optional declarations for speed and static checking
yet able to run without them. (Henry Baker has a paper on a type
inference algorithm for Common Lisp types.)

[Graham Matthews]

fell...@cs.man.ac.uk (Donal K. Fellows) writes:

> >: toplevel .t

> >: button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at (%x,%y)"}
> >: pack .t.b -fill both -expand 1

Jeffrey Hobbs wrote:
> Yes and no. Some of the discussion has wandered off the main thrust of JO's
> paper, but Donal's point here is LOC (or perhaps more generally syntactic
> simplicity). The use of Tk here proves a point because Tk has been grafted
> onto so many other languages. The example above is written most "plainly"
> (concisely / fewest chars with greatest clarity / ...) when written in Tcl.

But this statement is not true. Someone posted the above code in TkGofer
and it had fewer characters (or at worst a roughly similar number of
characters). Moreover the TkGofer code is more robust since its
statically typed check.

Jeffrey Hobbs wrote:
> However, within the realm of JO's original paper, try the above example in
> Java. Then try and make it look not so ugly.

Try it in TkGofer and you will see the fallacy of your position.

graham

--
beating on a tin drum marching to a sound
what is it I think?
am I beating on a tin drum marching to a cause
when I don't know what it is I believe

[Cyber Surfer]

With a mighty <k9qk9me...@prism.loc201.tandem.com>,
ca...@loc201.tandem.com uttered these wise words...

> IMHO, Ousterhout's paper isn't about how TCL is better than VB as a
> scripting language (this bias may show through but it isn't the main
> thrust) but how scripting languages have a definite role to play.

If anyone is going to discuss tools for easily creating Windows
programs, then VB has some relevance. To most people, Tcl is far
behind VB in terms of the ease of developing Windows apps. We should
really be comparing Visual Basic with Visual Tcl, of course.

Comparing Tcl/Tk with C++/MFC is certainly interesting. If you've read
the Tcl/Tk review in Windows Tech Journal, you may have noticed that
Tcl/Tk is compared to VB, not the other way around. (Not that this
means anything: readers of that review will more likely already be
familiar with VB.) A text box mentions that Ousterhout is working on
an interface building tool, "similar to Visual Basic and NeXTStep,
called SpecTcl." Is SpecTcl available yet? It sounds like it could
make Tcl/Tk a lot more attractive for Windows developers.

Unfortunately, the closest material that I can find in this magazine,
for the last year, is stuff about AciveX scripting. Almost everything
else is about VB or C++.

> - From this standpoint having players who are on the same "team" compete
> against one another is meaningless.

Which team is this? If you mean VB and Tcl programmers, well, I'm not
sure that they even know that each other exist, never mind playing on
the same "team". While two tools may address similar problems, you'd
have to be pretty naive to expect the people who use them to
appreciate the value of any alternatives.

This thread should be more than enough evidence of that, but if it
isn't, then consider the years of bickering about the value of this,
the virtues of that, and frustration of the other.

> - From the point of the white paper, we should have contests between VB
> and VC++ to illustrate the the paper's thesis in the Win-tel realm and
> we should have contests between TCL and <insert your favorite *system
> programming* language> to illustrate the thesis in the UNIX realm.

There's also the "look and feel" factor. I've read that Tk for Windows
can now do a Windows "look and feel", which is excellent. Tk really
needs that, if you want Windows people to accept it. The X Windows
"look and feel" just won't do, I'm afraid. I know that X Windows is a
lot more flexible than MS Windows, but this is _exactly_ why Windows
people won't accept anything that deviates from the "standard"
behaviour - unless it's MS software, of course.

Encarta is a prime example of how MS can break their own rules and get
away with it, if they make the software atrractive enough. I gues if
you define the "rules", you can change 'em, too. Anyway...

> Changing the subject, I'd have to say that MFC used with MSVC++ is
> much more productive than writing directly to the Win32 API (I'm not
> going to quibble about the exceptions to this generalization). While
> much of this could be attributed to MSVC++'s gui building
> functionality, I think that *implementation inheritance* works well
> for MFC (contradicting Ousterhout's proposition ...).

It's certainly more productive than a lot of things, for apps that
have a user interface that uses features already supported by MFC. For
example, the document/view classes help with a lot of MDI apps. This
is another "look and feel" issue, only at the app level rather than
the "window manager" level. If you prefer to ignore the official style
guide (I have the old IBM CUA book, but not the more recent MS guide),
then you'll probably have more work to do, even if you do use MFC.

> As for VB verses MSVC++, I know several windows developers who have
> used both environments for professional development and they all rave
> about how great VB is for creating (non computationally intensive)
> applications.

Most Windows apps are "non computationally intensive", as many of them
only need to call code in other components - written in C++, no doubt.
This is one the qualities that VB has in common with Tcl. VB is great
for glueing components (OLE,OCX,DLL,etc) together. The VB part of an
app need only provide the user interface, and even that might mostly
be done by OCX components. Does this sound like Tcl/Tk or what?

> I haven't heard one person slander VB's ability to build GUI
> applications quickly and effectively.

Same here. I'd love to see the same kind of interface builder working
with other languages. Borland did this with their Pascal (yes, son,
Pascal is _still_ alive and kicking), with stunning results. If you
think that Pascal is obscure, then consider what could be done with a
more "popular" language (take your pick).

> This anecdotal evidence supports Ousterhout's claim that "scripting"
> language are better at being "glue".

Err, what? Did I miss something? Better than C++, maybe, but that's
not saying anything. Delphi can beat the crap out of VC++, as can VB.
If you look at other platforms, let's not overlook Guile, or any other
alternative. However, for Win32, it would be pretty hard to beat VB.
I'm wondering if ActiveX might help change that, but it's too early to
tell. Right now, ActiveX looks like a great way to embed VB or Java in
your MFC apps! Not exactly what many of us would prefer, I bet!

If "anecdotal evidence" is such a good argument, then VB/Java/C++ will
easily beat everything else. Most people think they _already have_. I
don't think that any of our arguments will convinec them otherwise,
but we can certainly try. However, IMHO we may need to be a little
more honest about the strengths and the failings of our tools, coz I'm
sure that the marketing folk at MS and Sun won't be.

Ousterhout at least got one thing "right", in that his arguments for
Java will be very welcome to all the people who've already chosen (or
think that _they've_ chosen) that language. Your pro-Tcl arguments
will probobaly fall on as many deaf ears as my pro-Lisp arguments. ;)

BTW, if your newsreader can't crosspost, then ignore this criticism -
we can't all choose our newreaders, but most of us can, hence the use
of the "cheap trick" (see below) with followups. So, just let us know,
and we can reset the newsgroup list accordingly.

However, I see that you're using Gnus v5.1. Either this software is
unable to crosspost (which I seriously doubt!), or you should upgrade
to a more recent version, like Gnus v5.3. So...

Thanks for setting your followups to comp.lang.tcl, but I'm not stupid
enough to fool for that old trick. If you want a "debate", then let's
have one where everyone can join in, rather than just those who will
more likely agree with you. I could easily set the followups for
_this_ article to comp.lang.basic.visual.misc, but I don't use cheap
tricks like that.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note the "gubbish" in my email address.

[Paul Prescod]

In article <5ibkb4$5et$1...@csnews.cs.colorado.edu>,

Tom Christiansen <tch...@mox.perl.com> wrote:
> [courtesy cc of this posting sent to cited author via email]
>
>In comp.lang.perl.misc,
> papr...@csclub.uwaterloo.ca (Paul Prescod) writes:
>: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.
>
>What dichotomy? Repeating something doesn't make it true. Perhaps you
>missed this brief article I posted last week in response to an article
>in comp.lang.python by j...@ks.uiuc.edu (Jim Phillips).

Someone asked about Sun's reason for promoting Tcl and Java. I wrote what
Sun's point of view was. You should mail your article to Sun.

Paul Prescod

[Smiljan Grmek]

2 bits worth by a recalcitrant programmer who declines going into sales,
consultancy or CS, and likes crafting precision software.

---

Discussing the merits of a language by contrasting it to all others is
unfair because a better one is easily found for any specific aspect.
This would imply that we should have a sort of 'language tournament' -
one on one - and probably no clear winner would emerge from that.

It should be remembered that Tcl was modelled after *shells* (remember
the surprise by authors of Unix that quite large shell programs were
being written and deployed - finaly catered to by 'shell compilers'). It
is a textual interpreter, like all the shells, a number of BASICs of
yore and a few 456Gen DB languages of today. This means: useful, slow,
wonderful for 5-liners, loose syntax, self-modifying, cryptic.

But the name is constant: Tool control langugage - glue code for
medium-sized application chunks, invoked either as procedures or
programs (vide Expect). To this day this purpose was faithfully served -
regression testing packages, net control systems, GIS applications, DB
interfaces ... all of these were produced by coordinating extant modules
using Tcl glue.

Let us not forget the proven practicality and usefulnes of Tcl - and no
amount of practicality of other languages can detract from it.

Tcl is an ugly duckling, to be sure - but all real-world langugages of
any impact are: COBOL, FORTRAN, C, C++, (awk, perl ... and the
unmentionable VB) with possible exceptions of PASCAL and ADA. For
contrast we can look at the elegant ones: Algol, LISP, Smalltalk, Scheme
(and here I refuse to name the recent ones, studies having shown that
most of the people earning their bread by programming are incapable of
understanding and using them). They are orthogonal, concise, clear - but
used mostly by the academe and as test-beds for extensions - and in
practice producing systems like MACSYMA with 1E9 lines of LISP code
(shudder ...).

Is it possible that languages with bumps and rough surfaces are somehow
easier to remember and decode when reading than quicksilver smooth
theoretical ones? Is it perhaps easier to interpret an ad-hoc construct
than to reconstruct semantics from first principles?

Tcl is for writing *programs* not *algorithms*. Think of it more as a
tool to get things done then a vehicle for expressing ideas.

My experience with Tcl is satisfactory. Having to write a system which
would control a number of weighing scales in an industrial application
the first step was choosing the implementation language. First decision:
C or other was influenced by the 'other' part - there had to be event
queuing, there had to be socket communications, there had to be Oracle
interface, there had to be text analysis (for a small application
language was envisioned). Tcl popped up as just the right tool. Two
months and 5000 lines of code later the system was delivered and had
only one problem - the scales sent leading zeroes with integer data and
these were interpreted as octal. And the application language was
implemented by converting it to Tcl and directly executing - did not
even have to write an expression evaluator!!!

The speed problem (later proven imaginary) was solved by investing in a
more powerful CPU. If I consider what would have to be done to code the
thing in C (even though I am vastly more familiar with C/C++ than Tcl) I
must conclude that the development would take much more time and effort.

Tcl downloads easily, compiles with no warnings - quite rare with
freeware - has ample documentation, sample programs (a Web browser had
approx 2000 lines - remarkable), and anybody who ever did any shell
scripting can use it immediately. Apparently Prof. Ousterhout is firmly
in control and resists all but the most useful additions or changes to
the language.

Tcl is not panacea, but it is a far better card up your sleeve than ...
(will not name names - you can fill this blank quite easily). In fact it
can only be compared to Perl.

After version 8.0, Tcl has a bytecode compiler/interpreter - really hard
to do when the text interpreter behavior must be preserved. If the
bytecode can be maped to the Java VM, then with the advent of hardware
Java VM processors Tcl will become a JIT - hilarious.

Smiljan Grmek
s...@4mate.hr

[Robin D. Newton]

Richard A. O'Keefe wrote:
> I note that the way Limbo (the vaguely C-ish language used in the Inferno
> network OS) handles its GUI interface is by creating window objects and
> sending Tk strings to them. There is no TCL there; just their completely
> fresh implementation of Tk. What precisely is there about C++ that would
> prevent equally direct use of a Tk clone from C++?
>

> --
> Will maintain COBOL for money.
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Out of idle curiosity, if there are Tk bindings for scheme, limbo,
python, caml, etc, does that mean Tk can be used to build an application
using components written in scheme, limbo, python, caml, etc? I can't
actually think of a reason why someone might want to do that, but you
never know.

Also (a bit off subject) if components are viewed as processes
communicating
over channels, rather than objects invoking methods on each other, how
does that effect a langauge's scope for static typechecking? Passing
strings over iostreams sounds sort of flimsy. I could be wrong there, of
course.

Robin Newton.

[Daniel Wang]

After thinking about J. O's paper it looks like what he's really talking
about is domain specific versus general purpose langauges.

Where "scripting language" = Domain Specific
and "systems language" = General Purpose.

When he talks about "gluing" I think he's really ought to say putting
together primitives designed by someone else that are at the right level of
abstraction. Read with this perspective some of what he says sounds a bit
more resonable.

[Rainer Joswig]

In article <5ic0qc$e...@psychotix.cs.uoregon.edu>, jho...@cs.uoregon.edu
(Jeffrey Hobbs) wrote:

> In article <5ibl1p$5et$2...@csnews.cs.colorado.edu>,

> Tom Christiansen <tch...@mox.perl.com> wrote:
> > fell...@cs.man.ac.uk (Donal K. Fellows) writes:
> >: toplevel .t
> >: button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at
(%x,%y)"}
> >: pack .t.b -fill both -expand 1
>

> >:How much extra Lisp would be needed to achieve this?

This depends on the GUI toolkit you would use and has nothing
to do with Lisp.

> Yes and no. Some of the discussion has wandered off the main thrust of JO's
> paper, but Donal's point here is LOC (or perhaps more generally syntactic
> simplicity). The use of Tk here proves a point because Tk has been grafted
> onto so many other languages. The example above is written most "plainly"
> (concisely / fewest chars with greatest clarity / ...) when written in Tcl.

Is "fewer chars" is a meaningful criteria for software quality?
I'd rather prefer readability and fewer implicit assumptions.
I'd also prefer layout in declarative formats. etc. etc.

--
http://www.lavielle.com/~joswig/

[Russ McManus]

mr. ousterhout-

many thanks for producing the wonderful tk and tcl libraries.

i do take issue with one of your main points however. you
seem to think that tcl sits on the curve of pareto optimality
between language power and 'glueing' facility.

the pareto optimum is the curve that describes the trade off
between two competing value functions; it shows where one can
not improve in one direction with out going backwards in the
other.

please forgive the ascii charts:

g | .
l |
u | .
e | * <---tcl
i | .
n | c++
g | . |
| . |
e | . v
a | .
s | . * .
e |
+-----------------------------
language power ->

however, i think the situation looks more like this:


g | .
l |
u | .
e | * * <--stk, e.g.
i | ^ .
n | | c++
g | | . |
| tcl . |
e | . v
a | .
s | . * .
e |
+-----------------------------
language power ->

as an example, i present erick gallesio's wonderful
scheme system stk, which is a combination of your very
own tk library with scheme instead of tcl.

the interface to tk is quite sparse, very nearly as
clean as tcl's. and the programmer gets the additional
power of scheme as compared to tcl.

as for glueing, there is a complete foreign function
interface that is well documented and very easy to use.
dynamic loading is supported.

i agree that scripting/glue languages have necessary trade
offs; i also think that it is possible to have scripting
languages that are considerably more powerful than tcl.

-russ

--
Russell D. McManus phone: 212-357-4901
Goldman, Sachs & Co. beep: 917-556-0708
Intl. Equities Technology

[Russ McManus]

fell...@cs.man.ac.uk (Donal K. Fellows) writes:

>
> OK, let's raise the stakes a little. :^)
>

> toplevel .t
> button .t.b -text Hi! -font {Times 16} -command {puts "Pressed at (%x,%y)"}
> pack .t.b -fill both -expand 1
>

> The button now appears in a separate window to the main application
> window, and reports where it was pressed. When this window is

> resized, the button will occupy any extra space allocated. How much

> extra Lisp would be needed to achieve this?
>

if you are using STk, then there is a nearly direct translation
from the tcl version to the scheme version. you also get to
program in scheme, which is considerably more powerful than

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Smiljan" =3D=3D Smiljan Grmek <S...@4mate.hr> writes:

Smiljan> Is it possible that languages with bumps and rough surfaces are so=
mehow
Smiljan> easier to remember and decode when reading than quicksilver smooth
Smiljan> theoretical ones? Is it perhaps easier to interpret an ad-hoc cons=
truct
Smiljan> than to reconstruct semantics from first principles?

No.

Anyone who has to read and write production code in Perl or Tcl or C++
within the same period as, say, Scheme, can testify to that.

--
Cheers =3D8-} Mike
Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla

[Graham Matthews]

Smiljan Grmek wrote:
> Tcl is an ugly duckling, to be sure - but all real-world langugages of
> any impact are: COBOL, FORTRAN, C, C++, (awk, perl ... and the
> unmentionable VB) with possible exceptions of PASCAL and ADA. For
> contrast we can look at the elegant ones: Algol, LISP, Smalltalk, Scheme
> (and here I refuse to name the recent ones, studies having shown that
> most of the people earning their bread by programming are incapable of
> understanding and using them). They are orthogonal, concise, clear - but
> used mostly by the academe and as test-beds for extensions

The argument is flawed. Smalltalk is in fact widely used in commercial
programming. So your nice separation into "ugly but used" vs "elegant
and academic" is false. Moreover Java is taking off commercially and yet
it is essentially a subset of Smalltalk.

Smiljan Grmek wrote:
> Is it possible that languages with bumps and rough surfaces are somehow

> easier to remember and decode when reading than quicksilver smooth

> theoretical ones? Is it perhaps easier to interpret an ad-hoc construct

> than to reconstruct semantics from first principles?

There is a much simpler reason why all these ugly languages about -- its
called intertia. There was a lot of code written in the 70s in ugly
languages -- written before we knew how to make good languages. All that
code has to be supported, interfaced to, etc, so all the ugly languges
it is written in are now the standard. Simple.

graham
--
well alas we've seen it all before
knights in armour, days of yore
the same old fears and the same old crimes
we haven't changed since ancient times

[Donal K. Fellows]

In article <87d8s8j...@A-abe.resnet.ucsb.edu>,
Graham C. Hughes <graham...@resnet.ucsb.edu> wrote:
> Donald Syme <drs...@cl.cam.ac.uk> writes:
>> Trash. Show me C++ which is as succinct and I may believe
>> 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.

What exactly do you mean by "subclassing"? How can you be sure that
you need a C extension to do it with Tcl/Tk? I have made Tcl/Tk-only
labelled frames, comboboxes and progress meters quite easily, so it is
entirely possible that you are simply mistaken in your assertion.

> 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

What version are you talking about? This (a long-standing complaint
of many Tcl entheusiasts) is no longer true in Tcl8.

> - numbers that autoconvert when you don't want them to (on
> east coast area codes, for example)

I believe this (another moan of great age) is fixed too.

> - non-extensible mathematical expressions (think expr here)

Fair enough, though I'd add that putting in your own stuff (which does
admittedly have a different syntax) is still not hard.

> - call by name
> - dynamic scoping

These two are construable as a feature (though I would like the other
kind of semantics AS WELL... :^)

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

For some things.

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

I suppose it all depends on your definition of trivial, but there are
commercial applications out there written in Tcl/Tk with over a
million lines of code. I do admit that systems of that size (whatever
written it) boggle my mind a bit though... :^)

[Henry Baker]

In article <334B68...@maths.anu.edu.au>, Graham Matthews
<graham....@maths.anu.edu.au> wrote:

> There is a much simpler reason why all these ugly languages about -- its
> called intertia. There was a lot of code written in the 70s in ugly
> languages -- written before we knew how to make good languages. All that
> code has to be supported, interfaced to, etc, so all the ugly languges
> it is written in are now the standard. Simple.

There are far more ugly programs than ugly languages. Using a 'good'
language does not guarantee pretty programs. In fact, since a 'good'
language has immense power, it is possible to write uglier
programs in a 'good' language, than it is to write ugly programs in
a 'bad' language. This, of course, is one of the justifications I've
seen for forcing people to write in 'bad' languages !!

[Fergus Henderson]

Graham Matthews <graham....@maths.anu.edu.au> writes:

>... Java is taking off commercially and yet

>it is essentially a subset of Smalltalk.

Hmm, didn't you forget to put the phrase "strongly typed" somewhere?

Perhaps the reason that Java is taking off commercially is that it is
seen as essentially a subset of <insert your favorite language here> ;-)

--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.

[Jason Trenouth]

On 7 Apr 1997 04:47:45 -0500, wil...@cs.utexas.edu (Paul Wilson) wrote:

> One of the saddest things about Java is that it screams for an
> interactive implementation, rather than batch compilation. (Unlike
> C++, it's got enough checking by default to build an uncrashable
> interaction environment.)
>
> Once there are interactive implementations, the dichotomy between
> scripting and systems languages will be less obvious.
> (And if you made type declarations optional in scripts, that
> would go much further.)

Checkout Asymetrix SuperCede:

http://www.asymetrix.com/schome/

for some steps in this direction.

__Jason

[Smiljan Grmek]

Graham Matthews wrote:

> The argument is flawed. Smalltalk is in fact widely used in commercial
> programming. So your nice separation into "ugly but used" vs "elegant

> and academic" is false. Moreover Java is taking off commercially and yet

> it is essentially a subset of Smalltalk.
>

Sorry, Smalltalk is infinitesimaly used. There is an ongoing drive by
IBM (of all companies!) but with little sucess. This can easily be
verified if you look at job offerings on the Net with Smalltalk as
keyword.

And it is hard to discuss computer languages with someone who can
seriously entertain the thought that 'Java is a *subset* (of all
possible relationships!) of Smalltalk!'

>
> There is a much simpler reason why all these ugly languages about -- its
> called intertia. There was a lot of code written in the 70s in ugly

-------- insecundia? imprimia - inquartia!

> languages -- written before we knew how to make good languages. All that
> code has to be supported, interfaced to, etc, so all the ugly languges
> it is written in are now the standard. Simple.

So now we know how to make *good* languages - like good indians?
Seriously, languages must be designed for average, garden variety of
programmers, not CS graduates. US DOD stated that conversion to parallel
processing is not advisable because only 1/3 of their programmers could
program in appropriate languages.

Smi

[Donn Cave]

as...@CS.Berkeley.EDU (Adam Sah) writes:
...
| - 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.

a.) For me, it's not at all clear why you think those features of Java
disqualify it from being a ``systems language''. While the ``scripting
languages'' have been bringing in some features from more formal
languages, the point of that paper seemed to be that in general
you don't need those features to script and glue.

In a sense this only proves your point - without more rigorous
definitions, we only end up arguing about semantics and lose the
point (if there is one.) I'd go farther, though: the notion of
using four or five computer languages (C, C++, Java, Tcl and VB)
to define a language taxonomy of ``scripting'' vs. ``systems''
needs rethinking. Even among these five we start to see some
strange bedfellows, as you point out.

b.) Portability is the last thing I'd worry about in a scripting language.
Contrary to apparently widespread belief, ``as we approach the year
2000'' scripting languages have been a mainstay of computing technology
pretty much all along, but the need to port old scripts hasn't been a
big issue. Occasionally you will hear from people who wish they could
port their DCL/REXX/Bourne shell/who knows what scripts, but this is
usually a sign of their own confusion. Scripting languages are so
profoundly dependent on their environment - the things they're gluing -
that it's pointless to port only the glue, you have to bring along the
whole environment. Time to reimplement, rather than port.

Again, this probably goes back to confusion over what we're talking
about. Further drafts of this paper may help to clarify the subject
of discussion. A system that hopes to implement applications all by
itself might indeed want to be portable. If a scripting language is
one of the components of such a system, then the language has to be
as portable as the other components. What's as likely to happen,
though, is that the other components (e.g., graphics) are going to
much harder to port with satisfactory results, and you'll get better
results if you can replace those components with their natural equivalent
in the destination environment. With luck, you may have designed it so
that major wholescale rewriting isn't necessary ... and that turns out
to be the point of all the abstractions provided by the formal languages,
for example, OOP: to improve your luck in these situations.

Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu

[Smiljan Grmek]

Michael Sperber [Mr. Preprocessor] wrote:

>
> Anyone who has to read and write production code in Perl or Tcl or C++
> within the same period as, say, Scheme, can testify to that.

[ie Scheme is better]
>

*Anyone* is a fairly large concept - please go find an average
programmer without experience in Tcl and Scheme, present him/her with
appropriate manuals and have h/h read/write code ...

Even a thought experiment gives correct results (if one bears in mind
the Gaussian distribution of human attributes - necessary for the
definition of *average* programmer)

Talk to a pschologist friend about averages and you will find out where
those who meet at the Net stand. I tested a friend's contention that you
cannot talk to an IQ 100 - he was mostly right and it was a saddening
experience.

Smi

[John Ousterhout]

In article <334B68...@maths.anu.edu.au>, Graham Matthews <graham....@maths.anu.edu.au> writes:
|>
|> There is a much simpler reason why all these ugly languages about -- its
|> called intertia. There was a lot of code written in the 70s in ugly

|> languages -- written before we knew how to make good languages. All that
|> code has to be supported, interfaced to, etc, so all the ugly languges
|> it is written in are now the standard. Simple.

Sorry, but this doesn't really make sense. For example, if "ugly languages"
refers to Tcl or Perl or C++, none of these languages even existed in the
1970s. In contrast, various flavors of Lisp have been around since at least
the early 60's and Smalltalk first appeared in the late 60's. Every single
programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even
C could have chosen Lisp, Scheme, or Smalltalk. But they didn't. If you
want to know the truth, I think you need to stop making superficial excuses
and ask deeper semantic questions. There really is something better about
each of these "ugly languages" that gives them an advantage over the "good"
languages; I'll leave it up to you to figure out what it is.

[Erik Naggum]

* Smiljan Grmek

| This can easily be verified if you look at job offerings on the Net with
| Smalltalk as keyword.

ahem. job markets have weird and counter-intuitive dynamics. let's say
you want to find cheap labor and the ability to fire people at will. it
would be smart to offer the job to a lot of people, all competing with each
other to drive their asking price down. mass marketing of jobs has very
significant benefits for employers, and almost only negative consequences
for employees. if there are many who could take your place, you're only as
well paid as your best competitor, and you can't plan very far ahead due to
the high probability of being replaced. assembly-line programmers are not
expected to add any significant value to the programming process, either,
just get the damn thing to work. therefore, you need lots of them, and it
is a good idea if lots of people could take these jobs. consequence: a
vibrant jobs market with mostly incompetent people who hire and get hired.

Smalltalk, Ada, and Lisp jobs are not advertised in the mass media. to get
at highly qualified personnell, employers must expect them to have a good
education, be able to and want to plan fairly far ahead, and have a sense
of quality that is incompatible with today's software. it would also be
silly to advertise such a job in the mass market for another reason: it
tells other programmers and companies that the hiring company is unable to
attract qualified programmers in niche markets. thus, they would not get
any useful responses, as well as getting negative publicity.

consider TV ads as another example. those who advertise on TV seek
customers who are easily manipulated by TV ads. that's why you see a lot
of religious groups, lawyers who speak of how much money they got their
clients, and car dealers advertise amidst the toilet and hygiene articles
and the detergents. some restaurants advertise on the TV, but invariably
those that attract mass market customers, such as burger and pizza joints
and the like. a gourmet restaurant should _not_ advertise on TV because
that would associate them with the restaurants that do.

the mass market is largely uninteresting if you're offering or after
anything of high quality. this applies to jobs, too.

| Seriously, languages must be designed for average, garden variety of
| programmers, not CS graduates.

you forgot to state the primary requirement of those languages this applies
to: that you want to advertise the language itself in the mass media and
likewise with programmer positions, and that you want to pay chicken feed
to those you hire. if you have somewhat higher aspirations, you design a
language so that average, garden variety programmers don't understand it,
or won't flock to it.

| US DOD stated that conversion to parallel processing is not advisable
| because only 1/3 of their programmers could program in appropriate
| languages.

precisely. note the converse: if you would like to retain the best third
of your programmers, convert to parallel processing.

those who argue for quantity over quality have yet to demonstrate that the
lower prices carry smaller costs in terms of reduced quality than it saves.

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

[Fredrik Lundh]

> | This can easily be verified if you look at job offerings on the Net with
> | Smalltalk as keyword.

> Smalltalk, Ada, and Lisp jobs are not advertised in the mass media

From Computerworld, October 1996 ("big cry for smalltalk")

/.../

For example, Source Services Corp., a Washington-area recruiting firm,
had more than 200 openings for Smalltalk programmers in the first half
of this year, compared with 77 openings in the same period last year.

Demand for C++ talent, on the other hand, is declining.

For the same period, Source Services had 140 C++ positions, down from
175 a year earlier, according to Paul Villella, managing partner at
the company's Tyson's Corner, Va., office.

/.../

Everything is relative, I suppose...

On the other hand, I've started seeing more and more Python ads
lately. Guess we're doomed ;-)

Cheers /F (http://hem1.passagen.se/eff)

[Erik Naggum]

* John Ousterhout

| Every single programmer who ever wrote a program in Tcl, Perl, C++,
| Visual Basic, or even C could have chosen Lisp, Scheme, or Smalltalk.
| But they didn't.

yeah, this is a _really_ ingenious argument. let's look at the operating
word here, "could". how do people choose languages? do they pick them out
of the blue? or do they pick languages according to hype, marketing,
availability, perceived proximity to known languages, etc? it should be
pretty darn obvious that they don't choose languages they don't "know".
C++ won because it was "a better C", then, as people got more into it, it
grew to become a behemoth of a language. perl was a cute little thing that
combined several of the silly little Unix languages into one language and
added a few cute improvements. then it got cancer and grew to become an
enormous _implementation_ of a largely unspecified language, just like its
predecessors. now, tcl is not really language, either, just as the Bourne
shell, awk, sed, etc, are not languages. they are just tools in a toolbox.
languages have more than one implementation. perl doesn't. does Tcl?

the Distinguished Professor of Computer Science has turned into a Marketing
Droid. how incredibly sad.

| If you want to know the truth, I think you need to stop making
| superficial excuses and ask deeper semantic questions.

the way I read this debate, people are asking deep, semantic questions of
Tcl and they get superficial excuses for answers.

| There really is something better about each of these "ugly languages"
| that gives them an advantage over the "good" languages; I'll leave it up
| to you to figure out what it is.

one word: novelty. for some reason, immature people prefer a new language
over an existing language when they are presented with one new and one old.

unformed people delight in the gaudy and in novelty.
cooked people delight in the ordinary.

[Henry Baker]

In article <5ighvq$e...@engnews2.Eng.Sun.COM>, ous...@tcl.eng.sun.com (John
Ousterhout) wrote:

> Sorry, but this doesn't really make sense. For example, if "ugly languages"
> refers to Tcl or Perl or C++, none of these languages even existed in the
> 1970s. In contrast, various flavors of Lisp have been around since at least

> the early 60's and Smalltalk first appeared in the late 60's. Every single

> programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even

> C could have chosen Lisp, Scheme, or Smalltalk. But they didn't. If you

> want to know the truth, I think you need to stop making superficial excuses

> and ask deeper semantic questions. There really is something better about

> each of these "ugly languages" that gives them an advantage over the "good"
> languages; I'll leave it up to you to figure out what it is.

Strong hyping ??

[Steven Correll]

In article <hbaker-0904...@10.0.2.1>,

You may be right. About ten years ago the AI folks (representing Lisp,
Prolog, neural networks, etc) were the acknowledged masters of hype,
but today they seem to have squandered their lead. I realized they were
fading a couple of years ago when I got a trial subscription to an AI
magazine along the lines of "C++ Report", and the feature story was
(I'm not making this up) a case study of an expert system written in Awk.
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == s...@netcom.com

[Stefan Monnier]

ous...@tcl.eng.sun.com (John Ousterhout) writes:
> 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

Now, I don't understand one thing: why is OO evil if its only problem is that
it doesn't increase productivity ? As far as I can see, OO doesn't have too
many nasty side-effects.

Once you have admittedl that what you meant by "strongly typed" was actually
"statically typed" and that Tcl is more or less "dynamically typed", the
question comes down as: what is the advantage of Tcl over other dynamically
typed languages ? I can see reasons to use a dynamically typed language (for
scripting among other things), but why insist on a string-based system ?

String based systems have several problems that you have to recognize such
as performance (Tcl is well known for its lame speed and to overcome it,
Tcl-8.0 has to partly drop the "everything's a string" principle) and support
for data-structures. Now you'll say "if you need data-structures, go to C", but
why ? Why couldn't my scripting language support data-structures nicely ?

I didn't need hand-assembly performance for my "approximate email matching"
in Exmh's interface to PGP, and since Exmh is a tcl-only program, including C
code in the distribution would have been a huge pain, so I coded the thing in
Tcl, result:
- the code is ugly
- the performance is bearable on current fast machines, whereas with the
simplest scheme interpreter (which only offers lists but no proper
structures), it would have been instantaneous even on a lowly 286 (or 68K)

Stefan

-----------------------------------------------
-- strings are the MS-DOS of data-structures --
-----------------------------------------------

[Karel Thönissen]

Donn Cave wrote:

> In a sense this only proves your point - without more rigorous
> definitions, we only end up arguing about semantics and lose the

Obviously you do not understand what semantics is. You remind me of the
British PM who once said about the discussion on further European
integration 'Mere Semantics'. As if semantics is not what it is all
about!!

> [....]

> Donn Cave, University Computing Services, University of Washington
> do...@u.washington.edu

Semantics amongst CS people is widely understood as the study of the
effect of expressions (usually programs) on the machine. However,
Semantics Proper studies the relationship between signs and the things
they stand for. Semantics as understood by CS is a special branch of
syntactics! (explaining one sign through equivalence in terms of
another)

Groeten, Karel

[Bill House]

John Ousterhout <ous...@tcl.eng.sun.com> wrote in article
<5ighvq$e...@engnews2.Eng.Sun.COM>...

>
> Sorry, but this doesn't really make sense. For example, if "ugly
languages"
> refers to Tcl or Perl or C++, none of these languages even existed in the
> 1970s. In contrast, various flavors of Lisp have been around since at
least
> the early 60's and Smalltalk first appeared in the late 60's. Every
single
> programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or
even
> C could have chosen Lisp, Scheme, or Smalltalk. But they didn't. If you
> want to know the truth, I think you need to stop making superficial
excuses

> and ask deeper semantic questions. There really is something better

about
> each of these "ugly languages" that gives them an advantage over the
"good"
> languages; I'll leave it up to you to figure out what it is.
>

That argument ignores the issues of tool availability and market awareness.
For example, in the WinTel world, one could point to the dearth of Tcl
applications as an aspersion on the "deeper semantic issues" of the tool,
but that would be wrong. It's not that all VB programmers have evaluated
against Tcl,. it's that most VB programmers don't know about Tcl, don't
hear much (if anything) about it and don't care -- for them, it's a
non-issue.

People use the tools that are available for them to use. From the list of
candidates, they choose based on perceived values that only include
quality. Familiarity, job security and market advantage are other drivers.
Note the word "perceived". Who can really tell how a language is going to
work out before implementing a few systems? Who gets the word out? The big
advantage that these so-called "ugly" languages enjoy is in part based on
marketing and the fact that companies are packaging the technology in tools
that people can use.

Other languages, such as Lisp, also suffer from this dynamic. Lisp is
perceived as some obscure, experimental language that is inherently slow.
None of this is necessarily true, but perception prevents many WinTel
programmers from even investigating the options. This loss of a potential
market in turn suppresses venture capital for Lisp products, limiting the
number of vendors. The fact that these programmers you speak of didn't
choose Lisp is most likely because Lisp was not even seen as a candidate,
and thus not even tried.

Bill House
--
bho...@dazsi.com
http://www.dazsi.com

[Rainer Joswig]

In article <5iafs1$f...@roar.cs.utexas.edu>, wil...@cs.utexas.edu (Paul
Wilson) wrote:

> > (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.
>
> The MCL example is mostly more verbose because MCL uses longer identifiers.
> If MCL were intended as a scripting language, the identifers could be changed
> and some of them could be made more intuitive for non-Lispers. You
> could also trivially define the instance-making macro (which I'll call new)
> to coerce a font name string into whatever representation it uses for a
> font spec.:
>
> (new button :text "Hello" :font "Times 16" :cmd (proc (item) (print
"Hello")))

Common Lisp users just don't believe in short identifiers.
They work with large libraries and very helpful interactive
development environments. Completion of names is only a keystroke
away. Macintosh Common Lisp is just fine for scripting other applications
(since it does support AppleEvents). People are using it all day for this.
Once you have to deal with libraries larger than just some GUI
stuff, then you will acknowledge descriptive names, a cool
object system, explicit datatypes and *interactive* use with
full speed of a native code Lisp compiler. You just don't
need the destinction between scripting and systems programming,
prototyping and delivery. Things start to become unified.

--
http://www.lavielle.com/~joswig/

[Graham Matthews]

Graham Matthews wrote:
> > The argument is flawed. Smalltalk is in fact widely used in commercial
> > programming. So your nice separation into "ugly but used" vs "elegant
> > and academic" is false. Moreover Java is taking off commercially and yet
> > it is essentially a subset of Smalltalk.

Smiljan Grmek wrote:
> Sorry, Smalltalk is infinitesimaly used. There is an ongoing drive by

> IBM (of all companies!) but with little sucess. This can easily be

> verified if you look at job offerings on the Net with Smalltalk as
> keyword.

Unfortunately looking at the Net job offering is not the gospel truth.
I'll give you a hint. Go read up how many software servers were written
in Smalltalk (before the advent of Java).

Smiljan Grmek wrote:
> And it is hard to discuss computer languages with someone who can
> seriously entertain the thought that 'Java is a *subset* (of all
> possible relationships!) of Smalltalk!'

But on many fronts Java is a subset of Smalltalk, both linguistically
and implementationally. The most obvious example is the Java virtual
machine that everyone is praising as the best thing since slice bread.
Smalltalk (and other languages) have had virtual machines for years.

> So now we know how to make *good* languages - like good indians?

> Seriously, languages must be designed for average, garden variety of
> programmers, not CS graduates.

What rubbish. You can train people to use a modern language just like
you can and do train them to use an older language. The "oh these new
languages are too hard to learn for Joe average programmer" just doesn't
stand up. How can a language with no pointers, no explicit memory
alloc/dealloc, etc be harder to learn than one where you have to do all
that yourself ...

>US DOD stated that conversion to parallel
> processing is not advisable because only 1/3 of their programmers could
> program in appropriate languages.

Indeed! And good programming languages do the conversion for the
programmer. Exactly my point.

graham

--
The girls is all salty, the boys is all sweet,
the food ain't too shabby
an' they piss in the streets
In France, way down in France, way on down, way on down in France

[Graham Matthews]

Bill House wrote:
John Ousterhout <ous...@tcl.eng.sun.com> wrote in article

> Sorry, but this doesn't really make sense. For example, if "ugly
> languages" refers to Tcl or Perl or C++, none of these languages
> even existed in the 1970s.

Bill House wrote:
> That argument ignores the issues of tool availability and market awareness.
> For example, in the WinTel world, one could point to the dearth of Tcl
> applications as an aspersion on the "deeper semantic issues" of the tool,
> but that would be wrong.

> ...

> People use the tools that are available for them to use. From the list of
> candidates, they choose based on perceived values that only include
> quality.

>..

> Other languages, such as Lisp, also suffer from this dynamic. Lisp is
> perceived as some obscure, experimental language that is inherently slow.
> None of this is necessarily true,

Bill you are letting rational argument and empirical fact get in the way
of the barrow you have to push :-) :-) [for the humour impaired]

[Jay Martin]

>> So now we know how to make *good* languages - like good indians?
>> Seriously, languages must be designed for average, garden variety of
>> programmers, not CS graduates.

CS graduates make competent software engineers..... yeah right.
Studies have shown lobotimized rats make better programmers than CS
graduates. But seriously, Computer Science is not doing a good job of
training software engineers. I agree that production oriented
languages should be design to be simple, promote good "programming in
the large" software engineering and be easily understandable in a
human understanding sense (as opposed to some CS theoretic
masturbation sense) for both CS and non-CS graduates.

>What rubbish. You can train people to use a modern language just like
>you can and do train them to use an older language. The "oh these new
>languages are too hard to learn for Joe average programmer" just doesn't
>stand up. How can a language with no pointers, no explicit memory
>alloc/dealloc, etc be harder to learn than one where you have to do all
>that yourself ...

I believe certain languages will higher training costs than other
languages. If I made a OO/functional/logical/constraint
based/procedural/dynamic-static-inferenced typed language (probably
based on analogies with the string theory of quantum gravity), then
the training time will probably be huge, especially if the traines are
not exactly "Marilyn Vos Savants". If the language doesn't really
give you any big gains over let say Eiffel, then whats the point?
C/C++ is complex and is hard to learn by the average Joe programmer,
but this gives no credence to language designs that remove some of
C/C++'s complexities but then add a whole bunch of other complex
features. I am sick of bloated languages, but thats all thats
possible due to standards committees, marketing pressures and
"bizarre/fad concept of the day" oriented academics.

>>US DOD stated that conversion to parallel
>> processing is not advisable because only 1/3 of their programmers could
>> program in appropriate languages.

>Indeed! And good programming languages do the conversion for the
>programmer. Exactly my point.

For many application areas, parallel programming is not trivial in any language.

Jay (CS Graduate)

[James Logajan]

John Ousterhout (ous...@tcl.eng.sun.com) wrote:
: Every single programmer who ever wrote a program in Tcl, Perl, C++, Visual

: Basic, or even C could have chosen Lisp, Scheme, or Smalltalk. But they
: didn't.

Others have responded to this point adequately; however, I just happen to be
working on a product that is going to require a scripting or extension
language. We get to pick our own language (for once). Our short list includes:

Lua
Python
Perl
Tcl

I have not used any of these before, so have "fresh eyes" on our team. We
need a language that is easy for beginners to pick up, that is not too
slow, handles string processing well, has a small memory footprint, and
is of course extensible. OOP support was considered important, but not
vital.

So far, Lua is winning, with Python still in the running because of its
stronger OO support. Tcl is horribly slow with no particular feature
that compensates for its sluggishness. Perl seems too syntactically unruly
for people to get a good grip on how best to compose their work but has
about the same speed as Python.

Lua is about 1/10 the size of the others (~70k versus ~1000k for all the
others on a Sparc) and is several times faster than Python and Perl. Tcl
is an order of magnitude (10, not 2!) slower than Python/Perl.

It is too bad that Lua doesn't have its own newsgroup (yet?). I was
pleasantly surprised by the small size, fast speed, simple syntax, and
powerful semantics of the language.

[Steve Cassidy]

> As for Tcl, it's there for one reason and one reason only -- strong
> corporate backing. We've got a powerful company that wants to
> make a quick buck and therefore is using its clout to force
> Tcl down our throats. This is the same tactic used by charlatans
> like Micro$oft. Indeed that's the only possible explanation
> as to why a glorified text preprocessor would even get a second
> look -- that and the fact that it is riding on the coattails
> of Tk.

Many people, myself included, started using tcl/tk before Sun took it
up. Remember that this is a free tool, which for my purposes is very
important. The current corporate backing is certainly seeking to
extend the user base of tcl/tk but, I would imagine, a vast proportion
of the current code base would still be there if Sun hadn't taken over.
My own decision to use tcl was based on easy embedding in my code and
the presence of Tk. I'm no great fan of the language but it is wrong
to compare Sun with Microsoft in this manner -- microsoft is unlikely
to give you the source of VB or port it to unix.

--
Steve Cassidy
Speech, Hearing and Language Research Center
School of English Linguistics and Media
Tel: +61 2 9850 8729 Macquarie University
Fax: +61 2 9850 8240 North Ryde,NSW, 2109
st...@srsuna.shlrc.mq.edu.au Australia
http://srsuna.shlrc.mq.edu.au/~steve

[Graham Matthews]

Graham Matthews <graham....@maths.anu.edu.au> writes:
> |> There is a much simpler reason why all these ugly languages about -- its
> |> called intertia. There was a lot of code written in the 70s in ugly
> |> languages -- written before we knew how to make good languages. All that
> |> code has to be supported, interfaced to, etc, so all the ugly languges
> |> it is written in are now the standard. Simple.

John Ousterhout wrote:
> Sorry, but this doesn't really make sense. For example, if "ugly languages"
> refers to Tcl or Perl or C++, none of these languages even existed in the

> 1970s. In contrast, various flavors of Lisp have been around since at least
> the early 60's and Smalltalk first appeared in the late 60's.

I didn't say that every language designed in the 60s or 70s was bad. Nor
did I say anything about every language designed since the 60s and 70s.
So your argument falls flat.

John Ousterhout wrote:
>Every single
> programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even
> C could have chosen Lisp, Scheme, or Smalltalk. But they didn't.

Yep and the probable reason they didnt was that they had to interface to
some existing code already written in one of these languages. Or (in the
case of Perl) they wanted to do something very specific and found the
language in question excellent for that.

John Ousterhout wrote:
> If you
> want to know the truth, I think you need to stop making superficial excuses
> and ask deeper semantic questions. There really is something better about
> each of these "ugly languages" that gives them an advantage over the "good"
> languages; I'll leave it up to you to figure out what it is.

So far I have yet to see something better about these "ugly languages".
As far as I can see people have quite effectively rebutted all the
points you made in your white paper, and subsequently on newsnet. For
example you mentioned how concise Tcl code was to interface to Tk. But
then someone posted a more concise piece of TkGofer code that did the
same thing. etc etc etc

[cosc...@bayou.uh.edu]

John Ousterhout (ous...@tcl.eng.sun.com) wrote:

: In article <334B68...@maths.anu.edu.au>, Graham Matthews <graham....@maths.anu.edu.au> writes:
: |>
: |> There is a much simpler reason why all these ugly languages about -- its
: |> called intertia. There was a lot of code written in the 70s in ugly
: |> languages -- written before we knew how to make good languages. All that
: |> code has to be supported, interfaced to, etc, so all the ugly languges
: |> it is written in are now the standard. Simple.

: Sorry, but this doesn't really make sense. For example, if "ugly languages"

: refers to Tcl or Perl or C++, none of these languages even existed in the
: 1970s.

Sounds like you need to review your history of languages. C++, while
not existing in the 70s, was designed to be a superset of a language
that was -- you get three guesses as to which language that is. Therefore
C++ _IS_ a product of inertia.

As for Perl and Tcl, they seem very "shell-like" to me, so I'm tempted
to say that they are also a product of inertia from that direction,
but someone with more knowledge in these particular languages would
do well to answer that issue, and also perform appropriate dating
as to the age of the predecessors of those 2 languages.

: In contrast, various flavors of Lisp have been around since at least

: the early 60's and Smalltalk first appeared in the late 60's.

I was under the impression that Smalltalk first appeared in the early
70s.

: Every single

: programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even
: C could have chosen Lisp, Scheme, or Smalltalk.

Here you show a grievous lack of common sense that goes well with your
lack of knowledge about language-history. The only programmers who
would be able to choose Lisp, Scheme, or Smalltalk are those who
would have known that those languages existed, and you would be
surprised at how many people do _NOT_ know they exist. I ran into
these languages because I was _ACTIVELY_ looking for languages,
this is the same reason I ran into Haskell (my favorite language).

Consider the average programmer who does not actively look for
new languages, but sits on her/his tail until some organization
hypes a marginal package as The Next Big Thing(tm), and then
proceeds to swallow it up. That's how crappy products become
big. That's the story of Tcl.

Many of the programmers I spoke with have very little if any knowledge
about the above languages, how can you even claim that they prefer
the languages they are using over the above ones?

Furthermore remember that most programmers program in the language
mandated by their employers -- I am the same way. We don't have
a choice most of the time.

: But they didn't. If you

: want to know the truth, I think you need to stop making superficial excuses
: and ask deeper semantic questions.

I think you need to wake up and smell the coffee. There are numerous
reasons why these superior languages were not chosen, the fact that
you are grasping at one flimsy reason does nothing but make one wonder
if you even have a clue.

: There really is something better about

: each of these "ugly languages" that gives them an advantage over the "good"
: languages; I'll leave it up to you to figure out what it is.

Let's see, C became popular for one reason only -- it was almost
mandatory for programming under Unix which was widespread (and
still is). So C rode on the coattails of an operating system, and
was not chosen on any virtue of the language itself. C++ is
popular for one reason only -- it isn't a far step away from C which
means that the C crowd flock to it in safety. So C++ rode on the
coattails of C which rode on the coattails of Unix.

Perl I could give some credit for -- it is a powerful tool although
its resemblence to shell scripting is still an issue which I feel
has helped it gain more acceptance. It's a lot easier to accept
something that looks familiar than something that looks foreign
(which explains why Lisp languages and Smalltalk didn't gain the
following that C and C++ did).

As for Tcl, it's there for one reason and one reason only -- strong
corporate backing. We've got a powerful company that wants to
make a quick buck and therefore is using its clout to force
Tcl down our throats. This is the same tactic used by charlatans
like Micro$oft. Indeed that's the only possible explanation
as to why a glorified text preprocessor would even get a second
look -- that and the fact that it is riding on the coattails
of Tk.

Try to come up with some arguments next time.

--
Cya,
Ahmed

[lvi...@cas.org]

According to Graham Matthews <graham....@maths.anu.edu.au>:
:> want to know the truth, I think you need to stop making superficial excuses
:> and ask deeper semantic questions. There really is something better about

:> each of these "ugly languages" that gives them an advantage over the "good"
:> languages; I'll leave it up to you to figure out what it is.

:
:So far I have yet to see something better about these "ugly languages".

:As far as I can see people have quite effectively rebutted all the
:points you made in your white paper, and subsequently on newsnet. For
:example you mentioned how concise Tcl code was to interface to Tk. But
:then someone posted a more concise piece of TkGofer code that did the
:same thing. etc etc etc

What kind of 'good' are we talking about? An intrinsic moral, ethical, or
technical superiority? Or is 'good' being defined as 'that undefinable
quality to results in a programming language being used by large numbers
of programmers, for large numbers of tasks'? Or is there some other
definition being battered about here?

I see nothing morally, ethically or technically superior about Tcl, Perl,
C, C++, or for that matter LISP, Scheme, Eiffel, etc.

If we are talking about the aspects of a language that result in it being
used for large numbers of tasks, of course one has to define what large
is and in relationship to what other languages.

I suspect there are many more IBM MVS JCL 'scripts' than there are programs
in any other scripting language. I suspect Visual Basic programs
make up the largest number of programs on MS-DOS/Intel machines - which is
supposedly the largest installed platform of computers.
C , COBOL, or FORTRAN may be the 'high level' languages with the most programs.

Are Visual Basic/Visual C/Visual C++ the most popular languages under
MS-DOS because of their technical superiority, their cost, their manufacturer,
their relationship to the owner of their OS?
--
Larry W. Virden INET: lvi...@cas.org
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.

[M. Prasad]

cosc...@bayou.uh.edu wrote:

> Let's see, C became popular for one reason only -- it was almost
> mandatory for programming under Unix which was widespread (and

When C became popular, the other major choices were Pascal, Fortran,
Basic, and at some places, Lisp. Pascal suffered from numerous
problems for writing large programs. All of these problems
were solved by the compiler vendors, but you had to learn the
particular solutions for each compiler you had to use. Fortran was
ok, but typos were a big nuiscance, and at the time it wasn't
structured. Basic was not useful for serious programming.
Lisp at the time was not very useful for systems
programming, and no standards existed. Smalltalk was
not available and when available was unusably slow.

So the rise of C happened because it was the best
language available for practical reasons. It may
have had something to with Unix, but this doesn't
explain why it also became the language of choice
on systems such as VAX/VMS (where the vendor was
actively pushing a language called Bliss for all systems
programming.)

A similar pheonomenon occurred in the PC world, which was
taken over by C. This was quite a surprising occurence for
the PC world. In early 80's, BYTE magazine covered
all languages it thought would be useful for the PC.
Smalltalk was deemed so important that it later on got
an article all to itself. C, somehow or the other,
didn't quite make it in the list of BYTE's languages.
The clear winner according to BYTE magazine was Pascal.
Yet by late 80's, most of PC programming had moved from
Pascal, Assembly and Basic to C and C++. The primary
reasons may have been the ability to do hardware manipulation
and memory accesses directly from C, thus saving the
programmer from having to use Assembly when speed was
not a concern.

So hype or the lack of it doesn't quite do it. People
choose languages for their own very sane reasons. Arguing
abilities and debating tricks of adherents have not proven
to be very effective, otherwise Lisp would be the most
widely used language today. It's not as if multi-million
dollar companies did not exist at one time to promote
Lisp. It's also not as if they lacked promotional
abilities or dedicated champions.

[lvi...@cas.org]

:> As for Tcl, it's there for one reason and one reason only -- strong

:> corporate backing. We've got a powerful company that wants to

The only strong corporate backing that I have seen has been from the
corporations using Tcl as a part of their products. Well, Sun continues
to pay the Tcl/Tk development team's salary, and for a couple of weeks
put 5 or 6 web pages up on their main corporate web site. That's been,
to date, about the extent of Sun's backing.

:> make a quick buck and therefore is using its clout to force

I don't know too many corporations still around who are only interested
in a slow buck. Got to some how pay those high salaried engineers,
the electricity for their computers, etc.

:> Tcl down our throats. This is the same tactic used by charlatans

Wow! I really feel for you. I myself typically have quite a tough time
finding a Sun employee other than the Tcl team itself who has even heard
much of Tcl - you have them coming to your office and force feeding the
language to you!

:> like Micro$oft. Indeed that's the only possible explanation

:> as to why a glorified text preprocessor would even get a second
:> look -- that and the fact that it is riding on the coattails
:> of Tk.

Hmm - seems like lots of folk have given that text preprocessor more than
just a second look. It's so sad to see techie cults like comp.lang.tcl
continue unchecked.

[Douglas Seay]

[posted and mailed]

Erik Naggum wrote:
>
> * John Ousterhout

> | Every single programmer who ever wrote a program in Tcl, Perl, C++,
> | Visual Basic, or even C could have chosen Lisp, Scheme, or Smalltalk.

> | But they didn't.
>
> yeah, this is a _really_ ingenious argument. let's look at the operating
> word here, "could". how do people choose languages? do they pick them out
> of the blue? or do they pick languages according to hype, marketing,
> availability, perceived proximity to known languages, etc? it should be
> pretty darn obvious that they don't choose languages they don't "know".
> C++ won because it was "a better C", then, as people got more into it, it
> grew to become a behemoth of a language. perl was a cute little thing that
> combined several of the silly little Unix languages into one language and
> added a few cute improvements. then it got cancer and grew to become an
> enormous _implementation_ of a largely unspecified language, just like its
> predecessors. now, tcl is not really language, either, just as the Bourne
> shell, awk, sed, etc, are not languages. they are just tools in a toolbox.
> languages have more than one implementation. perl doesn't. does Tcl?

If I understand you correctly, you are saying that the definition of a
language (as opposed to a tool) is multiple implementations? If I sat
down and wrote a new implementation of Perl or Tcl from scratch, then
these two "tools" would become "languages"? Since gawk is a superset of
awk and was written from scratch, does this mean that awk is now a
language and gawk is half-language, half-tool?

I'll agree that they aren't ivory tower languages, and that the language
specification may have been created hand-in-hand with the tool, but I
don't see how that makes them less of "languages". This m ight be
ancient history, but was there a formal specification of COBOL, FORTRAN
or APL before the first implementation?]

But the first part of your paragraph is correct. People often do chose
languages for reasons other than "which is best for this task". Some
important items that you overlook are support and complimentary tools
(debuggers, code generators, etc), and ocassionally cost.

> the Distinguished Professor of Computer Science has turned into a Marketing
> Droid. how incredibly sad.

Oh no, he sold out! Traitor! Don't you just hate it when the
underground groups go mainstream? It ruins everything. I'll never buy
one of his albums again!

> | If you want to know the truth, I think you need to stop making

> | superficial excuses and ask deeper semantic questions.
>

> the way I read this debate, people are asking deep, semantic questions of
> Tcl and they get superficial excuses for answers.
>

> | There really is something better about each of these "ugly languages"
> | that gives them an advantage over the "good" languages; I'll leave it up
> | to you to figure out what it is.
>

> one word: novelty. for some reason, immature people prefer a new language
> over an existing language when they are presented with one new and one old.

I'm not sure that I agree with this. Am I immature for chosing "new"
Perl over "old" C? The same for deciding to use "new" perl instead of
"newer" Python? I have yet to see a language that lets me do what I
want more easily than Perl. Should I chose lisp as my text formatting
language of choice because it is "good" and not "ugly"? Maybe SmallTalk
instead? Maybe I don't have an ivory tower view of languages.

> unformed people delight in the gaudy and in novelty.
> cooked people delight in the ordinary.

But aren't "ugly" languages like Perl, VB, C++ and Tcl more "ordinary"
than the "good" languages Lisp, Scheme, and Smalltalk? How do you
define "ordinary"? I would say that procedural languages are more
"ordinary" than functional or OO languages. Does "ordinary" means
"often used? Although I dislike VB, I'd bet that there is as much
working code in VB as in the whole lisp family of languages. Yes, this
is just a gut feeling, I have no numbers to back it up.

I'll admit that I'm being a bit of the devil's advocate here because I
don't like several of the "ugly" languages here. I certainaly don't use
Tcl and I don't think I'm likely to ever use it if I have an
alternative. But that doesn't mean I like Ivory Tower attacks on
practical languages. Tcl was made to do something specific, namely glue
together executables. In this domain, it does its job.

> I'm no longer young enough to know everything.

funny sig.

- doug

PS - The syntax of perl5 is actually simplier than perl4. The thing
that got bigger was the libraries. But since it is no longer "cute", I
couldn't expect you to keep up with it.

[M. Prasad]

Bill House wrote:
> Other languages, such as Lisp, also suffer from this dynamic. Lisp is
> perceived as some obscure, experimental language that is inherently slow.

> None of this is necessarily true, but perception prevents many WinTel
> programmers from even investigating the options. This loss of a

Lisp is rather nice, but it is the evangelists/Lisp-marketeers
many of us could do without. I have gotten to suspect that
since a programming language occupies a lot of a programmer's mind
and thoughts, and since programming in Lisp tends to encourage
the quick hack for "fooling the machine" to get what you want
done, the hardcore Lisp programmers tend to acquire the mindset
that in a newsgroup the objective is to "fool the audience" to
get them to believe whatever you want them to believe.

Amazingly, a lot of the hardcore ng Lisp evangelists don't even
seem to have learned the language or the issues well, but are good
at fooling the audience into believing they have! And those
who do know the language and the issues well will not speak
out if it contributes away from a "desired" fooling of the
audience. Contrast that with C, where in strange debates
involving Scott Nudd, C supporters would go out of their way
to correct each other if one of them stepped on the truth
and facts.

Duck...

[Bill House]

Graham Matthews <graham....@maths.anu.edu.au> wrote in article
<334C23...@maths.anu.edu.au>...

>
> Bill you are letting rational argument and empirical fact get in the way
> of the barrow you have to push :-) :-) [for the humour impaired]
>

Actually, since I'm not in sales and my employer doesn't sell a Lisp
programming tool, I guess my only "barrow" is that I hate to see good
technology (and techniques) go under utilized.

Bill House
Director of Engineering
DAZSI
--
bho...@dazsi.com
http://www.dazsi.com

[Vassili Bykov]

Smiljan Grmek <S...@4mate.hr> wrote in article <334BC5...@4mate.hr>...

> Sorry, Smalltalk is infinitesimaly used. There is an ongoing drive by
> IBM (of all companies!) but with little sucess. This can easily be
> verified if you look at job offerings on the Net with Smalltalk as
> keyword.

Sorry, but you have no idea what you are talking about. Are you an
experienced Smalltalker unable to find a job? I don't think so. If you
claim Smalltalk is "infinitesimally" used, it's you who are in the wrong
place in the wrong time with the wrong skills. No, Smalltalk jobs are not
hire-by-the-dozen kind of thing some others are, but this is only an
advantage when you are on this side of the fence.

Besides, it might be useful to know that interesting positions are rarely
found through the Net or newspaper ads.

--Vassili

[Bill House]

M. Prasad <pra...@not4u.polaroid.com> wrote in article
<334CD6...@not4u.polaroid.com>...

> So hype or the lack of it doesn't quite do it.

Hype alone won't make an intelligent shopper buy, but without some form of
hype, the shopper needs to be quite a scrounger to even locate the
"product". In an ideal world, perhaps all products would be evaluated
fairly, but this world is no one's ideal.

[Rainer Joswig]

In article <5ihqfv$f...@lynx.dac.neu.edu>, mkag...@lynx.dac.neu.edu
(Michael Kagalenko) wrote:

> I think you'll excuse me for another mention of NeXT programming
> environment, based on dynamically-typed language. Interface
> builder allows you to create, change and test interface without
> compiling it. I do not know of any analog of this tool.

Why not compile it? Don't you guys have incremental compilation?
Even the ideas for the Interface Builder was once a Mac program
written in Lisp (ExperLisp?).

For a newer user- and object-oriented scripting language with strong
capabilities in user interface programming (multimedia) see the
SK8 project from Apple (http://sk8.research.apple.com/).
Btw., written in MCL.

--
http://www.lavielle.com/~joswig/

[bvaleria]

What's with the JavaScript bomb and the flashing text - you discover a
few new script commands and you have to show your new-found knowledge to
everyone??

Spamming jerk.... will you grow up and get a life, you reject....

[M. Prasad]

Bill House wrote:
>
> M. Prasad <pra...@not4u.polaroid.com> wrote in article
> <334CD6...@not4u.polaroid.com>...
>
> > So hype or the lack of it doesn't quite do it.
>
> Hype alone won't make an intelligent shopper buy, but without some form of
> hype, the shopper needs to be quite a scrounger to even locate the
> "product". In an ideal world, perhaps all products would be evaluated
> fairly, but this world is no one's ideal.

I am sure there have to be mechanisms to make the product
available to the users. In the case of C, AT&T's cheap
Unix licenses certainly must have helped. However, of
all the choices which did have the good luck to get
out there, the ones which do survive well, must have some
strong contributing reasons.

I don't think AT&T did any serious marketing of C.
They just let it get out there. At least that
is my impression, since I was in the field when
C was starting to get popular -- I already knew
Fortran, Pascal, Lisp and APL before I heard
of a language called C. So I knew there were
very good personally validated reasons for me
to prefer C over, say, Pascal. Developing
multiple-module programs in Pascal could be
quite a pain. By the time somebody asked my
opinion about which language to use for a serious
product development effort, I had already had to
learn three different Pascals, with their own ways
to handle modularity and their own "use variant,
write integer, read pointer" type tricks that were
forced in systems programming. So I had no
hesitation in answering -- "C". No hype from AT&T
was required.

I am sure my personal experiences were repeated
over and over, resulting in many different
projects choosing to use C. What is more,
those who saw C projects succeeding where
others floundered, made their own conclusions.
These conclusions and successes are much
more powerful than any amount of arguments.

[Mike Haertel]

In article <5ihaol$n...@Masala.CC.UH.EDU>, cosc...@bayou.uh.edu wrote:
>As for Tcl, it's there for one reason and one reason only -- strong
>corporate backing.

Tcl rose to prominence long before Ousterhout ever joined Sun.
It is just as much of a "grass roots" language as perl or python.
There are indeed many things to criticize about Tcl, but before
you start slinging stones and arrows you should at least get
your facts right.
--
Mike Haertel <mi...@ducky.net>

[Jesper Buus Nielsen]

Daniel Wang <dan...@salomon.CS.Princeton.EDU> skrev i artiklen
<r8tg1x1...@salomon.CS.Princeton.EDU>...
>
> After thinking about J. O's paper it looks like what he's really talking
> about is domain specific versus general purpose langauges.
>
> Where "scripting language" = Domain Specific
> and "systems language" = General Purpose.
>
> When he talks about "gluing" I think he's really ought to say putting
> together primitives designed by someone else that are at the right level
of
> abstraction. Read with this perspective some of what he says sounds a bit
> more resonable.

Unless of course his totally undocumented (as anything in the article was
that) comment about OO languages - not that I do not agree in his opinion,
but 'opinion' is an important word that JO confuses with the english word
fact(1).

/Jesper

(1) Or maybe he is confusing it with the sentence "I'm proud of me
concept". Taking into consideration the widespread use of Tcl - he should
be, but pride makes no trues.

[Jesper Buus Nielsen]

Kelly Murray <k...@math.ufl.edu> skrev i artiklen
<5iboqu$qhk$1...@sparky.franz.com>...
> It's only because people can't seem to stop using C/C++
> that there is demand for inefficient "scripting" languages.
>
> Common Lisp has so much versatility that it can be used for both
> low-level "system" programming as well as "scripting" languages.
> Extensive type declarations and safety optimization settings can produce
> highly efficient machine code similiar to C compilers.
> Fully general purpose macros can be used to define very high level
> language constructs, like rules in an expert system,
> or also very low-level constructs, like "assembly" languages,
> or bit-level array graphics commands, which can expand into
> heavily type-declared and optimized "system" CL code.
> It's the best of both worlds, and only one simple language and set
> of tools needs to be learned.
>
> No other (widely known) language in the world has as much flexibility.

That is (at best) an useless comment. To some point I agree, but all that
you do is setting off another flame-thread by using a very inconcise term
as "widely known". As far as I'm concerned the BETA(1) language will give
you those advantages too, including a portable(2) GUI system, a persistent
object system that interfaces with C++(3) and a fully graphical development
environment. NB: CLOS were a significant source of inspiration in designing
BETA - and BETA, being one of the first languages fully combining locality
(block structure) and OO, was the main source of inspiration in making up
the "inner classes" of Java - a beer to the one that find the ref. in the
Java documentations - I know that it is there - saw it :-)

(1) Look at: http://www.daimi.aau.dk/~beta/
(2) Windows [95/NT], Mach., Unix and maybe, to me, unknown systems.
(3) Forgive me writing that diabolical sequence of characters.

/Jesper

>
> -Kelly Murray k...@franz.com http://www.franz.com
>
>