From: ········@bayou.uh.edu
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ihaol$n3g@Masala.CC.UH.EDU>
John Ousterhout (······@tcl.eng.sun.com) wrote:
: In article <·············@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.
: Sorry, but this doesn't really make sense. For example, if "ugly languages"
: refers to Tcl or Perl or C++, none of these languages even existed in the
: 1970s.
Sounds like you need to review your history of languages. C++, while
not existing in the 70s, was designed to be a superset of a language
that was -- you get three guesses as to which language that is. Therefore
C++ _IS_ a product of inertia.
As for Perl and Tcl, they seem very "shell-like" to me, so I'm tempted
to say that they are also a product of inertia from that direction,
but someone with more knowledge in these particular languages would
do well to answer that issue, and also perform appropriate dating
as to the age of the predecessors of those 2 languages.
: In contrast, various flavors of Lisp have been around since at least
: the early 60's and Smalltalk first appeared in the late 60's.
I was under the impression that Smalltalk first appeared in the early
70s.
: Every single
: programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic, or even
: C could have chosen Lisp, Scheme, or Smalltalk.
Here you show a grievous lack of common sense that goes well with your
lack of knowledge about language-history. The only programmers who
would be able to choose Lisp, Scheme, or Smalltalk are those who
would have known that those languages existed, and you would be
surprised at how many people do _NOT_ know they exist. I ran into
these languages because I was _ACTIVELY_ looking for languages,
this is the same reason I ran into Haskell (my favorite language).
Consider the average programmer who does not actively look for
new languages, but sits on her/his tail until some organization
hypes a marginal package as The Next Big Thing(tm), and then
proceeds to swallow it up. That's how crappy products become
big. That's the story of Tcl.
Many of the programmers I spoke with have very little if any knowledge
about the above languages, how can you even claim that they prefer
the languages they are using over the above ones?
Furthermore remember that most programmers program in the language
mandated by their employers -- I am the same way. We don't have
a choice most of the time.
: But they didn't. If you
: want to know the truth, I think you need to stop making superficial excuses
: and ask deeper semantic questions.
I think you need to wake up and smell the coffee. There are numerous
reasons why these superior languages were not chosen, the fact that
you are grasping at one flimsy reason does nothing but make one wonder
if you even have a clue.
: There really is something better about
: each of these "ugly languages" that gives them an advantage over the "good"
: languages; I'll leave it up to you to figure out what it is.
Let's see, C became popular for one reason only -- it was almost
mandatory for programming under Unix which was widespread (and
still is). So C rode on the coattails of an operating system, and
was not chosen on any virtue of the language itself. C++ is
popular for one reason only -- it isn't a far step away from C which
means that the C crowd flock to it in safety. So C++ rode on the
coattails of C which rode on the coattails of Unix.
Perl I could give some credit for -- it is a powerful tool although
its resemblence to shell scripting is still an issue which I feel
has helped it gain more acceptance. It's a lot easier to accept
something that looks familiar than something that looks foreign
(which explains why Lisp languages and Smalltalk didn't gain the
following that C and C++ did).
As for Tcl, it's there for one reason and one reason only -- strong
corporate backing. We've got a powerful company that wants to
make a quick buck and therefore is using its clout to force
Tcl down our throats. This is the same tactic used by charlatans
like Micro$oft. Indeed that's the only possible explanation
as to why a glorified text preprocessor would even get a second
look -- that and the fact that it is riding on the coattails
of Tk.
Try to come up with some arguments next time.
--
Cya,
Ahmed
From: Jete Software Inc.
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ijkfo$ice@DGS.dgsys.com>
In article <··········@Masala.CC.UH.EDU>,
········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
>John Ousterhout (······@tcl.eng.sun.com) wrote:
>: In article <·············@maths.anu.edu.au>, Graham Matthews <···············@maths.anu.edu.au> writes:
>: |>
>
>As for Tcl, it's there for one reason and one reason only -- strong
>corporate backing. We've got a powerful company that wants to
>make a quick buck and therefore is using its clout to force
>Tcl down our throats. This is the same tactic used by charlatans
>like Micro$oft. Indeed that's the only possible explanation
>as to why a glorified text preprocessor would even get a second
>look -- that and the fact that it is riding on the coattails
>of Tk.
>
The beginning of your story was pretty good, but you have run into
some serious plot problems right here.
I am an independent developer (so I was correctly free to choose
any language that I wished). I choose Tcl simply because at that time
it was the only thing that interefaced to TK. At that point in time,
Sun wasn't in the picture. I still use it, because it still has the
most extensive support (interfaces to largest number of extensions,
earliest support for new features) for TK than any other language.
Strong corporate backing is irrelevant!! Except if you believe in
large conspiracy theories than it is a necessity.
-- Norman
From: marduk
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5iki55$m98$2@news2.gte.net>
Why does everyone insist on crossposting to every damn newsgroup in
existance?
--
Fights between cats and dogs are prohibited by statute in Barber, North
Carolina.
With a mighty <············@news2.gte.net>,
······@gte.net uttered these wise words...
> Why does everyone insist on crossposting to every damn newsgroup in
> existance?
I wish I knew. Memetic drift? Competing memes might explain massive
crossposting, along with many (other) non-rational behaviours.
What I wonder why you set your followups to alt.test without warning
anyone? This could be interpreted as a non-rational behaviour, similar
to spamming with forged headers, and other malicious tricks. Did you
hope to derail this thread? Why? What could you gain that a killfile
can't accomplish far more effectively?
I wish I knew...
--
<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: Hume Smith
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ilefr$jdq@news.istar.ca>
>In article <··········@Masala.CC.UH.EDU>,
>········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
>>As for Tcl, it's there for one reason and one reason only -- strong
>>corporate backing. We've got a powerful company that wants to
>>make a quick buck and therefore is using its clout to force
>>Tcl down our throats. This is the same tactic used by charlatans
>>like Micro$oft. Indeed that's the only possible explanation
>>as to why a glorified text preprocessor would even get a second
>>look -- that and the fact that it is riding on the coattails
>>of Tk.
put "Java" instead of "Tcl", and you'd be right. the fact is, Tcl existed
before Tk, and was used long before Sun took it up (i never have figured out
why Sun got so interested in it, actually, especially considering JO demanded
they had to keep the core non-proprietary). i would say, that by far the most
significant thing Sun has done for Tcl is fund and coordinate the multiplatform
work - neither the language nor its builtin commands have been changed
significantly under Sun; Sun in no sense "made" Tcl. (oh, i guess i forgot the
BC; probably because i'm still too timid to try it :)
Sun did not force Tcl down my throat - in fact i was scared of what would
happen to Tcl with Sun in on it. so far it has *not* lived down to my worst
fears :) i did start using Tcl because of Tk - i was looking for something
with which to write for X - but most of my use lately has been non-Tk stuff.
(trimmed F-ups)
> As for Tcl, it's there for one reason and one reason only -- strong
> corporate backing. We've got a powerful company that wants to
> make a quick buck and therefore is using its clout to force
> Tcl down our throats. This is the same tactic used by charlatans
> like Micro$oft. Indeed that's the only possible explanation
> as to why a glorified text preprocessor would even get a second
> look -- that and the fact that it is riding on the coattails
> of Tk.
Many people, myself included, started using tcl/tk before Sun took it
up. Remember that this is a free tool, which for my purposes is very
important. The current corporate backing is certainly seeking to
extend the user base of tcl/tk but, I would imagine, a vast proportion
of the current code base would still be there if Sun hadn't taken over.
My own decision to use tcl was based on easy embedding in my code and
the presence of Tk. I'm no great fan of the language but it is wrong
to compare Sun with Microsoft in this manner -- microsoft is unlikely
to give you the source of VB or port it to unix.
--
Steve Cassidy
Speech, Hearing and Language Research Center
School of English Linguistics and Media
Tel: +61 2 9850 8729 Macquarie University
Fax: +61 2 9850 8240 North Ryde,NSW, 2109
·····@srsuna.shlrc.mq.edu.au Australia
http://srsuna.shlrc.mq.edu.au/~steve
From: ·······@cas.org
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5iilog$kd1@srv13s4.cas.org>
:> As for Tcl, it's there for one reason and one reason only -- strong
:> corporate backing. We've got a powerful company that wants to
The only strong corporate backing that I have seen has been from the
corporations using Tcl as a part of their products. Well, Sun continues
to pay the Tcl/Tk development team's salary, and for a couple of weeks
put 5 or 6 web pages up on their main corporate web site. That's been,
to date, about the extent of Sun's backing.
:> make a quick buck and therefore is using its clout to force
I don't know too many corporations still around who are only interested
in a slow buck. Got to some how pay those high salaried engineers,
the electricity for their computers, etc.
:> Tcl down our throats. This is the same tactic used by charlatans
Wow! I really feel for you. I myself typically have quite a tough time
finding a Sun employee other than the Tcl team itself who has even heard
much of Tcl - you have them coming to your office and force feeding the
language to you!
:> like Micro$oft. Indeed that's the only possible explanation
:> as to why a glorified text preprocessor would even get a second
:> look -- that and the fact that it is riding on the coattails
:> of Tk.
Hmm - seems like lots of folk have given that text preprocessor more than
just a second look. It's so sad to see techie cults like comp.lang.tcl
continue unchecked.
--
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: M. Prasad
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334CD665.186E@not4u.polaroid.com>
········@bayou.uh.edu wrote:
> Let's see, C became popular for one reason only -- it was almost
> mandatory for programming under Unix which was widespread (and
When C became popular, the other major choices were Pascal, Fortran,
Basic, and at some places, Lisp. Pascal suffered from numerous
problems for writing large programs. All of these problems
were solved by the compiler vendors, but you had to learn the
particular solutions for each compiler you had to use. Fortran was
ok, but typos were a big nuiscance, and at the time it wasn't
structured. Basic was not useful for serious programming.
Lisp at the time was not very useful for systems
programming, and no standards existed. Smalltalk was
not available and when available was unusably slow.
So the rise of C happened because it was the best
language available for practical reasons. It may
have had something to with Unix, but this doesn't
explain why it also became the language of choice
on systems such as VAX/VMS (where the vendor was
actively pushing a language called Bliss for all systems
programming.)
A similar pheonomenon occurred in the PC world, which was
taken over by C. This was quite a surprising occurence for
the PC world. In early 80's, BYTE magazine covered
all languages it thought would be useful for the PC.
Smalltalk was deemed so important that it later on got
an article all to itself. C, somehow or the other,
didn't quite make it in the list of BYTE's languages.
The clear winner according to BYTE magazine was Pascal.
Yet by late 80's, most of PC programming had moved from
Pascal, Assembly and Basic to C and C++. The primary
reasons may have been the ability to do hardware manipulation
and memory accesses directly from C, thus saving the
programmer from having to use Assembly when speed was
not a concern.
So hype or the lack of it doesn't quite do it. People
choose languages for their own very sane reasons. Arguing
abilities and debating tricks of adherents have not proven
to be very effective, otherwise Lisp would be the most
widely used language today. It's not as if multi-million
dollar companies did not exist at one time to promote
Lisp. It's also not as if they lacked promotional
abilities or dedicated champions.
From: Bert Robbins
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334D599C.742F@pls.com>
M. Prasad wrote:
>
> ········@bayou.uh.edu wrote:
>
> > Let's see, C became popular for one reason only -- it was almost
> > mandatory for programming under Unix which was widespread (and
>
> When C became popular, the other major choices were Pascal, Fortran,
> Basic, and at some places, Lisp.
I think that a large factor that contributed to the C language
becomming so popular and being the language of choice for
development was due to the tremendous number of poeple that
were turned out by the colleges and universities that had
experience with C.
AT&T/Bell Labs, when they still owned Unix, did a good job of
giving away source code to educational institutions in the late
seventies and early eighties. The educational institutions
therefore had all of these free computers with source code
to the OS to use in teaching CS to their students. With C
being the language that came with the OS, not to mention
that a majority of the OS was written in C, the were somewhat
forced to teach C.
The smart compaines jumped on the C bandwagon, rightly or
wrongly, and started to produce software written in C due
to the large labor pool that had been schooled in C which
resulted in the new hires being productive almost immediately
rather than having to train them on the companies preferred
language.
Blasphemy Alert:
Cobol is the most widely used language with the greatest
number of lines of code and programmers. If any language
can be described as the best language, based on commercial
success, then Cobol is the winner hands down.
And don't try to through the Cobol is wordy and simplistic
argument around. If you take a good hard look at the programs
and how the are customarily written these days you will find
that the lines of code is a good measure to use to compare
how much code has been written for both languages.
Blasphemy Completed.
Long live Perl!
--
Bert Robbins
From: M. Prasad
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334E58FE.7B82@not4u.polaroid.com>
Bert Robbins wrote:
>
> I think that a large factor that contributed to the C language
> becomming so popular and being the language of choice for
> development was due to the tremendous number of poeple that
> were turned out by the colleges and universities that had
> experience with C.
I don't think so -- at first Pascal was the big wave at
colleges and universities in the wake of "Goto-less
programming". C took over from Pascal, slowly.
They often _chose_ to change a course being
taught in Pascal/Fortran or Assembly, to C. I
recall when an "introduction to systems programming"
course at my university started getting taught in C
instead of the assembly language it was traditionally
taught it. I am sure the teachers would have considered
Pascal for it if they could have. Teaching in assembly is
not very efficient, only necessary sometimes.
But using Pascal or Fortran just wasn't feasible.
The desire here was not C per se, but just getting
away from assembly. C happened to provide a
real alternative to assembly. And it happened
to be the only real alternative. Hence
the popularity.
From: Roy Smith
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5im818$v0n$1@news.nyu.edu>
·······@not4u.polaroid.com writes:
> C happened to provide a real alternative to assembly.
There are some who claim that C is just a nice high-level assembler. I used
to use it that way when I was writing 6800 (not 68000) code. I would write
my programs in simple-minded C, then hand-compile it into 6800 ASM.
--
Roy Smith <···@popmail.med.nyu.edu>
New York University School of Medicine
Copyright 1997 Roy Smith
For-profit redistribution prohibited
From: Erik Naggum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3069759746565482@naggum.no>
* Bert Robbins
| AT&T/Bell Labs, when they still owned Unix, did a good job of giving away
| source code to educational institutions in the late seventies and early
| eighties.
really? when AT&T/Bell Labs sent out the famous tapes, they had four
requirements imposed on the agreement:
NO ADVERTISING
NO SUPPORT
NO BUG FIXES
PAYMENT IN ADVANCE
this pretty much built the foundation for Unix user groups, and thus grew
the popularity of Unix -- no thanks to AT&T. in fact, AT&T's lawyers
didn't want to license Unix out at all at the time, but felt they had to
because of their legal battles and the antitrust suits that were in the
budding. we can blame the divestiture for the spread of Unix.
| The smart compaines jumped on the C bandwagon, ...
this seems at least as dubious as your first claim.
| Long live Perl!
and this more than any...
#\Erik
--
I'm no longer young enough to know everything.
M. Prasad <·······@not4u.polaroid.com> wrote in article
<·············@not4u.polaroid.com>...
> So hype or the lack of it doesn't quite do it.
Hype alone won't make an intelligent shopper buy, but without some form of
hype, the shopper needs to be quite a scrounger to even locate the
"product". In an ideal world, perhaps all products would be evaluated
fairly, but this world is no one's ideal.
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: <334D2FE5.4F53@not4u.polaroid.com>
Bill House wrote:
>
> M. Prasad <·······@not4u.polaroid.com> wrote in article
> <·············@not4u.polaroid.com>...
>
> > So hype or the lack of it doesn't quite do it.
>
> Hype alone won't make an intelligent shopper buy, but without some form of
> hype, the shopper needs to be quite a scrounger to even locate the
> "product". In an ideal world, perhaps all products would be evaluated
> fairly, but this world is no one's ideal.
I am sure there have to be mechanisms to make the product
available to the users. In the case of C, AT&T's cheap
Unix licenses certainly must have helped. However, of
all the choices which did have the good luck to get
out there, the ones which do survive well, must have some
strong contributing reasons.
I don't think AT&T did any serious marketing of C.
They just let it get out there. At least that
is my impression, since I was in the field when
C was starting to get popular -- I already knew
Fortran, Pascal, Lisp and APL before I heard
of a language called C. So I knew there were
very good personally validated reasons for me
to prefer C over, say, Pascal. Developing
multiple-module programs in Pascal could be
quite a pain. By the time somebody asked my
opinion about which language to use for a serious
product development effort, I had already had to
learn three different Pascals, with their own ways
to handle modularity and their own "use variant,
write integer, read pointer" type tricks that were
forced in systems programming. So I had no
hesitation in answering -- "C". No hype from AT&T
was required.
I am sure my personal experiences were repeated
over and over, resulting in many different
projects choosing to use C. What is more,
those who saw C projects succeeding where
others floundered, made their own conclusions.
These conclusions and successes are much
more powerful than any amount of arguments.
From: Andrew Koenig
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <E8H3sq.Jt6@research.att.com>
In article <··························@wjh_dell_133.dazsi.com> "Bill House" <······@dazsi.com> writes:
> Hype alone won't make an intelligent shopper buy, ...
But hype alone will sometimes make the intelligent shopper's boss' boss buy,
which is the same thing from the hype merchant's viewpoint.
I've seen the phenomenon in action as long as I've been involved
in computing, which is more than a quarter century at this point.
It applies equally to hardware, software, languages, tools, and
methodologies.
--
--Andrew Koenig
···@research.att.com
http://www.research.att.com/info/ark
From: Henry Baker
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <hbaker-1104970841520001@10.0.2.1>
In article <··········@research.att.com>, ···@research.att.com (Andrew
Koenig) wrote:
> In article <··························@wjh_dell_133.dazsi.com> "Bill
House" <······@dazsi.com> writes:
> > Hype alone won't make an intelligent shopper buy, ...
>
> But hype alone will sometimes make the intelligent shopper's boss' boss buy,
> which is the same thing from the hype merchant's viewpoint.
>
> I've seen the phenomenon in action as long as I've been involved
> in computing, which is more than a quarter century at this point.
> It applies equally to hardware, software, languages, tools, and
> methodologies.
Amen!
Dogfood: That which a dog eats, but his master buys.
From: David Hanley
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334E8E59.6AFD@nospan.netright.com>
Henry Baker wrote:
>
> In article <··········@research.att.com>, ···@research.att.com (Andrew
> Koenig) wrote:
> > In article <··························@wjh_dell_133.dazsi.com> "Bill
> House" <······@dazsi.com> writes:
> > > Hype alone won't make an intelligent shopper buy, ...
> >
> > But hype alone will sometimes make the intelligent shopper's boss' boss buy,
> > which is the same thing from the hype merchant's viewpoint.
> >
> > I've seen the phenomenon in action as long as I've been involved
> > in computing, which is more than a quarter century at this point.
> > It applies equally to hardware, software, languages, tools, and
> > methodologies.
>
> Amen!
>
> Dogfood: That which a dog eats, but his master buys.
Sorry, But I'm a developer, and I picked my development language,
enviornemnt and tools, all by my lonesome.
dave
With a mighty <·············@nospan.netright.com>,
·····@nospan.netright.com uttered these wise words...
> Sorry, But I'm a developer, and I picked my development language,
> enviornemnt and tools, all by my lonesome.
Good for you! My employer picked VB, Java, and C++. I'm currently
compromising, by using Java. My first choice is Lisp, but it isn't on
the list. Nor is Tcl, for the same reasons.
I don't think that this is unusual, but please let me know if it is.
--
<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: Andrew P. Mullhaupt
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334FAFE2.8AD@ix.netcom.com>
Cyber Surfer wrote:
>
> With a mighty <·············@nospan.netright.com>,
> ·····@nospan.netright.com uttered these wise words...
>
> > Sorry, But I'm a developer, and I picked my development language,
> > enviornemnt and tools, all by my lonesome.
>
> Good for you! My employer picked VB, Java, and C++. I'm currently
> compromising, by using Java. My first choice is Lisp, but it isn't on
> the list. Nor is Tcl, for the same reasons.
>
> I don't think that this is unusual, but please let me know if it is.
Lots of programmers find themselves constrained by the employer's choice
of language. A choice which is frequently insane and regrettable.
In case anyone wonders out there how employers think, I'll give myself
as an example.
We are a real-time trading organization with a lot of technology
leverage and a lot of programming chores which need to be done on the
fly. But we also carry out very high performance scientific
computations. I happen to be the guy who gets to pick the languages, and
the programmers report to me. I also happen to be the guy who develops
the high performance scientific computations, so there are research
types (who _think_ they can write code, but, uh, well, ...right). The
research types also report to me.
So if I felt like it, I could have everyone program in GOTRAN II.
But, since I'm trying to make things go, I don't pick the languages, I
_suggest_ them. Like, a couple years ago I thought it would be good to
see if Tcl/TK/expect was a good choice, so I had a programmer learn it
and decide if it was useful. It turned out to be much better than C++
(which was his original idea) so he uses Tcl/TK/expect for our entire
trading system interface. We still have some stuff in C, and some shell
scripts, but Tcl/TK/expect basically took over the user interface world.
In the research side, we use S, APL, C, and Fortran. It's a lot better
for me to have the high-priced researchers doing research instead of
learning a new language, so we pretty much let things go all over the
place in research. But when we put stuff into production, we have to cut
the choice down a little. We generally have to re-implement it anyway
(and this turns out to be a _good_ thing more than a _bad_ thing) so
it's not a problem.
As a result, we maintain about 10K or 20K lines or code to do work
similar to that which at one of my previous firms took close to 1M lines
of straight C.
So do I have a "big" project? Except for the number of lines of code,
_yes_, especially since I've seen this type of stuff take close to 1M
lines of C. But by creative and flexible choice of language, we have to
maintain only about 2% of that amount of code, and better yet, only
about half of our code is mission-critical.
So when you wonder if a language "scales" worry more about how the
project might not have to scale in the right choice of language.
Now at the moment, we're looking at whether or not we can consolidate
some of our development by finding a language which can support more of
our common needs between research and production, and among other
candidates, Python with Numerical Extensions is the reason I participate
in this newsgroup. I started a few months ago, and about three of us are
looking into this possibility. I expect it will be another three or four
months before we really know if Python is a piece of the puzzle for our
future, and this will be apparent more from if the people who are
already doing the work in other languages choose to defect to Python
more than anything else.
This approach has worked out pretty well, and I would recommend it to
other people.
Later,
Andrew Mullhaupt
Andrew Koenig <···@research.att.com> wrote in article
<··········@research.att.com>...
>
> But hype alone will sometimes make the intelligent shopper's boss' boss
buy,
> which is the same thing from the hype merchant's viewpoint.
>
I particularly hate it when you have a certain evil vendor giving NDA
presentations to management, selling them on application development tools
according to a marketing strategy, with no regard for the technical
practicalities of the so-called solution. This kind of thing has led to a
number of horror stories. Even worse than the cost to projects, which is
somehow never accounted for in the real culprit's debit column, these
activities become a self-fulfilling prophecy of doom for whatever
tool/technology is being sold against -- oh that tool? so-and-so said it
wasn't strategic, so we quit using it. <sigh>
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: Andreas Eder
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <m37miangj6.fsf@laphroig.mch.sni.de>
Bill House writes:
>Hype alone won't make an intelligent shopper buy,
And what about all those not so intelligent shoppers ?
Majority rules, you know.
Andreas
Andreas Eder <···@laphroig.mch.sni.de> wrote in article
<··············@laphroig.mch.sni.de>...
>
> And what about all those not so intelligent shoppers ?
> Majority rules, you know.
>
Which is why it ought to be important that good technology gets some kind
of market awareness, even if it's word of mouth. Unfortunately, the world
is still mostly divided into incompatible platforms, so a technology can be
20 years old in one place and yet-to-be commercialized for the first time
in another.
Of course, the Web and related technologies are lessening that
fracturization. We'll probably see a lot more competitive evolution in
languages as time goes on. Browser-based delivery of language-execution
engines should not remain Java-specific, but should allow many languages to
serve specialized domains on a common, cross-platform environment.
Bill House
--
······@dazsi.com
http://www.dazsi.com
From: Mike Haertel
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <slrn5kqbj5.b2n.mike@ducky.net>
In article <··········@Masala.CC.UH.EDU>, ········@bayou.uh.edu wrote:
>As for Tcl, it's there for one reason and one reason only -- strong
>corporate backing.
Tcl rose to prominence long before Ousterhout ever joined Sun.
It is just as much of a "grass roots" language as perl or python.
There are indeed many things to criticize about Tcl, but before
you start slinging stones and arrows you should at least get
your facts right.
--
Mike Haertel <····@ducky.net>
From: John Ousterhout
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5ilnmp$rg9@engnews2.Eng.Sun.COM>
In article <··········@Masala.CC.UH.EDU>, ········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
|> ...
|>
|> As for Tcl, it's there for one reason and one reason only -- strong
|> corporate backing. We've got a powerful company that wants to
|> make a quick buck and therefore is using its clout to force
|> Tcl down our throats. This is the same tactic used by charlatans
|> like Micro$oft. Indeed that's the only possible explanation
|> as to why a glorified text preprocessor would even get a second
|> look -- that and the fact that it is riding on the coattails
|> of Tk.
Sorry for taking so long to respond to this comment, but I couldn't stop
laughing long enough to compose a response. I wish your accusation were
true, but I'm afraid you are a bit out of touch. Apparently you haven't
heard of a language called Java, which is the main thing Sun is pushing
these days? We're a small player in comparison. Also, how do you explain
the 100,000 or so people who learned Tcl while I was still a lowly
professor at Berkeley? Was that just a powerful university trying to
make a quick buck and using its clout to force Tcl down people's throats?
OK, enough is enough. I can see that I'm not going to be able to fool you
guys. I confess everything. You're right. It all *was* an evil
conspiracy. There really isn't a shred of merit in Tcl, or C++, or Perl,
or C; there is not a single reason on earth why anyone should use any of
these languages for any programming task. Scheme truly is the perfect
language that solves every problem and combines the virtues of every
other language. For years we've been plotting to trick programmers into
using bad languages. Yes, I mean "we". Many many people have participated
in this sinister plot, including Larry Wall, Dennis Ritchie, Bill Gates,
the Bureau of ATF, most of the LAPD, and Mark Fuhrman (sorry you guys, but
the truth has overwhelmed me so I've been forced to expose you). I feel
just terrible at how I have set the programming world back, and I promise
to be a good boy from now on.
Now that that's over with, you can all get back to work now.
From: Bryan Oakley
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334E7767.63DECDAD@healthcare.com>
John Ousterhout wrote:
> OK, enough is enough. I can see that I'm not going to be able to fool you
> guys. I confess everything. You're right. It all *was* an evil
> conspiracy. There really isn't a shred of merit in Tcl, or C++, or Perl,
> or C; there is not a single reason on earth why anyone should use any of
> these languages for any programming task. Scheme truly is the perfect
> language that solves every problem and combines the virtues of every
> other language. For years we've been plotting to trick programmers into
> using bad languages. Yes, I mean "we". Many many people have participated
> in this sinister plot, including Larry Wall, Dennis Ritchie, Bill Gates,
> the Bureau of ATF, most of the LAPD, and Mark Fuhrman (sorry you guys, but
> the truth has overwhelmed me so I've been forced to expose you). I feel
> just terrible at how I have set the programming world back, and I promise
> to be a good boy from now on.
>
> Now that that's over with, you can all get back to work now.
BRAVO!
--
Bryan Oakley ·············@healthcare.com
Software Engineer http://www1.clearlight.com/~oakley/
Healthcare Communications, Inc. http://www.healthcare.com/
From: John Shen
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <yuhsp0xjst2.fsf@cnet.com>
-----BEGIN PGP SIGNED MESSAGE-----
······@tcl.eng.sun.com (John Ousterhout) writes:
> OK, enough is enough. I can see that I'm not going to be able to fool you
> guys. I confess everything. You're right. It all *was* an evil
> conspiracy. There really isn't a shred of merit in Tcl, or C++, or Perl,
> or C; there is not a single reason on earth why anyone should use any of
> these languages for any programming task. Scheme truly is the perfect
> language that solves every problem and combines the virtues of every
> other language. For years we've been plotting to trick programmers into
> using bad languages. Yes, I mean "we". Many many people have participated
> in this sinister plot, including Larry Wall, Dennis Ritchie, Bill Gates,
> the Bureau of ATF, most of the LAPD, and Mark Fuhrman (sorry you guys, but
> the truth has overwhelmed me so I've been forced to expose you). I feel
> just terrible at how I have set the programming world back, and I promise
> to be a good boy from now on.
>
> Now that that's over with, you can all get back to work now.
Dear Professor O,
I hope you are just trying to be hilariously humorous in an emotional
argument to lighten up everyone, not really overwhelmed by the
personal attacks which are quite normal around the net (unless you are
too busy and seldom have time to stay long enough to witness that,
which I suspect being the case). I tend to think they are a normal
part of the cyberlife, whether we like it or not. Please get back to
doing your good work and gently ignore them. Also, when you are now
working for a company with clout and commercial interests in seeing
certain tools/languages succeed, suspicions (minus the ad hominim
part) that you have a mercurial motives are actually healthy and do
help us avoid being "taken" by hypes and infomercials.
I must say that your paper (which undoubtedly can be improved in many
ways) truly has had an enormous impact on all the programmers/project
leaders as I have not seen that much discussions on any other topic
recently in so many programming groups. This alone should hopefully
motivate all us of to read and think carefully about what you have
written, and give you more reason to follow up the topic with more
rigorous and convincing results and demonstrations. Languages like
Perl and Tcl (well, I cannot help putting Perl ahead of Tcl :-) have
been looked down upon by some as tools to craft quick-and-dirty
solutions, yet their successes in mission-critical projects
contradicts such views (actually they can be used for the full
spectrum from q&d to enterprise-level applications, which is the
beauty of it all). Your research and explanation will help such
successes, so please do continue, for the good of the community,
please say yes.
john
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: http://www.ifcss.org/~zshen/ faith,hope,love http://www.cnet.com/
iQB1AwUBM06IYTagfthcdazpAQE5sQL/TaHv5E+ZFa0ex1zoTfYAIdVNt+RFIGFe
wNhdsJmCoxn/kYQKmXwrmEicAo6O0nxTj5iWlpCPgPKEjaKcmLbzDmvaDtbxkJqk
lW3WPS/1LmCmQnt8oMcNVh87TYtXigBp
=m8xn
-----END PGP SIGNATURE-----
In article <················@news.sydney.apana.org.au>,
<····@gco.apana.org.au> wrote:
>
>{ courtesy copy emailed to ······@tcl.eng.sun.com , ·····@cnet.com}
>---------------------------------------------------------------------------------------------------------
>Someone who claimed to be John Shen <·····@cnet.com> wrote:
>>Dear Professor O,
>> Please get back to doing your good work and gently ignore them.
>>I must say that your paper (which undoubtedly can be improved in many
>>ways) truly has had an enormous impact on all the programmers/project
>>leaders as I have not seen that much discussions on any other topic
>>recently in so many programming groups.
>
>I personally was favorably affected by Prof O's paper.
>Sure, it may not be a literary or a CS masterpiece, but it certainly
>provided food for thought.
Tastes vary. Many of us already knew the almost all of the stuff in the
whitepaper, had questions about them, and were left unsatisfied, or
even with a bad taste in their mouths.
Ousterhout's notion of "scripting" vs. "systems" programming is a
very limitied view, and many of us think it's not right---there
can be languages that can be good for both "systems" and "applications"
programs, and there are languages that can be good for both "applications"
and "systems" programming. Unfortunately, the split that Ousterhout
has chosen just happens to be the one that makes Tcl look best.
It's also the one that appeals to C programmers, who are sick to
death of using a systems programming language as an applications
programming language. Mightn't it be better to use a convenient,
interactive language most of the time, and only write the most
time-critical or system-dependent code in C?
It's interesting that many Tcl programmers are using Tcl as one could
Lisp or Smalltalk. They're not hitting themselves in the head with a
big rock (C development style) as often as they used to. Instead
they're hitting themselves with a smaller rock (Tcl's limitations)
most of the time. In some sense, Lisp has won, after being shunned
by macho C programmers for so long. ("We don't need no steenking
command-loop, we've got compilers! And we write FAST code!")
Often the reason that Tcl seems like the right language for the job,
even one it's not designed for, is just that C is the wrong language
for the job.
>>Languages like
>>Perl and Tcl (well, I cannot help putting Perl ahead of Tcl :-) have
>>been looked down upon by some as tools to craft quick-and-dirty
>>solutions, yet their successes in mission-critical projects
>>contradicts such views (actually they can be used for the full
>>spectrum from q&d to enterprise-level applications, which is the
>>beauty of it all).
As I've said before, languages like Tcl should in fact embarrass the
academic programming languages community, which has generally had
tunnel vision with respect to gluing.
>His clear accounts of the gluing vs systems programming paradigms
>were "worth the price of admission ".
I think that the general idea has some truth to it, but Ousterhout
presents it in such a way that it misleads many of his readers.
Mostly by omission, he makes it sound as though the design of Tcl
followed rationally from the problem domain, which many knowledgeable
people doubt. Some of the language features are obviously a good
idea, but the guts of the language seem poorly motivated.
I, for one, had hoped we could get to a point where we'd talk about
design choices in programming languages, and how they'd interact,
rather than just flaming back and forth about whose language was
better.
>Perhaps he didn't mention your or my currently favorite languages, (
>eg: Perl in your case, Python in mine ) but that was not the point of
>the paper.
No, it wasn't, but he also didn't mention programming language design
alternatives, such as lexical scope, conventional dynamic typing,
closures, objects, and garbage collection. People have been doing
scripting of some sort in languages with various combinations
of those features for a very long time. Are they irrelevant?
By neglecting to mention language *ideas* that are relevant, as
well as seminal languages, and by strongly pushing a false dichotomy,
Ousterhout wrote a paper that sounded to some people like more biased
marketing hype rather than interesting discussion of important issues.
If Ousterhout had taken the line that "Tcl is a warty, limited
language, but it has momentum so let's go with it," fewer people
would have objected. But by what he stresses, and omission, he
makes Tcl sound better than it is, and like it has not only
momentum but righteousness. He stakes out the ground of a good
language designer who's invented a New Kind of Language.
>Read, learn and move on....
Exactly. But to learn what's important, you have to understand
basic things, so that you can compare them properly, and know
what lessons to take with you.
I'm a language designer, and I don't know what to make of Tcl.
I think Ousterhout's a very smart guy, and I have immense respect
for much of his work in other areas. When it comes to Tcl,
though, I often can't distinguish between his technical smarts
and his marketing smarts. I don't know what to learn from Tcl
other than that "Tk and glue are real handy."
Arguments from popularity and size of extant programs can have
some merit, but remember that there are programs in COBOL that are
millions of lines long, and that well after UNIX became fairly
popular, MS-DOS was by far the most popular OS in the world.
None of that convinces me that COBOL and MS-DOS are Good Things.
The fact that it's possible to use something for a nontrivial
task doesn't make it a good idea. The fact that many people do so
doesn't make it a good idea, either.
Simple personal testimonials don't quite cut it---unless there is a
description of the advantages of that tool, and *how* the tool works
well when you'd think it'd be lacking a crucial feature. An argument
like "we don't need no steenking records, because I wrote 100,000
lines of Tcl and it worked!" The same goes for millions of lines of
COBOL and FORTRAN, and IBM 360 assembler. Unless we're told how
it was done, and why doing it that way is better than doing it some
seemingly better way, we don't know how to learn from it.
--
| 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/)
> ······@cs.utexas.edu (Paul Wilson):
> Often the reason that Tcl seems like the right language for the job,
> even one it's not designed for, is just that C is the wrong language
> for the job.
Excellent Observation. That pretty much sums up this whole
Ousterhout's paper/TCL/Script/System topic!
-Kelly Murray ···@franz.com
P.S. Don't get me wrong, C is a great language! ...for implementing UNIX.
From: Charles Lin
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5imkr2$l1o@mimsy.cs.umd.edu>
John Ousterhout (······@tcl.eng.sun.com) wrote:
[...]
|| OK, enough is enough. I can see that I'm not going to be able to fool you
|| guys. I confess everything. You're right. It all *was* an evil
|| conspiracy. There really isn't a shred of merit in Tcl, or C++, or Perl,
|| or C; there is not a single reason on earth why anyone should use any of
|| these languages for any programming task. Scheme truly is the perfect
|| language that solves every problem and combines the virtues of every
|| other language. For years we've been plotting to trick programmers into
|| using bad languages. Yes, I mean "we". Many many people have participated
|| in this sinister plot, including Larry Wall, Dennis Ritchie, Bill Gates,
|| the Bureau of ATF, most of the LAPD, and Mark Fuhrman (sorry you guys, but
|| the truth has overwhelmed me so I've been forced to expose you). I feel
|| just terrible at how I have set the programming world back, and I promise
|| to be a good boy from now on.
And suddenly, we're going to see this quote in the preface
of every Scheme book out there. All 3 of them.
--
Charles Lin
····@cs.umd.edu
With a mighty <··········@mimsy.cs.umd.edu>,
····@cs.umd.edu uttered these wise words...
> And suddenly, we're going to see this quote in the preface
> of every Scheme book out there. All 3 of them.
Hey, you only need _one_. My choice would be SICP, but it could easily
be a personal thing. For C, as far as I'm concerned there's only one
book, and that's the _1st edition_ of K&R. The 2nd ed. lost too many
important nuggests of wisdom, despite the gain of a few gems. It's a
tough choice, but I'd rather have the extra warnings and tips.
Still, YMMV, and I expect it does. I'd worry if there was only _one_
way of looking at things, so Your Mileage _Should_ Vary. This is the
way in which memes adapt and evolve in a changing world.
BTW, I added JO's quote to my Tcl page. ;)
--
<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".
With a mighty <···············@aimnet.com>,
······@nohost.nodomain uttered these wise words...
> Many people don't care about learning programming at the level of
> SICP; they simply want to get some particular problem done quickly.
> You may frown on them, but hands-on books like "Learn XYZ in 21 Days",
> "Writing CGI Scripts in XYZ", "Neural Networks in XYZ", "Database
> Programming in XYZ", and "GUI Apps in XYZ" are very useful to lots
> of people.
Yes, most people won't be as interested as I am in comiler theory.
That's one of those YMMV type things. The same goes for every other
kind of tutorial, which is why I mentioned K&R. Not everyone will
appreciate the difference between integers and pointes, so a book that
makes that point clear _may_ be better than another, which lets a
programmer think that tricks with pointers may be more "portable" than
they at first seem.
Some programmers might not be concerned with writing portable code at
all! However, I've used enough C compilers on enough different
machines to appreciate this issue. Even when you know which CPU and OS
you're using, and the compiler vendor, changes in the language itself
can trip you up. It's not for nothing that the C++ compiler I've use
most during the last year will give you "new behaviour" warnings, when
you give it code that earlier versions of the same compiler just
accepted without comment.
> Since I write software that is used by other people, the existence of
> such books is an important consideration when picking an extension
> language, because it saves me considerable time when documenting what
> I did when I can simply point at existing books for a lot of the
> functionality.
If I had the time, I'd write a "Lisp for Dummies" book. At least, I'd
attempt it. The result probably wouldn't get published, as I doubt
that I can communicate at that kind of level - not without a dummy to
test it on. Still, if I did do it, and failed, I could just put the
text in my homepage, where anyone can read it.
CGI scripts...now there's something I can write about. I might even be
able to find some "dummies" to proof read it - if I can pursuade them
to find the time. Alas, these are the people least likely to believe
that they _have_ the time for such things, and they won't know
otherwise until they read it, assuming that it _is_ readable etc.
Hmm. Watch this space...
--
<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 <················@netcom.com>, ······@netcom.com (Will Hartung)
wrote:
> ······@abwillms.demon.co.uk (Alaric B. Williams) writes:
...deleted lots of good things
>
> Most programmers, especially in smaller companies and in the smaller
> organizations within large companies, are mechanics. They are given a
> problem, and they start looking for tools to solve the problem. They
> see something like MS Access that seems to do 80% of the problem. The
Most programmers I know that fits this description never look for tools.
They have Mirosoft Office, VB (and maybe VC++). If it can't be done with
these, it is impossible to do.
--
Best Wishes, Bengt
Email: ······@damek.kth.se
With a mighty <·······················@sl54.modempool.kth.se>,
······@damek.kth.se uttered these wise words...
> Most programmers I know that fits this description never look for tools.
> They have Mirosoft Office, VB (and maybe VC++). If it can't be done with
> these, it is impossible to do.
If you added Java, then I could say the same thing. Even when they
admit that something else _could_ do it, they find some way to justify
not using it. E.g. "nobody here knows how to use that" or "not enough
people here know how to use that, it's too risky".
Is it possible to get fired for using C++? Are C++/VB/Java so popular
for the same reason that Smith is a popular surname? Not exactly, I
think, but could there be a similar - but much faster - process at
work? I wonder.
--
<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.
With a mighty <·················@alexandria>,
···@alexandria uttered these wise words...
> In article <·························@news.demon.co.uk> ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>
> > If I had the time, I'd write a "Lisp for Dummies" book. At least, I'd
> > attempt it. The result probably wouldn't get published, as I doubt
>
> Isn't this basically what the "Little Lisper" is?
I've yet to read it, alas, but from what I've read _about_ it, I
suspect this is true. Certainly a number of people who could easily be
described as "sceptics" have made favourable comments about this book.
Yes, it's on my list of "books to get". The trouble is, there are so
many books on that list, and most of them are about Lisp. ;-) Still,
I'll get there someday.
--
<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: Jonathan Guthrie
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j644j$h97$1@news.hal-pc.org>
In comp.lang.scheme Cyber Surfer <············@gubbish.wildcard.demon.co.uk> wrote:
> > > If I had the time, I'd write a "Lisp for Dummies" book. At least, I'd
> > > attempt it. The result probably wouldn't get published, as I doubt
> > Isn't this basically what the "Little Lisper" is?
> I've yet to read it, alas, but from what I've read _about_ it, I
> suspect this is true. Certainly a number of people who could easily be
> described as "sceptics" have made favourable comments about this book.
> Yes, it's on my list of "books to get". The trouble is, there are so
> many books on that list, and most of them are about Lisp. ;-) Still,
> I'll get there someday.
The title is now "The Little Schemer". I recently bought a copy of it
but I'd call it "LISP for nonprogrammers" rather than "LISP for dummies."
It certainly has a light, conversational style all the while it's
introducing concepts like S-expressions and abstraction.
One thing about that book is that you really need to work through it.
One day, I expect to finish working through my copy.
--
Jonathan Guthrie (········@brokersys.com)
Information Broker Systems +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
We sell Internet access and commercial Web space. We also are general
network consultants in the greater Houston area.
With a mighty <················@netcom.com>,
······@netcom.com uttered these wise words...
> They are a really poor way for someone without a "knack" and desire to
> look other places to learn "programming". After someone has finished
> "VB in 21 Days", you don't see them back at the bookshop looking at
> SICP, or Data Structure books, or anything else in the "Advanced
> Computing" section. They find that the book didn't tell them how to do
> what THEY needed to do, so they're out surfing the net looking for VBXs
> and whatnot that they can "plug in". Anybody out their see a "Data
> Structures and Algorithms for VB" book out there?
This is exactly why I think there should a "Lisp for Dummies" book.
> These books do not communicate any concept of abstraction or problem
> solving or CREATING using a computer. They're fill in the blanks, glue
> it together, get it to work types of books.
What they do is promote the VB/C++/Java/Delphi memes. A "Lisp for
Dummies" book would do the same for Lisp memes.
> SICP and its ilk are much more conecptual books. IMHO, "Simply Scheme"
> is one of the better "programming for dummies" books. It's not a
> Scheme book, it's a programming book using Scheme. Like Bertrand
> Meyers "OO Program Construction" is an OOP book, not an Eiffel book.
I agree, it's much closer to what we need to see on the bookshelves.
However, I don't think we should underestimate the value of "dummies",
nor overestimate their ability to recognise a book of quality or a
tool that can help make them more productive.
> But if someone came to me and said "I want to learn to program",
> they'd think I was smoking something if I gave them "Simply Scheme".
> What they REALLY wanted was to balance their checkbook, or try some
> stock market equations or something simpler, like DOOM.
Sadly, yes, this is true. People don't want enlightenment, they just
want tools that satisfy their demands. What they don't want is a whole
knew way of looking at things, which is all too often what Lisp books
(and let's face it, Lisp people) offer them.
> The "CGI progamming in Lisp" would be a bad idea I think. It SOUNDS
> great, but a mechanical book on Lisp does not really leverage off of
> what Lisp REALLY has to offer. Lisp would be a great enabler and a
I don't believe that we can just leap in at the deep end, and start
with what experienced Lisp hackers want to use. Start on some familiar
ground before leading them from the well beaten path, and they might
not need to be lead. CGI is on that path. All I'm proposing is that we
might show how this path is connected to the "Lisp path". This might
help kill the perception of Lisp as a path that leads somewhere that
most people _don't want to go_.
> very productive environment for such a task, but the type of
> people who are generally targeted by such books would use the included
> libraries and macros, and just "use it" rather than "understand it".
So? It's one way begin. In fact, that may have been how I began
treading the Lisp path. I didn't get it immediately, and I don't
expect that most other people will, either.
> The "understand" part is where the leverage comes from, not the using.
Ultimately, yes. You have to have a lot of patience to get that far
down the Lisp path before you reach that point. You may not have
noticed, but most people don't bother to even begin the journey. Why
is that? Could it be that they don't see Lisp as being relevant to
anything they're doing? This is certainly the message that I get from
people who don't know Lisp.
Stop thinking about what an ideal world would be like, coz we don't
have one. Instead, we live in a world full of people who are ignorant
of Lisp, many of them very happy that way.
> While it would, perhaps, give Lisp more exposure to be able to do
> "Real Work", folks would see little difference between it and any
> other CGI tool, because they're after the end result, not the path
> that took them there.
The first battle is to convince people that Lisp is still alive and
well, and fully capable of doing things that they need. I don't think
that books with code for meta-circular evaluators will help do that,
however useful such things may be to experienced Lisp hackers.
> The best possible book that could be published right now, that would
> have a chance of truly highlighting Lisp and its capabilities would be
> something titled like "Building Dynamic, Extensible, High Performance
> Web Servers". Throw a nice blurb on the back about using "trend
> breaking leading edge technology to build and run" web servers. Then,
> when they get to Chapter 2, they find they've been blind-sided with
> CL-HTTPD buried in the tome.
Didn't I say something like that, a little while ago? ;-) Jump on the
Internet bandwagon, before it leaves town!
> Chapter 1 discusses the problems, the challenges, and the inadequacies
> of current implementations. Chapter 2 brings up that dirty, 4 letter
> "L" word, and from there, it's all downhill (or uphill, depending on
> the reader). They'll either stay up all night reading it, or they'll
> throw it across the room screaming "I can't use this!! It's in
> L-L-Lisp! I've been flim-flammed!".
Yup.
> A CL server would (does) show Lisp in the large, where it shines. It
> enables easy use of Lisp for scripting, where it shines. It puts it in
> an application that is in great demand, today. An application that
> tends to need to scale quickly.
Hey, I knew we could find something to agree on. ;)
> This is better than, say, embedding SIOD in Apache (which certainly
> isn't a BAD idea), because SIOD isn't doing anything more than Perl,
> it is just doing it differently.
Yes. It's not enough to be able to do the same things. Lisp has to do
them _better_. Test any Windows developers that you know by describing
the Win32 features of DylanWorks (esp the OLE server bit about
changing the code while it still runs), but don't tell them that it
isn't VB or C++. I bet their reaction will be, "Wow! Where can I get
it?" Start with the Lisp-like features and you'll more likely get a
lot of blank faces.
> Most programmers, especially in smaller companies and in the smaller
> organizations within large companies, are mechanics. They are given a
> problem, and they start looking for tools to solve the problem. They
> see something like MS Access that seems to do 80% of the problem. The
> "21 Days" books are great for these folks, because they are task
> oriented and, hopefully, able to focus their study on their problem.
> They don't care about "Access in the large". The book helps them solve
> their problem by acting as a better reference/users manual than the
> one provided with Access.
I know people like that. I only have to say "Lisp" and they lose
interest in anything I say. What is it about the name that does that?
Whatever kind of historical baggage Lisp implementations may have
lost, there's still _something_ that gets in the way, perhaps
something that might not even be a part of Lisp itself. It could just
be a _perception_ of Lisp.
That kind of baggage may be much harder to lose.
> Of course, incrementally, they discover that their little project has
> escalated into Franken-Code. The "21 Days" books do little to address
> this kind of strategic planning. If they're lucky, they'll be able to
> re-engineer the system.
At which point, a Lisp programmer steps forward...?
> If they're unlucky, they'll have not learned their lesson the first
> time, and go out and get "Sybase in 21 days".
All too likely, IME. A Lisp hacker might say, "I told you this would
happen", or words to that effect, but if no such person is available,
which could easily be the case, then Lisp won't be the alternative
that is tried next. Sybase is more likely, along with a lot of others.
In fact, there are loads of tools that have a higher profile in the
low end of the database world than Lisp.
One of Lisp's great strengths is that it's different. That's also one
of the biggest weaknesses! Meanwhile, the strength of tools like
Access is that it's widly used. That shouldn't be a real strength, but
somehow it is. That's why it's also a great weakness - tool quality
has nothing to do with 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.
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <334EDC93.2376@maths.anu.edu.au>
John Ousterhout wrote:
> OK, enough is enough. I can see that I'm not going to be able to fool you
> guys. I confess everything. You're right. It all *was* an evil
> conspiracy. There really isn't a shred of merit in Tcl, or C++, or Perl,
> or C; there is not a single reason on earth why anyone should use any of
> these languages for any programming task. Scheme truly is the perfect
> language that solves every problem and combines the virtues of every
> other language. For years we've been plotting to trick programmers into
> using bad languages. Yes, I mean "we". Many many people have participated
> in this sinister plot, including Larry Wall, Dennis Ritchie, Bill Gates,
> the Bureau of ATF, most of the LAPD, and Mark Fuhrman (sorry you guys, but
> the truth has overwhelmed me so I've been forced to expose you). I feel
> just terrible at how I have set the programming world back, and I promise
> to be a good boy from now on.
John you overplay your hand. Almost no-one has suggested that there is
no merit in Tcl. What they have suggested is that some of the merits
*you are claiming* are not true. That is a very different claim.
I would like you ask you a question. You claim that the "everything is a
string" approach is the be-all-and-end-all, the way to go, etc, etc. Why
then has Tcl8.0 moved away from this philosophy?
grahm
--
On the streets tonight
The innocent are dying
And the world's not right
So many millions dying
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3353200E.52CD@maths.anu.edu.au>
Graham Matthews <···············@maths.anu.edu.au> wrote:
> [ Replying to JO ]
> > I would like you ask you a question. You claim that the "everything is a
> > string" approach is the be-all-and-end-all, the way to go, etc, etc. Why
> > then has Tcl8.0 moved away from this philosophy?
Donal K. Fellows wrote:
> Semantically it hasn't. It just now has a rather neat behind-the-scenes
> way of caching the results of converting the value from a string into
> something else (like a list or number) in case it gets used like that
> again. You never see this though. It is transparent to the programmer
> (unless you are coding an extension in C and want to use the faster
> programming interface - you don't have to though) and all the user
> sees are (sometines significantly) faster programs.
Ok thats fair enough, but for me it raises another question, a question
that goes to the heart of why people think JO's article is just
advertising hype. Why did JO chose to represent everything as a string?
Why not everything as a number. Why not everything as a list? The latter
question intrigues -- JO claims that the everything as a string paradigm
makes it very easy to glue things together and that this is why Tcl is
so wonderful. Given that a string is just a list of characters you would
have thought that JO would have acknowledged somewhere in the paper that
Lisp can do what Tcl can do just as well, since in Lisp everything is a
list. The fact that JO did not mention this fact is why I think people
consider the white paper to be just marketing. The paper is not
analytical -- it praises Tcl without mentioning that other languages can
do the same kinds of things. An analytical fair paper would have
commented to this effect. A marketing paper of course would not make
such comment. ...
graham
--
Black velvet in that little boy's smile
Black velvet and a soft southern sky
A new religion that'll bring you to your knees
Black velvet, if you please
In article <·············@maths.anu.edu.au>, Graham Matthews
<···············@maths.anu.edu.au> wrote:
> Lisp can do what Tcl can do just as well, since in Lisp everything is a
> list.
Where was the smiley?
Where have you been the last twenty years?
In Lisp is not *everything* a list.
Common Lisp for example has numbers
(diverse floats, fixnum, bignum, complex, ratio),
arrays, characters, hashtables, structures, objects, functions,
cons, symbols, strings, ...
And guess what, they are ****not**** represented as lists.
--
http://www.lavielle.com/~joswig/
With a mighty <·································@news.lavielle.com>,
······@lavielle.com uttered these wise words...
> In Lisp is not *everything* a list.
>
> Common Lisp for example has numbers
> (diverse floats, fixnum, bignum, complex, ratio),
> arrays, characters, hashtables, structures, objects, functions,
> cons, symbols, strings, ...
>
> And guess what, they are ****not**** represented as lists.
This is the point at which we should refer anyone interested to a
reference for Lisp, or at least one of the Lisp dialects. For Common
Lisp, there are a couple to choose from:
<URL:http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html>
<URL:http://www.harlequin.com/books/HyperSpec/FrontMatter/>
For Scheme:
<URL:http://swissnet.ai.mit.edu/~jaffer/r4rs_toc.html>
Locating the Lisp FAQ is left as an exercise for the reader. ;-)
--
<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: Charles Lin
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j0gq5$jbi@mimsy.cs.umd.edu>
Graham Matthews (···············@maths.anu.edu.au) wrote:
|| Ok thats fair enough, but for me it raises another question, a question
|| that goes to the heart of why people think JO's article is just
|| advertising hype. Why did JO chose to represent everything as a string?
|| Why not everything as a number. Why not everything as a list? The latter
[...]
If one had to choose a single type for everything, a string is a
pretty good choice. Why not a number? How would you represent a
string with a number? You can represent a number with a string.
Just put quotes around it. Code can be represented with a string.
Again, put quotes around it. The main thing would be to parse the
string. Should everything be just one type? Obviously not, because
many languages have many types. I don't have an answer to that
for a scripting language, however.
--
Charles Lin
····@cs.umd.edu
From: Henry Baker
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <hbaker-1504971737030001@10.0.2.1>
In article <··········@mimsy.cs.umd.edu>, ····@cs.umd.edu (Charles Lin) wrote:
> If one had to choose a single type for everything, a string is a
> pretty good choice. Why not a number? How would you represent a
> string with a number?
Goedel showed how to represent everything with bignums.
From: Hume Smith
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j1hks$46o@news.istar.ca>
In article <·······················@10.0.2.1>, ······@netcom.com says...
>
>In article <··········@mimsy.cs.umd.edu>, ····@cs.umd.edu (Charles Lin) wrote:
>
>> If one had to choose a single type for everything, a string is a
>> pretty good choice. Why not a number? How would you represent a
>> string with a number?
>
>Goedel showed how to represent everything with bignums.
same thing, really. G�del used base 1000, strings use base 256. (tcl strings,
anyway, where NUL can't be used. the "obivous" mapping won't distinguish the
null string from NUL from NUL-NUL etc.)
IIRC, it was in fact one of JO's points, that in a computer *everything* is a
number. i'm just as glad he chose to use strings, since i don't think i'd like
programming in 38154 much:
34758273445786346634726782237283742374857385683724
is my new newsreader, but it's got a bug. can you find it? :)
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <335440D1.5762@maths.anu.edu.au>
Graham Matthews (···············@maths.anu.edu.au) wrote:
> || Ok thats fair enough, but for me it raises another question, a question
> || that goes to the heart of why people think JO's article is just
> || advertising hype. Why did JO chose to represent everything as a string?
> || Why not everything as a number. Why not everything as a list? The latter
Charles Lin wrote:
> If one had to choose a single type for everything, a string is a
> pretty good choice. Why not a number? How would you represent a
> string with a number? You can represent a number with a string.
> Just put quotes around it.
Oh come on -- if you have a a finite alphabet then there is a bijection
between
the natural numbers and strings over that finite alphabet. For example
if you N
symbols in your alphabet, A ..., then AA is represented by N+1.
graham
--
I was gonna be your Romeo
You were gonna be my Juliet
These days you don't wait on Romeos
You wait on that welfare cheque
From: Paul Wilson
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j1j9d$kq9@roar.cs.utexas.edu>
In article <·············@maths.anu.edu.au>,
Graham Matthews <···············@maths.anu.edu.au> wrote:
>Charles Lin wrote:
>> If one had to choose a single type for everything, a string is a
>> pretty good choice. Why not a number? How would you represent a
>> string with a number? You can represent a number with a string.
>> Just put quotes around it.
>
>Oh come on -- if you have a a finite alphabet then there is a bijection
>between the natural numbers and strings over that finite alphabet. For
>example if you N symbols in your alphabet, A ..., then AA is represented
>by N+1.
This is, of course, a long-established and deep theoretical result,
but I think for these purposes it's pretty much irrelevant, or trivially
true of most existing implementations already, depending on how you look
at it.
The real issue is not whether you can create a correspondence between
the natural numbers and anything you want, but whether you can do it
efficiently. It's just easier to use pointer-linked data structure
representations than to maintain such a mapping to the naturals in any
obvious and direct way.
Of course, most languages do maintain a mapping from language-level
objects such as strings and records---a string or record value is
represented as a pointer to the string or record, and that pointer
is represented as something like a virtual address (an integer offset
from the beginning of the address space), maybe tagged or whatever at
the implementation level, and usually abstracted into an "object reference"
at the language level, rather than being exposed as a raw address.
--
| 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: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <33545E78.4983@maths.anu.edu.au>
Charles Lin wrote:
> If one had to choose a single type for everything, a string is a
> pretty good choice. Why not a number? How would you represent a
> string with a number? You can represent a number with a string.
> Just put quotes around it.
Graham Matthews <···············@maths.anu.edu.au> wrote:
>Oh come on -- if you have a a finite alphabet then there is a bijection
>between the natural numbers and strings over that finite alphabet. For
>example if you N symbols in your alphabet, A ..., then AA is represented
>by N+1.
Paul Wilson wrote:
> This is, of course, a long-established and deep theoretical result,
> but I think for these purposes it's pretty much irrelevant, or trivially
> true of most existing implementations already, depending on how you look
> at it.
No its not irrelevant. The question was why did JO chose the "everything
is a string" paradigm, when he could have chosen the "everything is an
integer", or "everything is a list" paradigm? This correspondence shows
the stupidity of the "everything is a string is so powerful" argument.
graham
--
I was gonna be your Romeo
You were gonna be my Juliet
These days you don't wait on Romeos
You wait on that welfare cheque
In article <·············@maths.anu.edu.au>, Graham Matthews
<···············@maths.anu.edu.au> wrote:
+No its not irrelevant. The question was why did JO chose the "everything
+is a string" paradigm, when he could have chosen the "everything is an
+integer", or "everything is a list" paradigm? This correspondence shows
+the stupidity of the "everything is a string is so powerful" argument.
Sorry, but that does not follow. Bijections are all very well (hey, I'm
a topologist by training :-)), but human predispositions are relevant
here, and most people are more intuitively at home with "reading" a
string "1.0 + 3" as a sequence of characters than, e.g., processing a
text into a Goedel enumeration, (or more directly to the point, going
the other way, from the integer to the text.)
Simplicity and uniformity *are* relevant. One might argue that it matters
not *what* primitive representation is used, but I would laugh at anyone
who seriously thought that non-string representations were "simpler" than
strings.
Try representing the _Iliad_ as either an integer or a list. Just try;
I want to see what kind of idiocies you will commit. That it is possible
I willingly acknowledge; that it is sane, I seriously doubt.
Humans reading strings which *happen* to contain conventional represent-
ations of numbers are happy to make mental conversions. The converse is
*not* true -- "reading" an arbitrary integer as (by some abstruse mapping)
a text string is utterly weird and non-standard. It is quite hopeless for
documentation, for training, and for maintenance. And in case you were a
bit out of it, LANGUAGE is what humans ordinarily use in communication.
It is human readers (and writers) who matter, when we are talking about
programming.
--
Michael L. Siemon ···@panix.com
"Green is the night, green kindled and apparelled.
It is she that walks among astronomers."
-- Wallace Stevens
From: Graham Matthews
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <335476A5.18EA@maths.anu.edu.au>
> In article <·············@maths.anu.edu.au>, Graham Matthews
> +No its not irrelevant. The question was why did JO chose the "everything
> +is a string" paradigm, when he could have chosen the "everything is an
> +integer", or "everything is a list" paradigm? This correspondence shows
> +the stupidity of the "everything is a string is so powerful" argument.
Michael L. Siemon wrote:
> Sorry, but that does not follow. Bijections are all very well (hey, I'm
> a topologist by training :-)), but human predispositions are relevant
> here, and most people are more intuitively at home with "reading" a
> string "1.0 + 3" as a sequence of characters than, e.g., processing a
> text into a Goedel enumeration, (or more directly to the point, going
> the other way, from the integer to the text.)
You have missed the point! I am arguing against the claim that
"everything is a string is so *powerful*". This claim is rubbish since
"everything is a list" is just as powerful. I agree that "everything is
a string" might be more convenient, humanly intelligible, etc, but thats
a different question. My point is that most people claim "power" for the
"everything is a string" approach, when in fact they mean "convenience,
etc". So lets be precise and argue convenience, reliability, etc and
forget this marketing hype of "power".
This leads to the question of why do you think the "everything is a
string" approach is so convenient. As far as I can see its less
convenient than allowing a mixture of typed objects.
> Simplicity and uniformity *are* relevant. One might argue that it matters
> not *what* primitive representation is used, but I would laugh at anyone
> who seriously thought that non-string representations were "simpler" than
> strings.
What about list representations?
graham
--
I was gonna be your Romeo
You were gonna be my Juliet
These days you don't wait on Romeos
You wait on that welfare cheque
From: Hume Smith
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j2p70$hj0@news.istar.ca>
In article <·············@maths.anu.edu.au>, ···············@maths.anu.edu.au
says...
>
>
>> In article <·············@maths.anu.edu.au>, Graham Matthews
>> +No its not irrelevant. The question was why did JO chose the "everything
>> +is a string" paradigm, when he could have chosen the "everything is an
>> +integer", or "everything is a list" paradigm? This correspondence shows
>> +the stupidity of the "everything is a string is so powerful" argument.
>Michael L. Siemon wrote:
>> Sorry, but that does not follow. Bijections are all very well (hey, I'm
>> a topologist by training :-)), but human predispositions are relevant
>> here, and most people are more intuitively at home with "reading" a
>> string "1.0 + 3" as a sequence of characters than, e.g., processing a
>> text into a Goedel enumeration, (or more directly to the point, going
>> the other way, from the integer to the text.)
>
>You have missed the point! I am arguing against the claim that
>"everything is a string is so *powerful*". This claim is rubbish since
>"everything is a list" is just as powerful.
"everything" is a list. hmm. so what should this do:
((()((()((()()))(()))))((()())))
i think we'd want a little more than just lists. not even Lisp constrains us
to just lists; it's got symbols, namespaces, strings, characters, umpteen kinds
of numbers; some lisps have structures, objects, classes, closures...
>This leads to the question of why do you think the "everything is a
>string" approach is so convenient. As far as I can see its less
>convenient than allowing a mixture of typed objects.
"everything as strings" is convenient because in most languages, programs
actually exist as a string at some stage - as their original source code. tcl
goes through a minimum of fuss converting source to internal form.
From: Evan Kirshenbaum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j69hm$p4f@hplms2.hpl.hp.com>
In article <··········@news.istar.ca>,
Hume Smith <········@tallships.istar.ca> wrote:
>"everything as strings" is convenient because in most languages,
>programs actually exist as a string at some stage - as their original
>source code. tcl goes through a minimum of fuss converting source to
>internal form.
If you want a minimum of fuss, use TECO (the original implementation
language for EMACS). No parsing involved. *Every* character is an
operator or part of data:
! detab routine - ts at 4 or 8 spaces depending upon EZ&4 !
@^UD]8UTEZ&4"N4UT'0J<·@S/ ···································@I/ /
QC"NQT-QC<@I/ />'>]@^UX/0JHXRHEQHK1XQ ZJ543HZPRHKG#/QZ&512"NMX0J'
0uz
No, that's not line noise. :-) Yes, people actually wrote in this
language. By hand.
--
Evan Kirshenbaum +------------------------------------
HP Laboratories |"Revolution" has many definitions.
1501 Page Mill Road, Building 1U |From the looks of this, I'd say
Palo Alto, CA 94304 |"going around in circles" comes
|closest to applying...
···········@hpl.hp.com | Richard M. Hartman
(415)857-7572
http://www.hpl.hp.com/personal/Evan_Kirshenbaum/
In article <··········@news.istar.ca>, ········@tallships.istar.ca (Hume
Smith) wrote:
+In article <·············@maths.anu.edu.au>, ···············@maths.anu.edu.au
+says...
+>Michael L. Siemon wrote:
+>> Sorry, but that does not follow. Bijections are all very well...
+>> but human predispositions are relevant
+>You have missed the point! I am arguing against the claim that
+>"everything is a string is so *powerful*". This claim is rubbish since
+>"everything is a list" is just as powerful.
No, I did not miss your point. Read my remark again. I freely acknowledge
the mathematical equivalence, and equal "power" of string, list, and other
representations. Bijections are all very well, but...
+"everything" is a list. hmm. so what should this do:
+ ((()((()((()()))(()))))((()())))
+i think we'd want a little more than just lists.
This misunderstands Mr. Matthews's point. One can easily enough construct
integers from lists (start with the empty list; then make a list comprising
the empty list; then a list whose single element is a list whose single
element is the empty list; etc. -- among several different methods of doing
effectively the "same" thing. Or you could read Whitehead and Russell :-)).
Once you have integers, you can map an alphabet. Lo, you get strings as a
fallout from playing with lists. No big deal.
And Lisp (at least, Famous Original Lisp :-)) is vastly more elegant with
its simple list formation and lambda operation than TCL can hope to be (I
mean, God help us when we have to deal with crap like the octal number
problem! let alone the vagaries of which commands do and which do not
perform a second round of evaluations....) Admittedly, as you note, more
modern Lisps have a lot of ugly excrescences too:
+not even Lisp constrains us
+to just lists; it's got symbols, namespaces, strings, characters, umpteen
kinds
+of numbers; some lisps have structures, objects, classes, closures...
Ayup.
However, Mr. Matthews seems not to have grasped my point, which you and
other TCL users know implicitly. That for the most part, for ordinary
human purposes, everything *does* start from and return to representation
by strings -- and hence, as a principle of least surprise, a language like
TCL which (aside from warts like octal integers :-)) does what most of
us ourselves usually do with strings, has a TREMENDOUS advantage over the
mathematically "equivalent" but mostly non-congenial alternative languages.
I have toyed with Lisp (for decades :-)), and with Prolog, and with a
few others -- and I am a sucker for elegant constructs. But I have never
felt that it would do me, or any user of any of my programs, any good to
have, e.g. a lambda calculus available for their casual use. On the other
hand, I *jumped* at the opportunity to plug TCL into my GUI-testing program
and have not only not regretted it, but been *amazed* at how productive I
and my users can be without a rigorous mathematical discpline in using it.
I can get my users (some of them :-)), to wrap their heads around TCL and
its occasionally non-intuitive behavior. Trying to train them into any kind
of "intuition" of a functional programming language is, IMO, hopeless.
TCL actually operates moderately well as a list-processing language; in
that way (and others) it strikes me as being rather like "Lisp meets the
Bourne shell" -- and wins hands down. That it has this shell usage *and*
its delightfully easy embeddability into existing (or projected) programs
is plenty of reason to celebrate it.
--
Michael L. Siemon ···@panix.com
"Green is the night, green kindled and apparelled.
It is she that walks among astronomers."
-- Wallace Stevens
From: Alex Williams
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j57s8$nql$1@netnews.alf.dec.com>
In article <····················@mls.dialup.access.net>,
Michael L. Siemon <···@panix.com> wrote:
>Try representing the _Iliad_ as either an integer or a list. Just try;
>I want to see what kind of idiocies you will commit. That it is possible
>I willingly acknowledge; that it is sane, I seriously doubt.
Last I checked, the ILIAD was a document and, as such, could be
treated as a /list/ of characters. Oddly enough, so is a string a
/list/ of characters. Seems to me, sir, you cannot see the forest for
the trees.
--
[ Alexander Williams ········@··················@photobooks.com} ]
[ Alexandrvs Vrai, Prefect 8,000,000th Experimental Strike Legion ]
[ BELLATORES INQVITI --- Restless Warriors ]
====================================================================
From: Mark Weissman
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3356599E.3F54@gte.com>
How about:
Iliad = 0
Bible = 1
Hamlet = 2
etc...
--
Mark Weissman
········@gte.com
From: Erik Naggum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3070209881177993@naggum.no>
* Charles Lin
| If one had to choose a single type for everything, a string is a pretty
| good choice. Why not a number? How would you represent a string with a
| number?
excuse me? what you call a "string" already _is_ a number. computers
don't have characters. display devices and printers do.
one of the first lessons of computer science _should_ have been internal
and external representation are so wildly different concepts that they
cannot even be confused, except, of course, by people who are fully aware
of the difference, but proceed to attempt to obliterate it.
#\Erik
--
I'm no longer young enough to know everything.
From: Charles Lin
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j5o3a$9rn@mimsy.cs.umd.edu>
Erik Naggum (····@naggum.no) wrote:
|| * Charles Lin
|| | If one had to choose a single type for everything, a string is a pretty
|| | good choice. Why not a number? How would you represent a string with a
|| | number?
|| excuse me? what you call a "string" already _is_ a number. computers
|| don't have characters. display devices and printers do.
|| one of the first lessons of computer science _should_ have been internal
|| and external representation are so wildly different concepts that they
|| cannot even be confused, except, of course, by people who are fully aware
|| of the difference, but proceed to attempt to obliterate it.
Egads. You must have a slow newsserver. You're at least the
third person to mention, plus there have been follow-ups to that, and
follow-ups to the follow-ups. To summarize. Yes, you can use
numbers to encode anything. Computers use binary representations
for everything. Second, no one would want to use numbers to program
in. The point was given that a programming language has one type,
what would be the most convenient type to use. If your only type
was integers, then strings would be a complete pain. Just write
a program that just prints "Hello, world". I don't think you want
to look up the ASCII representation just to force the use of numbers
as types.
--
Charles Lin
····@cs.umd.edu
From: Erik Naggum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3070347275198364@naggum.no>
* Charles Lin
| Erik Naggum (····@naggum.no) wrote:
| || * Charles Lin
| || | If one had to choose a single type for everything, a string is a pretty
| || | good choice. Why not a number? How would you represent a string with a
| || | number?
|
| || excuse me? what you call a "string" already _is_ a number. computers
| || don't have characters. display devices and printers do.
|
| || one of the first lessons of computer science _should_ have been internal
| || and external representation are so wildly different concepts that they
| || cannot even be confused, except, of course, by people who are fully aware
| || of the difference, but proceed to attempt to obliterate it.
|
| Egads. You must have a slow newsserver. You're at least the third
| person to mention, plus there have been follow-ups to that, and
| follow-ups to the follow-ups. To summarize. Yes, you can use numbers to
| encode anything. Computers use binary representations for everything.
| Second, no one would want to use numbers to program in. The point was
| given that a programming language has one type, what would be the most
| convenient type to use. If your only type was integers, then strings
| would be a complete pain. Just write a program that just prints "Hello,
| world". I don't think you want to look up the ASCII representation just
| to force the use of numbers as types.
I'm sorry you didn't get the point simply because you think I have a slow
newsfeed. at issue is that you must be the only person here who thinks
that "everything is a number" is equivalent to "everything is a decimal
digit string". it isn't. it never was. the point is that your "string"
is merely the expression of a number in base 256, and the digits look like
characters because that is what happens when you throw those base-256
digits at your display device. (adjust for other bases as appropriate.)
my second point also escapes you completely. the internal representation
of a number is _not_ a digit string. the internal representation of an
character is _not_ "the ASCII representation" (by which one must assume you
mean "string of decimal digits"). the idea is that there is a difference,
a very important difference, in fact, between internal and external
representation. I get the impression that you don't understand this
difference. whether a sequence of bits or bytes is given the external
representation of a decimal digit string, a string, an image on a bitmap
display, etc, is completely irrelevant to that sequence.
strings are excellent for external representation, and that's where they
should be used. internal representation should be efficient for the
machine. when and if you need to read or print a value, use the external
representation, but as long as you work with it internally, use something
more efficient. where you define yourself relative to "external" is of
course an open issue.
from what I read here, it seems that even John Ousterhout has seen this
light in Tcl 8.0.
btw, only the Lisp family has a consistent interface between internal and
external representation, with the read/write functions. when non-Lispers
try to reinvent this wheel, they get it completely wrong, such as Tcl.
some don't even understand the difference between internal and external
representation in the first place, so are precluded from appreciating this
lesson from the Lisp family.
#\Erik
--
I'm no longer young enough to know everything.
From: Charles Lin
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j8ice$agv@mimsy.cs.umd.edu>
Erik Naggum (····@naggum.no) wrote:
|| strings are excellent for external representation, and that's where they
|| should be used. internal representation should be efficient for the
|| machine. when and if you need to read or print a value, use the external
|| representation, but as long as you work with it internally, use something
|| more efficient. where you define yourself relative to "external" is of
|| course an open issue.
This was the point. Now, perhaps I completely misunderstood
what Ousterhout did, but I was under the impression that he said
everything in Tcl (the external representation) is a string.
Why are we talking about internal representations at all? My
point is that if you had one external type you wanted to use
(and I don't even argue that this is a good idea), I would think
it would be a string. Internal representations aren't going to
be important because they are hidden from the user (mostly). Use
whatever representation is useful to get the thing done internally.
That's not what I was addressing. To repeat, my argument
has absolutely nothing to do with how the computer represents
the language internally. The point is that (almost) no one wants
to write a program whose *external* representation is numbers. Strings
are more flexible, if they're the only type you have, as external
representation.
The argument I've read is (1) numbers can be used to represent
any other (countable) type through Godel enumeration, and (2) computers
use numbers to represent things underneath. The challenge is this.
You are to write a language for users to use. I give you one type
that you will give to the user to use. Would your users prefer
strings or numbers? I'm not talking about internal representation.
Do I think everything should be strings in a language. Personally,
no, but given the above, how would you have answered it?
p.s. I understand internal representation vs. external. Computers
use two's complement signed notation to represent integers and
mostly IEEE 754 floating point representation to represent
floating point numbers with mantissa and exponent. Strings
are usually represent (in C/C++) as ASCII in consecutive bytes
in memory terminated by a null character. Each position is
a character in the ASCII character set.
--
Charles Lin
····@cs.umd.edu
From: Erik Naggum
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3070390128524499@naggum.no>
* Charles Lin
| Now, perhaps I completely misunderstood what Ousterhout did, but I was
| under the impression that he said everything in Tcl (the external
| representation) is a string. Why are we talking about internal
| representations at all?
because the internal representation in Tcl is the string.
| Internal representations aren't going to be important because they are
| hidden from the user (mostly).
I think you're missing the point all over the place. Tcl's purpose is to
glue different applications together, but also to do something with the
returned "values" (i.e., output) of these programs. of course we're
dealing with interfaces where external representations will be used, but
Tcl uses the same external representations for internal purposes, too.
when you execute a numeric operation, the string is converted to a number,
the operation is performed, and then converted back to a string. in
contrast to this view, AWK converts a string to a number when it is used
for a numeric purpose, and a number to a string when it is used for a
string purpose, but not otherwise. (at least, this is what I have
understood from what I have read about Tcl.)
| The point is that (almost) no one wants to write a program whose
| *external* representation is numbers.
nobody has suggested they do, and nobody in their right mind would.
| Strings are more flexible, if they're the only type you have, as external
| representation.
but external representations _aren't_ typed!
I'd venture that that's the whole point in using an _untyped_ string (or
even byte-sequence) representation is that whoever reads it would be able
to interpret it, indeed that type would emerge from the interpretation.
#\Erik
--
I'm no longer young enough to know everything.
Hi all,
Erik Naggum wrote:
>
> * Charles Lin
> | Now, perhaps I completely misunderstood what Ousterhout did, but I was
> | under the impression that he said everything in Tcl (the external
> | representation) is a string. Why are we talking about internal
> | representations at all?
>
> because the internal representation in Tcl is the string.
This was true some times ago, but not anymore. See below for more complete
explanation.
> | Internal representations aren't going to be important because they are
> | hidden from the user (mostly).
>
> I think you're missing the point all over the place. Tcl's purpose is to
> glue different applications together, but also to do something with the
> returned "values" (i.e., output) of these programs. of course we're
> dealing with interfaces where external representations will be used, but
> Tcl uses the same external representations for internal purposes, too.
> when you execute a numeric operation, the string is converted to a number,
> the operation is performed, and then converted back to a string. in
> contrast to this view, AWK converts a string to a number when it is used
> for a numeric purpose, and a number to a string when it is used for a
> string purpose, but not otherwise. (at least, this is what I have
> understood from what I have read about Tcl.)
Same as above.
> | The point is that (almost) no one wants to write a program whose
> | *external* representation is numbers.
>
> nobody has suggested they do, and nobody in their right mind would.
Former discussion in this thread was rather ambiguous on this point. Some
suggested to use lists (as in Lisp). Some to use numbers, and gave a way
to represent strings as numbers. But nobody wants to code in numbers! (as
an external representation). Anyway, to be a little extremist, I could
pretend that there's a bijection between every data representation, since
everything in a computer is a vector of _bits_ ;-) Just to caricaturate
former aguments. Enough on that point.
> | Strings are more flexible, if they're the only type you have, as external
> | representation.
>
> but external representations _aren't_ typed!
They are "semantically typed": see below.
> I'd venture that that's the whole point in using an _untyped_ string (or
> even byte-sequence) representation is that whoever reads it would be able
> to interpret it, indeed that type would emerge from the interpretation.
Yes, that's the point.
Ok. Now, why did JO choose strings as external representation?
Let me remind everybody that Tcl means Tool Command Language, and was
intended to glue apps together. JO then choosed to use an external interface
similar to the main() function in C programs, and THAT is the great point
of Tcl, because this kind of interface is well known and widely used since
every C program HAS to use it as an entry point. This was the best choice
IMHO as an external interface for a glue language, and I don't think we
can argue against that. JO didn't choose lists or numbers, not because they
are bad or whatsoever, but because command lines arguments are strings, and
string are the only data structure that is common to any programming language
_as an external interface_ and that there's (nearly) always a string
representation of any data structure. Without performance considerations,
you can represent strings, numbers, lists, trees, and so on, using Tcl lists,
provided you use proper conventions.
Tcl's first intent was to glue programs together. Thus, one programs could
be written in Fortran, one another in C, even in Lisp or anything. Then
every program had to export its external interface as Tcl commands. This
is very easy since it's like writing a main() function. Then you had to
write the Tcl script to glue things together (calling programs via their
external interfaces, passing string arguments and getting back string
results).
Tcl was not intended to act as a programming language by itself. But it's
a fact that many apps that use Tcl are Tcl-only, because there are enough
primitives in Tcl for that. But since everything in Tcl is a string, there's
a huge overhead if the whole program is written in Tcl, while there's little
overhead if Tcl only acts as a glue.
Thus, strings are the only external interface in Tcl, and were the only
internal representation as well until some months ago. Tcl-only procedures
were strings. Number were strings. Lists were strings. And so on. This
wasn't a big deal if Tcl was used as a glue language, but Tcl was quite slow
if used as a stand-alone programming language.
So, and AFAIK due to the increasing number of Tcl-only projects, the Tcl
Team decided to change the internal representation of data. This was a
long time planed project, and many attempts were made before, but the main
challenge was to keep the "everything is a string" semantic of Tcl from
an external point of view, especially regarding the metaprogramming and
dynamic capabilities of Tcl (along with pass-by-name stuff).
So, the current version of Tcl (version 8.0, still in alpha, but soon beta.
First public release in Dec 1996) introduces several changes:
- internal representation is now "objects" (not in the usual meaning).
Now, an "object" still has an external string representation, but can
internally be a string, a list, an integer, program bytecode... And
internal representation can be ubiquitous (it is cached).
- former Tcl strings were C strings. This prevented Tcl from processing
binary strings/data, due to the terminating null char. Now, Tcl strings
know their length and can contain arbitrary characters.
- former Tcl lists were space-separated strings, with {}'s for nesting.
access was in O(n). Now, lists are _real_ lists and access is O(1).
Strings are "aggressively" parsed, and although they remain strings from
an external point of view, they can be used as lists and vice versa. This
results in a major speedup on list commands, and now lists can be used as
compound types, for which arrays were formerly used for performance issue
(use of hash tables).
- Data is now "semantically typed" : string "1" is first a string, then an
integer representation is generated if it's used eg in a math. expression.
"my name is Fred" is a string that is turned into a list when list commands
are used. "puts foo" is a string that can be turned into bytecode if it's
eval'd, and similarly into a list. And so on.
For example :
set i 0
while {$i < 50} {
incr i
puts $i
}
* variable i is set to the string "0"
* "while" command is called with 2 arguments: the strings "{$i < 50}" and
"{\n incr i \n puts $i \n}". While then evaluates the 1st as a logical
expression, thus generates an int representation of i, that is used in
the comparison expression. If the result is true, it then evaluates the
second argument. A bytecode representation is then generated by the
bytecode compiler, and evaluated. "incr i" adds 1 to the value of i, but
it already has an int representation, so it's used instead of the string
representation. "puts $i" prints the string representation of i, but since
it has changed, it has been invalidated and another representation is generated
from the current int representation (well, I think so). Then we test again
the expression {$i < 50} and reevaluate the loop body and so on.
Note that only the first iteration is slightly slower than in previous Tcl
versions, due to the extra computations. But following iterations are much
faster. So if you use Tcl as a glue language, the speed difference is not
significant, but if you use it as an extension language or a standalone
language, then there's a significant speed boost.
So, I think that the "string is bad as an external representation" argument is
irrelevant. Lisp has lists. Prolog has predicates. And so on. I think that the
only relevant argument is what you can do with the language (which has something
to do with the internals), and not which external representation you use.
Last point: there _are_ several implementations of Tcl. Ioi Lam is working on
a promising Tcl interpreter written in Java, called Jacl (Jackal). Its internal
structures will be arbitrary Java objects. See:
http://simon.cs.cornell.edu/home/ioi/Jacl/
So the whole point on "Tcl is bad because everything is a string" is irrelevant.
It's not because an implementation of Tcl uses strings as its internal
representation that it's a Tcl problem: it's the implementation's.
Sorry for the length of this message, but many things that were said about Tcl
(eg "Tcl is a glorified preprocessor") made me wonder which language we were
talking about. Sometimes it was a bit too close to Tcl-bashing on irrelevant
points. There have been major changes in Tcl since its first release. I hope I
refreshed many people's mind.
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
From: Donal K. Fellows
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5k4p3j$qmm@m1.cs.man.ac.uk>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> Charles Lin
>> Now, perhaps I completely misunderstood what Ousterhout did, but I was
>> under the impression that he said everything in Tcl (the external
>> representation) is a string. Why are we talking about internal
>> representations at all?
>
> because the internal representation in Tcl is the string.
In some implementations for some objects. Not all of either. Get
your facts straight Erik (by having a look at Tcl8 :^)
>> Internal representations aren't going to be important because they are
>> hidden from the user (mostly).
>
> I think you're missing the point all over the place. Tcl's purpose is to
> glue different applications together, but also to do something with the
> returned "values" (i.e., output) of these programs. of course we're
> dealing with interfaces where external representations will be used, but
> Tcl uses the same external representations for internal purposes, too.
> when you execute a numeric operation, the string is converted to a number,
> the operation is performed, and then converted back to a string. in
> contrast to this view, AWK converts a string to a number when it is used
> for a numeric purpose, and a number to a string when it is used for a
> string purpose, but not otherwise. (at least, this is what I have
> understood from what I have read about Tcl.)
Tcl (well, Tcl8) does better than AWK, in that when it converts a
string to a number (because it has been used numerically) it keeps the
old string representation around[*] in case the programmer refers to
that symbol in a string context, instead of having to convert back and
forth. The same is true for Tcl8 lists - then you program with them
you use a string representation of them, but when they are referred to
in a list context, an efficient internal list representation is
generated, and if the list is created internally in the program, then
a string representation may never actually exist at all (it would only
be created if the programmer did something like interpolating the list
into a string, as you'd expect.) This system of lazy type-conversion,
when coupled with an on-the-fly bytecode compiler (Tcl doesn't match
well with compilation to the JVM, compilation to native code is much
more difficult to make portable between architectures, and static
compilation is, in general, probably nigh-on impossible) gets the
performance boost that many of Tcl's detractors and advocates have
been after for years.
Donal.
[* Naturally, if the numberic representation is then modified, the
string rep. is discarded and may need regenerating. But you would
have expected that...]
--
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: Alaric B. Williams
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <33588b2c.1887203@news.demon.co.uk>
On 18 Apr 1997 19:34:38 GMT, ····@cs.umd.edu (Charles Lin) wrote:
> The argument I've read is (1) numbers can be used to represent
>any other (countable) type through Godel enumeration, and (2) computers
>use numbers to represent things underneath. The challenge is this.
>You are to write a language for users to use. I give you one type
>that you will give to the user to use. Would your users prefer
>strings or numbers? I'm not talking about internal representation.
>Do I think everything should be strings in a language. Personally,
>no, but given the above, how would you have answered it?
Actually, I think they'd prefer audio samples instead of either...
"Let X equal Y plus one, write X to the screen, then for every element
E of list B, write E to the screen, end loop."
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: Hume Smith
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5jbjmh$6ns@news.istar.ca>
In article <················@news.demon.co.uk>, ······@abwillms.demon.co.uk
says...
>Actually, I think they'd prefer audio samples instead of either...
>
>"Let X equal Y plus one, write X to the screen, then for every element
>E of list B, write E to the screen, end loop."
"let tex eke wall why plus won, rye text to the scream, then forever elephanty
of list bee, rye tea tooth ask ream, end loupe." rightho, me ol' bucko! :)
From: Kelly Murray
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5jemhu$5nb$1@sparky.franz.com>
>····@cs.umd.edu (Charles Lin):
>>Erik Naggum (····@naggum.no) wrote:
>>|| strings are excellent for external representation, and that's where they
> This was the point. Now, perhaps I completely misunderstood
>what Ousterhout did, but I was under the impression that he said
>everything in Tcl (the external representation) is a string.
Why not make everything a stream of BYTES ?
Then we can send one programs output BYTES as input BYTES to another program!
It works, you can do a lot of stuff with it --
been around now for 20-30 years. Has a few bugs though. BYTE number 4 causes
some confusion. BYTE number 0 too. BYTE numbers > 127 seem to cause some
bugs too. Nothing that can't be found and fixed after 20 years of testing.
Hmm, maybe if everything was an OBJECT instead, we might get somewhere??
Just a thought.
-Kelly Murray ···@franz.com http://www.franz.com
From: Bror Johansson
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3356375B.11EA@nrk.ericsson.se>
Erik Naggum wrote:
>
> * Charles Lin
> | If one had to choose a single type for everything, a string is a pretty
> | good choice. Why not a number? How would you represent a string with a
> | number?
>
> excuse me? what you call a "string" already _is_ a number. computers
> don't have characters. display devices and printers do.
>
Programming language related topics should then be discussed in the
context of number theory, or...? If so, sci.math.* should host this
ever ongoing, and rapidly deteriorating thread of discussion.
> one of the first lessons of computer science _should_ have been internal
> and external representation are so wildly different concepts that they
> cannot even be confused, except, of course, by people who are fully aware
> of the difference, but proceed to attempt to obliterate it.
>
> #\Erik
> --
> I'm no longer young enough to know everything.
Bror Johansson
Ericsson Telecom AB, Norrk�ping, Sweden
From: Alaric B. Williams
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <3356878f.5428776@news.demon.co.uk>
On 15 Apr 1997 18:18:45 GMT, ····@cs.umd.edu (Charles Lin) wrote:
> If one had to choose a single type for everything, a string is a
>pretty good choice. Why not a number? How would you represent a
>string with a number?
Because the fundamental type has to be some kind of list. So really,
the TCL fundamental type is the character, which never exists outside
of a string (much like quarks like to hang around in pairs or threes),
whereas in LISP, there ain't a fundemantal type... you get ints,
chars, etc. which may or may not be inside lists or vectors.
Just thought I'd clear that up.
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: Jussi Piitulainen
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <oiu3l6oxsg.fsf@polva.helsinki.fi>
[I cut some of the newsgroups; might have cut all of them.]
···@panix.com (Michael L. Siemon) writes:
> Try representing the _Iliad_ as either an integer or a list. Just try;
> I want to see what kind of idiocies you will commit. That it is possible
> I willingly acknowledge; that it is sane, I seriously doubt.
A string as a list of character codes is just a _special case_ of a
list, or rather a vector since one expects constant time access to any
element. Here's Prolog:
| ?- Iliad = "The wrath sing, goddess, of Peleus' son, Achilles, ...".
Iliad = [84,104,101,32,119,114,97,116,104,32,115,105,110,103,44,32,
103,111,100,100,101,115,115,44,32,111,102,32,80,101,108,101,117,115,
39,32,115,111,110,44,32,65,99,104,105,108,108,101,115,44,32,46,46,46] ?
yes
| ?-
The string and the list are actually the same thing, no idiocy
committed. And there's nobody is playing the game where fixna would
be represented as lists.
I found the text at <http://homer.reed.edu/Iliad.html>.
--
Jussi
From: Thomas A. Russ
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <ymi2089fpdd.fsf@hobbes.isi.edu>
In article <···············@aalh02.alcatel.com.au> ·············@alcatel.com.au (Chris Bitmead uid(x22068)) writes:
>
> Now Aristotle wrote in Greek, the characters of which you cannot
> represent in an ascii string.
"Now <Alpha><rho><iota><sigma><tau><omega><tau><lambda><epsilon> wrote in..."
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Chris Bitmead uid(x22068)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <s6ypvvukubq.fsf@aalh02.alcatel.com.au>
···@panix.com (Michael L. Siemon) writes:
> Sorry, but that does not follow. Bijections are all very well (hey, I'm
> a topologist by training :-)), but human predispositions are relevant
> here, and most people are more intuitively at home with "reading" a
> string "1.0 + 3" as a sequence of characters than, e.g., processing a
> text into a Goedel enumeration, (or more directly to the point, going
> the other way, from the integer to the text.)
>
> Simplicity and uniformity *are* relevant. One might argue that it matters
> not *what* primitive representation is used, but I would laugh at anyone
> who seriously thought that non-string representations were "simpler" than
> strings.
>
> Try representing the _Iliad_ as either an integer or a list. Just try;
> I want to see what kind of idiocies you will commit. That it is possible
> I willingly acknowledge; that it is sane, I seriously doubt.
Goodness me, The Iliad! As in Homer?
Ok, let's talk about that, but I pick Aristotle instead :-).
Now Aristotle wrote in Greek, the characters of which you cannot
represent in an ascii string.
I don't subscribe to the "everything is a ...." theory. Sure it's nice
to be able to deal with different types in the same way, but that's
what *polymorphism* is for. Oh sorry, JO don't like OO.
I can see no advantage whatsover in making everything fit in a string
(or a list or a bignum). Take lists for example. A properly designed
OO library would allow you to traverse a string or list or array
without knowing what the underlying type is.
> Humans reading strings which *happen* to contain conventional represent-
> ations of numbers are happy to make mental conversions. The converse is
> *not* true -- "reading" an arbitrary integer as (by some abstruse mapping)
> a text string is utterly weird and non-standard. It is quite hopeless for
> documentation, for training, and for maintenance. And in case you were a
> bit out of it, LANGUAGE is what humans ordinarily use in communication.
> It is human readers (and writers) who matter, when we are talking about
> programming.
While Lisp does not store numbers as strings, I never know or care
that this is the case. In fact I could write a Lisp implementation
that does store numbers as strings, and a programmer using it would be
none the wiser (apart from awful performance of course). Why do you
want to fit everything in a string?? It buys you NOTHING.
In article <···············@aalh02.alcatel.com.au>,
Chris Bitmead uid(x22068) <·············@alcatel.com.au> wrote:
>While Lisp does not store numbers as strings, I never know or care
>that this is the case. In fact I could write a Lisp implementation
>that does store numbers as strings, and a programmer using it would be
>none the wiser (apart from awful performance of course). Why do you
>want to fit everything in a string?? It buys you NOTHING.
It buys you not having to write string->number. I don't think that this is a
big win, but I could see how it would be useful to people who are not used
to thinking about data types. Any programmer should run screaming from it,
but I can see its value for end users. That explains why apps embed TCL, but
not why programmers write whole programs in it.
Paul Prescod
From: ·······@cas.org
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j88bl$mf9$1@cas.org>
According to Paul Prescod <········@csclub.uwaterloo.ca>:
:In article <···············@aalh02.alcatel.com.au>,
:Chris Bitmead uid(x22068) <·············@alcatel.com.au> wrote:
:>none the wiser (apart from awful performance of course). Why do you
:>want to fit everything in a string?? It buys you NOTHING.
Note that Tcl does _not_ store _everything_ in a string. It uses strings
as the data type to pass between it's commands.
For instance, when one opens a file, one gets back a string whose value
is a handle pointing to an open file descriptor. The file descriptor remains
the binary structure the OS expects. The Tk extension's creation of
widgets is another fine example. I hope that folk don't think that Tcl
somehow converts all the various X window system structures to string to
pass around. Instead, handles (of type string) for these structures are
created. When one needs to manipulate the binary entity under one of these
handles, one uses a structure which knows how to move from the string to the
structure and back.
Various other extensions have had great success adding other handles to other
data types. So in the strictest sense, one is not just limited to strings
in Tcl. One is, at least pre-Tcl 8.0, limited in treating the _names_
of these entities as strings.
--
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 <·········@undergrad.math.uwaterloo.ca>, ········@csclub.uwaterloo.ca (Paul Prescod) writes:
>In article <···············@aalh02.alcatel.com.au>,
>Chris Bitmead uid(x22068) <·············@alcatel.com.au> wrote:
>>While Lisp does not store numbers as strings, I never know or care
>>that this is the case. In fact I could write a Lisp implementation
>>that does store numbers as strings, and a programmer using it would be
>>none the wiser (apart from awful performance of course). Why do you
>>want to fit everything in a string?? It buys you NOTHING.
>
>It buys you not having to write string->number. I don't think that this is a
>big win, but I could see how it would be useful to people who are not used
>to thinking about data types.
Actually there is no win at all. If you are going to DO anything with
the number you need string->number. The question in this case is
rather WHEN you do the conversion.
> Any programmer should run screaming from it,
>but I can see its value for end users. That explains why apps embed TCL, but
>not why programmers write whole programs in it.
If it is not the language itself then it must be some property of the
system itself which is useful and not found in other language
systems. What I don't know.
--
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".
In article <············@news.du.etx.ericsson.se>,
Robert Virding <··@erix.ericsson.se> wrote:
>In article <·········@undergrad.math.uwaterloo.ca>, ········@csclub.uwaterloo.ca (Paul Prescod) writes:
>>In article <···············@aalh02.alcatel.com.au>,
>>Chris Bitmead uid(x22068) <·············@alcatel.com.au> wrote:
>>>none the wiser (apart from awful performance of course). Why do you
>>>want to fit everything in a string?? It buys you NOTHING.
>>
>>It buys you not having to write string->number. I don't think that this is a
>>big win, but I could see how it would be useful to people who are not used
>>to thinking about data types.
>
>Actually there is no win at all. If you are going to DO anything with
>the number you need string->number. The question in this case is
>rather WHEN you do the conversion.
No, the system does the conversion implicitly. The user never types
string->number.
>If it is not the language itself then it must be some property of the
>system itself which is useful and not found in other language
>systems. What I don't know.
Tk, which was tied to Tcl in the early days.
Paul Prescod
From: Chris Bitmead uid(x22068)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <s6yohb9mf4y.fsf@aalh02.alcatel.com.au>
········@csclub.uwaterloo.ca (Paul Prescod) writes:
> In article <···············@aalh02.alcatel.com.au>,
> Chris Bitmead uid(x22068) <·············@alcatel.com.au> wrote:
> >While Lisp does not store numbers as strings, I never know or care
> >that this is the case. In fact I could write a Lisp implementation
> >that does store numbers as strings, and a programmer using it would be
> >none the wiser (apart from awful performance of course). Why do you
> >want to fit everything in a string?? It buys you NOTHING.
>
> It buys you not having to write string->number. I don't think that this is a
> big win, but I could see how it would be useful to people who are not used
> to thinking about data types. Any programmer should run screaming from it,
> but I can see its value for end users. That explains why apps embed TCL, but
> not why programmers write whole programs in it.
If you're using string->number you're already doing fairly
sophisticated programming. The naive user can input and output numbers
without conversion.
scheme
> (* (read) 2)
10
=> 20
In article <···············@aalh02.alcatel.com.au>,
Chris Bitmead uid(x22068) <·············@alcatel.com.au> wrote:
>
>If you're using string->number you're already doing fairly
>sophisticated programming. The naive user can input and output numbers
>without conversion.
>
>scheme
>> (* (read) 2)
>10
>=> 20
Okay, you want to put up a dialog box. You want to report the number in it.
In scheme, you must type number->string, which is very reasonable for
programmers -- you want to understand the difference between numbers and
strings. End-users don't. Thus I think that automatically coercing strings
is quite reasonable in in a scripting language. Unfortunately TCL has some
"gotchas" that makes it not perfect as a scripting language. REXX also has
some funny gotchas. Sometimes when you bend over too far trying to help
the user, your presumptions of what they want lead to many subtle errors.
Paul Prescod
> If one had to choose a single type for everything, a string is a
> pretty good choice. Why not a number? How would you represent a
> string with a number?
Perlis, as usual, summed it up well in one of his aphorisms:
The string is a stark data structure, and everywhere it
occurs there is much hiding of information.
This is what is wrong with both Unix and tcl. Their power is also a great
weakness: they are designed around a "least common denominator"
representation, strings. What it buys you is that everything interoperates.
The above aphorism explains what it costs you.
-Olin
From: Charles Lin
Subject: Re: Strings as a uniform representation & tcl
Date:
Message-ID: <5j5hm9$448@mimsy.cs.umd.edu>
Olin Shivers (·······@lambda.ai.mit.edu) wrote:
|| > If one had to choose a single type for everything, a string is a
|| > pretty good choice. Why not a number? How would you represent a
|| > string with a number?
|| Perlis, as usual, summed it up well in one of his aphorisms:
|| The string is a stark data structure, and everywhere it
|| occurs there is much hiding of information.
|| This is what is wrong with both Unix and tcl. Their power is also a great
|| weakness: they are designed around a "least common denominator"
|| representation, strings. What it buys you is that everything interoperates.
|| The above aphorism explains what it costs you.
Notice this is why I said "if one HAD to" choose a single data type,
a string would probably be it. I didn't argue that it was a good idea.
In other words, given that you had to choose one type that a language
had to be in, what would you choose? The problem with lists is that
a list is really a compound data structure. For example, in a Lisp
list (a (b c)), what is "a", "b", and "c"? Lists are built from
basic elements. Yes, yes, you can build up some sort of counting by
using the empty list and list of empty lists, and so on, but again,
ease of programming counts.
My preference is to have multiple types.
--
Charles Lin
····@cs.umd.edu
On 17 Apr 1997 16:04:25 GMT, ····@cs.umd.edu (Charles Lin) wrote:
> Notice this is why I said "if one HAD to" choose a single data type,
>a string would probably be it. I didn't argue that it was a good idea.
>In other words, given that you had to choose one type that a language
>had to be in, what would you choose? The problem with lists is that
>a list is really a compound data structure. For example, in a Lisp
>list (a (b c)), what is "a", "b", and "c"? Lists are built from
>basic elements. Yes, yes, you can build up some sort of counting by
>using the empty list and list of empty lists, and so on, but again,
>ease of programming counts.
It's that misconception again! TCL is lists of characters! Scheme has
a load of types which are on equal footings, in that containers and
atoms are interchangeable!
> My preference is to have multiple types.
What, like TCL does, you mean? :-)
>--
>Charles Lin
>····@cs.umd.edu
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>
In article <··················@lambda.ai.mit.edu>, Olin Shivers
<·······@lambda.ai.mit.edu> wrote:
> > If one had to choose a single type for everything, a string is a
> > pretty good choice. Why not a number? How would you represent a
> > string with a number?
>
> Perlis, as usual, summed it up well in one of his aphorisms:
>
> The string is a stark data structure, and everywhere it
> occurs there is much hiding of information.
I'm afraid you may be 'casting Perlis before swine'.... ;-) ;-) ;-)
From: Michel de Groot
Subject: Re: Strings as a uniform representation & tcl
Date:
Message-ID: <33856ACD.4B9C@cs.utwente.nl>
Olin Shivers wrote:
>
> > If one had to choose a single type for everything, a string is a
> > pretty good choice. Why not a number? How would you represent a
> > string with a number?
Like a computer does: using a bit string. Much more efficient than a
ascii string anyway (which ofcourse is a bit string, I know).
Michel de Groot
>
> Perlis, as usual, summed it up well in one of his aphorisms:
>
> The string is a stark data structure, and everywhere it
> occurs there is much hiding of information.
>
> This is what is wrong with both Unix and tcl. Their power is also a great
> weakness: they are designed around a "least common denominator"
> representation, strings. What it buys you is that everything interoperates.
> The above aphorism explains what it costs you.
> -Olin
--
Freddy's Law: Murphy was an optimist
Visit the Ducosim website at
www.euronet.nl/~ducosim
R.M. de Groot
Campuslaan 57-104
7522 NK Enschede
the Netherlands
tel. NL-053-4895100 (home)
NL-053-4894179 (work)
email: ···········@student.utwente.nl (home)
······@cs.utwente.nl (work)
Michel-
From your citation (which I reprint below), it appears you believe
I am the one who said, "If one had to choose ..." I didn't. Someone
else wrote that. In fact, I'm not sure I've even seen that text, much
less written it, so perhaps it occurred on some newsgroup I don't read.
I am the one who invoked Perlis, as you correctly cite further on.
(Perlis was my advisor in college, so I am apt to so at the drop of a hat.)
Just to clarify any confusion, I personally think strings are a lousy
univeral representation for data. Same goes for integers, or even, for
that matter, lambdas. Languages like tcl that only give you one basic data
structure are, in my opinion, pretty lousy languages.
This is a little subtle, so stick with me here, but my preference is
to use lambdas to represent procedures, strings to represent character
sequences, and integers to represent, uh, integers. Call me old-fashioned.
-Olin
-------------------------------------------------------------------------------
From: Michel de Groot <······@cs.utwente.nl>
Subject: Re: Strings as a uniform representation & tcl
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
Date: Fri, 23 May 1997 12:00:45 +0200
Organization: University of Twente
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!panix!news-xfer.netaxs.com!chippy.visi.com!news-out.visi.com!news.IAEhv.nl!news.cs.utwente.nl!not-for-mail
Lines: 38
Distribution: world
Message-ID: <·············@cs.utwente.nl>
References: <··········@Masala.CC.UH.EDU> <··········@engnews2.Eng.Sun.COM>
<·············@maths.anu.edu.au> <··········@m1.cs.man.ac.uk>
<·············@maths.anu.edu.au> <··········@mimsy.cs.umd.edu>
<·······················@10.0.2.1> <··················@lambda.ai.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server-Date: 23 May 1997 10:00:44 GMT
X-Mailer: Mozilla 3.0 (X11; I; HP-UX B.10.10 9000/730)
Xref: senator-bedfellow.mit.edu comp.lang.scheme:20407 comp.lang.scheme.scsh:972 comp.lang.lisp:27466 comp.lang.tcl:67081 comp.lang.functional:9448 comp.lang.c++:262581 comp.lang.perl.misc:75452 comp.lang.python:21553 comp.lang.eiffel:20569
Olin Shivers wrote:
>
> > If one had to choose a single type for everything, a string is a
> > pretty good choice. Why not a number? How would you represent a
> > string with a number?
Like a computer does: using a bit string. Much more efficient than a
ascii string anyway (which ofcourse is a bit string, I know).
Michel de Groot
>
> Perlis, as usual, summed it up well in one of his aphorisms:
>
> The string is a stark data structure, and everywhere it
> occurs there is much hiding of information.
>
> This is what is wrong with both Unix and tcl. Their power is also a great
> weakness: they are designed around a "least common denominator"
> representation, strings. What it buys you is that everything interoperates.
> The above aphorism explains what it costs you.
> -Olin
From: Hume Smith
Subject: Re: Strings as a uniform representation & tcl
Date:
Message-ID: <5m4jbu$50n@news.istar.ca>
In article <·············@cs.utwente.nl> Michel de Groot <······@cs.utwente.nl> writes:
> From: Michel de Groot <······@cs.utwente.nl>
> Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
> Date: Fri, 23 May 1997 12:00:45 +0200
> Organization: University of Twente
> X-Server-Date: 23 May 1997 10:00:44 GMT
>
> Olin Shivers wrote:
> >
> > > If one had to choose a single type for everything, a string is a
> > > pretty good choice. Why not a number? How would you represent a
> > > string with a number?
>
> Like a computer does: using a bit string. Much more efficient than a
> ascii string anyway (which ofcourse is a bit string, I know).
you may personally find it more efficient to write
\//\/\\\\//\\/\/\//\//\\\//\//\\\//\////\\/\\\\\\//\\\\\\//\/\\\\//\\/\/\///\\/\\//\\/\/
in base 2 than
hello there
in base 256, but i certainly didn't.
--
Hume Smith <···················@tallships.istar.ca>
<URL:http://dess.tallships.istar.ca/%7Ehclsmith/>
From: Chris Bitmead uid(x22068)
Subject: Re: Nothing to read (was Re: Reply to Ousterhout's reply)
Date:
Message-ID: <s6y912imjav.fsf@aalh02.alcatel.com.au>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> Is it possible to get fired for using C++?
I do know that it should be a sackable offence.
Seriously! Of the last 5 C++ projects I've done, 2 were canned because
they were too late and over-budget. The other 3 have their lateness
measured in _years_.
The actual answer to whether using C++ is a sackable offence, is yes,
you will be sacked when the project fails, but by then the damage has
been done.
With a mighty <···············@aalh02.alcatel.com.au>,
·············@alcatel.com.au uttered these wise words...
> ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>
> > Is it possible to get fired for using C++?
>
> I do know that it should be a sackable offence.
Dream on. ;-)
> Seriously! Of the last 5 C++ projects I've done, 2 were canned because
> they were too late and over-budget. The other 3 have their lateness
> measured in _years_.
I've also experienced problems with C++, and I've made it clear that
I'm _not_ a C++ programmer (despite using it a little). I'm not a Java
programmer, either, and yet it seems that inexperience isn't a problem
_if_ everyone else is using the language.
> The actual answer to whether using C++ is a sackable offence, is yes,
> you will be sacked when the project fails, but by then the damage has
> been done.
How often will C++ get the credit it deserves, i.e. credit for killing
the project? I get the impression that nobody using C++ cares about
this, which may explain why they're using C++.
Circular arguments abound. I like summarise them as, "We use it
because we can." It seems a hell of a lot more honest than any of the
arguments that claim some kind of superiority over alternatives. How
seriously can you take the bickering over whether the semicolon should
be used as a statement separator or terminator (a popular argument in
the "C vs Pascal" circus that's been running for _years_).
I'm not even going to mention the dirty tricks. Oops. Why am I
reminded of the films of a certain German propaganda minister? If your
argument is so weak that you have to resort to such cheap devices,
then I'll suggest that your cause is doomed - unless, of course, you
have massive resources at your disposal. Alas, for C++/Java/etc, this
appears to be the case. Yep, the biggest possible resources ever seen;
an almost complete domination of the computing media.
Fortunately, there are still a few magazine editors who refuse to sell
out. Full marks go to J.D. Hildebrand at Windows Tech Journal, who
indcidently gave ACL/PC a glowing review a few years ago, despite
being a complete Lisp newbie. His stand against the MS inforwar
machine is also commendable, a few years ago. The mag lost all
advertising from MS, but it's a price worth paying, and J.D. stands by
everything he said in the editorial for the September 1994 issue.
The Computer Press Association said it was one of the three best
computer related editorials to appear that year.
That's the kind of dirty trick that MS like to play on the media. No
wonder so many people have been fooled. It's almost like something out
o George Orwell's 1984. (Almost? Did I say _almost_?)
--
<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.
····@gco.apana.org.au writes:
| Plan 9 (of beloved memory ) did pretty much the same thing.
And Inferno (c.f. comp.os.inferno, http://inferno.lucent.com/) does it
even more.
Works great.
From: Gary D. Duzan
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5jfl2e$3qn@news-central.tiac.net>
In article <··············@galapagos.cse.psu.edu>,
Scott Schwartz <········@galapagos.cse.psu.edu.NO-SPAM> wrote:
=>
=>····@gco.apana.org.au writes:
=>| Plan 9 (of beloved memory ) did pretty much the same thing.
=>
=>And Inferno (c.f. comp.os.inferno, http://inferno.lucent.com/) does it
=>even more.
=>
=>Works great.
To clarify, I have no problem whatsoever having things live in
a common namespace; that is obviously a good thing. What I have
some objection to is calling everything in that namespace a file.
The traditional notion of a file, an organized collection of data,
seems unnatural for things like terminals, system control interfaces,
etc. If you can make these thing look like files from one angle,
that's fine, and probably useful, but it still isn't a file. Calling
something what is isn't is not helpful when looking at it in the
abstract.
Gary D. Duzan
Humble Practitioner of the Computing Arts
From: Steven D. Majewski
Subject: Correct timelines [was: Reply to Ousterhout's reply ]
Date:
Message-ID: <AF734804-B1B9E@128.143.7.209>
On Wed, Apr 9, 1997 8:03 PM, ········@bayou.uh.edu
<···············@bayou.uh.edu> wrote:
>John Ousterhout (······@tcl.eng.sun.com) wrote:
>
JO>: In contrast, various flavors of Lisp have been around since at least
JO>: the early 60's and Smalltalk first appeared in the late 60's.
>
>I was under the impression that Smalltalk first appeared in the early
>70s.
>
As one of the greybeards (literally) in this group, I have to correct you
both on your history:
Smalltalk was being developed at Xerox in the 70s, but except for a
few academics, it was pretty much unknown outside of PARC.
By the mid seventies they had something that would be recognizably
close to today's Smalltalk. Steve Job's came to PARC in 79 and left
impressed ( and then launched work on the Lisa ).
BYTE magazine came out with an issue devoted to Smalltalk in 81 --
that's was the first most people heard of it . [ YES -- in those days,
before internet news connections were ubiquitous, computer magazines
were still a source of "timely" information, and you didn't learn about
the latest computer research or new language the very next day! ]
I bought copies of the first books that came out on Smalltalk-80
in 1983. The books were much easier to get than were any working
systems -- one of the books "SMALLTALK-80 : Bits of History, Words
of Advice" was mostly reports from various groups that had tried to
port it. [ You got a tape image of byte codes for the Smalltalk
virtual machine -- you had to build your own virtual machine to load it.
This was also in the days before C became the "universal assembler" . ]
It was difficult to fit it onto the machines of those days. [ Our main
machine when I was at UPENN was a VAX 750 with the maximum 8MB
memory. ] Most of the implementation reports in that book did not
lead to a commercial product.
Anyone know when the first commercial Smalltalk for PC was released ?
In any case, it can't be *too* far off to say that Smalltalk has been
widely
available only for perhaps less than a decade.
[ This from my greying memory, my ancient copies of
Krasner,Glenn SMALLTALK-80 : Bits of History, Words of Advice. &
Goldberg & Robinson - SMALLTALK-80: The Language and its
Implementations ( both published in 1983 ) and Alan Kays talk in
HOPL-II ( ed. Bergin & Gibson ). ]
JO>: Every single
JO>: programmer who ever wrote a program in Tcl, Perl, C++, Visual Basic,
JO>:or even C could have chosen Lisp, Scheme, or Smalltalk.
>
>Here you show a grievous lack of common sense that goes well with your
>lack of knowledge about language-history. The only programmers who
>would be able to choose Lisp, Scheme, or Smalltalk are those who
>would have known that those languages existed, and you would be
>surprised at how many people do _NOT_ know they exist. I ran into
>these languages because I was _ACTIVELY_ looking for languages,
>this is the same reason I ran into Haskell (my favorite language).
> [ ... ]
There is a recent article in the New Yorker about HDTV, pollution
regulation and technological development, which knocks the notion
that the market can always make the right technology choices -- an
idea that supposes that individuals have perfect knowledge of the
possible choices. That line goes back to Simon's studies on decision
making with imperfect information. The sort of simple minded
market economy argument John Ousterhout uses has become our
ages version of Social Darwinism.
JO>: But they didn't. If you
JO>: want to know the truth, I think you need to stop making superficial
JO>: excuses and ask deeper semantic questions.
I'm afraid I have to agree with Erik Naggum's reply here:
Erik> the way I read this debate, people are asking deep, semantic
questions of
Erik> Tcl and they get superficial excuses for answers.
>Let's see, C became popular for one reason only -- it was almost
>mandatory for programming under Unix which was widespread (and
>still is). So C rode on the coattails of an operating system, and
>was not chosen on any virtue of the language itself.
I think you're off on your history here also.
Going back in time about 20 years:
My friends who did business computing systems used Cobol, BAL
( IBM's BAsic Assembler for 360/370 systems ) and were starting to
use 4GL Database languages where performance and other constraints
allowed.
Everyone I knew in the University used Fortran and some assembler -
mostly on PDP-11s and VAXen -- running RSX11, RT-11 and VMS.
Unix was just starting to make inroads then.
On smaller systems: embedded LSI-11's and early PCs we used FORTH
or Basic.
[ Lisp systems were very incompatible before Common Lisp came around.
I had trouble learning it because none of the Lisp's I had access to
matched the syntax of any of the Lisp books I had ( and they didn't
match each other, either. We got VAX Common Lisp on our 750,
but it was a pig on an 8MB time shared machine. Several companies --
I remember GE and some others -- had some success using Lisp
machines for prototyping and development of expert systems, which
they then ported to FORTH for delivery. ]
C basically filled a need and a vacuum.
"Standard" Pascal was not very usable, and usable Pascal's were not very
standard. Pascal was designed as a teching language -- so even it's
adoption showed the hunger for something better. I used Ratfor
( a preprocessor for Fortran which added some of the features of
C ) for a while. C had and has its faults, but at the time it was
the best thing available. ( as well as Forth, which filled a rather
different niche. In fact, it gave you all of the benefits and more
of Tcl, 20 years ago. ).
Pascal, for all *it's* faults, was neck and neck with C for a while --
especially after Apple chose Pascal for the Mac and Turbo Pascal
became a defacto PC standard. I think Unix and it's close association
with C, the Unix philosophy of programming which spread beyond
Unix by things like Ratfor and books like "Software Tools" , and
finally, Gnu C allowing C compiler backends for every possible
processor to become available, probably gave C a big boost, but
it would be wildly incorrect to say that it's all due to Unix. It
really seemed like the best solution at the time.
> C++ is
>popular for one reason only -- it isn't a far step away from C which
>means that the C crowd flock to it in safety. So C++ rode on the
>coattails of C which rode on the coattails of Unix.
As Steve McQueen says in The Magnificent Seven:
"Reminds me of a feller I once knew -- took off all his clothes
and jumped into a patch of cactus. When they fished him out
and fixed him up, they asked him why he did it."
"He said: 'IT SEEMED LIKE A GOOD IDEA AT THE TIME! ' "
Tcl also seemed like a good idea at the time.
Long Ago, when I was contemplating moving from an LSI-11 running
Forth to a 68000 Unix system, I talked to a programmer in the lab upstairs
who was running Unix system 7 on a PDP-11. I told him that what
I liked about Forth was that I could write new primitive commands
for things like "x y MOVE-BEAM" and 'ACQUIRE-SPECTRUM' ,
and use them and the basic Forth commands to write simple scripts,
test them interactively and do new experiments almost as fast as I
could think of them.
He said: Oh -- that's simple in Unix! There are these tools called Lex
and Yacc you use to write your own command language. You write a
grammar for your language and write the primitive commands in C .
Needless to say, it was not anywhere as simple, easy or fast as what
I had had before. So when I first read John Ousterhout's first Tcl paper,
I though: *Finally* -- something almost as simple as what I had years
ago. But it's a bit of a distortion to write about it as if you've
discovered
some new revolutionary concept in programming languages: Interactivity!
>As for Tcl, it's there for one reason and one reason only -- strong
>corporate backing.
As other have already noted in this thread -- Tcl was developed long
before John Ousterhout was at Sun and it grew without any corporate
backing. Even at Sun, compared to Java, it's getting more what I would
call benign corporate neglect.
- Steve Majewski
<·····@Virginia.EDU>
"Twenty years in the computer business, and all I got to show for
it is this Python T-shirt!" ;-)
From: David Combs
Subject: Re: Correct timelines [was: Reply to Ousterhout's reply ]
Date:
Message-ID: <dkcombsE8s50o.5DA@netcom.com>
In article <··············@128.143.7.209>,
>...
>...
>adoption showed the hunger for something better. I used Ratfor
... ratfor and books like Software Tools ...
...
HOORAY for Software Tools, both the book and the
Lawrence Berkeley Labs (up hill from Berkeley) software system that
implemented it all for the vax, and the effort
at U Ariz that moved it to the DEC-10 & 20!
Had a "cc", macro preprocessor, grep, sh, etc, etc.
At my site we (well, a consultant who REALLY knew
his stuff) added a bunch of stuff to it. Like Recursion.
You'd write this recursive code much as in algol etc,
the macro processor would see it and generate special
code to be seen only by the ratfor "compiler", which
would then generate humongous computed go-to, etc, etc,
maintain stacks for args, locals, etc.
Turned a compu-serv (then t/s company) dec-10 into
an incredible workhorse -- same later for 2060 elsewhere.
Thanks to dave hanson then at Ariz, debbie & others at LBL,
and (of course!) Brian K for the book(s). (Oh, please write
some more, pretty please?).
Man, did they advance the ease of getting things done
via computer!
From: David Combs
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <dkcombsE8s5w5.66q@netcom.com>
> Yes, when I got a copy of SICP last Xmas, I felt I was humouring the
Please, what book title is "SICP"?
From: Gary D. Duzan
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j53ij$i1u@news-central.tiac.net>
In article <·················@netcom.com>,
David Combs <·······@netcom.com> wrote:
=>> Yes, when I got a copy of SICP last Xmas, I felt I was humouring the
=>
=>Please, what book title is "SICP"?
=>
Ah, the joys of cross-posting to a Scheme group. _Structure and
Interpretation of Computer Programs_, by Harold Abelson and Gerald Jay
Sussman with Julie Sussman, recently released in Second Edition.
http://mitpress.mit.edu/sicp/
Gary D. Duzan
Humble Practitioner of the Computing Arts
p.s. I really need to get a copy of the thing. I sold my First Edition
back to the bookstore after the course. (Don't hurt me too badly,
Scheme people; I was an ignorant freshman at the time. I'm better now.)
From: brech patricia
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Date:
Message-ID: <5j54nk$fti@umbc10.umbc.edu>
In article <·················@netcom.com>,
David Combs <·······@netcom.com> wrote:
>> Yes, when I got a copy of SICP last Xmas, I felt I was humouring the
>
>Please, what book title is "SICP"?
>
"SICP" is "Structure and Interpretation of Computer Programs" by Abelson,
Sussman and Sussman, MIT Press (2nd Ed recently out).
From the Scheme FAQ:
"Starts off introductory, but rapidly gets into powerful Lisp-particular
constructs, such as using closures, building interpreters, compilers,
and OO systems... This is the classical text for teaching program
design using Scheme, and everybody should read it at least once..."
prb
--
+-------------------------------------------------------------------------+
Patricia Riley Brech (CMSC) University of Maryland Baltimore County
·······@gl.umbc.edu http://www.gl.umbc.edu/~pbrech1