····@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.
From: Joe English
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5huesh$sgh@crl2.crl.com>
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
········@crl.com
In article <··················@aalh02.alcatel.com.au>, Chris Bitmead
<·············@alcatel.com.au> wrote:
> ····@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?
--
············@mbnet.mb.ca
I have to agree that this article is complete drivel. Where has this guy
been? While it's true that dynamic typing can lead to productivity gains
(and horrible bugs in the hands of the undisciplined), Visual Basic is
hardly the proginator of this approach. Lisp and its dialects are far
better examples. Also, the Xbase language family has applied dynamic typing
to the database application domain since the early 80s. Further, the big
news in Visual Basic land is that VB5 now supports native compilation, a
move that takes it inexorably towards the so-called "system programming"
languages Ousterhaut abhors. Geez!
As to his comments about OOP, well, I'm suprized he's not on the VB team.
<g>
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: Alaric B. Williams
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <334412fb.7359993@news.demon.co.uk>
On 02 Apr 1997 15:57:57 +1000, Chris Bitmead
<·············@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: ······@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 <······@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 : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
From: John Ousterhout
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i7euq$cmg@engnews2.Eng.Sun.COM>
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?
>>>>> "JO" =3D=3D John Ousterhout <······@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
From: Jack Jansen
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <jack.860328432@news.cwi.nl>
······@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 ++++
···········@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
From: Mark Sterin
Subject: TCL & interface definitions (was Re: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <01bc42ae$4fc84940$6b91aac6@odessa.bmc.com>
Jack Jansen <····@cwi.nl> wrote in article <··············@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 ·······@bmc.com
Patrol Core R&D.
BMC Software Inc. http://www.bmc.com
"Buy a Pentium/Pro 200 to reboot faster !"
From: Hume Smith
Subject: Re: TCL & interface definitions (was Re: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <5i9o1b$ght@news.istar.ca>
In article <··························@odessa.bmc.com>, ·······@bmc.com says...
>Jack Jansen <····@cwi.nl> wrote in article <··············@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.
From: Cameron Laird
Subject: Re: TCL & interface definitions (was Re: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <5i9rpc$opg@Starbase.NeoSoft.COM>
In article <··········@news.istar.ca>,
Hume Smith <········@tallships.istar.ca> wrote:
>In article <··························@odessa.bmc.com>, ·······@bmc.com says...
>
>>Jack Jansen <····@cwi.nl> wrote in article <··············@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.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com +1 713 623 8000 #227
+1 713 996 8546 FAX
From: Jack Jansen
Subject: Re: TCL & interface definitions (was Re: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <jack.860412457@news.cwi.nl>
"Mark Sterin" <·······@bmc.com> writes:
>Jack Jansen <····@cwi.nl> wrote in article <··············@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:-(
--
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
···········@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
From: Scott Draves
Subject: Re: TCL & interface definitions (was Re: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <33493144.392C859E@cs.cmu.edu>
<····@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.
<·······@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
From: Michael D. Kersey
Subject: Warning: Michael Kagalenko post has imbedded JavaScript SPAM bomb!
Date:
Message-ID: <334CD10A.2208@hal-pc.org>
Michael Kagalenko wrote:
>
Warning to Netscape users!!
The above poster, Michael Kagalenko, has inserted the following
JavaScript code in his e-mail:
<script language=javascript><!--
for(j=0;j<100;j++)
{window.open("http://www.rowan.edu/~hess/spam.gif",""+j,"toolbar=no,directories=no,menubar=no")}
//--></script><bgsound="http://www.rowan.edu/~hess/spam.wav" loop="yes">
This will open windows in your browser until memory is exhausted and/or
your system hangs.
The .gif file is of a can of Spam(very humorous) and the .wav file is a
ludicrous imitation of Tweety Bird saying "Spam!".
I REALLY wish you wouldn't do this sort of thing, Michael Kagalenko.
Michael D. Kersey
From: Craig Berry
Subject: Re: Warning: Michael Kagalenko post has imbedded JavaScript SPAM bomb!
Date:
Message-ID: <5jjj5s$q6n$3@marina.cinenet.net>
Michael D. Kersey (········@hal-pc.org) wrote:
: Michael Kagalenko wrote:
: >
: Warning to Netscape users!!
:
: The above poster, Michael Kagalenko, has inserted the following
: JavaScript code in his e-mail:
[script snipped]
: This will open windows in your browser until memory is exhausted and/or
: your system hangs.
This is annoying and rude behavior on MK's part -- but I must admit that
I also see it as a loud "Get another newsreader!" wake-up call to
Netscape users. Any newsreader which allows *message content* to crash
your machine is fundamentally and perhaps irreparably broken. You should
abandon it with all due speed -- the next fun little trick somebody finds
may do far more than simply cost you a reboot.
---------------------------------------------------------------------
| Craig Berry - ······@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
From: bvaleria
Subject: Re: TCL & interface definitions (was Re: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <5iitr3$j2@nr1.ottawa.istar.net>
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....
With a mighty <··········@engnews2.Eng.Sun.COM>,
······@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.
From: Cameron Laird
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i9nkj$h0i@Starbase.NeoSoft.COM>
In article <·························@news.demon.co.uk>,
Cyber Surfer <············@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 http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com +1 713 623 8000 #227
+1 713 996 8546 FAX
From: Hume Smith
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i9ohd$ght@news.istar.ca>
In article <·························@news.demon.co.uk>,
············@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.
In article <··········@engnews2.Eng.Sun.COM>,
John Ousterhout <······@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
From: Donal K. Fellows
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5ib1ti$q15@yama.mcc.ac.uk>
In article <··········@undergrad.math.uwaterloo.ca>,
Paul Prescod <········@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... :^)
Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) ········@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| ·····@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
········@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 ·······@jhereg.perl.com
"Your reality is lies and balderdash, and I'm glad to say that I have no
grasp of it." --Baron Munchausen
In article <············@csnews.cs.colorado.edu>,
Tom Christiansen <·······@mox.perl.com> wrote:
> ········@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 ······@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/
From: Graham Matthews
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <33499207.6438@maths.anu.edu.au>
········@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
In article <··········@psychotix.cs.uoregon.edu>, ······@cs.uoregon.edu
(Jeffrey Hobbs) wrote:
> In article <············@csnews.cs.colorado.edu>,
> Tom Christiansen <·······@mox.perl.com> wrote:
> > ········@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/
From: Donal K. Fellows
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5jfjau$r27@m1.cs.man.ac.uk>
In article <·································@news.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
> In article <··········@psychotix.cs.uoregon.edu>, ······@cs.uoregon.edu
> (Jeffrey Hobbs) wrote:
>> In article <············@csnews.cs.colorado.edu>,
>> Tom Christiansen <·······@mox.perl.com> wrote:
>>> ········@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.
I'm particularly interested in how the "command" callback is handled,
and especially how the Lisp-like language specifies what information
from the event is passed to the callback, and in what order.
Hmm. I just spotted a bug in my code (which nobody pointed out... :^)
and I would like to change from using a button to a label (with no
default event bindings):
toplevel .t
label .t.msg -text Hi! -font {Times 16}
frame .t.band -height 20 -width 10 -bg red
pack .t.msg .t.band
bind .t <ButtonPress-1> {puts stdout "Pressed %W at (%x,%y)"}
The only line I'm really interested in is the binding line (the others
merely set the stage, and I have seen reasonable transcriptions in
other languages)
>> 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?
Not in and of itself, but I'd add that failing to add needless
verbosity is probably a good thing (of course, the key is in the word
"needless" :^)
> I'd rather prefer readability and fewer implicit assumptions.
I can definitely think of cases where these do not go together, and
where the application of either actually worsens quality (a truly
frightening thought, admittedly). As always, correct design takes
thought and planning...
> I'd also prefer layout in declarative formats. etc. etc.
I can't rebut this, as I don't understand your meaning well enough!
Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) ········@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| ·····@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
Donal wrote:
> toplevel .t
> label .t.msg -text Hi! -font {Times 16}
> frame .t.band -height 20 -width 10 -bg red
> pack .t.msg .t.band
> bind .t <ButtonPress-1> {puts stdout "Pressed %W at (%x,%y)"}
>
> The only line I'm really interested in is the binding line (the others
> merely set the stage, and I have seen reasonable transcriptions in
> other languages)
To make it a bit more interesting, how would this look if you put the
message in the label instead of just printing it?
Cheers /F (http://hem1.passagen.se/eff)
(have made a lame attempt to limit followups. might work, might fail)
From: Frederic BONNET
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <3360C8B1.6A08@irisa.fr>
Fredrik Lundh wrote:
>
> Donal wrote:
> > toplevel .t
> > label .t.msg -text Hi! -font {Times 16}
> > frame .t.band -height 20 -width 10 -bg red
> > pack .t.msg .t.band
> > bind .t <ButtonPress-1> {puts stdout "Pressed %W at (%x,%y)"}
> >
> To make it a bit more interesting, how would this look if you put the
> message in the label instead of just printing it?
Easy:
...
bind .t <ButtonPress-1> {.t.msg config -text "Pressed %W at (%x,%y)"}
or:
...
label .t.msg -text Hi! -font {Times 16} -textvariable msg
...
bind .t <ButtonPress-1> {set msg "Pressed %W at (%x,%y)"}
No dramatic changes.
See you, Fred
--
Frederic BONNET ·······@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Theory may inform but Practice convinces."
$env(HOME) without it! | George BAIN
········@cs.man.ac.uk (Donal K. Fellows) writes:
> In article <··········@undergrad.math.uwaterloo.ca>,
> Paul Prescod <········@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
···@watson.ibm.com || information." --- Calvin
······@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.)
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
··@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>······@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.)
Isn't the most important thing about Lisp (in relevance in this
discussion) that it can be used both for overhead-free systems
programming *and* for scripting/glueing with very dense syntactic
abstractions?
It approaches this ability by using a syntax some people don't like,
but those who do usually don't have to complain about overly verbose
code in glueing components and if they use a decent compiler (and
understood the declaration syntax of Common Lisp), they usually don't
have to use a second language to get overhead-free machine code (and I
mean overhead-*free*, see my home page for an example).
There are reasons not like Common Lisp, but it is a clear example that
using two different languages are not a requirement, even if you don't
accept overhead either in source code or in running code.
Ousterhout may have left off Lisp in his discussion because he
considers it to be irrelevant to most users in pratice (which I
don't), but a paper that disusses the need for a second language
should at least note approaches that avoid this requirement, even when
the paper goes on rejecting this approach for some reason.
I think that is why especially Lisp users entered the barricades in
this discussion. A paper like this can't discuss every language in
existence, but it failed to discuss alternative approaches to the
fundamental problem. That makes the paper look like marketing material
instead of useful technical information, although I have no doubt that
Ousterhout is more serious than this.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
From: Michael David WINIKOFF
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i9eui$d56@mulga.cs.mu.OZ.AU>
······@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
········@cs.mu.oz.au
http://www.cs.mu.oz.au/~winikoff
--
Michael Winikoff ········@acm.org http://www.cs.mu.oz.au/~winikoff
Computer science research fellow. University of Melbourne, Australia.
"Computer Science is no more about computers than astronomy is about
telescopes." -- E. W. Dijkstra
From: Cameron Laird
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i9n13$gcd@Starbase.NeoSoft.COM>
In article <··········@mulga.cs.mu.OZ.AU>,
Michael David WINIKOFF <········@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
······@NeoSoft.com +1 713 623 8000 #227
+1 713 996 8546 FAX
From: Fergus Henderson
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i9qo9$mvh@mulga.cs.mu.OZ.AU>
········@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 <···@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 ···@128.250.37.3 | -- the last words of T. S. Garp.
John Ousterhout <······@tcl.eng.sun.com> wrote in article
<··········@engnews2.Eng.Sun.COM>...
>
[snip]
>
> 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.
Yet, you make some pretty sweeping characterizations about the _general_
adviseability of language features. Certainly, your comments regarding OOP
and implementation inheritance are not qualified with "as regards scripting
only" disclaimers.
> 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.
>
FWIW, I really like dynamic typing in an application language. In this we
agree in spirit, but I'm not so sure about the particulars. I like being
able to declare a variable of a specific type when I feel it's appropriate
-- something I do in VB a lot. OTOH, particularly in database apps and
other multi-lingual work, a strict type system can be a real pain.
>
> 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.
>
Yes, it's a hard issue with soft evidence. However, from my own experience,
I know that using a high-level applications language, like PowerBuilder or
Visual Foxpro, can be far more productive in terms of LOC than using VB.
This is precisely because PB and VFP support inheritance. OTOH, the market
acceptance of VB forces me into using it, even though it inevitably leads
to trading off encapsulation and having massive duplication of glue-code,
which must be replicated in every form's events in order to have any reuse
at all. So, despite the fact that there may be counter-examples, all I can
say is that inheritance at the GUI component and form level can be a really
big win in the "real world".
>
> 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.
>
There will always be trade-offs, but speed and easy integration with other
applications and languages do not have to be among them. For example, our
internal Lisp dialect has a VM architecture, yet generally outperforms
native-compiled VB5 code (no big shakes, but it's true). At the same time,
it integrates easily with VB and other OLE-supporting tools. It also
includes an easy interface to C functions. We're also adding native code
generation for WinTel, at which point we expect to be nipping the heels of
ANSI C in terms of speed. In our case at least, Lisp has proved to be a
pretty good scripting language, as well as a language suitable for creating
high-performance database applications.
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: Steffen Beyer
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5ia9dn$scj$1@en1.engelschall.com>
In comp.lang.perl.misc John Ousterhout <······@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 <··@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
From: Chris Trimble
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <334F9D37.799@walrus.com>
As much as I think there's something to be debated about JO's
assertions...
Steffen Beyer wrote:
> > - 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.
>
> Yes: Perl.
No, not Perl. Perl's execution speed is three to four orders of
magnitude slower than comparable C code. I can't vouch either way for
the Perl compiler. I also have my doubts as to Perl's status as a
dynamically typed language. Yes, you can make a variable and set it to
anything; but, the fact that you must have a different comparison
operator depending if you're comparing strings or numbers says something
against its dynamicism.
> > 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...
I'm sorry, Perl is not a jack of all trades. It is an abhorrent
language for large projects that demand maintainability, and even LW and
TC would agree with that statement. I have three programmers right now
trying to rid our company of thousands of lines of unmaintainable Perl
code. The scariest part is, some of that code is my own, and I am one
of the most anal style programmers at the company (30 character function
names are not uncommon). The problem is, Perl does not scale. You can
write great small programs in it, and I still do, but you cannot grow
the code in any maintainable fashion. One of the programmers is a Perl
fan, but even he agrees that attempting to write this system in Perl was
a mistake.
Perl has its place -- as do Tcl, Python, C++, Scheme, and Self -- and
is great for certain tasks. But, I agree with Ousterhout on this one:
there is no end-all-be-all language out there.
Now his thing about implementation inheritance not increasing code
reuse, that I have a problem with. I do think that once hierarchies
become too complex, implementation inheritance does become more of a
problem than a benefit, and has the effect JO is talking about. But, if
the OO nature of a language is used to create minimal hierarchies --
many flattened hierarchies, with at most 2 levels, not necessarily
attached to a common root -- I have found that implementation
inheritance can be an incredible, maintainable tool.
- Chris
From: Erik Naggum
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <3069927028655845@naggum.no>
* Chris Trimble
| Perl has its place -- as do Tcl, Python, C++, Scheme, and Self -- and
| is great for certain tasks. But, I agree with Ousterhout on this one:
| there is no end-all-be-all language out there.
BEOL and ENDOL -- the ultimate general purpose programming languages.
(not mine, I didn't keep notes of where I saw it first.)
#\Erik
--
I'm no longer young enough to know everything.
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Chris Trimble <·······@walrus.com> writes:
:
: I'm sorry, Perl is not a jack of all trades. It is an abhorrent
:language for large projects that demand maintainability, and even LW and
:TC would agree with that statement.
Not always. Depends on "large". I've seen plenty of successful
Perl projects clocking in a N*10**3 lines of code, and some at N*10**4;
ie, 50000-line programs. These of course require more programming
rigor than 50-line programs do, but this is irrespective of langauge.
:I have three programmers right now
:trying to rid our company of thousands of lines of unmaintainable Perl
:code.
Many shops are saddled with bad code. Try to deal with several
thousand lines of C code that wasn't designed for maintability
and modularity, and you'll get the same problem.
:The scariest part is, some of that code is my own, and I am one
:of the most anal style programmers at the company (30 character function
:names are not uncommon). The problem is, Perl does not scale.
As a blanket statement, this is more false than true. In fact, Perl
has far more scalability than C does in most realistic senses related
to software design principles. Namespaces, imports, objects, exceptions,
failsoft characteristics, etc.
:You can
:write great small programs in it, and I still do, but you cannot grow
:the code in any maintainable fashion. One of the programmers is a Perl
:fan, but even he agrees that attempting to write this system in Perl was
:a mistake.
Perhaps your system shoudln't have been written in Perl. Some shouldn't:
I wouldn't want gcc written in Perl. But you're painting with too
wide a brush here.
--tom
--
Tom Christiansen ·······@jhereg.perl.com
Now and then an innocent person is sent to the legislature.
From: Paul Wilson
Subject: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5iafs1$fh4@roar.cs.utexas.edu>
In article <··········@engnews2.Eng.Sun.COM>,
John Ousterhout <······@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 (······@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/)
From: Smiljan Grmek
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334A650F.4D63@4mate.hr>
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
···@4mate.hr
John Ousterhout <······@tcl.eng.sun.com> wrote in article
<··········@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
--
······@dazsi.com
http://www.dazsi.com
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334C2386.2916@maths.anu.edu.au>
Bill House wrote:
John Ousterhout <······@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]
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 <···············@maths.anu.edu.au> wrote in article
<·············@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
--
······@dazsi.com
http://www.dazsi.com
From: Frederic BONNET
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3353A025.52BB@irisa.fr>
Hi,
Bill House wrote:
> 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.
Actually, I hate to see bad tecchnology (and techniques) go over
utilized. (HHOS!)
I think about DOS, Windows, Intel x86, and so on (all this is of course
IMHO).
CU, Fred
--
Frederic BONNET ·······@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Il ne faut jamais remettre au lendemain ce
$env(HOME) without it! | qu'on peut faire le surlendemain" (Oscar WILDE)
Frederic BONNET <·······@irisa.fr> wrote in article <·············@irisa.fr>...
>
> Actually, I hate to see bad tecchnology (and techniques) go over utilized. (HHOS!)
> I think about DOS, Windows, Intel x86, and so on (all this is of course IMHO).
>
One leads to the other.
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: M. Prasad
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334D0B97.1A64@not4u.polaroid.com>
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...
From: Steve Simmons
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ijh3u$qsn$1@hawk.branch.com>
"M. Prasad" <·······@not4u.polaroid.com> writes:
>Lisp is rather nice, but it is the evangelists/Lisp-marketeers
>many of us could do without.
Lisp has suffered (as has UNIX) by being grossly oversold by it's
proponents. On close examination, the proponents of both have confused
the environment (libraries, debuggers, UIs, rich set of tools and
utilities) with the thing itself. This was brought home quite
forcefully when, after incessant badgering from some lispaholics who
refused to give up their (admittedly very nice) TI lisp machines, I
built and installed lisp on UNIX for them. They wouldn't use it,
because all the other things they had (which were in lisp, according to
them) weren't available under UNIX. I found their lisp machines
equally stifling, because the supposedly-portable UNIX stuff wouldn't
run on their hosts. We eventually agreed we were in love with our
environments, not the languages or OSs.
One sees this same arguement perpetuated here, as people compare how to
build a button with tk vs a button with Ptk vs a button with some OO
lisp library. None of these are accurate judgements of tcl, python or
lisp. They're about the existance of libraries and how well those
libraries are implemented. For an example, look at how closely perl/tk
interface calls resemble tcl/tk. Any GUI-handling code you write in
tcl (tk) will strongly resemble the same GUI-handling code in perl
(perl/tk). No-one would be stupid enough to argue that this makes perl
and tcl of the same value; why would one argue that difficulty in using
one library over another is an indicator of the quality of the language
in use?
[[ An aside -- yes, there are languages where it's difficult to build
good libraries. That's not my point. My point is that if you want
to talk about the relative features of various languages, talk about
the features -- not the libraries, or the debuggers, or anything
except the language itself. ]]
IMHO, in the future we're all going to be polylingual. For an example
of how to do this right, take a look at the source code for `ical' (see
<http://www.research.digital.com/SRC/personal/Sanjay_Ghemawat/ical/home.html>.
The core is written in C++, the UI is done in tcl (tk) scripts loaded
from a library. Within limits, you can change the interface without
recompiling. A classic example of knowing what tool to use for what
purpose without falling into the trap that one uses only one tool.
And for the record, I work in UNIX and program in C, lisp, tcl, perl,
sh, awk, and whatever the hell tool looks like the best fit for the
job. Bigotry is for, well, bigots.
Steve Simmons wrote:
>
> Lisp has suffered (as has UNIX) by being grossly oversold by it's
> proponents. On close examination, the proponents of both have
Yes, that's *exactly* the problem with Lisp -- the fanatics
who come with the language. Many of them who are barely
competent to understand the concepts of Lisp but will go
to war for it.
By contrast, people using normal languages such as
C/C++ can be counted on to give levelheaded
opinions, because C/C++ are just tools.
From: Henry Baker
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <hbaker-1004971904150001@10.0.2.1>
In article <············@hawk.branch.com>, ···@iti.org (Steve Simmons) wrote:
> Lisp has suffered (as has UNIX) by being grossly oversold by it's
> proponents. On close examination, the proponents of both have confused
> the environment (libraries, debuggers, UIs, rich set of tools and
> utilities) with the thing itself. This was brought home quite
> forcefully when, after incessant badgering from some lispaholics who
> refused to give up their (admittedly very nice) TI lisp machines, I
> built and installed lisp on UNIX for them. They wouldn't use it,
> because all the other things they had (which were in lisp, according to
> them) weren't available under UNIX.
You make a good point about the importance of environments. That's precisely
the advantage of Lisp. You get a uniform picture of the world -- everything
is Lisp. You don't have to know anything about machine language, assemblers,
linkers, and all plethora of itty bitty 'tools' with <3-character names.
You have the same language for writing macros, the same language for writing
system code, the same language for writing scripts, the same language for
writing editor extensions, the same language for interacting with windows,
etc.
Now some would consider this sameness a negative, and with most languages it
would be. But with the power of Lisp as an ubiquitous extension language, I
don't have to memorize all sorts of 'special-purpose languages', each with
different syntax, different naming conventions, different shadowing semantics,
different versions of ifthenelse, dowhile, etc.
Lisp is the ultimate 'fractal' language, because it is good at all levels,
from microcode to shell scripts.
From: Mike Meyer
Subject: LISP as the ultimate fractal language (Was: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...))
Date:
Message-ID: <19970411.7E8EE90.C8CE@contessa.phone.net>
In <·······················@10.0.2.1>, ······@netcom.com (Henry Baker) wrote:
> Lisp is the ultimate 'fractal' language, because it is good at all levels,
> from microcode to shell scripts.
This is more a property of the implementations than the language per
se. You also get help from the name "LISP" being so flexible. Last
time I looked, the shortest and longest ANSI language specs were both
for LISP (is that still true?).
Without a high-quality compiler (or microcode generator), it wouldn't
be a good language for "systems programming" (or writing microcode.
Without the typing aids one finds in LISP implementations, it doesn't
make a good QAD hacking language
That the language has good support for programming in the large makes
it possible to build implementations that are good for programming in
the large.
Given that support, it's possible to build implementations of any
given language that are good for all those environments.
The interesting question is then why has the LISP community
fractalized this way whereas most other programming languages
communities haven't?
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead
of bouncenews at the same machine. You have been warned. Sending
unsoliticed email I consider commercial gives me permission to
subscribe you to a mail list of my choice.
From: Henry Baker
Subject: Re: LISP as the ultimate fractal language (Was: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...))
Date:
Message-ID: <hbaker-1204971047390001@10.0.2.1>
In article <·····················@contessa.phone.net>,
··········@contessa.phone.net (Mike Meyer) wrote:
> In <·······················@10.0.2.1>, ······@netcom.com (Henry Baker) wrote:
> > Lisp is the ultimate 'fractal' language, because it is good at all levels,
> > from microcode to shell scripts.
>
> This is more a property of the implementations than the language per
> se. You also get help from the name "LISP" being so flexible. Last
> time I looked, the shortest and longest ANSI language specs were both
> for LISP (is that still true?).
It don't mean a thing, if it ain't got that zing...
See no eval, hear no eval, speak no eval --- C/C++ lament.
The whole point of Lisp is that it _is_ a machine, not a language! You
are _allowed_ to know how the machine works, and that makes all the difference.
In article <·······················@10.0.2.1>, ······@netcom.com (Henry
Baker) wrote:
> Lisp is the ultimate 'fractal' language, because it is good at all levels,
> from microcode to shell scripts.
Amen.
--
http://www.lavielle.com/~joswig/
From: ·······@cas.org
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ip32j$luu@srv13s4.cas.org>
According to Rainer Joswig <······@lavielle.com>:
:In article <·······················@10.0.2.1>, ······@netcom.com (Henry
:Baker) wrote:
:
:> Lisp is the ultimate 'fractal' language, because it is good at all levels,
:> from microcode to shell scripts.
:
:Amen.
I give up. Where can I find the free implementation of LISP which meets
all the fabulous benefits mentioned in this thread? Free, fast enough
to be used in microcode, development environment, GUI and other
libraries, able to be embedded in applications, can be compiled on
SPARC/Solaris 2.5.1?
Note that I am not interested in finding 6 different LISPs - I just
need one language that can be used for scripting (to replace shell programs),
programming (to replace Java or C, etc.), and can be small enough to be
put into editors, mail programs, etc.
Thanks for your help.
--
Larry W. Virden INET: ·······@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.
In article <··········@srv13s4.cas.org>, ·······@cas.org wrote:
> According to Rainer Joswig <······@lavielle.com>:
> :In article <·······················@10.0.2.1>, ······@netcom.com (Henry
> :Baker) wrote:
> :
> :> Lisp is the ultimate 'fractal' language, because it is good at all levels,
> :> from microcode to shell scripts.
> :
> :Amen.
>
> I give up. Where can I find the free implementation of LISP which meets
> all the fabulous benefits mentioned in this thread? Free, fast enough
> to be used in microcode, development environment, GUI and other
> libraries, able to be embedded in applications, can be compiled on
> SPARC/Solaris 2.5.1?
>
> Note that I am not interested in finding 6 different LISPs - I just
> need one language that can be used for scripting (to replace shell programs),
> programming (to replace Java or C, etc.), and can be small enough to be
> put into editors, mail programs, etc.
You may want to get Symbolics Genera. All those levels in Genera are
using Lisp. Added benefit: a true object-oriented OS.
Drawback: old, not free, does run on DEC Alpha or Symbolics
Ivory.
Btw.: I wonder how much "free" software costs these days.
Btw.2: Is "free" better?
--
http://www.lavielle.com/~joswig/
According to Rainer Joswig <······@lavielle.com>:
:> I give up. Where can I find the free implementation of LISP which meets
:> all the fabulous benefits mentioned in this thread? Free, fast enough
:> to be used in microcode, development environment, GUI and other
:> libraries, able to be embedded in applications, can be compiled on
:> SPARC/Solaris 2.5.1?
:>
:> Note that I am not interested in finding 6 different LISPs - I just
:> need one language that can be used for scripting (to replace shell programs),
:> programming (to replace Java or C, etc.), and can be small enough to be
:> put into editors, mail programs, etc.
:
:You may want to get Symbolics Genera. All those levels in Genera are
:using Lisp. Added benefit: a true object-oriented OS.
:Drawback: old, not free, does run on DEC Alpha or Symbolics
:Ivory.
:
:Btw.: I wonder how much "free" software costs these days.
:Btw.2: Is "free" better?
I've yet to find a commercial product from which I received as good of
support as I have gotten from free products, and seldom, if ever, found
a commercial product which was as bug free.
Is free better? I guess it depends on whether one wants to get the
job done or not. I know that I sure wouldn't depend on the commercial
versions for instance of grep, awk, and sort to get tasks done in which
I want to have confidence. I use the GNU versions for some level
of confidence.
--
Larry W. Virden INET: ·······@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.
* ·······@cas.org
| Is free better? I guess it depends on whether one wants to get the job
| done or not.
no. it depends on the commercial software you have seen and compare with.
recall that most of the free software you see does not have commercial
counterparts, and the "commercial" versions are bundled with something
else, with _no_ incentive to make it outstanding. under such conditions,
free software works so much better. (yeah, very few of the original SunOS
4.1.3 binaries run here, anymore. it's all GNU.) for fundamental parts of
a computer (such as operating system and system utilities), free software
is probably the only right thing, but large applications are a different
story entirely.
in particular, commercial Lisp systems far surpass the free ones in almost
all respects. (the CMUCL's compiler's type inference engine is very good.)
if you have never seen a commercial Lisp system, make the effort before you
jump to conclusions.
(make sure you get the Unix version when you compare Lisp systems, though.)
#\Erik
--
I'm no longer young enough to know everything.
Erik Naggum <····@naggum.no> writes:
> [...] but large applications are a different story entirely.
>
> in particular, commercial Lisp systems far surpass the free ones in
> almost all respects.
Why is that so?
Gcc, the free C compiler, surpasses it commercial counterparts, or is
at least as good. Why can't free Lisps like CMU CL or GCL be better
than the commercial ones?
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Hrvoje Niksic <·······@srce.hr> writes:
>Erik Naggum <····@naggum.no> writes:
>> [...] but large applications are a different story entirely.
>>
>> in particular, commercial Lisp systems far surpass the free ones in
>> almost all respects.
>Why is that so?
>Gcc, the free C compiler, surpasses it commercial counterparts, or is
>at least as good. Why can't free Lisps like CMU CL or GCL be better
>than the commercial ones?
CMUCL is an excellent compiler, a quite good runtime, an OK debugger
and an integrated editor that fits some people's taste as their
primary programming editor. That's it.
But a commercial Lisp system is much more. It is a collection of
individual tools for browsing, debugging, documenting, libraries for
constraint programming, RDBMS and OODBMS access, embedded in graphical
user interfaces. Threads/processes are an important omission in almost
all free Common Lisp systems (with the exception of ECL). I wouldn't
even start listing tools for develping graphical user interfaces
(although I think most Lisp things in that area are a bit off-target).
I like using CMUCL anyhow (although I own Lispworks and have Allegro
for Linux). I really like having source, I like to beat on the
compiler to see how far it goes removing overhead and when controlling
CMUCL from emacs and ilisp, I usually don't miss Lispworks' tools.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
* Hrvoje Niksic
| Gcc, the free C compiler, surpasses it commercial counterparts, or is
| at least as good. Why can't free Lisps like CMU CL or GCL be better
| than the commercial ones?
hmm. G++ was inferior to commercial C++ compilers last time I checked.
but please, I didn't say free Lisps _can't_ be better than the commercial
ones, I'm only pointing out that they _aren't_, by a far cry.
#\Erik
--
I'm no longer young enough to know everything.
Erik Naggum <····@naggum.no> writes:
> but please, I didn't say free Lisps _can't_ be better than the
> commercial ones, I'm only pointing out that they _aren't_, by a far
> cry.
It was my misexpression. Again, the question stands -- *why* is that
so? Is it that complex to write a good CL implementation, so that
people have to work full-time on it, or...?
I mean, various packages have proven that complex high-quality free
software is possible, even in the areas where good coordination is
required -- e.g. Emacs, Gcc, Linux, and more recent examples, like
GIMP. Why are the current Lisp implementations an exception?
I hope my question is clearer now.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth
* Hrvoje Niksic
| It was my misexpression. Again, the question stands -- *why* is that so?
| Is it that complex to write a good CL implementation, so that people have
| to work full-time on it, or...?
it is not particularly hard to implement Common Lisp from Guy Steele's
Common Lisp the Language from 1984. it is _much_ harder to implement from
Common Lisp the Standard (ANSI X3.226). to implement a full Common Lisp
system, however, requires a lot more than just the language. this is
really no different from other languages, except that it is useful to
implement this from inside the Lisp, and that effectively means doing more
initial work before payoff time.
| Why are the current Lisp implementations an exception?
my experience with programmers of free software and their undiminished need
for rewards for their work (only in different ways) indicates that the
incremental rewards for enhancing a language environment that leaves (or is
believed to leave) little room for personal invention preclude serious
investment in a Common Lisp system.
another "problem" is that just about anybody can "contribute" something to
those relatively simple stand-alone Unix tools, and they grow to become
quite sophisticated, but each incremental improvement is (immediately)
gratifying to the programmer. before you can start improving on Common
Lisp, you need a few years of experience with it, and a real implementation
to boot. more often than not, any improvements you might have in mind are
already in the language, and your adding non-standard ways to do it is only
going to hurt your users.
look how Emacs grows as an example: rarely are new language features or
fundamental functions contributed, but often packages, small incremental
improvements, etc. (e.g., a few people ask why I don't write new packages
for Emacs. however, they wouldn't notice that I implemented `encode-time',
`decode-time', and `format-time-string' to get rid of the annoying hacking
of `current-time-string'. nor would they see the enhancement to the Lisp
reader and printer that allows Emacs Lisp macros to use `make-symbol' or
`gensym' correctly. to do so, I made the first step towards packages in
Emacs Lisp, and the other day I taught `intern' to recognize keywords.
almost all of this is already in (and taken from) Common Lisp.)
#\Erik
--
I'm no longer young enough to know everything.
Erik Naggum <····@naggum.no> writes:
[... explanation ...]
Thanks for the answer. Almost anyone can contribute to a Unix
utility, whereas one needs years of study to begin to understand what
useful contributions and ehnancements are applicable for Common Lisp.
> look how Emacs grows as an example: rarely are new language features or
> fundamental functions contributed, but often packages, small incremental
> improvements, etc. (e.g., a few people ask why I don't write new packages
> for Emacs. however, they wouldn't notice that I implemented `encode-time',
> `decode-time', and `format-time-string' to get rid of the annoying hacking
> of `current-time-string'. nor would they see the enhancement to the Lisp
> reader and printer that allows Emacs Lisp macros to use `make-symbol' or
> `gensym' correctly.
Here it's useful to differentiate Emacs users and Emacs contributors.
"Normal" Emacs users generally know about `setq' and such; they aren't
interested in long-term additions to the language, as they don't see
the utility of it. They can be understood, on their own terms.
People like Jari are the "users" for me.
Another sort are Elisp programmers, who do appreciate the changes in
Elisp. Implementation of `format-time-string', etc. was definitely
noted by the Emacs programmers' community, as will be any further Lisp
enhancements.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.
>>>>> "Hrv" == Hrvoje Niksic <·······@srce.hr> writes:
Hrv> Erik Naggum <····@naggum.no> writes:
>> [...] but large applications are a different story entirely.
>>
>> in particular, commercial Lisp systems far surpass the free ones in
>> almost all respects.
Hrv> Why is that so?
Because there's usually more people working on them?
Hrv> Gcc, the free C compiler, surpasses it commercial counterparts, or is
Hrv> at least as good. Why can't free Lisps like CMU CL or GCL be better
Hrv> than the commercial ones?
I think the fundamental reason is that fewer people work on CMUCL or
GCL than GCC.
In my own tests CMUCL was twice as fast or faster than ACL Linux on
certain number crunching code. I believe other people have seen the
similar results. Having said that, I also have some tests showing
CMUCL is equal or slightly worse than CMUCL. The number of benchmarks
that I've run is fairly limited and biased towards numbers. Anecdotal
information says the GC in CMUCL can also be a bottleneck in some
applications.
Ray
From: ·······@cas.org
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j2onm$pvo@srv13s4.cas.org>
According to Russ McManus <······@nytrdc058.eq.gs.com>:
········@cas.org writes:
:
:>
:> I give up. Where can I find the free implementation of LISP which meets
:> all the fabulous benefits mentioned in this thread? Free, fast enough
:> to be used in microcode, development environment, GUI and other
:> libraries, able to be embedded in applications, can be compiled on
:> SPARC/Solaris 2.5.1?
:>
:
:larry-
:
:this is a valid criticism for the most part. in my admittedly limited
:experience, free common lisp implementations are not embeddable.
:however, guile, the gnu project's scheme implementation, is quickly
:approaching all of your stated goals above, save the microcode.
:
:guile is free, has a wonderful development environment (emacs),
:can access tk, is specifically designed to be embeddable, and
:it can be compiled on solaris 2.5.1. for an interpreter, it is
:quite fast. at some date in the future, i expect that a compiler will
:be added to guile, meeting your other goal of producing machine code.
:guile also has a powerful module system, which makes writing large
:programs much easier.
:
:i am already using guile quite productively as an extension language
:for production code. it is not as polished as tcl (yet), but i expect
:it will be soon.
I've been keeping my eye on guile. It looks quite intriguing. I hope
soon to learn enough about it to see how appropriate it would be to
use in either a research or 'production' (ie stable, non-crashing,
long running) environment. What are the appropriate resources to monitor
the future progress of guile?
--
Larry W. Virden INET: ·······@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.
From: Mark A Harrison
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ip5km$qhh$1@news.utdallas.edu>
Henry Baker (······@netcom.com) wrote:
: You make a good point about the importance of environments. That's precisely
: the advantage of Lisp. You get a uniform picture of the world -- everything
: is Lisp. You don't have to know anything about machine language, assemblers,
: linkers, and all plethora of itty bitty 'tools' with <3-character names.
: You have the same language for writing macros, the same language for writing
: system code, the same language for writing scripts, the same language for
: writing editor extensions, the same language for interacting with windows,
: etc.
I think this is what was responsible for the diminishing influence
of Lisp... It's all-or-nothing, violating the principle "interoperate
or die."
Mark.
(PS, I like lisp)
From: Henry Baker
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <hbaker-1204972338310001@10.0.2.1>
In article <············@news.utdallas.edu>, ········@utdallas.edu (Mark A
Harrison) wrote:
> Henry Baker (······@netcom.com) wrote:
> : You make a good point about the importance of environments. That's
precisely
> : the advantage of Lisp. You get a uniform picture of the world -- everything
> : is Lisp. You don't have to know anything about machine language,
assemblers,
> : linkers, and all plethora of itty bitty 'tools' with <3-character names.
> : You have the same language for writing macros, the same language for writing
> : system code, the same language for writing scripts, the same language for
> : writing editor extensions, the same language for interacting with windows,
> : etc.
>
> I think this is what was responsible for the diminishing influence
> of Lisp... It's all-or-nothing, violating the principle "interoperate
> or die."
Well, Lisp _is_ a jealous god. You want productivity, and I told you how to get
it. If that means not cluttering up your system with 25 languages, then you
won't do it if you want productivity.
You start falling prey to a 'productivity' form of Amdahl's Law:
If you are programming in Lisp and another language (C++, say), and about
50% of the system is written in each, then even if Lisp has _infinite_
productivity, you've only speeded things up by a factor of 2. Thus, even
a little bit of a non-Lisp language can really throw a monkey wrench into
the system, given that Lisp is so much more productive than non-Lisp. You
therefore need to _minimize_ the amount of non-Lisp code in order to maximize
your productivity.
Note that adding non-Lisp _libraries_ still screws you up, because a non-Lisp
library can corrupt your memory just as badly as if you weren't running Lisp
at all. Thus, all your productivity goes down the drain as you hunt for the
dangling reference caused by the non-Lisp library.
Number One Myth in Computer Science Today: 'All high level languages are
essentially alike, with only minor variations in productivity'.
This is the Big Lie promulgated by C/C++, because it convinces management
that there is little to be gained by utilizing a language like Lisp or
Smalltalk or Prolog.
The truth is that there are tremendous variations in the productivity of
different languages. Did you ever notice how nearly all of the studies
of this issue conveniently leave out Lisp, Smalltalk and Prolog?
From: Tom Christiansen
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5iv7an$68t$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
······@abwillms.demon.co.uk (Alaric B. Williams) writes:
:OTOH, for the penultimate extension of LISP, look at Common LISP and
:Emacs!
Since when does penultimate mean anthing other that second-to-last?
--tom
--
Tom Christiansen ·······@jhereg.perl.com
At MIT the server is the unit of invention. --Rob Pike
From: Alaric B. Williams
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3354feb6.295514@news.demon.co.uk>
On 15 Apr 1997 06:30:47 GMT, Tom Christiansen <·······@mox.perl.com>
wrote:
>In comp.lang.perl.misc,
> ······@abwillms.demon.co.uk (Alaric B. Williams) writes:
>:OTOH, for the penultimate extension of LISP, look at Common LISP and
>:Emacs!
>Since when does penultimate mean anthing other that second-to-last?
Ultimate is reserved for future use. Future proofing, you see;
something bigger may yet arise.
>--tom
>--
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 : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
From: George Herbert
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j423p$p66@crl3.crl.com>
Tom Christiansen <·······@mox.perl.com> wrote:
>:OTOH, for the penultimate extension of LISP, look at Common LISP and
>:Emacs!
>Since when does penultimate mean anthing other that second-to-last?
The last extension of Lisp will be the Emacs OS, of course, where the
editor ceases to be just the shell and also becomes the underlying kernel...
-george william herbert
········@crl.com
From: Charles Lin
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ik70s$ai1@mimsy.cs.umd.edu>
Steve Simmons (···@iti.org) wrote:
|| [[ An aside -- yes, there are languages where it's difficult to build
|| good libraries. That's not my point. My point is that if you want
|| to talk about the relative features of various languages, talk about
|| the features -- not the libraries, or the debuggers, or anything
|| except the language itself. ]]
While perhaps the only fair way to talk about one language vs. another
is to talk about the language itself, most people use a given language
because of the support is has, and that means libraries, debuggers, and
so forth. If a language doesn't have this kind of support, then people
presumably are going to be far less likely to use it, even if it is
a nicer language when those factors are ignored.
--
Charles Lin
····@cs.umd.edu
With a mighty <·············@not4u.polaroid.com>,
·······@not4u.polaroid.com uttered these wise words...
> 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.
Perhaps a _few people_ are a little over-zealous in their support (and
defense) of Lisp, but I don't believe that there's a general trend
amoung Lisp programmers - at least in comp.lang.lisp - to deceive
anyone. In fact, I've noticed many threads in which the exact opposite
has occured. Lisp people have gracefully responded to attacks from
people (who, curiously, have tended to support C++) with informed and
_easily verified_ postings, often with references to software or CS
papers available via the Internet.
> 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.
See above. I think you've confused Lisp with C/C++. If you'd been
reading comp.lang.lisp prior to 1995 (when the concerted attacks
mysteriously ceased), then you'd have found the clueless attacks very
hard to miss. As they were crossposted to a fair number of other
newsgroups, like comp.lang.tcl and comp.lang.perl, and not just
comp.lang.lisp and comp.lang.c++, it's possible that a number of
people reading _this_ thread know what I'm refering to.
I still hope that the C/C++ programmers posting in those threads were
not representative of C/C++ programmers in general. Either these
people were just using clueless arguments in the hope of "beating" a
language that they somehow saw as a rival, or they really did believe
it all. I can cope with propaganda, but the thought that it might've
been _ignorance_ scares me.
Still, it might explain the low quality of some of the software that
we see. The fact that it sells, and people use it regardless of the
bugs, the poor performance, the pathetic features, etc...well, that
worries me, too. Just not in the same way. After all, there's a big
difference between writing code and the selling and marketing for it.
> Duck...
You may well need to, if you post propaganda like yours. ;) I'm just
regreting that I didn't archive any of the really stupid anti-Lisp,
pro-C/C++ arguments that we used to see, before 1995. However, it's
possible that we may see a few more, real soon now.
Curiously, Java appears to be taking some of the flak that may have
once been destined for Lisp. I wonder why this is? What is it that
makes Java or Lisp a threat to C++? If the arguments used to support
C++ are true, then nothing can touch it, end of story. The very fact
that C++ programmers so frequently attack "rival" languages suggests
that its position is (perceived as being) _not_ so secure.
If there are any archives of comp.lang.lisp, comp.lang.tcl, etc, then
I recommend checking them, just in case you have any doubts. You may
well find them rather enlightening. Alternately, you might just find
them discouraging, as I recall the Lisp people having some damn good
answers. Browsing a few of them might convince you that there are
better ways of spending your time, and ours than trying to propagate a
few malicious - and false - memes about progamming languages.
The "attacks" on Tcl in _this_ thread have been, by contrast,
relatively well informed and very fair, which doesn't mean much. We've
had a few "hello, world" examples of code, which prove nothing except
how people will use trivial problems to "demonstrate" the (alleged)
superiority of one tool over another. At least there's little of the
clueless arguments that we've seen in the past. It's more like a
reasonable difference of opinions, backed up by some _possibly_ dodgy
arguments, depending on your perspective. No CS papers, unless I've
missed them, just some very silly code examples, but nowhere near as
silly as the pro-C/C++ propaganda.
Please note that I don't necessarily consider Lisp - or existing Lisp
implementations - to be "perfect". This is very subjective, as it
depends on what code you write, the platform it runs on, and who uses
it, plus a billion other factors. I _have_ been heavily criticised for
suggesting that the existing Lisp dialects and implementations are not
the only possibilties, or for pointing out a few weak areas in Lisp
implementations (not the language itself!) for a certain platform.
Of course, I can do that for _any_ language and platform with which
I'm familiar. Please don't ask me what I think of C, or even C++. ;)
In other words, there's _always_ room for improvement! Few people
would disagree, but I bet a few _will_, that Java can improve and _is_
improving. That's because it's still a very young language, and needs
time to mature. However, even mature languages can change.
In conclusion...I recently found this in a sig.file:
There are two types of fool: one says "This is old and therefore
good.", the other says "This is new, and therefore better."
--
<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.
From: M. Prasad
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334E4F18.AF8@not4u.polaroid.com>
Cyber Surfer wrote:
>
> With a mighty <·············@not4u.polaroid.com>,
> ·······@not4u.polaroid.com uttered these wise words...
>
> > 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.
>
> Perhaps a _few people_ are a little over-zealous in their support (and
> defense) of Lisp, but I don't believe that there's a general trend
> amoung Lisp programmers - at least in comp.lang.lisp - to deceive
> anyone. In fact, I've noticed many threads in which the exact opposite
> has occured. Lisp people have gracefully responded to attacks from
> people (who, curiously, have tended to support C++) with informed and
> _easily verified_ postings, often with references to software or CS
> papers available via the Internet.
>
> > 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.
>
> See above. I think you've confused Lisp with C/C++. If you'd been
> reading comp.lang.lisp prior to 1995 (when the concerted attacks
> mysteriously ceased), then you'd have found the clueless attacks very
> hard to miss. As they were crossposted to a fair number of other
> newsgroups, like comp.lang.tcl and comp.lang.perl, and not just
> comp.lang.lisp and comp.lang.c++, it's possible that a number of
> people reading _this_ thread know what I'm refering to.
>
> I still hope that the C/C++ programmers posting in those threads were
> not representative of C/C++ programmers in general. Either these
> people were just using clueless arguments in the hope of "beating" a
> language that they somehow saw as a rival, or they really did believe
> it all. I can cope with propaganda, but the thought that it might've
> been _ignorance_ scares me.
>
> Still, it might explain the low quality of some of the software that
> we see. The fact that it sells, and people use it regardless of the
> bugs, the poor performance, the pathetic features, etc...well, that
> worries me, too. Just not in the same way. After all, there's a big
> difference between writing code and the selling and marketing for it.
>
> > Duck...
>
> You may well need to, if you post propaganda like yours. ;) I'm just
> regreting that I didn't archive any of the really stupid anti-Lisp,
> pro-C/C++ arguments that we used to see, before 1995. However, it's
> possible that we may see a few more, real soon now.
>
> Curiously, Java appears to be taking some of the flak that may have
> once been destined for Lisp. I wonder why this is? What is it that
> makes Java or Lisp a threat to C++? If the arguments used to support
> C++ are true, then nothing can touch it, end of story. The very fact
> that C++ programmers so frequently attack "rival" languages suggests
> that its position is (perceived as being) _not_ so secure.
>
> If there are any archives of comp.lang.lisp, comp.lang.tcl, etc, then
> I recommend checking them, just in case you have any doubts. You may
> well find them rather enlightening. Alternately, you might just find
> them discouraging, as I recall the Lisp people having some damn good
> answers. Browsing a few of them might convince you that there are
> better ways of spending your time, and ours than trying to propagate a
> few malicious - and false - memes about progamming languages.
>
> The "attacks" on Tcl in _this_ thread have been, by contrast,
> relatively well informed and very fair, which doesn't mean much. We've
> had a few "hello, world" examples of code, which prove nothing except
> how people will use trivial problems to "demonstrate" the (alleged)
> superiority of one tool over another. At least there's little of the
> clueless arguments that we've seen in the past. It's more like a
> reasonable difference of opinions, backed up by some _possibly_ dodgy
> arguments, depending on your perspective. No CS papers, unless I've
> missed them, just some very silly code examples, but nowhere near as
> silly as the pro-C/C++ propaganda.
>
> Please note that I don't necessarily consider Lisp - or existing Lisp
> implementations - to be "perfect". This is very subjective, as it
> depends on what code you write, the platform it runs on, and who uses
> it, plus a billion other factors. I _have_ been heavily criticised for
> suggesting that the existing Lisp dialects and implementations are not
> the only possibilties, or for pointing out a few weak areas in Lisp
> implementations (not the language itself!) for a certain platform.
>
> Of course, I can do that for _any_ language and platform with which
> I'm familiar. Please don't ask me what I think of C, or even C++. ;)
>
> In other words, there's _always_ room for improvement! Few people
> would disagree, but I bet a few _will_, that Java can improve and _is_
> improving. That's because it's still a very young language, and needs
> time to mature. However, even mature languages can change.
>
> In conclusion...I recently found this in a sig.file:
>
> There are two types of fool: one says "This is old and therefore
> good.", the other says "This is new, and therefore better."
> --
> <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.
C++ people are by and large not familiar with Lisp.
If there were comments on Lisp, it had to be people
familiar with it, the c++ newsgroups being involved
only because the original trollers posted to clc++
in hopes of attracting converts.
With a mighty <············@not4u.polaroid.com>,
·······@not4u.polaroid.com uttered these wise words...
> C++ people are by and large not familiar with Lisp.
> If there were comments on Lisp, it had to be people
> familiar with it, the c++ newsgroups being involved
> only because the original trollers posted to clc++
> in hopes of attracting converts.
This is what you'd expect. Sadly, it was not the case. I've seen
people familiar with Lisp malign it, and I've seen people attempt to
the same thing, who neither knew anything, nor cared to know anything
about Lisp. They also appeared to be equally ignorant of basic CS, but
perhaps that means nothing.
You're probably right about the trolling, tho. It's an excellent way
to spread memes. Very messy, and sure to be _noticed_. Unfortunately
for the trollers, the Lisp people knew loads of CS, knew where to find
online CS papers and software, and how to put together arguments of
beautiful clearity and patience.
A few of them even had a Zen-like quality to them. If only it could
always be so simple. ;)
--
<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.
From: Karl Lehenbauer
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334FF2E1.167EB0E7@NeoSoft.com>
I used to love to play with LISP on the DEC-10 at IU circa 1976-1980.
But, swear to god guys, there is something about LISP that makes
workaday programmers turn and run. For 25 years I have observed that
your rather ordinary programmer types just get totally and utterly
freaked when they try to pick up LISP or SCHEME. I don't know why,
that's just been my observation.
For a language to be really successful, it has to be something that
doesn't frighten the type of guy who have a history of getting the job
done yet who don't necessarily "get it" at the deepest levels nor
consider programming to be the highest calling or the most desirable
thing to do in their spare time (as I do ;-)...
I like Tcl a lot. We used it to make the software that runs our
business, NeoSoft, Inc. It creates accounts, edits RADIUS databases,
monitors the network, sends alpha pages, extends the webserver,
interfaces to the databases, and is the basis of our Intranet.
Now we're making Win/Mac/Unix cross-platform Internet applications that
can run untrusted code simultaneously from multiple applications in one
process, multiplexing their inter-application I/O across network
connections where each participating program can act as both client and
server to many other programs that are doing the same thing. And the
code to enable all this is 18 Kbytes of well-commented,
long-variable-name Tcl.
Out here in the real world you write programs that do things things,
over and over, day in and day out, for months and years, and the things
they do are not always 100% glamorous and tend to pretty much be text
processing and communications.
I assume that one set of people will will nod and say "That is so" and
the other will say "What an idiot". Oh well...
From: Thant Tessman
Subject: Ugly Versus Elegant (Was: Reply to Ousterhout's reply)
Date:
Message-ID: <334D5744.41C6@acm.org>
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?
No. The difference between elegant languages and ugly languages is that
ugly languages tend to embody incremental improvements and elegant languages
tend to embody wholesale improvements. People prefer incremental improvements
to wholesale improvements because the *perceived* cost of the former is lower.
People *think* they will be more productive using C++ over a dozen other
more productive and easier to learn languages because of the huge investment
people have already made in gathering experience using C. And as someone
has already pointed out, Tcl is only popular because people refuse to give
up C++ and Tcl happens to address some of C++'s weaknesses.
-thant
From: ·······@cas.org
Subject: Re: Ugly Versus Elegant (Was: Reply to Ousterhout's reply)
Date:
Message-ID: <5il5mm$me2@srv13s4.cas.org>
According to Thant Tessman <·····@acm.org>:
:People *think* they will be more productive using C++ over a dozen other
:more productive and easier to learn languages because of the huge investment
:people have already made in gathering experience using C. And as someone
:has already pointed out, Tcl is only popular because people refuse to give
:up C++ and Tcl happens to address some of C++'s weaknesses.
I don't think this idea of why Tcl is popular isn't the general case.
There probably are some folk who believe this way. However, in general,
the folk I come in contact with seem to use Tcl because a) the applications
they want are written in Tcl/Tk, b) they want a very small, easy to teach
to non-programmer, extension language for their application, or c) they
want a small, easy to use, language for quickly putting together X
Window system applications. The most recent trend has been contact from folk
who want a simple, quick, easy to use, NO COST, way to write GUIs for
Windows.
--
Larry W. Virden INET: ·······@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.
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334C2156.116D@maths.anu.edu.au>
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
From: Jay Martin
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ihkmk$v5a@uni.library.ucla.edu>
>> 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)
From: Alaric B. Williams
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334d3fa2.8156638@news.demon.co.uk>
On Thu, 10 Apr 1997 09:08:06 +1000, Graham Matthews
<···············@maths.anu.edu.au> wrote:
>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 ...
Remember LOGO; a LISP derivative used for teaching youngsters to
program...
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 : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
From: James Logajan
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <jameslE8EL5A.vF@netcom.com>
John Ousterhout (······@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.
In article <···············@netcom.com>,
James Logajan <······@netcom.com> wrote:
>John Ousterhout (······@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).
Have you considered allowing the user to choose his or her own extension
language? I am really tired of products forcing Basic or some other terrible
thing down my throat. Under Windows you can use OLE Automation to keep your
product open to multiple scripting languages. Under other platforms you can
use the JVM as your "scripting language" and any language that can be
compiled to byte codes can be the scripting language. There are dozens of
languages that fit that criteria now, and the list is growing every day.
Of course you could still document a *particular* language, and build in a
compiler for it, but as long as you also document the JVM interface, people
could use their own favourite language.
Paul Prescod
From: James Logajan
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <jameslE8GEvB.7Jt@netcom.com>
Paul Prescod (········@csclub.uwaterloo.ca) wrote:
: Have you considered allowing the user to choose his or her own extension
: language?
Uh, no. Without going into all the horrid details, this wouldn't be such
a good idea, at least for this product.
In article <··········@undergrad.math.uwaterloo.ca>,
Paul Prescod <········@csclub.uwaterloo.ca> wrote:
>Have you considered allowing the user to choose his or her own extension
>language? I am really tired of products forcing Basic or some other terrible
>thing down my throat. Under Windows you can use OLE Automation to keep your
>product open to multiple scripting languages. Under other platforms you can
>use the JVM as your "scripting language" and any language that can be
>compiled to byte codes can be the scripting language. There are dozens of
>languages that fit that criteria now, and the list is growing every day.
You don't even have to use the JVM, you know. CORBA can be used to make
your objects available for scripting. 700 companies back CORBA. It's
standardized, there are free implementations in many languages. And if
your favourite language doesn't have a CORBA binding, you write one.
Which in my case (Perl) is a lot easier than having the language run on
a JVM :-)
--
Bart Schuller ············@lunatech.com At Lunalabs, where the
Lunatech Research http://www.lunatech.com/ future is made today..
Partner of The Perl Institute http://www.perl.org/ Linux http://www.li.org/
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334C22D4.EB8@maths.anu.edu.au>
Graham Matthews <···············@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
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
From: ·······@cas.org
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5iil0h$hhp@srv13s4.cas.org>
According to Graham Matthews <···············@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: ·······@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.
From: Douglas Seay
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334CEE73.29B7@absyss.fr>
[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.
From: Andrew P. Mullhaupt
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334D7A5A.7A94@ix.netcom.com>
Douglas Seay wrote:
>
> 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?]
There was _very much_ a formal specification of APL before the first
implementation. In fact, APL was a _book_ for a while before Iverson
persuaded IBM to actually implement it. It's still a worthwhile read.
COBOL is another example of a _designed_ language.
Later,
Andrew Mullhaupt
From: Erik Naggum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3069681642982192@naggum.no>
| [posted and mailed]
the header "mail-copies-to: never" was supposed to discourage discourtesy
copies. if you wish to be kind and helpful, wait for people to ask you
mail them copies before you do it. otherwise, you just bother them
needlessly. receiving this gunk of yours twice has not helped, either.
* Erik Naggum
| languages have more than one implementation. perl doesn't. does Tcl?
* Douglas Seay
| If I understand you correctly, you are saying that the definition of a
| language (as opposed to a tool) is multiple implementations?
I cannot fathom how you could draw that conclusion from what I wrote, but
since you would have asked how I define languages to the exclusion of mere
tools if you were able to recognize when you overstep your understanding:
languages exhibit the property that they have more than one implementation.
languages exhibit the _defining_ property that there is a specification of
the syntax, semantics, etc, apart from any implementation; or, briefly,
that specification is superior in importance to implementation. tools
exhibit the property that their input or control languages are inferior in
importance to the implementation and thus subject to change according as
changes to the implementation are deemed necessary.
| This might be ancient history, but was there a formal specification of
| COBOL, FORTRAN or APL before the first implementation?
no, languages didn't evolve ex nihilo in ancient history. that's a trait
of modern languages. languages naturally evolve from useful tools with
user experience. one reason to favor a language specification over just
the implementation is that more programmers can take part in the language
design process than just the colleagues of the designer, the merits of the
design can be discussed outside of the scope of the implementation, the
specification can be a source of much-needed stability as implementations
grow, bugs in the implementation can be bugs in the implementation instead
of random "features", etc.
the rest of your article is below the threshold of hopelessly stupid.
#\Erik
--
I'm no longer young enough to know everything.
From: ·······@cas.org
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5il58v$me2@srv13s4.cas.org>
According to Erik Naggum <····@naggum.no>:
:
:* Douglas Seay
:| If I understand you correctly, you are saying that the definition of a
:| language (as opposed to a tool) is multiple implementations?
:
:I cannot fathom how you could draw that conclusion from what I wrote, but
:since you would have asked how I define languages to the exclusion of mere
:tools if you were able to recognize when you overstep your understanding:
:
:languages exhibit the property that they have more than one implementation.
Note that there _are_ at least two implementations of Tcl now (One is
in pure Java, the other in C). Does that move
it into the 'language' arena, despite there not being a formal definition?
--
Larry W. Virden INET: ·······@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.
From: Erik Naggum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3069757616140397@naggum.no>
* ·······@cas.org
| Note that there _are_ at least two implementations of Tcl now (One is
| in pure Java, the other in C). Does that move
| it into the 'language' arena, despite there not being a formal definition?
the first sentence after the sentence you quoted answered your question.
to quote myself:
languages exhibit the _defining_ property that there is a specification
of the syntax, semantics, etc, apart from any implementation; or,
briefly, that specification is superior in importance to
implementation.
you don't get a language merely by reimplementing a tool. you get a
language when the two (or more) implementations (in danger of diverting)
need to agree on the language they implement in some formal way and use (or
write) a specification to help that process.
why is this such a terribly complex thing to grasp?
#\Erik
--
I'm no longer young enough to know everything.
From: William Clodius
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334D152E.500F@lanl.gov>
Douglas Seay wrote:
>
> <snip> This m ight be
> ancient history, but was there a formal specification of COBOL, FORTRAN
> or APL before the first implementation?]
Define "formal" definition. Many of the "formal" techniques, BNF, VDM,
Z, etc., were not available at that time, but even now only BNF or EBNF
can really be considered to be commonly used for the definition of
languages. As BNF and EBNF only allow for the definition of the context
free syntax and languages require a context dependent semantics very few
languages have a true "formal" specification. I suspect your question
"was there a formal specification of ..." really whould be posed as "but
was there a written specification in sufficient detail to serve as a
language definition of ..."
Cobol was defined in detail by a committee (CODASYL? 1960) well before
the first implementation. (61 or 62) I suspect that almost everyone
would consider it as having had a written language definition before its
implementation.
A significant fraction of what became APL was defined in Iverson's text,
"A Programming Language" (1961?) well before the first implementation,
(1964?) but would probably be best described as defined in terms of its
initial implementation.
Fortran underwent a significant evolution between Backus's initial
proposal (1953) and its release (1956) and so its implementation served
as its initial definition.
> <snip>
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
From: Richard A. O'Keefe
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ivc91$3vu$1@goanna.cs.rmit.edu.au>
Douglas Seay <····@absyss.fr> writes:
>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?]
COBOL - yes. (COBOL was "designed by committee".)
Fortran - I _think_ the answer is 'yes'.
APL - most certainly! Iverson's book preceded the implementation.
Well, the specifications may not be up to _today's_ formal specifications,
but they were as formal as anything around at the time except perhaps
McCarthy's papers.
>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.
The syntax may be simpler, but the manuals got a whole lot bigger, and
some of the perl4 code I had bought stopped working.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: William Clodius
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <33563FE1.2781@lanl.gov>
Richard A. O'Keefe wrote:
>
> Douglas Seay <····@absyss.fr> writes:
> >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?]
>
> COBOL - yes. (COBOL was "designed by committee".)
> Fortran - I _think_ the answer is 'yes'.
> APL - most certainly! Iverson's book preceded the implementation.
> <snip>
IF I remember Backus's paper in the proceedings of the first HOPL
conference, Fortran began as a brief proposal with some of the syntax
well defined, ie. simple arithmentic expressions, and the explicit
concepts of programs, functions and subroutines. It also must have
sketched some ideas as to how optimization was to be performed, because
that was a major thrust behind the language effort. However, several
aspects of the langage were not specified in any detail at all. The
syntax and implementation of I/O in particular was, I believe, left
primarilly to one team member who found that an interpreted
implementation was a good way to test his ideas, and then found when the
decision was made to ship Fortran (I) that he did not have time to
convert the I/O implementation to a compiled form. Interpreted I/O is
still used (in some contexts) in Fortran, because users foundthis
accidental feature to be useful. Also while Backus's original proposal
had the concept of subroutines this construct was not available in
Fortran (I), (after more than three years of work on a one year project
they had to get something out of the door and that aspect of the
language was not ready), but was instead introduced in Fortran II.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
Smiljan Grmek <···@4mate.hr> wrote in article <·············@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
From: Dan Haskell
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <slrn5krts1.8c.danh@danpc.cris.com>
In article <················@naggum.no>, Erik Naggum wrote:
[snip]
>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.
[snip]
How sad for you if you think that ad homonym arguments and insults
constitute deep semantic questions.
Can we skip the attacks on Dr Ousterhout and discuss the issue at hand?
From: Joe English
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5im770$40k@crl2.crl.com>
Dan Haskell <····@danpc.cris.com> wrote:
>[...]
>How sad for you if you think that ad homonym arguments and insults
^^^^^^^^^^
>constitute deep semantic questions.
This is the best spelling error I've seen in this whole thread.
··········@crl.com
From: Dan Haskell
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <slrn5l7kab.1ka.danh@danpc.cris.com>
In article <··········@crl2.crl.com>, Joe English wrote:
>Dan Haskell <····@danpc.cris.com> wrote:
>>[...]
>>How sad for you if you think that ad homonym arguments and insults
> ^^^^^^^^^^
>>constitute deep semantic questions.
>
>This is the best spelling error I've seen in this whole thread.
Have pity on me Joe English! (*if* that is your real name :) I am a
poor victim of foneticks who grew up to be abused by a spell checker
that thinks "ad homonym" is the correct spelling.
From: ········@wat.hookup.net
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j39gf$16$6@nic.wat.hookup.net>
In <···················@danpc.cris.com>, ····@danpc.cris.com (Dan Haskell) writes:
>In article <··········@crl2.crl.com>, Joe English wrote:
>>Dan Haskell <····@danpc.cris.com> wrote:
>>>[...]
>>>How sad for you if you think that ad homonym arguments and insults
>> ^^^^^^^^^^
>>>constitute deep semantic questions.
>>
>>This is the best spelling error I've seen in this whole thread.
>
>Have pity on me Joe English! (*if* that is your real name :) I am a
>poor victim of foneticks who grew up to be abused by a spell checker
>that thinks "ad homonym" is the correct spelling.
In fact, it is correct spelling, but it doesn't mean what you intended.
Hartmann Schaffer
From: Paul Wilson
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ir9r4$hrr@roar.cs.utexas.edu>
In article <··················@danpc.cris.com>,
Dan Haskell <····@danpc.cris.com> wrote:
>In article <················@naggum.no>, Erik Naggum wrote:
>[snip]
>
>>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.
>[snip]
>How sad for you if you think that ad homonym arguments and insults
>constitute deep semantic questions.
>
>Can we skip the attacks on Dr Ousterhout and discuss the issue at hand?
I think that would be great. But in defense of the Tcl skeptics,
I have to say that my take on this thread is quite different.
Like any usenet thread, there's a mix of good posts and bad posts. But
many of the postings here HAVE asked deeper semantic questions, and they
have generally gone unanswered.
Critizing someone's writing as superficial, simplistic, and misleading is
NOT an ad hominem argument, if you make a decent case that it's true.
Certainly on both sides some of the rhetoric has been unnecessarily
inflammatory, but I wouldn't say that the Tcl skeptics have been
particularly bad on average. Dr. Ousterhout has the right to write
papers that seem to flatter Tcl, and others have the right to question
his claims.
Unfortunately, Dr. Ousterhout has not yet taken the opportunity to
reply constructively to the serious technical questions that have
been raised. Of course he can't be expected to reply to every
question or criticism in such a torrent, but it doesn't look good that
so far he's chosen the easy way out. In one instance, he selected the
most ill-considered posting to reply to---the one saying that Tcl was
a success mainly due to corporate backing, which is of course ludicrous.
(It's good that he made that very clear, but he's ignored the serious
questions that have been asked.)
And in his most recent posting, he apparently tried to end the discussion
by likening his critics to a bunch of lunatic-fringe paranoids who simply
cannot be reasoned with. In fact, most of them appear to be sincere and
well-informed skeptics asking serious questions. Some are even heavy
Tcl users who simply wonder why they can't have a little more cake and eat
a bit more of it too.
Sure, Dr. Ousterhout tried to avoid seeming like a bad guy, by presenting
his it in as a joking manner, but I think the implications are quite
clear---his critics are just a bunch of fanatical losers who aren't worth
talking to.
Now remind us, what's an ad hominem argument again?
And what are those who are on the fence supposed to think of all this?
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (······@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/)
In article <··········@engnews2.Eng.Sun.COM>, ······@tcl.eng.sun.com (John Ousterhout) writes:
> 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.
This is a completely ridiculous argument. Try using it in other contexts.
"Every person who bought a 10-year old secondhand car could have
bought a new Ferrari instead. But they didn't."
--
Robert Virding Tel: +46 (0)8 719 95 28
Computer Science Laboratory Email: ··@erix.ericsson.se
Ericsson Telecom AB
S-126 25 �LVSJ�, SWEDEN
WWW: http://www.ericsson.se/cslab/~rv
"Folk s�ger att jag inte bryr mig om n�gonting, men det skiter jag i".
From: Richard A. O'Keefe
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ivns6$o09$1@goanna.cs.rmit.edu.au>
Smiljan Grmek <···@4mate.hr> writes:
>Michael Sperber [Mr. Preprocessor] wrote:
>*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 ...
Bogus constraint. Many people are quite comfortable picking up an
unfamiliar language from manuals. Many more are not. Most people
learn languages by being guided. It would certainly be interesting
to try the experiment, but I think you would find that the average
programmer would find TCL even weirder than Scheme. At least in
Scheme you have conventional arrays and assignment statements; you
can *transliterate* Pascal into Scheme a lot of the time and expect
it to work.
>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)
You can't expect to get away with that in a newsgroup where some
people actually understand statistics. To start with, many human
distributions are closer to lognormal than normal, and to continue,
many aren't at all close to either. (For example, for many years
I have found the distribution of exam results in my classes to be
bi-modal.) And then the appeal to "the average programmar" is an
appeal to a meaningless concept. You can make this average as low
as you want by including people who flunked high-school BASIC as
"programmers", or as high as you want by excluding people who
don't understand higher-order predicate calculus. And then of
course the entire idea of ranking programmers on some sort of
unidimensional scale as if programming involved only one skill
is completely bogus.
>Talk to a pschologist friend about averages and you will find out where
well, talk to a statistician first about the notions of "population",
"sampling frame", "average" (everyone _except statisticians seems to
know what an "average" is; statisticians know of several infinite
families of measures that fit the concept), and "bias".
>I tested a friend's contention that you
>cannot talk to an IQ 100 - he was mostly right and it was a saddening
>experience.
Hmm. To start with, "IQ 100" is not a well defined concept.
The measurement error of IQ is around the 5 to 10 point level,
and that's with the same tester administering variants of the
same test to the same subject. The effect of the tester on the
IQ is is pretty serious. And then of course _everyone's_ IQ
tends to 100, because the tests run out of things to test, but
smart people keep on learning new kinds of things. (Consider:
some 80-year-olds learn new human languages. But IQ tests do
not measure what other languages you know or how well you know them.)
So someone _called_ "IQ 100" could be IQ 90 to IQ 110, and for that
matter, could be considerably smarter than most of the people posting
in this thread, if they were old enough. (That's a significant
contributor to the famous correlation between IQs of separated twins,
by the way, IQ varies with calendar age, and twins are the same
calendar age.)
To continue, if you really understand something, you can get
_something_ about it across to people. Heck, there's at least
one American publisher with a high school physics book that has
been entirely purged of mathematics. Either the publisher is
ripping people off (and the teachers using the book are incompetent)
or they are succeeding in conveying _something_ about physics to
people who would probably fail the maths part of an IQ test.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
>>>>> "Smiljan" =3D=3D Smiljan Grmek <···@4mate.hr> writes:
Smiljan> 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.
Smiljan> [ie Scheme is better]
>>
Smiljan> *Anyone* is a fairly large concept - please go find an average
Smiljan> programmer without experience in Tcl and Scheme, present him/her w=
ith
Smiljan> appropriate manuals and have h/h read/write code ...
"Anyone" has nothing to do with averages. "Anyone" is anyone. Find
one person that has to read and write *production code* in one of
Perl, Tcl, C++ *and* Scheme who doesn't agree.
As for the "average programmer without experience," (which is not what
my post referred to, but so what) refer to Paul Hudak's and Mark
Jones's paper
"Haskell vs. Ada vs. C++ vs. Awk vs. ..."
(I believe published in the Journal of Functional Programming, but
also available from
/nebula.systemsz.cs.yale.edu:/pub/yale-fp/papers/NSWC
)
which reports a DoD study involving (among others) Lisp, C++, and
Haskell. The object was to implement a "Geometric Region Server".
The Haskell folks also repeated the experiment with a Haskell novice
that finished *even faster* than the expert Haskell programmer.
The abstractions used in the Haskell code are pretty much the ones a
Lisp programmer would use. (The Lisp guys also finished very
quickly.) These abstractions also happen to be not as readily
available to, say, Tcl or C++ programmers.
--
Cheers =3D8-} Mike
Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla
From: Frederic BONNET
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3353D461.58FD@irisa.fr>
Hi all,
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.
I don't know where you got this information from, but Smalltalk is far
from being infinitesimaly used. When I was a student at the EMN, my
friends and I were surprised by the number of high-tech software
companies who preferred Smalltalk to C++. And job offering on the Net
is not what I call a trustable reference (I'd rather call it Deep
Bullshit (tm))
> 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!'
Looking like C++ doesn't make Java one of its subsets. There are _lots_
of semantic changes that makes it closer to Smalltalk.
You should have a look at the Java specs as well as at a good Smalltalk
book (I recommend the "Blue book", "Smalltalk: the language and its
implementation" by Goldberg & Robson). Then you'll see that Java is
merely a Smalltalk with C++-like syntax, a bit more typing in the VM,
and less mature libraries. Maybe you'll look more informed next time ;-)
CU, Fred
--
Frederic BONNET ·······@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Il ne faut jamais remettre au lendemain ce
$env(HOME) without it! | qu'on peut faire le surlendemain" (Oscar WILDE)
In article <··········@roar.cs.utexas.edu>, ······@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/
In article <··········@lynx.dac.neu.edu>, ········@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/
From: Kelly Murray
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <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.
-Kelly Murray ···@franz.com http://www.franz.com
Kelly Murray <···@math.ufl.edu> skrev i artiklen
<············@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 ···@franz.com http://www.franz.com
>
>
That's easy. If you don't find the backslashes:
\java\doc\guide\innerclasses\spec\innerclasses.doc1.html
Inner classes result from the combination of block structure with
class-based programming, which was pioneered by the programming language
Beta
Too many good systems, too little time..
- Jay
Jesper Buus Nielsen <····@daimi.aau.dk> wrote in article
<··························@lissi.daimi.aau.dk>...
>
>
> Kelly Murray <···@math.ufl.edu> skrev i artiklen
> <············@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
....
> 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 ···@franz.com http://www.franz.com
> >
> >
>
From: Mark A Harrison
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5ibrp0$n3l$1@news.utdallas.edu>
John Ousterhout (······@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.
In article <··············@tequila.systemsz.cs.yale.edu>,
Stefan Monnier <····························@tequila.cs.yale.edu> wrote:
>······@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.
It is expensive to learn. I think that it is only valuable to train people in
it if they are going to save time later on.
Paul Prescod
John Ousterhout <······@tcl.eng.sun.com> wrote in article
<··········@engnews2.Eng.Sun.COM>...
> Wow, there's been quite a party going on over here on comp.lang.scheme!
There is always a party here. But I think the major reason your paper
struck a nerve
has nothing to do with "languages being left out" per se, but everything to
do
with the fact that lisp people do not beleive in your fundamental
assumption
that there is a difference between "scripting" and "system programming"
languages.
In LISP there is a tradition, nearly 40 years old now, of a mixture of
interpreted, compiled, and mixed mode environments. Issues not unique to
LISP
of course, Reference for example Gordon Bell's classic book "Computer
Engineering,
a DIGITAL Perspective." But still, for some reason new lisp programmers
seem to
pick up on this more than newbees using other languages. Eventually of
course
everybody seems to crank out the need to write a compiler. Witness what is
happening
in the Perl community now.
However, I am one that beleives that the language battle is over.
There have been a number of operating systems which emphasize
language-independant "binary interface" component integration to
a sufficiently developed degree that multi-language projects are practical
and robust; however, Microsoft Windows 95/NT seems to have reached
a significant "breakthrough" level in a way that VMS or AS-400 did not.
Primarily because the developer community itself has been sold, kicking and
screaming!
dragged, pushed, whatever, on the component-integration religion.
Meanwhile, the Unix side continues to be "A House Divided Against Itself"
which I do not think can stand against a determined attack by a competitor
with the vast resources of Microsoft. (The anology is that Sun and the Unix
camp
is like the "South" and Microsoft is like the "North" with Oracle sitting
on the
sidelines much like a "Great Britain" did.)
It is horribly difficult for implementors (e.g. of Java, TCL) in the Unix
environment to
make multi-language projects robust with respect to all system conditions,
exceptions and future features.
Glue: Sure, glue is nice. But you cannot glue together wet wood. You have
to
cut away the rotting parts first before attempting a repair. And it is not
sound
to use glue to fill up gaps which are too large.
You guys integrating Java and TCL in the Unix environment really have your
work
cut out for you. Any serious competitor to Microsoft must address its
attack
from the point of view of component integration at the compiled-program
level,
and not merely be yet-another-platform-promising-portability while at the
same
time limiting implementors to a small set of languages.
-gjc
p.s. http://people.delphi.com/gjc reference for my own hacks.
With a mighty <··························@gjchome.nis.newscorp.com>,
···@delphi.com uttered these wise words...
> There have been a number of operating systems which emphasize
> language-independant "binary interface" component integration to
> a sufficiently developed degree that multi-language projects are practical
> and robust; however, Microsoft Windows 95/NT seems to have reached
> a significant "breakthrough" level in a way that VMS or AS-400 did not.
Yep, and the latest development is ActiveX (a new name for some old
ideas from MS, i.e. OLE,OCX,etc). ActiveX Scripting is particularly
neat, as it'll mean that Windows should be free of most of these
language wars. Anyone who wants VBScript can have it, anyone who wants
JavaScript have it, and so on, providing that the script language has
been packaged as an ActiveX script engine and your app can use it
ActiveX scripting.
This isn't rocket science, so I'm expecting to see a _lot_ of Windows
apps using it. MS have made sure that it's easy to add to a apps that
use MFC classes. I'm no great fan of MS, but I think that this is an
excellent move, one of the few trully great things that _anyone_ can
do. In this case, it just happens to be MS.
If you'd like to use a language like Scheme to extend to your
favourite Windows apps, it'll be easy. Just take your SCM ActiveX
script engine, and plug it into your favourite app, and bingo! If you
had the source code to the app, perhaps you could've added Tcl, but
not many, if any, vendors will supply that. Perhaps if the app uses
OLE, you could use OLE Automation, but that's a big perhaps. As big as
ActiveX Scripting? Hmm. We'll see.
I think that the Guile people have also got it right, by supporting
more than one syntax. If you prefer a C syntax, fine. If there's some
syntax that you'd like, and it's not currently available, it shouldn't
be too hard to fix it, and other people can benefit from your work,
too. Each additional syntax helps make Guile stronger.
Meanwhile, everyone else picks a specific language and then fights to
the death to continue using it, forcing it on other people, and
generally wasting a lot of time and effort. Who does that help?
Well, Microsoft, for a start. Bill Gates' dream was once to make Basic
the script language for everything (like JO and Tcl? Sun and Java?
Hmm), but MS have now gone beyond that. The reality is that people
want to use the language that _they_ choose, and some people want to
use that language exclusively. Fine, now they can do it.
Isn't it ironic that it's _MS_ doing this, and not Sun? What about
Apple? Perhaps they've been doing this for years, and I've just missed
it - considering how much bickering people do, it wouldn't be hard.
Keep it up, people. You're making Windows stronger by the minute, by
holding everything else back. Good luck to you - you may need it.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In <·························@news.demon.co.uk>, ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
> Yep, and the latest development is ActiveX (a new name for some old
> ideas from MS, i.e. OLE,OCX,etc). ActiveX Scripting is particularly
> neat, as it'll mean that Windows should be free of most of these
> language wars. Anyone who wants VBScript can have it, anyone who wants
> JavaScript have it, and so on, providing that the script language has
> been packaged as an ActiveX script engine and your app can use it
> ActiveX scripting.
Yup, it is. I've been working in an environment where applications
include a communications port for scripting languages to talk to
rather than a scripting language for most of the last decade. Any
application worthy of the name includes that facility (including web
browsers and web servers :-). Most programming languages (including
ports from Unix) include facilities to talk to these applications.
The result is that you can write scripts in pretty much anything you
want. However, the bundled scripting language (A Rexx, and I *added*
comp.lang.rexx to the newsgroups list) was designed for this kind of
environment. It sort of follows the TCL model of "everything is a
string", and a bare expression gets sent to the default application.
Further, the implementation was meant for this environment, so the
interpreter is written as a small application that includes commands
to launch scripts. The net result of this is that most scripts (mine,
anyway) are written in Rexx in spite of the availability of clearly
superior languages.
> Keep it up, people. You're making Windows stronger by the minute, by
> holding everything else back. Good luck to you - you may need it.
Windows isn't forever. Probably not even for the rest of my life. And
there'll always be a niche market of people for whom the "good enough"
sold by MS isn't.
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead
of bouncenews at the same machine. You have been warned. Sending
unsoliticed email I consider commercial gives me permission to
subscribe you to a mail list of my choice.
In <·····················@contessa.phone.net>, ··········@contessa.phone.net (Mike Meyer) writes:
-In <·························@news.demon.co.uk>, ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
-- Yep, and the latest development is ActiveX (a new name for some old
-- ideas from MS, i.e. OLE,OCX,etc). ActiveX Scripting is particularly
-- neat, as it'll mean that Windows should be free of most of these
-- language wars. Anyone who wants VBScript can have it, anyone who wants
-- JavaScript have it, and so on, providing that the script language has
-- been packaged as an ActiveX script engine and your app can use it
-- ActiveX scripting.
-
-Yup, it is. I've been working in an environment where applications
-include a communications port for scripting languages to talk to
-rather than a scripting language for most of the last decade. Any
-application worthy of the name includes that facility (including web
-browsers and web servers :-). Most programming languages (including
-ports from Unix) include facilities to talk to these applications.
-
-The result is that you can write scripts in pretty much anything you
-want. However, the bundled scripting language (A Rexx, and I *added*
-comp.lang.rexx to the newsgroups list) was designed for this kind of
-environment. It sort of follows the TCL model of "everything is a
-string", and a bare expression gets sent to the default application.
-Further, the implementation was meant for this environment, so the
-interpreter is written as a small application that includes commands
-to launch scripts. The net result of this is that most scripts (mine,
-anyway) are written in Rexx in spite of the availability of clearly
-superior languages.
-
-- Keep it up, people. You're making Windows stronger by the minute, by
-- holding everything else back. Good luck to you - you may need it.
-
-Windows isn't forever. Probably not even for the rest of my life. And
-there'll always be a niche market of people for whom the "good enough"
-sold by MS isn't.
For those interested in Rexx may want to take a look at the abstracts to this
year's Rexx symposium (<http://www2.hursley.ibm.com/rexx/>) as it shows how wide
the applicability of Rexx has grown.
For the time being there are three main Rexx incarnations of the language
itself:
- REXX (available on any platform; commercial as well as freeware),
originates from IBM
- OBJECT REXX (with Warp 4, since Feb 97 for Windows95/NT;
a seven (!) year work on IBM's side to develop a fully procedural
Rexx compatible, truly OO-version even with multiple inheritance,
direct SOM/CORBA support etc.); still remains easy to use, yet
incredible powerful
- NETREXX (available on any platform with Java installed; IBM EWS -
"employee written software") by the very author of the Rexx
language itself: Mike F. Cowlishaw; NetRexx is Java "in the clothes
of Rexx", i.e. Java with the syntax of Rexx (Rexx adapted to the Java
OO-model where necessary, supplying most of the native Rexx
instructions and functions in addition), so Java-programming becomes
feasible for non-C++/Java-tech-gurus; in fact, it's so easy that it
may be used in addition as a *scripting* language *for* *Java*
applications
Rexx itself became an ANSI-standard last year, work has started to produce
an object oriented ANSI-version of Rexx, possibly blending Object Rexx and
NetRexx in the years to come.
A powerful, easy to use and easy to maintain language.
---rony
With a mighty <·····················@contessa.phone.net>,
··········@contessa.phone.net uttered these wise words...
> Most programming languages (including
> ports from Unix) include facilities to talk to these applications.
So what are people arguing over? The choice of scripting language is
irrelevant, if the app doesn't dictate any specific language.
> Windows isn't forever. Probably not even for the rest of my life. And
> there'll always be a niche market of people for whom the "good enough"
> sold by MS isn't.
So this isn' a problem? It sounds a lot like you're just sticking your
head in the sand, and ignoring the problem. I'm not suggesting that
Windows is "right", or even that it'll last forever. (See the
Millenium page on the MSR website. It might be their next OS.)
What I'm saying is that focusing on the _language_ is missing the
point. Let everyone choose the scripting language they prefer, and the
language choice becomes a non-issue. That's what MS have done. Now,
they may suck farts from dead cats, but IMHO this is the right way to
do it. You seem to agree with me about that, so please let's not let
mere OS politics get in the way. I'm no fan of ActiveX, but the one
thing that I can truely appreciate about it is the approach to
scripting, as it throws away the language politics!
I don't see why MS and Windows developers - and users - should be the
only people to benefit from this fine idea. This is why I welcome non-
Windows scripting systems, like Guile. However, if anyone objects to
using Scheme as a core scripting language, then the Guile people will
have failed to remove the language issue completely, as MS have done.
I hope that nobody will have any reason to object, but experience
tells me that some people will. I just hope that I'm wrong.
What I'm most certainly _not_ suggesting is that everyone should use
Windows, or anything else sold by MS. I'm not even suggesting that
ActiveX itself is a good thing. I just wonder how much easier it might
be to extend an app if it were possible to use familiar scripting
language, instead of the one that the author of an app arbitrarily
decided would be "best". I used the word "arbitrarily", as there seems
to be no consensus on the issue of lanaguage choice, nor does it look
like there'll be one in the forseeable future. Such choices are
currently influenced by what I'd call language politics, as there's no
real consensus over the _technical_ pros and cons, never mind anything
of a more subjective nature!
This is why I say that ActiveX Scripting is a good thing. Perhaps it's
unfortunate that it comes from MS, and not Sun or Apple. Well, that's
OS politics, an which is possibly even _more_ "arbitrary" choice,
depending on your view of things. If it's determined by where you work
or were first exposed to computers, then I'd call it "arbitrary".
I try to be pragmatic. ;) A pragmatic approach might be to not bother
trying to convert people who do _not_ want to be converted, but to
instead accept that they'll make "arbitrary" choices, and to support
them. The fact that MS have done this should be irrelevant. I'm using
it as an example to make a point, which is that this helps everyone,
while the endless bickering about which language is "best" does _not_.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In <·························@news.demon.co.uk>, ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
> With a mighty <·····················@contessa.phone.net>,
> ··········@contessa.phone.net uttered these wise words...
>
> > Most programming languages (including
> > ports from Unix) include facilities to talk to these applications.
> So what are people arguing over? The choice of scripting language is
> irrelevant, if the app doesn't dictate any specific language.
Unfortunately, there are people using lesser platforms that don't have
or only recently acquired these facilities, so they can't do that. :-)
And some people just like arguing about religious issues.
> I don't see why MS and Windows developers - and users - should be the
> only people to benefit from this fine idea.
They aren't. Like I said, I (and a few million others) have had the
benefit of this functionality for most of the last decade.
It appears that Unix may get such a solution in the form of
applications that support JVM as a scripting mechanism. This allows
any language that can be used to produce JVM bytecodes to be used for
scripting. There may be technical problems with this solution, but
it's a start.
If you're really interested, I started working on a TCP/IP solution
for this kind of thing a while back. It got aborted by a corporate
takeover, but I may still have the groundwork somewhere (if not, the
critical parts are easy to recreate).
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead
of bouncenews at the same machine. You have been warned. Sending
unsoliticed email I consider commercial gives me permission to
subscribe you to a mail list of my choice.
With a mighty <·····················@contessa.phone.net>,
··········@contessa.phone.net uttered these wise words...
> Unfortunately, there are people using lesser platforms that don't have
> or only recently acquired these facilities, so they can't do that. :-)
That's exactly my point. If MS can do it, so can lots of other
presumably more talented people. Am I the only one who thinks that
this will be a big win? Actually, I think that's an understatement.
I'm predicting that it'll be a _massive_ win.
> And some people just like arguing about religious issues.
Alas. No wonder MS get ahead - they steamroller along, ignoring the
religious issues, and just _do it_. No wonder so many people feel a
need to slag them off. I'm one of them, BTW, so I'm criticising
myself! Was this what Richard P. Gabriel's "Lisp: Good News Bad News
How to Win Big" was about? Well, he didn't mention MS, but I guess
they're way of doing things is closer to "MIT" than "NJ".
<URL:http://www.ai.mit.edu/articles/good-news/good-news.html>
> > I don't see why MS and Windows developers - and users - should be the
> > only people to benefit from this fine idea.
>
> They aren't. Like I said, I (and a few million others) have had the
> benefit of this functionality for most of the last decade.
Has Guile been around for that long?
> It appears that Unix may get such a solution in the form of
> applications that support JVM as a scripting mechanism. This allows
> any language that can be used to produce JVM bytecodes to be used for
> scripting. There may be technical problems with this solution, but
> it's a start.
<sigh> Yet Another Language Specific Solution. Please note that
Activex isn't dependant on a single language. You don't have to use
JavaScript to appreciate ActiveX. It'll work with _any_ language
that's available as an ActiveX script engine.
I'm sure that something similar _could_ be done for Unix, but I've not
yet heard of it. Guile is close, but no cigar. Of course, if nobody
complains about using Scheme as the "VM", then there's no problem.
However, ActiveX Scripting doesn't use a VM. That could be a big
limitation, but the only working (note: I didn't say "workable")
alternative right now is the JVM, which apparently has a few
disadvantages for some languages. ActiveX Scripting doesn't suffer
like this, altho it is (currently) dependant on Wintel. The ideas
could be a lot more portable than the technology itself, which is why
I wonder if something similar could be done for other platforms.
Think it as introspection. ActiveX Scripting adds enough introspection
to allow the scripting language to be completely decoupled from the
app that uses it. That gives the developer and the user a lot of of
leaverage, and without sacrificing any performance, nor leaving any
room for language politics to get in the way of using it. Neither
Guile nor the JVM have that advantage, but perhaps this can change.
Meanwhile, MS steamroller ahead. Who can blame them? They set a goal,
they achieve it, and everyone else eats their dust. In the case of
Bill Gates' "Basic for scripting everywhere", I think that it took 10
something like years or more to achieve, but now it's here. It would
be naive to pretend that people won't exploit it, or that it won't big
a big win. It's such a simple idea, so only the "not invented here"
attitude can stop anyone else from using it.
Unfortunately, that's been an effective block to progress for many
years. (Who remembers ACE?) If technical superiority really does
count, then please forget the political crap and just _do it_. You can
argue all you like about which language is "best" _after_ you've saved
the world...
> If you're really interested, I started working on a TCP/IP solution
> for this kind of thing a while back. It got aborted by a corporate
> takeover, but I may still have the groundwork somewhere (if not, the
> critical parts are easy to recreate).
Good luck.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <kig912fjgfs.fsf@jagor.srce.hr>
[Newsgroups trimmed to comp.lang.lisp]
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> Was this what Richard P. Gabriel's "Lisp: Good News Bad News How to
> Win Big" was about? Well, he didn't mention MS, but I guess they're
> way of doing things is closer to "MIT" than "NJ".
?
RPG lists the following characteristics as the main issues in the MIT
approach:
Simplicity -- the design must be simple, both in implementation and
interface. It is more important for the interface to be simple than
the implementation.
Correctness -- the design must be correct in all observable
aspects. Incorrectness is simply not allowed.
Consistency -- the design must not be inconsistent. A design is
allowed to be slightly less simple and less complete to avoid
inconsistency. Consistency is as important as correctness.
Completeness -- the design must cover as many important situations
as is practical. All reasonably expected cases must be
covered. Simplicity is not allowed to overly reduce completeness.
I don't know about you, but I certainly don't recognize MS here.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> I don't know about you, but I certainly don't recognize MS here.
Oops, I meant to say that they're closer to the "NJ" camp. Thanks for
pointing out my (obvious) error. It's one of those boolean "off by
one" errors...
I guess my intended meaning wasn't clear enough. Sorry for the
confusion. I've untrimmed the newsgroups list, so that my correction
will reach anyone who read the article that we're refering to.
Followups are set to comp.lang.lisp.
Many thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <kig2086kgd1.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> With a mighty <···············@jagor.srce.hr>,
> ·······@srce.hr uttered these wise words...
>
> > I don't know about you, but I certainly don't recognize MS here.
>
> Oops, I meant to say that they're closer to the "NJ" camp.
Well yes, but even then, I'd like to raise the question (this time
completely unrelated to your claim) how Microsoft relates to "Worse is
Better". Again; according to RPG, these are the characteristics of
the New Jersey approach:
Simplicity -- the design must be simple, both in implementation
and interface. It is more important for the implementation to be
simple than the interface. Simplicity is the most important
consideration in a design.
Correctness -- the design must be correct in all observable
aspects. It is slightly better to be simple than correct.
Consistency -- the design must not be overly
inconsistent. Consistency can be sacrificed for simplicity in
some cases, but it is better to drop those parts of the design
that deal with less common circumstances than to introduce
either implementational complexity or inconsistency.
Completeness -- the design must cover as many important
situations as is practical. All reasonably expected cases should
be covered. Completeness can be sacrificed in favor of any other
quality. In fact, completeness must sacrificed whenever
implementation simplicity is jeopardized. Consistency can be
sacrificed to achieve completeness if simplicity is retained;
especially worthless is consistency of interface.
All the UNIX systems can be easily recognized in this description, but
I wonder how much of it pertains to Mircosoft products. I'm by no
account a Mircosoft expert, but people who have worked with their
software extensively claim that Mircosoft is much worse than New
Jersey.
Since Richard Gabriel wrote the famous article before the advent of
the new "Operating systems", which seem even *worse* than Unix, maybe
it's time for an update. Or is it a deeper misunderstanding of the
article of my side that prevents me to connect Microsoft with "New
Jersey"?
What do the others think: how does "worse is better" relate to
Microsoft?
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> > Oops, I meant to say that they're closer to the "NJ" camp.
>
> Well yes, but even then, I'd like to raise the question (this time
> completely unrelated to your claim) how Microsoft relates to "Worse is
> Better". Again; according to RPG, these are the characteristics of
> the New Jersey approach:
Noe that I said they're closer, not identical. There are areas in
which one may compare Unix and Windows, but that would stray into OS
politics, and I'm not sure that we want to do that here. It would be
better to say that everything sucks compared to the "MIT" approach,
including Unix and NT in a "neck and neck" position.
> Simplicity -- the design must be simple, both in implementation
> and interface. It is more important for the implementation to be
> simple than the interface. Simplicity is the most important
> consideration in a design.
Remember that we're comparing Unix and Windows. I'd rather use VB than
Tcl any day - but I'll prefer Lisp over most other tools, when its
available. When your goal is produce a small stand alone app, VB is
hard to beat, esp when you have OLE and OCX components to do most of
the work for you. There's your simplicity.
> Correctness -- the design must be correct in all observable
> aspects. It is slightly better to be simple than correct.
Again, VB wins. Esp if you can pick components that are correct. Note
that any language that uses OLE/OCX can be substituted for VB, e.g.
Delphi, and perhaps even C++. Smalltalk, too. Some of these languages
can also create OLE servers. I recall that there's an APL that can do
this, by saving the workspace as an OLE object.
> Consistency -- the design must not be overly
> inconsistent. Consistency can be sacrificed for simplicity in
> some cases, but it is better to drop those parts of the design
> that deal with less common circumstances than to introduce
> either implementational complexity or inconsistency.
One of the few inconsistency that I know of in VB is the way that
global variables are declared, using DIM. Most Basics I've known have
used this keyword for DIMensioning arrays. Local variables, on the
other hand, are declared with LOCAL.
As for Windows in general, well, there's a lot of historical baggage,
left over from the days when Windows was 16bit and still used Real
Mode. Perhaps this is the price you pay for pushing an OS out the door
before "maturing". A few years of nurturing might've helped.
As for Unix...It could be very unfair to refer to UNIX HATERS, but it
does have some relevance, esp the preface, and the John Rose rant:
<URL:http://www.research.microsoft.com/%7Edweise/rant%2Dof%2Dthe%2Dwee
k/preface.html>. As I said earlier, neck and neck...Win95 can reboot
over as efficiently as a Sun workstation. NT can also be pursuaded to
die, if you know how. (First, pick a dodgy device driver!)
> Completeness -- the design must cover as many important
> situations as is practical. All reasonably expected cases should
> be covered. Completeness can be sacrificed in favor of any other
> quality. In fact, completeness must sacrificed whenever
> implementation simplicity is jeopardized. Consistency can be
> sacrificed to achieve completeness if simplicity is retained;
> especially worthless is consistency of interface.
It would be wonderful if every Windows app was an OLE server, but even
MS have yet to fully embrace their own technology, so it would be
unfair to criticise mere vendors for their intertia. The advantages
have to be pretty impressive to get that many people to follow such a
poor example as the one (many, in fact) set by MS.
On the other hand, I don't expect Sun to reverse engineer all of their
tools and utilities using Java. Not overnight, anyway. This kind of
inertia gets in the way of Completeness, regardless of the OS vendor.
> All the UNIX systems can be easily recognized in this description, but
> I wonder how much of it pertains to Mircosoft products. I'm by no
> account a Mircosoft expert, but people who have worked with their
> software extensively claim that Mircosoft is much worse than New
> Jersey.
Again, please check the UNIX HATERS arguments. I'm not interested in
them myself, as I wouldn't choose _any_ OS, if I could make the choice
myself. See the 'Design Principles Behind Smalltalk', article, by
Daniel Ingalls, in the August 1981 issue of Byte:
"An operating system is a collection of things that don't fit into a
language. There shouldn't be one."
This sounds like a Lisp Machine! It's the "MIT" way of thinking, and
it's one that, unfortunately for us, most people don't want. The
choice between Unix and Windows is a lot like the choice between Emacs
and Vi, in the sense that rational arguments won't convince someone
who disagrees with you.
My only answer is all that any OS will suck, on the principle quoted
above. Perhaps my way of looking at such things was influenced at a
critical stage, as I had no fixed preferences at the time I was
exposed to the Smalltalk ideas. I'm not even sure if Windows existed
back then, but I am sure that no machine I had access to could come
close to running either Unix or Windows.
Plus, there's your next point, which I agree with:
> Since Richard Gabriel wrote the famous article before the advent of
> the new "Operating systems", which seem even *worse* than Unix, maybe
> it's time for an update. Or is it a deeper misunderstanding of the
> article of my side that prevents me to connect Microsoft with "New
> Jersey"?
I see no difference between NT and Unix, apart from some small
details, a bit like C and Pascal programmers arguing over the use of
the semicolon. Which way up do you eat your eggs?
MS seem to be promoting NT as "Unix", which I find confusing, but not
suprising. If the POSIX support is worth anything, then it should at
least support _some_ Unix software. Cygnus Software have also done a
lot to make Win32 as much like Unix as possible. As I understand it,
the CMUCL port to Win32 depends on this, along with compilers for
Haskell, C/C++, and probably a number that I don't yet know of.
Whether any of this makes NT a "Unix" is debatable, and of little
concern to me, as I wouldn't choose either of them. Instead, they
"choose" me, in the sense that most of the software that I'd like to
use is only available for Unix and Windows. Most, if not all, of the
Mac software that has ever interested me has been ported to other
platforms (e.g. the Atari ST, not just Windows).
Sometimes I wonder why I stopped using Forth. ;-) I had the complete
source code (I wrote it myself), and it could boot itself. Since then,
things just got more complicated and ugly. A few things, like Lisp,
make it possible to put up with computers, but so few people seem to
know it even exists, and many who do seem to think that it's dead.
These days, I have my eggs _fried_, not boiled. I couldn't care less
which end up is "better".
> What do the others think: how does "worse is better" relate to
> Microsoft?
As I said, I think that they're closer to the "NJ" style than the
"MIT" style. If you think I'm saying that Windows is "better" than
Unix, then you've grossly misunderstood me. You can eat your eggs any
way you like, just as I can. It won't change the world.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <kigu3l1fys0.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> With a mighty <···············@jagor.srce.hr>,
> ·······@srce.hr uttered these wise words...
>
> > > Oops, I meant to say that they're closer to the "NJ" camp.
> >
> > Well yes, but even then, I'd like to raise the question (this time
> > completely unrelated to your claim) how Microsoft relates to "Worse is
> > Better". Again; according to RPG, these are the characteristics of
> > the New Jersey approach:
>
> Noe that I said they're closer, not identical.
I said the question I asked was *completely* unrelated to your
previous claim. I don't want to comment your comparisons of Tcl and
VB, etc. -- however bad Tcl is, I don't think anyone does it justice
when comparing it with crap like VB. For example, lWhen you claim
that VB is "correct", our definitions of correctness obviously
diverge.
Besides, Visual Basic doesn't make an operating system, and I have no
idea why you cling to it so forcefully -- I was talking about the
whole OS design. The Unix haters I know are mostly comparing Unix to
other, better designed operating systems, *before* the advent of
Microsoft's "OS"-es.
> As for Windows in general, well, there's a lot of historical
> baggage, left over from the days when Windows was 16bit and still
> used Real Mode. Perhaps this is the price you pay for pushing an OS
> out the door before "maturing". A few years of nurturing might've
> helped.
Before Windows appeared, everyone thought Unix was full of historical
baggage. But now people see what *real* baggage is.
> > What do the others think: how does "worse is better" relate to
> > Microsoft?
>
> As I said, I think that they're closer to the "NJ" style than the
> "MIT" style.
Well, that's your opinion. Now I'd like to hear what others have to
say, if anything.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> I said the question I asked was *completely* unrelated to your
> previous claim. I don't want to comment your comparisons of Tcl and
> VB, etc. -- however bad Tcl is, I don't think anyone does it justice
> when comparing it with crap like VB. For example, lWhen you claim
> that VB is "correct", our definitions of correctness obviously
> diverge.
VB is "correct" for a great many people. I admit that I'm using VB as
an example because it winds people up, but the only reason I want to
do _that_ is because you can wind people up with _any_ language, and
people have been using this thread to do that very successfully. In
the case of VB, it also happens to be a pretty damn useful tool, and a
good deal of what JO claims for Tcl also applies to VB. That leaves me
wondering what JO trying to say, but I that he's reading this posting
(he might be, but I dunno if he reads comp.lang.lisp).
However, I'm not going to simply accept the idea that popularity
itself is an endorsement of a tool, whether that tool may be VB, Tcl,
Emacs, or whatever. VB is just a tool that performs a simple task,
binding components into an app, extremely well. What I like best about
VB are not the details, necessarily, but the way in which is
integrates with the platform which runs it, and which it creates apps
for. The fact that the platform is Windows could just be a detail.
In other words, what makes VB so interesting is merely the strong
support VB has for developing code for the platform that runs it.
This is also what makes it so popular. The fact that Delphi has
excited Pascal programmers in the same way suggests that it's not the
language itself, but the development environment.
The significance for Lisp programmers is that this might also work for
Lisp, if anyone were to create such a system. This looks unlikely, but
it at least makes a good "what if" question. I've been making this
point for a couple of years now, so I'll assume that everyone is
familiar with it and just move on...
> Besides, Visual Basic doesn't make an operating system, and I have no
> idea why you cling to it so forcefully -- I was talking about the
> whole OS design. The Unix haters I know are mostly comparing Unix to
> other, better designed operating systems, *before* the advent of
> Microsoft's "OS"-es.
VB is specific to small set of a platforms, all of which can be called
Windows, even tho they're all distinctly different operating systems.
In this sense, they have something in common with Unix. Still, VB is
IMHO an important part of the Windows philosophy. It's the central use
of DLLs throughout Windows, and the features that exploit this, such
as compoment technologies like OLE and OCX that's the key.
As I pointed out in my earlier posting, OLE hasn't been adopted as
widely as MS perhaps intended, even within MS. As I understand it, the
idea was to create a completely object oriented API, based on OLE.
On the other hand, MS have now renamed this group of related
technologies as ActiveX, in order to address the "web component"
market. Whether this is "good" or "bad" is irrelevant, as MS will do
it anyway. It may very possibly affect Windows development in general,
and so perhaps Lisp development for Windows.
> Before Windows appeared, everyone thought Unix was full of historical
> baggage. But now people see what *real* baggage is.
As I've said, I'm not interested in egg orientation. If you want an OS
war, try one of the .advocacy newsgroups. This is comp.lang.lisp, and
we're now in danger of drifting too far away from Lisp. Alternately,
try comp.lang.misc, as the Lisp content of this sub-thread is minimal.
> > As I said, I think that they're closer to the "NJ" style than the
> > "MIT" style.
>
> Well, that's your opinion. Now I'd like to hear what others have to
> say, if anything.
I'm also curious, but please let's try to keep this relevant to Lisp,
if that's possible. OS wars should be in OS .advocacy newsgroups IMHO.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <kig2084ewj0.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> VB is "correct" for a great many people.
[...]
I'm not talking abot "great many people". Great many people like
Windows, too. So what?
> > Before Windows appeared, everyone thought Unix was full of historical
> > baggage. But now people see what *real* baggage is.
>
> As I've said, I'm not interested in egg orientation. If you want an OS
> war, try one of the .advocacy newsgroups. This is comp.lang.lisp, and
> we're now in danger of drifting too far away from Lisp.
It was you who started to talk about VB, OLE, and God knows what else
acronyms. I was asking a simple question regarding "Worse is Better",
as related to the state of Computer Science today, and it *does* have
to do with Lisp -- more than your followups, at any rate.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> I'm not talking abot "great many people". Great many people like
> Windows, too. So what?
Exactly. So what? Windows is rather different from a Lisp machine, and
so is Unix. It seems to me that when you compare such systems to Lisp
machines, the "MIT" approach, they seem to have to a lot in common.
Now, while its common to look at what makes Unix and Windows
different, I see mainly similiarities.
I refered to VB and ActiveX because I see them as playing a
significant part in distinguishing Windows from Unix, but this might
only be because the "componment" in Unix systems appear to be programs
and shell scripts. A lot of similarities remain, like processes
protected from each other by memory management, shared memory, pipes,
user accounts, access rights, etc.
> It was you who started to talk about VB, OLE, and God knows what else
> acronyms. I was asking a simple question regarding "Worse is Better",
> as related to the state of Computer Science today, and it *does* have
> to do with Lisp -- more than your followups, at any rate.
See above. The details may be different, but the general principles
are the same. If you want differences, you can find them. If you want
similarities, you can find them also. No doubt we can also compare
programs, shell scripts, DLLs, etc, with functions, variables, macros,
and other things found in Lisp. You tell me - I've never seen a Lisp
machine, never mind used one. Running a Lisp system as a process is as
close as I get to my "ideal" development environment.
Of course, the distinction between a development environment and a
"user" environment is worth making, too. As a programmer, I've never
felt the need for such a distinction, but I can appreciate that most
computer users don't wish to be a programmer, and so have a very
different set of values.
This is directly relevant to the "Ousterhout and Tcl lost the plot
with latest paper" thread, I think. That's why I mentioned ActiveX
Scripting and VB. There are apps with languages, like VB and Lisp
"hardwired" into them, and that's great for programmers, but not all
users are able to use Basic or Lisp.
I'd better stop there, or I may find myself justifying Tcl, and I
don't wish to do that. ;) I'd rather argue for a system that allows us
to use any language with any app. It would be wonderful if it could be
cross-platform, like the JVM, but I don't actually care what the
system is, as long as it's there and widely adopted.
At least one platform has a system that's likely to be very widely
adopted, but we'll see. Perhaps it'll fail miserably. Who knows?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Mike Meyer
Subject: Universal scripting interfaces (Was: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <19970420.40022388.FA37@contessa.phone.net>
In <·························@news.demon.co.uk>, ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
> Alas. No wonder MS get ahead - they steamroller along, ignoring the
> religious issues, and just _do it_. No wonder so many people feel a
> need to slag them off. I'm one of them, BTW, so I'm criticising
> myself! Was this what Richard P. Gabriel's "Lisp: Good News Bad News
> How to Win Big" was about? Well, he didn't mention MS, but I guess
> they're way of doing things is closer to "MIT" than "NJ".
> <URL:http://www.ai.mit.edu/articles/good-news/good-news.html>
See <URL: http://www.phone.net/home/mwm/workstations/good-enough.html
> for the draft of my take on this. I think that MS is further from
MIT than NJ is.
> > They aren't. Like I said, I (and a few million others) have had the
> > benefit of this functionality for most of the last decade.
> Has Guile been around for that long?
We aren't using Guile.
> > It appears that Unix may get such a solution in the form of
> > applications that support JVM as a scripting mechanism. This allows
> > any language that can be used to produce JVM bytecodes to be used for
> > scripting. There may be technical problems with this solution, but
> > it's a start.
> <sigh> Yet Another Language Specific Solution. Please note that
> Activex isn't dependant on a single language. You don't have to use
> JavaScript to appreciate ActiveX. It'll work with _any_ language
> that's available as an ActiveX script engine.
I don't think this is a language-specific solution. After all, you can
use _any_ language that can be compiled to Java bytecodes. Java was
the first one. Last time I looked, people were talking about or
working on Java bytecode compilers for Python, Scheme and Perl. There
are problably others as well.
> I'm sure that something similar _could_ be done for Unix, but I've not
> yet heard of it. Guile is close, but no cigar. Of course, if nobody
> complains about using Scheme as the "VM", then there's no problem.
If all you give them is JVM binaries, why should they CARE what the
source language was? I have as yet to run into a user who really
cares whether a program was written in C, Scheme or Perl. I've seen a
few who complain that the programs are to big and blame it on the
implementation language, but they are a minority (and usually wrong
anyway).
> Unfortunately, that's been an effective block to progress for many
> years. (Who remembers ACE?) If technical superiority really does
> count, then please forget the political crap and just _do it_. You can
> argue all you like about which language is "best" _after_ you've saved
> the world...
If you believe the Gabriel paper you referenced, technical suepriority
doesn't count. Personally, I believe the paper, and further believe
that marketing counts for far more than technical superiority once
you've reached the "good enough" level described in my paper.
Believing that technical superiority counts left me with lots of
orphans.
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead
of bouncenews at the same machine. You have been warned. Sending
unsoliticed email I consider commercial gives me permission to
subscribe you to a mail list of my choice.
From: Cyber Surfer
Subject: Re: Universal scripting interfaces (Was: Ousterhout and Tcl lost the plot with latest paper)
Date:
Message-ID: <MPG.dc552b8f2907cc798978b@news.demon.co.uk>
With a mighty <······················@contessa.phone.net>,
··········@contessa.phone.net uttered these wise words...
> I don't think this is a language-specific solution. After all, you can
> use _any_ language that can be compiled to Java bytecodes. Java was
> the first one. Last time I looked, people were talking about or
> working on Java bytecode compilers for Python, Scheme and Perl. There
> are problably others as well.
From the discussions that I've read about compiling languages that use
features like closures, tail recursion, continuations, etc to JVM
bytescodes, you might think that there's at least a language bias.
Personally, I'm not worried about a little loss of performance, as
long as it's _possible_.
My point about ActiveX Scripting is that there's _no_ language bias at
all, so even those people who worry about a small loss of performance
(obsessive bean counters or realists?) will be happy. We don't need to
use every language to write MPEG drivers, so I don't think that we
need to judge every language by that standard - even if some people
will. Either these people really believe that there's no difference
between an MPEG driver and any other software, or they're just trying
to convince us that we should all be using assembly language and C.
> If all you give them is JVM binaries, why should they CARE what the
> source language was? I have as yet to run into a user who really
> cares whether a program was written in C, Scheme or Perl. I've seen a
> few who complain that the programs are to big and blame it on the
> implementation language, but they are a minority (and usually wrong
> anyway).
I agree with you about this, which is why I'm not talking about the
language used to write the app, but the scripting language, or even
the means by which a user may choose the language in which to write
scripts to extend an app.
> If you believe the Gabriel paper you referenced, technical suepriority
> doesn't count. Personally, I believe the paper, and further believe
> that marketing counts for far more than technical superiority once
> you've reached the "good enough" level described in my paper.
My experience is that most people don't care about what we like to
call "technical superiority", as they only want an app that performs a
useful task, at a reasonable price. This may be why marketing is such
a powerful factor in deciding what succeeds and what fails.
> Believing that technical superiority counts left me with lots of
> orphans.
It's also a very subjective issue. Jonathon Swift made an excellent
point about what I call "egg orientation". It's a lesson that I
learned at an early age, but it's the "advocacy" threads here on
UseNet (and elsewhere) that've taught me that it's not just an amusing
story for children. It's also a painful lesson for adults.
These days, I prefer my eggs fried, not boiled.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Arturo P�rez
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <AF837FB99668DC55@ppp131.itw.com>
In article <·························@news.demon.co.uk>,
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
>With a mighty <··························@gjchome.nis.newscorp.com>,
>
>Isn't it ironic that it's _MS_ doing this, and not Sun? What about
>Apple? Perhaps they've been doing this for years, and I've just missed
>it - considering how much bickering people do, it wouldn't be hard.
Apple, as usual, addressed this problem several years ago. It's called
OSA (I think it stands for Open Scripting Architecture).
Some weird, perhaps not exact descriptions of it are:
Imagine being able to activate Xt accelerators via an IPC mechanism.
Or
Imagine OpenLook synthetic events available via IPC.
You have your choice of syntaxes (Perl, AppleScript or Frontier are
available or you can make your own). You can do it from C (but man!
does that hurt from what I hear).
Print shops love the thing. With it they can automate an entire production
process using the applications they already have; e.g. QuarkExpress,
FileMaker, etc, etc.
If you're a consultant it may pay very well to know about it...
With a mighty <················@ppp131.itw.com>,
·····@acm.org uttered these wise words...
> Apple, as usual, addressed this problem several years ago. It's called
> OSA (I think it stands for Open Scripting Architecture).
Excellent. I guess I missed it coz I'm not a Mac developer. Since it
has some relevance to this thread, I wonder how it compares with Tcl?
> You have your choice of syntaxes (Perl, AppleScript or Frontier are
> available or you can make your own). You can do it from C (but man!
> does that hurt from what I hear).
Even better. Is it possible to use Lisp? Tcl? You're saying that it
can be done, but has anyone _actually_ done it yet?
Not that it matters. What's important is that Apple - and now MS -
have a way of making the scripting language irrelevant. The choice is
with the user, instead of hardcoded by the app developer. Now, if the
Unix people could also use something like this...
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>,
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
>With a mighty <················@ppp131.itw.com>,
>·····@acm.org uttered these wise words...
>
>> Apple, as usual, addressed this problem several years ago. It's called
>> OSA (I think it stands for Open Scripting Architecture).
>
>Excellent. I guess I missed it coz I'm not a Mac developer. Since it
>has some relevance to this thread, I wonder how it compares with Tcl?
There's all kinds of ways to look at this comparison. If we go back to
the creating a button comparison then AppleScript loses because it is
extremely verbose. This is a typical snippet (syntax not guaranteed 100%)
repeat with w in {every word of every paragraph of window 1}
set the first character of w to 'T'
end repeat
On the other hand you can do exactly the same thing from MacPerl (I've
heard) so the syntax then acquires Perl's economy of expression. I would
also expect that Macintosh Common Lisp does OSA. I know that the GNU emacs
that runs on Mac also does OSA - I used it to get compilation errors from
CodeWarrior and parse them using the 'next-error' capabilities of emacs.
OSA is a strange hybrid of a thing. The closest analogy to it that I've
seen in the Unix world is Xt actions. If you could envision a way of
activating Xt actions via some IPC mechanism. I'm not a windows guy but
the people I know who are agree that windows has _nothing_ comparable to
OSA. It's another thing that keeps publishers on Macs.
In a nutshell (in case you're not familiar with Xtactions), the application
developer determines what capabilities a scripter might require. This is
called "factoring." The idea is, rather than allow the scripter to
activate GUI elements such as pushing buttons or selecting menu items,
allow the scripter to perform sensible operations. I've spent quite some
time scripting CodeWarrior so I'll use that as an example. In CodeWarrior,
the Mac IDE, you have commands Make Project, Remove Binaries, Set
Preferences of ___ to ___. Some of these correspond to menu items and some
of them don't. One that doesn't is "Save Error Window to file." There's
no corresponding menu item for it but the CW developers added it because it
was a sensible operation.
Let's define driving an application. Under Unix you typically drive an
application by opening a pipe to it and feeding it the commands that you
would type at it because most Unix things are keyboard-driven. This is the
entire paradigm behind expect. So, when you drive ed you feed it a string
of cryptic one character commands. You must get the command exactly right
because errorchecking is extremely difficult (although expect does make
this easier). And, of course, every utility/tool has a completely
different command set. So, you must know the "API" to awk,ed,sed,ls etc to
build fully functional glued together things. And you have no way to
control GUIs - they don't tend to be able to read from pipes. And GUIs
don't tend to have command languages anyway.
Tcl is just a better way of driving than the Bourne shell. If you embed
Tcl into your apps then you could do TkSends I suppose. But you have no
way of determining what are legal commands to Tksend. And, in general, I
haven't seen people use Tcl to express operations the way that
OSA/AppleScript does.
With AppleScript (the Script Editor, in fact) you can query the application
for what AppleEvent's it accepts and it gives you the syntax for activating
them. Whenever you execute a statement you get the results of that
statement. It's more of a dialogue with the application then you tend to
see with Tcl.
And the best thing is: your standard apps already do it. Quark Express,
CodeWarrior, Filemaker Pro, etc all support it. So you can use your
current favorite word processor to automatically process words. With Tcl
you tend to have to get a new word processor that was written in Tcl.
On the downside, I think AppleScript is slower than Tcl.
>
>> You have your choice of syntaxes (Perl, AppleScript or Frontier are
>> available or you can make your own). You can do it from C (but man!
>> does that hurt from what I hear).
>
>Even better. Is it possible to use Lisp? Tcl? You're saying that it
>can be done, but has anyone _actually_ done it yet?
I've used EmacsLisp a few years back. I imagine Macintosh Common Lisp can
do it. I wonder how well MacGambit supports OSA?
>
>Not that it matters. What's important is that Apple - and now MS -
>have a way of making the scripting language irrelevant. The choice is
>with the user, instead of hardcoded by the app developer. Now, if the
>Unix people could also use something like this...
Amusingly enough Apple ported OSA to AIX under the guise of their highend
network servers. So, you could send AppleEvents from you Mac to the server
to perform operations.
That's something else I forgot to mention. OSA is "network aware." So,
you could
tell application "FileMaker Pro" of machine "Sammy" in zone "Davis"
to activate
end tell
to start filemaker pro on that machine.
It's a fun capability to have when you're a nerd. :-)
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Bruce" == Bruce S Tobin <······@infinet.com> writes:
Bruce> OO alone won't increase productivity significantly, but if
Bruce> you take a well-designed OO language (i.e., pretty much
Bruce> anything except C++), and add a good class library and
Bruce> application framework aimed at a particular problem domain,
Bruce> your productivity gains can be very impressive; often greater
Bruce> than what you get with a scripting language tailored to the
Bruce> same domain.
Interestingly, I've found that even C++ works this way. A simple case
in point: often I need to read strings from an input channel into an
associative array. I certainly could do this in Perl, where it is
very easy, or Python, also easy. However, because of
- the draft ANSI standard's string class
- STL's map<>
- and libg++'s Regex class
I can and have done it in C++ with very little effort. Without these
classes, I wouldn't even think about doing it in C++.
A good case example is Perl. Quite a lot of people think that the
popularity of Perl is because of some innate desire for `sinful'
languages. I content that this has nothing to do with it; Perl is
popular precisely because there is a module for just about every need.
Before I found a special purpose C POP3 client, I hacked one up in
Perl in only a few lines, because I had a POP3 library available to
me. Given a POP3 library in language x, I could do the same thing;
Tcl exists and is useful largely because of Tk.
I don't traditionally program in Scheme or Common LISP,
not because I don't have interpreters or compilers for them, but
because they aren't good enough at string processing to interest me.
Similarly for Ada. On the other hand, Icon is beautiful at string
processing, but can't do other useful things like sockets.
Frankly, if you want me to use language x, you'll have to give me some
enticement. I imagine that there are other programmers who
feel the same way I do.
- --
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.h>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM1sekCqNPSINiVE5AQGuAQP+Iy/djVsUkdA6h+BtTuO8W/vP+yqS2tlw
wG7Y43d4If+5GVZHtx1nnpscM/nBByOB0uwXkbzOAZHWbZN/KrA9z2UUvlGuCUgm
CARtEfYrEwLVhAql9QvnShgSZKJS0xaervWt+QHTHjDHNp5X4LIBkz5nTMsHOFtM
MZ4VH2mD7SI=
=aUbv
-----END PGP SIGNATURE-----
"Graham C. Hughes" <·············@resnet.ucsb.edu> writes:
> I don't traditionally program in Scheme or Common LISP,
> not because I don't have interpreters or compilers for them, but
> because they aren't good enough at string processing to interest me.
I must disagree. I find scheme *wonderful* for string
processing. Using map and filter functions and for-each, you can do
incredible things in a few lines of code. And it's fast too!
John Ousterhout wrote:
[...]
> >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.
Well, I found this discussion just now, but this is IMHO easy to answer:
void action() { cout << "Hello" << endl; }
button b=buttonstyle().text("Hello").font("Times",16).execute(action);
Where the library would have the following definitions (only public
parts
shown):
typedef void (*actionproc)();
class buttonstyle
{
public:
friend button;
buttonstyle& text(string txt);
buttonstyle& font(string name, int size);
buttonstyle& execute(actionproc);
// other attributes
};
class button
{
public:
button(const buttonstyle& style);
void changestyle(const buttonstyle&);
buttonstyle style();
// button actions
};
As you see, it *is* possible to do it in C++. So if the C++ interface of
real
GUI libraries isn't as simple, you should complain to the library
writer,
not the language.
And it is neither untyped (you can't initialize a button with anything
but
a buttonstyle), nor hard to do (all methods are just straightforward).
BTW, what would the following possible C++ interface for menus look like
in
tcl/tk?
MenuBar MainMenu
(
Menu("Main")
.Item
(
Menu("~File")
.Item(Command("~Open", cmOpenFile), helpOpen)
.Item(Command("~Save", cmSaveFile), helpSave)
.Item(Command("~Save ~As", cmSaveFileAs), helpSaveAs)
.Separator()
.Item(Switch("Make ~Backup", BackupFlag), helpBackup)
)
.Item
(
Menu("~Search")
.Item(Command("~Find"), cmFind), helpFind)
.Item(Command("~Replace"), cmReplace), helpReplace)
.Separator()
.Item(Command("Find ~Again"), cmFindAgain), helpFindAgain)
)
)
Here cmXXX specifies the Action (or Message, as usual in GUIs), while
helpXXX specifies an optional help context for online help.
[...]
From: L.J. Wischik
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5k2v86$e2@lyra.csx.cam.ac.uk>
>>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: ...
>
>>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).
I think this is a silly debate. You could write it in C++Builder, and
select the button in the integrated development environment, and click on
the 'font' button, and select a font for it graphically, without any lines
of code. So what?
--
Lucian Wischik, Queens' College, Cambridge CB3 9ET. ·······@cam.ac.uk
With a mighty <·········@lyra.csx.cam.ac.uk>,
·······@cus.cam.ac.uk uttered these wise words...
> I think this is a silly debate. You could write it in C++Builder, and
> select the button in the integrated development environment, and click on
> the 'font' button, and select a font for it graphically, without any lines
> of code. So what?
I said something like this a while ago, but I guess nobody noticed.
Code generators for MFC/C++ aren't the only way of doing this. VB did
it a little earlier, Pascal programmers can do it with Delphi - and
this is just for Windows!
Some Lisp programmers have done it, too, but these tools have tended
to be for X Windows. I think that Garnet has an interface builder, but
not all of them are for Common Lisp.
Yes, this is very silly. Pick an app with 400 forms, and you might
find some significant differences, but a simple "Hello, World" app
will tells us _nothing_. That same argument can be used to justify
tools like WinBatch (yep, build your app in a language that makes
Basic look sophisticated! Never mind Tcl...) in just a couple of lines
of source code. It could even justify using assembly language, so that
the object code will be small enough.
When you have 400 forms, perhaps tools like ObjectVision make more
sense, but I don't know if it's still available. Ok, just build the
same kind of abstractions in another language, perhaps by using sexprs
in Lisp (or Prolog, or any language that you can build an sexpr parser
with), writing your forms in your domain-specific meta-language, and
then compile it into, say, Lisp expressions that build the user
interface using your chosen tool (Garnet, Tk, CLIM, whatever).
You could even compile them into C++ code using MFC, OWL, V, or some
other C++ framework. V would give you Windows _and_ X Windows. It
might even give you Mac support, but I don't know if that's been added
yet. Alternately, how about compiling to HTML forms and CGI code (C,
Perl, Java, etc), or just go for Java and the AWT.
The important thing is that you'd have complete control over the meta
language and the abstractions that it uses, the code for the forms
could do whatever you wanted (like specifying validation formats,
compiling reg-exprs to state automata), and because the expressions
are s-exprs, they're easily manipulated, unlike strings. This means
that when you make some fundamental change to your meta language, you
can let the machine to the rewriting.
If you have 400+ forms, this could be a _big_ win. This is isn't an
articifical example, BTW. Some people actually write such apps. If
they use tools like ObjectVision, it's likely that they won't get the
same leverage that a programmer who builds a domain specific meta
language will get. Even for smaller apps, you can still win big, esp
if the effort to build the meta language is small enough, which it
often will be.
Followups adjusted, for the benefit of the perl, python and eiffel
people who don't appreciate this thread. If you know this stuff
already, then I apologise for wasting your time.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Christopher Eltschka <········@physik.tu-muenchen.de> wrote in article
<················@physik.tu-muenchen.de>...
> John Ousterhout wrote:
>
> [...]
>
> > >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 ...
> >
> > 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.
>
> Well, I found this discussion just now, but this is IMHO easy to answer:
>
> void action() { cout << "Hello" << endl; }
>
> button b=buttonstyle().text("Hello").font("Times",16).execute(action);
Indeed! I have written such a C++ GUI toolkit myself. I started writing it
because I found MFC and Borland's OWL to be so useless. Because I'm a Tcl/Tk
programmer, I used Tk's model of layout managers and configurable GUI
components.
E.g, here's how a main window with some buttons would be created, first in Tk:
proc Quit { ... }
proc Beep { ... }
proc MyMainWindow {w} {
toplevel $w
wm title $w "An Example Main Window in Tk"
# Create and configure user-interface widgets
#
button $w.quit -text "Quit" -command Quit
button $w.beep -text "Beep" -command Beep
# Layout widgets
#
grid $w.quit -row 0 -column 0 -sticky nsew
grid $w.beep -row 0 -column 1 -sticky nsew
}
And now in my framework, WOOL. This is a little larger, but is more
explicit about the relationship between components:
#include <mainwin.h>
#include <button.h>
#include <action.h>
class MyMainWindow : public MainWindow
{
private:
void quit(); // Closes the main window and quits the application
void beep(); // Makes a beep noise - just an example
GridLayout _grid; // Layout manager
TextButton _quit, _beep; // GUI components
public:
MyMainWindow( HINSTANCE app ) :
MainWindow(app,"An Example Main Window in the WOOL libary"),
_quit(this), _beep(this)
{
/* Configure the user-interface widgets
*/
_quit.text("Quit")
.action(new MemberAction<MyMainWindow>(&MyMainWindow::quit))
_quit.text("Beep")
.action(new MemberAction<MyMainWindow>(&MyMainWindow::beep))
/* The grid layout manager will fill the window, allocating the
* space to its slaves
*/
this->manage(_grid);
/* Tell the layout manager which slaves to layout and where to
* to put them.
*/
_grid.manage(_quit).row(0).column(1).anchor(fill);
_grid.manage(_beep).row(0).column(0).anchor(fill);
}
};
And using C++ has a number of other advantages. Because the interactions
between layout managers and layout slaves are defined in terms of abstract
interfaces, a layout manager can lay out any object which provides the
LayoutSlave interface and so can lay out Widgets, canvas objects and even
other layout managers. The latter is useful because it reduces the need
for extra frame widgets which only exist to create pleasing layouts.
I haven't found the need to use weak typing, probably because I make
full use of C++'s template mechanisms, and because I find it natural
to design frameworks in terms of roles and interactions defined using
strongly-typed abstract interfaces. I also designed the framework to
interact with other frameworks by providing interfaces through which
event loops can be merged and support for multiple threads.
There is nothing in C++, strongly typed languages or object orientation
which makes it impossible to glue components together or implement reusable
software components. Its just that you have to design things that way
from the start. It is exactly the same with Tcl/Tk. It is as possible to
design an infexible and un-reusable component for Tcl/Tk as it is for
C++ or any language. It's not a platform or language issue, but a
design issue.
IMHO, The flaw in Dr. Ousterhout's paper is that it can essentially be
boiled down to the argument "A well designed framework is better than a
poorly designed framework" with which nobody can argue but which says
nothing about the usefulness of Tcl or scripting languages in general.
Cheers,
Nat.
--
+-------------------------------------------+---------------------------------+
| Name: Nat Pryce MEng ACGI O- | Mail: Department of Computing, |
| Email: ···@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 (Direct Dial) | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+-------------------------------------------+---------------------------------+
From: Donal K. Fellows
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5k4uqv$8a@m1.cs.man.ac.uk>
In article <················@physik.tu-muenchen.de>,
Christopher Eltschka <········@physik.tu-muenchen.de> wrote:
[ ... ]
> BTW, what would the following possible C++ interface for menus look
> like in tcl/tk?
>
> MenuBar MainMenu
> (
> Menu("Main")
> .Item
> (
> Menu("~File")
> .Item(Command("~Open", cmOpenFile), helpOpen)
> .Item(Command("~Save", cmSaveFile), helpSave)
> .Item(Command("~Save ~As", cmSaveFileAs), helpSaveAs)
> .Separator()
> .Item(Switch("Make ~Backup", BackupFlag), helpBackup)
> )
> .Item
> (
> Menu("~Search")
> .Item(Command("~Find"), cmFind), helpFind)
> .Item(Command("~Replace"), cmReplace), helpReplace)
> .Separator()
> .Item(Command("Find ~Again"), cmFindAgain), helpFindAgain)
> )
> )
>
> Here cmXXX specifies the Action (or Message, as usual in GUIs),
> while helpXXX specifies an optional help context for online help.
Well, using a (modified) version of some code that I've used in my own
apps (and which is available on my website), I get something like this:
dkfMenu .mbar hvar {
button -text "Main" -contents {
cascade -label "~File" -menu {
command -label "~Open" -command cmOpenFile -help helpOpen
command -label "~Save" -command cmSaveFile -help helpSave
command -label "Save ~As" -command cmSaveFileAs \
-help helpSaveAs
separator
checkbutton -label "Make ~Backup" -variable BackupFlag \
-help helpBackup
}
cascade -label "~Search" -menu {
command -label "~Find" -command cmFind -help helpFind \
-accel <Control-s>
command -label "~Replace" -command cmReplace \
-help helpReplace -accel <Meta-percent>
separator
command -label "Find ~Again" -command cmFindAgain \
-help helpFindAgain -accel <F3>
}
}
}
Modifications from my published code are as follows:
1) Excessive curlies are removed (a line or two as Tcl has built-in
primitives to help with this trick)
2) "~" processing to extract underline positions (totally trivial in
Tcl)
3) Help is modified to redirect through a message catalogue - not
unreasonable in the circumstances... :^)
Points to note:
1) I've specified my keyboard accelerators as part of the menu
definition. That causes a user-readable string to be attached to
the menu entry and an appropriate keyboard binding to be made
within that window.
2) There are a lot of options that I've not specified in there.
Having a menu item with a picture on it instead of a text label
does not increase the complexity of the code.
3) I wrote the original code nearly two years ago as one of my first
little projects in Tcl. It is _not_ even close to idiomatic IMHO
As you can see, Tcl can easily see everything that you did (without
difficulty I might add) and raise proper keyword-based arguments that
make maintenance much easier while allowing for a much greater range
of behaviour. Indeed, this is an advantage shared with languages like
Perl, Lisp and many others (that should placate Erik a little... :^)
and it is the design of C/C++ which is a stumbling block here.
Admittedly, this can be kludged around (either using the inefficient
mechanism used above or by using a variable number of arguments, which
unfortunately compromises anything even remotely approximating to type
safety)
Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) ········@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| ·····@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
From: Harvey J. Stein
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <m2u3keuzw1.fsf@blinky.bfr.co.il>
In article <·········@m1.cs.man.ac.uk> ········@cs.man.ac.uk (Donal K. Fellows) writes:
In article <················@physik.tu-muenchen.de>,
Christopher Eltschka <········@physik.tu-muenchen.de> wrote:
[ ... ]
> BTW, what would the following possible C++ interface for menus look
> like in tcl/tk?
>
> MenuBar MainMenu
> (
> Menu("Main")
> .Item
> (
> Menu("~File")
> .Item(Command("~Open", cmOpenFile), helpOpen)
> .Item(Command("~Save", cmSaveFile), helpSave)
> .Item(Command("~Save ~As", cmSaveFileAs), helpSaveAs)
> .Separator()
> .Item(Switch("Make ~Backup", BackupFlag), helpBackup)
> )
> .Item
> (
> Menu("~Search")
> .Item(Command("~Find"), cmFind), helpFind)
> .Item(Command("~Replace"), cmReplace), helpReplace)
> .Separator()
> .Item(Command("Find ~Again"), cmFindAgain), helpFindAgain)
> )
> )
>
> Here cmXXX specifies the Action (or Message, as usual in GUIs),
> while helpXXX specifies an optional help context for online help.
How about something similar from STk:
(define-method make-menu ((self <dbwidget>) menu-parent window)
;;; Menu structure
;;; File DO Sort Filter ... Help
;;; -Save -Set -Set -Set -help
;;; -Meta-add -Do 1 -Do 1 -Do 1
;;; -Undo -Do 2 -Do 2 -Do 2
;;; -Save
;;; -Quit -Do 3 -Do 3 -Do 3
(define (make-cmd-list name-cmd-pairs f slot)
(cond ((null? name-cmd-pairs) ())
(else
(cons (list
(caar name-cmd-pairs)
(lambda ()
(f self (cadar name-cmd-pairs))
(slot-set! self slot
(cadar name-cmd-pairs))))
(make-cmd-list (cdr name-cmd-pairs) f slot)))))
(let* ((menu-list `((" File"
("Reload"
,(lambda () (open-dbase self)))
("Meta Add"
,(lambda ()
(set-new-record-of
*master-db*
(list-insert! (get-state-of self) 2 ""))
(add-record *master-db*)))
("Undo"
,(lambda () (undo self)))
("Save"
,(lambda () (save-dbase self)))
("")
("Edit Current"
,(lambda () (edit-record-popup self)))
("")
("Quit"
,(lambda ()
((quit-hook-of self) self)
(close-dbase self)
(destroy window))))
(" Do "
("Add" ,(lambda ()
(get-doer self menu-parent)))
("Edit" ,(lambda ()
(edit-slot "Command"
'cmd-list
self menu-parent)))
("")
,@(make-cmd-list (cmd-list-of self)
(lambda (s f)
(execute-do-cmd-on-current s f))
'cmd))
(" Sort "
("Add" ,(lambda () (get-sort-popup self menu-parent)))
("Edit" ,(lambda ()
(edit-slot "Sorter" 'sort-list self menu-parent)))
("")
,@(make-cmd-list (sort-list-of self)
(lambda (s f) (sort-data-of s f))
'sorter))
(" Filter "
("Add" ,(lambda () (get-filter self menu-parent)))
("Edit" ,(lambda ()
(edit-slot "Filter" 'filter-list self menu-parent)))
("")
,@(make-cmd-list (filter-list-of self)
(lambda (s f) (filter s f))
'filter))
((" Help " :side "right")
("dbzone" ,(lambda () (stk:show-help-file *help-file*)))
("General STk help" ,(lambda () (help)))))))
(make-menubar menu-parent menu-list)))
This function puts a menu on a database viewer object. The database
viewing object contains lists of data from which some of the menu
commands are generated. For example, where you see:
,@(make-cmd-list (cmd-list-of self)
(lambda (s f)
(execute-do-cmd-on-current s f))
'cmd)
(cmd-list-of self) returns a list of the form:
((name1 fcn1) (name2 fcn2) ...)
@,(make-cmd-list...) then splices something like the following into
the menu list:
("name1" (lambda ()
(execute-do-cmd-on-current self fcn1)
(slot-set! self 'cmd '(execute-do-cmd-on-current self fcn1))))
("name2" (lambda ()
(execute-do-cmd-on-current self fcn2)
(slot-set! self 'cmd '(execute-do-cmd-on-current self fcn2))))
...
The slot-set! records the last action on the 'cmd slot in the database
viewer object.
--
Harvey J. Stein
Berger Financial Research
····@netvision.net.il
From: Donal K. Fellows
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5i37u3$s0a@m1.cs.man.ac.uk>
In article <··················@aalh02.alcatel.com.au>,
Chris Bitmead <·············@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... :^)
> ····@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.
> >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.
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) ········@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| ·····@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
Donal K. Fellows <········@cs.man.ac.uk> wrote in article
<··········@m1.cs.man.ac.uk>...
>
> 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...
>
I've thought about this comment and I now realize that we probably owe JO a
bit of an apology. He did not storm over to comp.lang.scheme and post his
article. No, JO put his article on his own personal Web page. Geez, I wish
I had realized that when I opened my big mouth to respond to the post of
the person who DID storm over and put JO's text into the stronghold of the
Lisp faithful. Anyway, a person has the right to put anything they want on
a personal Web page, and nobody, least of all moi, has the right to
interfere with that.
Bill House (with sheepish look)
--
······@dazsi.com
http://www.dazsi.com
In article <··························@wjh_dell_133.dazsi.com>,
Bill House <······@dazsi.com> wrote:
>Donal K. Fellows <········@cs.man.ac.uk> wrote in article
><··········@m1.cs.man.ac.uk>...
>>
>> 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...
>>
>
>I've thought about this comment and I now realize that we probably owe JO a
>bit of an apology. He did not storm over to comp.lang.scheme and post his
>article. No, JO put his article on his own personal Web page. Geez, I wish
>I had realized that when I opened my big mouth to respond to the post of
>the person who DID storm over and put JO's text into the stronghold of the
>Lisp faithful. Anyway, a person has the right to put anything they want on
>a personal Web page, and nobody, least of all moi, has the right to
>interfere with that.
Let me get this straight: as long as someone *publishes* mistruths or
half-truths to their web page, you have no right to criticize the
mistruth or half-truth? That is an amazing attitude, in my opinion. Once
something is published, it is open to debate and criticism.
Paul Prescod
> From: Paul Prescod <········@csclub.uwaterloo.ca>
> Newsgroups: comp.lang.lisp; comp.lang.scheme; comp.lang.scheme.scsh;
comp.lang.tcl
> Subject: Re: Ousterhout and Tcl lost the plot with latest paper
> Date: Friday, April 04, 1997 12:37 PM
>
> In article <··························@wjh_dell_133.dazsi.com>,
> Bill House <······@dazsi.com> wrote:
>
[snipping earlier msgs]
>
> Let me get this straight: as long as someone *publishes* mistruths or
> half-truths to their web page, you have no right to criticize the
> mistruth or half-truth? That is an amazing attitude, in my opinion. Once
> something is published, it is open to debate and criticism.
I don't want to start yet-another-flame, but I realized that the URL for
this thing was way down in the bowels of Sun, under People, and under JO's
name. I was reacting to it in the context of comp.lang.scheme, as if he
had posted it here. Frankly, I would never have known about it if someone
(was it you?) hadn't reposted it. There's a difference between a person
harboring opinions I disagree with and actually walking up and asking for
trouble.
I guess what I'm trying to say is that, if I had happened by it on JO's Web
page, I *might* have sent the man some e-mail and let that be that. After
all, does everyone who publishes something on their personal page have to
mention Lisp? Anyway, despite the silly stuff in the paper (like
implementation inheritance being a bad idea, etc.), I don't think JO really
deserves to be hunted across the I-Net like some Unix-based Simon Legree.
He's just a very talented software engineer who happens to hold some views
I find outrageously slanted.
OTOH, perhaps I'm just thinking how I would feel if someone posted one of
my less enlightened works in a newsgroup I never visited, had no particular
interest in and didn't realize I was infuriating, and then began to
eviscerate me, point by point. Geez... gives me the willies! What happens
when the Forth guys find out about this, and our failure to include their
language's unique qualities in our discussions? We'll all be hurting then!
A little compassion isn't necessarily a bad thing. Anyway, maybe it's time
for JO to actually drop by and offer his response in "person". It's really
not much fun to deride someone for days when they're not even around to
appreciate it. <g>
Bill House
--
······@dazsi.com
http://www.dazsi.com
········@cs.man.ac.uk (Donal K. Fellows) writes:
>In article <··················@aalh02.alcatel.com.au>,
>Chris Bitmead <·············@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.