In article <s6y208um0ey.fsf_-_@aalh02.alcatel.com.au>,
Chris Bitmead <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... :^)
> chen@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) fellowsd@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| donal@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
|