In article <·························@handma.apple.com>
········@apple.com "Maynard Handley" writes:
> I am not someone who is by nature much interested in the details of
> computer languages---I'd much rather focus on CPU design or my field,
> digital video. However every so often I have been overcom by guilt pangs
> and attempted to read about ideas in computer languages, and I have
> repeatedly been disappointed at the extraordinarily poor quality of the
> books I find. The computer languages field seems to have no Dawkins, no
> Gould, no popularizers and not even any very good text books. Every one of
> the books I have tried has come across as boring, poorly structured,
> making no obvious attempt to justify things and completely unwilling to
> stand by itself. No I don't know lisp, snobol or prolog---that's why I'm
> reading the damn book---so why do we start getting examples using these
> languages in chapter 1?
I agree that more could be done popularise certain languages.
It seems that the supporters of Lisp expect everyone to see how
superior it is to other languages, and just accept it. However,
whatever "superiority" it may or may not have, it's irrelevant
when you have to first know the language to appreciate it, and if
the language can alienate you as effectively as Lisp can, then
you're only likely to learn it once you can appreciate it. Catch-22.
> People write comprehensible text books in fields like math, physics and
> engineering that seem, a priori, substantially more difficult than
> computer languages. I can read one of those and learn the subject right
> off---I don;t have to engage in a strange two-steps-forward, one-step-back
> dance involving reading four books in parallel. I'm a busy guy and if you
> can't be bothered to make your ideas accessible, I'll read other fields
> that do take that time.
Perhaps you just need one really good book? I don't know if
such a book exists. It could be that my own experience has only
been a positive one because I have an "aptitude" for learning
programming languages. It's not unusual for me to learn more
than one at the same time. (I'm currently learning two different
dialects of ML _and_ at least one dialect of Haskell.)
It could be that the people get the best results from using Lisp
are people like myself - people who enjoy the linguistic mind games
that Lisp can make possible. That's not a great way to "sell" a
language to a programmer, as I bet that most people will be like
yourself, too busy and under pressure to _get results_. Even if
you could get the results better by using Lisp, you still need
to learn it, to want to learn it, and to appreciate why this is
what you want. This isn't easy! Instead, it's easy for someone
with an aptitude for a language, and years of experience using
it, to say "it's easy - go on, it'll change your life!"
That's also an argument for surfing, but not everyone is convinced.
I don't blame them. (My nickname is an in-joke, BTW. It's also a
wind-up for anyone who thinks a "name" on a computer screen means
anything.)
You've mentioned Dawkwins, who in his book "The Blind Watchmaker"
spent a whole chapter listing theories that rival Darwin's. Many
of those "doomed rivals" are nothing more than Darwin's own ideas!
The reason for this, Dawkins claims, is coz of a communication
error made by Darwin. Apparently, he gave answering his critics
a higher priority than explaining evolution.
Is this your criticism of tutorials for Lisp and other languages?
> If those people out there who cares about computer languages and
> constantly complain that the world uses nothing but Fortran, C and Cobol,
> want to actually change that situation, they could do worse than to write
> a comprehensible book on the subject.
It's worth adding that I love Lisp, and I appear to understand
it well enough to have written a couple of interpreters & "toy"
compilers. For my own amusement, of course, and because when I
discovered Lisp, I was using a machine for which the only
development tools available to me were C and assembly language.
However, I can see why it alienates people unfamiliar with it.
It appears to me that hardcore Lisp hackers either can't see this,
or they just don't care. The best Lisp tutorials that I've read
give me no problems, but they do introduce new - and sometimes what
to most programmers will be radical - ideas at an alarming rate.
No doubt Lisp isn't unique in this respect. No language has virtues
that are obvious to the uninitiated. Perhaps even languages as
simple and easy to learn as Basic will baffle some people, or just
leave them unconvinced of any "superiority" that many may feel it
has. I suspect that Lisp and Basic are merely examples of two
extremes.
I'm not interested in "language wars", just as I don't care for
"OS wars", or any other daft allegiance some people may feel to
their chosen tools. I'm not going to try to convert anyone who
isn't at least curious about what I'm using, but if I were to try,
then I'm sure it could be done much better than many of the books
available. In other words, whether we're talking about Lisp or
Linux, the books tend to be "preaching to the converted".
While I don't feel there's a great threat to my favourite programming
languages, I don't feel complacent. That could be because of the
lack of support for them. It's there, but it's so small that you
could easily miss it - and most people seem to be unaware of it.
You couldn't easily say that about C...
Today, Fortran, C and Cobol don't need strong advocates, as they're
already "established". Perhaps too well established in some cases.
It's not hard to find critics of Cobol! Still, there are critics
of Fortran, Lisp, and many other languages, and yet we can still
use them and find damn good counter-arguments to most, if not _all_,
of the critisms.
I prefer instead to criticise the would-be advocates of languages.
You've criticised the tutorials, and I agree that they have their
weaknesses. They fail to communicate the joy of using a particular
language, while writers such as Gould and Dawkins excel at it,
writing about science - another potentially very dry subject.
No wonder that so many people have such distorted ideas of what
Lisp is! A bad learning experience can leave a negative impression,
and there's plenty of that to be found. Perhaps there's a little
less evidence of it, now that Java is popularising many of the
ideas that Lisp exploits, but that merely supports the view that
Lisp is being promoted very badly - or not at all.
In short, "must try harder".
Martin Rodgers,
Enrapture Limited
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
> In article <·························@handma.apple.com>
> ········@apple.com "Maynard Handley" writes:
>
> If those people out there who cares about computer languages and
> constantly complain that the world uses nothing but Fortran, C and Cobol,
> want to actually change that situation, they could do worse than to write
> a comprehensible book on the subject.
I couldn't agree more. As regards Common Lisp, the most readable and
enjoyable introduction I've found yet is Paul Graham's ANSI Common Lisp,
published by Prentice hall (ISBN: 0-13-370875-6). It is also a fairly
comprehensive reference as well. I can't recommend it highly enough.
You might also try the Common Lisp Hyper Spec at
<http://www.harlequin.com/books/HyperSpec/FrontMatter/Starting-Points.html>.
This is a great reference and learning tool available free on the web.
Essentially, it's a complete hypertext reference of Common Lisp.
Raf
A Gentile Introduction to Common Lisp by
Dr. David Troursky helped me learn Lisp
and see it was more beautiful then C/C++ or Pascal
ever would. It had no pointers (I don't understand
how to use pointers. :) ) And is interactive like
Basic but much much more powerful.
--
We make the sotfware that powers tomarrow!
In article <·························@handma.apple.com>
········@apple.com "Maynard Handley" writes:
: The computer languages field seems to have no Dawkins, no
: Gould, no popularizers and not even any very good text books.
What an interesting observation! You're right. When Dawkins came to Boston
to promote his new book, I took pains to see him talk, and was happy to sit
on the floor when there were no more chairs. I can't think of anybody in
computer science I'd do that for.
You said you didn't like books that immediately throw code samples at the
reader. I think the intent in such cases is to immerse the reader in the
language, like the idea of learning French by getting lost in Paris without
a guide book. But there's a question of impedance matching, or assumptions
about just how much immersion the reader is ready for. The immersion idea
has definite merits, but perhaps the art hasn't yet been perfected.
Cyber Surfer (············@wildcard.demon.co.uk) wrote:
: ...whether we're talking about Lisp or
: Linux, the books tend to be "preaching to the converted".
I think this might be the reason, that "the converted" exist in such numbers
and with such intensity of feeling in various areas of computer science
(OSes, languages). Joe Weizenbaum talked about "compulsive programmers"
and I think there was a little truth to that. There are lots of undergrads
who are powerfully drawn to computer science, and there's no pressure on
anybody to provide a greater incentive by writing really compelling books
on computer languages that you just can't put down. Maybe this isn't the
case for evolution; I don't recall ever meeting a "compulsive evolution
hacker" when I was in school.
As far as Dawkins, I love his stuff, but he harbors a powerful grudge against
creationists and at times, that grudge drags his writing in a particular
direction, leaving me wondering what it would have been like if he'd just
written out of a passion for explaining things without that kind of agenda.
"Climbing Mount Improbable" is a lovely book, but the whole thing is an
anti-creationist argument.
But you're right, really compelling computer science books would be a great
thing, particularly as computers continue to impact the lives of average
people. And even as somebody who is himself a slightly compulsive programmer,
I often find computer science books pretty inaccessible if they're about a
topic that's pretty new to me.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
In article <··········@world.std.com> ·····@world.std.com "Will Ware" writes:
> I think this might be the reason, that "the converted" exist in such numbers
> and with such intensity of feeling in various areas of computer science
> (OSes, languages). Joe Weizenbaum talked about "compulsive programmers"
> and I think there was a little truth to that. There are lots of undergrads
> who are powerfully drawn to computer science, and there's no pressure on
> anybody to provide a greater incentive by writing really compelling books
> on computer languages that you just can't put down. Maybe this isn't the
> case for evolution; I don't recall ever meeting a "compulsive evolution
> hacker" when I was in school.
The impression I get from the hardcore Lisp people is that there
isn't a problem, and yet almost every programmer I meet thinks of
Lisp as a strange choice. As I have an interest in compilers and
interpreters, perhaps it's not so strange to me, but I can see
why it would seem that way to others.
I've only succeeding in readin CS books because I've had one or
recommended to me by older and wiser programmers, and because when
I see a name crop up again and again, I get curious. My curiosity
has driven me to some pretty far flung corners, but I do sometimes
come back again. When I return, I bring what I've learned with me
and then try and apply it to problems with which I work.
It doesn't suprise me that so few programmers know as much CS as
I do, and I really don't know much! I've still got a lot to learn,
but in the areas that interest me, I seem to know vastly more than
most programmers appear to. This shocks me, but others tell me that
it isn't at all unusual.
Are we overrun with "9 to 5" programmers, or are we too busy to
learn anything more what is absulately necessary in order to do
our jobs vaguely competently? I sometimes wonder.
Somewhere in my homepage, I'm constructing a page listing the books
that I've found most useful as a programmer, and even a few that've
been highly recommended to me, but which I've not yet read. The
danger of collection lists like this based on suggestions from people
on UseNet etc is that they get _very_ long. I'm not sure if anyone
would bother reading my "recommended" list, but it's there anyway.
> As far as Dawkins, I love his stuff, but he harbors a powerful grudge against
> creationists and at times, that grudge drags his writing in a particular
> direction, leaving me wondering what it would have been like if he'd just
> written out of a passion for explaining things without that kind of agenda.
> "Climbing Mount Improbable" is a lovely book, but the whole thing is an
> anti-creationist argument.
I've not read that one yet, but I'm aware of it. Someday...
> But you're right, really compelling computer science books would be a great
> thing, particularly as computers continue to impact the lives of average
> people. And even as somebody who is himself a slightly compulsive programmer,
> I often find computer science books pretty inaccessible if they're about a
> topic that's pretty new to me.
In the 70s, I used to watch Open University shows on TV (see
<URL:http://www.open.ac.uk/> for details), and it never worried
me that the subjects would go right over my head. I read CS books
the same way - if I don't understand it today, perhaps I will
tomorrow, or whenever it is that I'll need it. And I usually do.
There's always enough that I can understand soon after buying a
book to have made it worthwhile, and if I buy a book that I've chosen
myself, it tends to be something I'm pretty damn interested in!
But yes, few of these books are compelling reading. I like the
books with a little humour in them, but there are very few of them.
Knuth's Art of Programming stands out, not just as a CS book (or
books, to be pedantic), but as a fairly _readable_ example. Sadly,
that's not saying much...
I'm sure there are many better CS books that I've just not yet
read, and there are plenty of candidates in my lists of books that
others have recommended. Someday I'll get around to them. In this
respect, I'm the one who should "try harder". ;-)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer (············@wildcard.demon.co.uk) wrote:
: In article <··········@world.std.com> ·····@world.std.com "Will Ware" writes:
: > But you're right, really compelling computer science books would be a great
: > thing, particularly as computers continue to impact the lives of average
: > people.
Computer programming, OTOH, is far from the lives of even most unaverage people.
This is the boring, prosaic 'Why do I need to learn what a distributor is to
drive my car' argument.
And a book to explain why computers crash, for example (this being about the
only encounter you're forced to have with internals) would be a horrible mass
of special cases about bugs in the VM system of WinNT : I wouldn't read it, and
I read compulsively.
: But yes, few of these books are compelling reading. I like the
: books with a little humour in them, but there are very few of them.
: Knuth's Art of Programming stands out, not just as a CS book (or
: books, to be pedantic), but as a fairly _readable_ example. Sadly,
: that's not saying much...
For mathematics, I'd recommend *extremely* highly Knuth's 'Concrete
Mathematics'. It's a book with humour in it about binomial expansions,
recurrence relations, and the sort of mathematics that Applied Mathmos
think too pure, and Pure Mathmos think is contemptibly applied.
I'd recommend 'Computer Architecture - a Quantitative Approach' from
someone-and-Pedderson; it explains very well not only what superscalarity
is, but exactly why you'd want it and exactly how much it helps.
--
Tom
The Eternal Union of Soviet Republics lasted seven times longer than
the Thousand Year Reich
In article <··········@news.ox.ac.uk>,
Thomas Womack <········@sable.ox.ac.uk> wrote:
> And a book to explain why computers crash, for example (this being about the
>only encounter you're forced to have with internals) would be a horrible mass
>of special cases about bugs in the VM system of WinNT : I wouldn't read it, and
>I read compulsively.
But you could write a different book about why computers crash, not
the technical details, but the *real* reason. Talk about what
software engineering is and why it's so difficult, especially on large
projects like operating systems. That could be reasonably accessible
(a la Soul of a New Machine).
--
== Seth Tisue <·······@nwu.edu> http://www.cs.nwu.edu/~tisue/
·····@cs.nwu.edu (Seth Tisue) writes:
> But you could write a different book about why computers crash, not
> the technical details, but the *real* reason. Talk about what
> software engineering is and why it's so difficult, especially on large
> projects like operating systems. That could be reasonably accessible
> (a la Soul of a New Machine).
It doesn't really matter whether software engineering is hard or easy, the
market in the last ten years has shown that once you get the machine
stable enough to run for a couple of hours for the average user, it's
better to spend any additional money/resources on more features and
marketing than on getting out the remaining bugs.
-- Bruce
--
...in 1996, software marketers wore out a record 31,296 copies of Roget's
Thesaurus searching for synonyms to the word "coffee" ...
> > But you could write a different book about why computers crash, not
> > the technical details, but the *real* reason. Talk about what
> > software engineering is and why it's so difficult, especially on large
> > projects like operating systems. That could be reasonably accessible
> > (a la Soul of a New Machine).
>
> It doesn't really matter whether software engineering is hard or easy, the
> market in the last ten years has shown that once you get the machine
> stable enough to run for a couple of hours for the average user, it's
> better to spend any additional money/resources on more features and
> marketing than on getting out the remaining bugs.
At cynical as it sounds, it appears to be true. The new book
by Yourdon "The Rise and Resurretion of the American Programmer"
makes more or less this point. He calls it "Good Enough" programming.
Whether you agree with this or not, the book is worth reading.
Richard Coleman
·······@math.gatech.edu
In article <··········@hoult.actrix.gen.nz>,
Bruce Hoult <·····@hoult.actrix.gen.nz> wrote:
> It doesn't really matter whether software engineering is hard or easy, the
> market in the last ten years has shown that once you get the machine
> stable enough to run for a couple of hours for the average user, it's
> better to spend any additional money/resources on more features and
> marketing than on getting out the remaining bugs.
Man you are *so* cynical. If that was true, why, how could anyone possibly
compete with a company that ships alphas as products and does quality control
by random consumer testing...
--
</peter>
Peter da Silva (·····@nmti.com) wrote:
: In article <··········@hoult.actrix.gen.nz>,
: Bruce Hoult <·····@hoult.actrix.gen.nz> wrote:
: > It doesn't really matter whether software engineering is hard or easy, the
: > market in the last ten years has shown that once you get the machine
: > stable enough to run for a couple of hours for the average user, it's
: > better to spend any additional money/resources on more features and
: > marketing than on getting out the remaining bugs.
: Man you are *so* cynical. If that was true, why, how could anyone possibly
: compete with a company that ships alphas as products and does quality control
: by random consumer testing...
Oh, I don't know. Haven't you just described Microsoft?
[ 8^) Couldn't resist. Now in pennance I must say Hail Hoppers...]
Eduardo
Peter da Silva wrote:
>
> In article <··········@hoult.actrix.gen.nz>,
> Bruce Hoult <·····@hoult.actrix.gen.nz> wrote:
> > It doesn't really matter whether software engineering is hard or easy, the
> > market in the last ten years has shown that once you get the machine
> > stable enough to run for a couple of hours for the average user, it's
> > better to spend any additional money/resources on more features and
> > marketing than on getting out the remaining bugs.
>
> Man you are *so* cynical. If that was true, why, how could anyone possibly
> compete with a company that ships alphas as products and does quality control
> by random consumer testing...
> --
> </peter>
An excellent question. Microsoft's competitors have wondered
about that for years ;-).
Lee.
·····@nmti.com (Peter da Silva) writes:
> In article <··········@hoult.actrix.gen.nz>,
> Bruce Hoult <·····@hoult.actrix.gen.nz> wrote:
> > It doesn't really matter whether software engineering is hard or easy, the
> > market in the last ten years has shown that once you get the machine
> > stable enough to run for a couple of hours for the average user, it's
> > better to spend any additional money/resources on more features and
> > marketing than on getting out the remaining bugs.
>
> Man you are *so* cynical. If that was true, why, how could anyone possibly
> compete with a company that ships alphas as products and does quality control
> by random consumer testing...
You're right. It couldn't possibly happen. I was mistaken. Any company can
rise to the top if they only strive for technical perfection.
-- Bruce
--
...in 1996, software marketers wore out a record 31,296 copies of Roget's
Thesaurus searching for synonyms to the word "coffee" ...
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to ····@docserver.cac.washington.edu for more info.
--0-868179301-851128958=:30168
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sounds to me like a treatise on "The Microsoft Marketing Machine".
*********************
## ##
## R.S., ##
## ##
## Dennis Kegley. ##
## ##
*********************
--0-868179301-851128958=:30168
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=t
Content-Transfer-Encoding: BASE64
Content-ID: <·································@internet.oit.edu>
Content-Description:
DQpGcm9tIHBldGVyQG5tdGkuY29tIEZyaSBEZWMgMjAgMTY6NDA6MTAgMTk5
Ng0KRGF0ZTogMTcgRGVjIDE5OTYgMDA6NTQ6MjcgR01UDQpGcm9tOiBQZXRl
ciBkYSBTaWx2YSA8cGV0ZXJAbm10aS5jb20+DQpOZXdzZ3JvdXBzOiBjb21w
LmFyY2gsIGNvbXAubGFuZy5saXNwDQpTdWJqZWN0OiBSZTogUGFyYWxsZWxp
c20NCg0KSW4gYXJ0aWNsZSA8MjkzMzI2NzYzNUBob3VsdC5hY3RyaXguZ2Vu
Lm56PiwNCkJydWNlIEhvdWx0IDxCcnVjZUBob3VsdC5hY3RyaXguZ2VuLm56
PiB3cm90ZToNCj4gSXQgZG9lc24ndCByZWFsbHkgbWF0dGVyIHdoZXRoZXIg
c29mdHdhcmUgZW5naW5lZXJpbmcgaXMgaGFyZCBvciBlYXN5LCB0aGUNCj4g
bWFya2V0IGluIHRoZSBsYXN0IHRlbiB5ZWFycyBoYXMgc2hvd24gdGhhdCBv
bmNlIHlvdSBnZXQgdGhlIG1hY2hpbmUNCj4gc3RhYmxlIGVub3VnaCB0byBy
dW4gZm9yIGEgY291cGxlIG9mIGhvdXJzIGZvciB0aGUgYXZlcmFnZSB1c2Vy
LCBpdCdzDQo+IGJldHRlciB0byBzcGVuZCBhbnkgYWRkaXRpb25hbCBtb25l
eS9yZXNvdXJjZXMgb24gbW9yZSBmZWF0dXJlcyBhbmQNCj4gbWFya2V0aW5n
IHRoYW4gb24gZ2V0dGluZyBvdXQgdGhlIHJlbWFpbmluZyBidWdzLg0KDQpN
YW4geW91IGFyZSAqc28qIGN5bmljYWwuIElmIHRoYXQgd2FzIHRydWUsIHdo
eSwgaG93IGNvdWxkIGFueW9uZSBwb3NzaWJseQ0KY29tcGV0ZSB3aXRoIGEg
Y29tcGFueSB0aGF0IHNoaXBzIGFscGhhcyBhcyBwcm9kdWN0cyBhbmQgZG9l
cyBxdWFsaXR5IGNvbnRyb2wNCmJ5IHJhbmRvbSBjb25zdW1lciB0ZXN0aW5n
Li4uDQotLSANCjwvcGV0ZXI+DQoNCg==
--0-868179301-851128958=:30168--
In article <··········@hoult.actrix.gen.nz>,
>Bruce Hoult <·····@hoult.actrix.gen.nz> wrote:
>> It doesn't really matter whether software engineering is hard or easy, the
>> market in the last ten years has shown that once you get the machine
>> stable enough to run for a couple of hours for the average user, it's
>> better to spend any additional money/resources on more features and
>> marketing than on getting out the remaining bugs.
>
>Man you are *so* cynical. If that was true, why, how could anyone possibly
>compete with a company that ships alphas as products and does quality control
>by random consumer testing...
Maybe I'm cynical, too. But aren't we just seeing this happening? That
software from a company called MegaHard ? (or whatever it is called?)
Andreas
In article <··········@news.ox.ac.uk>
········@sable.ox.ac.uk "Thomas Womack" writes:
> Computer programming, OTOH, is far from the lives of even most unaverage people.> This is the boring, prosaic 'Why do I need to learn what a distributor is to
> drive my car' argument.
How true. Few of us need to look inside our TV sets, and we're even
warned _not_ to do this. The attitude with computers is sometimes
different. We're often told that installing some free software is
"easy", only to discover that, no, it ain't easy. Cheap, yes, if
your time is free, but not necessarily easy.
> And a book to explain why computers crash, for example (this being about the
> only encounter you're forced to have with internals) would be a horrible mass
> of special cases about bugs in the VM system of WinNT : I wouldn't read it, and
> I read compulsively.
A lot of software will crash because the programmer was optimistic,
and assumed that something (e.g. a function call) couldn't fail.
I shudder whenever I see the source for a program that includes
a call to fopen and doesn't check that the result isn't NULL. Ok,
most of this code is in tutorials, but that doesn't make it any
less serious. After all, where do new programmers learn these bad
habits from? And then there's the gets function...
I'm sure the problem isn't unique to C. There's just a hell of
a lot of C source available. We all know how, err, expensive the
consequences can be. I guess either some programmers committed
mistakes like these _before_ seeing a worldwide software disaster,
or some of us think that it'll never happen to us, to _our_ code.
> For mathematics, I'd recommend *extremely* highly Knuth's 'Concrete
> Mathematics'. It's a book with humour in it about binomial expansions,
> recurrence relations, and the sort of mathematics that Applied Mathmos
> think too pure, and Pure Mathmos think is contemptibly applied.
I know someone who might like such a book...thanks.
> I'd recommend 'Computer Architecture - a Quantitative Approach' from
> someone-and-Pedderson; it explains very well not only what superscalarity
> is, but exactly why you'd want it and exactly how much it helps.
That's more like my kind of book. ;-)
Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer wrote:
> It doesn't suprise me that so few programmers know as much CS as
> I do, and I really don't know much! I've still got a lot to learn,
> but in the areas that interest me, I seem to know vastly more than
> most programmers appear to. This shocks me, but others tell me that
> it isn't at all unusual.
>
> Are we overrun with "9 to 5" programmers, or are we too busy to
> learn anything more what is absulately necessary in order to do
> our jobs vaguely competently? I sometimes wonder.
Strangely enough, I've heard this same complaint from all sorts
of people in CS, in many different areas. "I know so much more
than most people about [OS design/Prog Lang design/weird data
structures/exotic searching and sorting/complex system design/
distributed algorithms/logic design/cpu architecture/computer
design/numerical analysis/combinatorics/discrete mathematics/
real analysis/compiler design/computer graphics/software
complexity/software engineering/parallel algorithms/telecommunications/
network protocols/computability theory/computer simulation
and queueing theory] that it surprises me every day!"
Maybe the problem is partly that the whole field identified with
the label "CS" is much bigger than you give it credit for being
and ranges a lot more widely than perhaps you realize.
I'm sure there are many 9-to5'ers but at the same time CS seems
to me to span a huge range of expertise, making it impossible for
anyone to be an expert everywhere in the field.
Pat
In article <·············@64k.com> ······@64k.com "Patrick Gainer" writes:
> Maybe the problem is partly that the whole field identified with
> the label "CS" is much bigger than you give it credit for being
> and ranges a lot more widely than perhaps you realize.
> I'm sure there are many 9-to5'ers but at the same time CS seems
> to me to span a huge range of expertise, making it impossible for
> anyone to be an expert everywhere in the field.
Another term for 9-5'ers might be "non-CS literate". It's not quite
the same thing, but very close.
My definition of non-CS is anyone who doesn't know or care about CS,
and thinks that they can manage ok withput it. And they do: people
still pay them to write code. ;-)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <·············@64k.com>, Patrick Gainer <······@64k.com> wrote:
>Strangely enough, I've heard this same complaint from all sorts
>of people in CS, in many different areas. "I know so much more
>than most people about
[ laundry list of CS topics ]
> that it surprises me every day!"
>Maybe the problem is partly that the whole field identified with
>the label "CS" is much bigger than you give it credit for being
>Pat
It's true that CS is a very big umbrella, and covers a wide, and sometimes
exotic range of topics.
However, out of your list, it's *still* surprising how little many programmers
know about: software complexity, theory of computation, algorithms, and
important concepts like data abstraction.
Complexity theory and theory of computation are absolutely basic for an
understanding of what computers do and why you can't do certain things, and,
much more importantly, why people are complaining about the performance of you
just-shipped product.
I've seen highly paid programmers use an algorithm that had exponential
complexity where they could have substituted one with logarithmic complexity
if they had a deeper understanding of algorithms.
I get paid to work on a product that implements a flavor of lisp, and uses a
more primitive, less efficient object representation than an interpreter I
wrote as an undergrad.
My (slightly unfocused) point is that there's a core of CS knowledge that's
common across all sub-fields, and it's disturbing how many programmers don't
know the theory behind what they do.
Adam
In article <·············@64k.com>, Patrick Gainer <······@64k.com> wrote:
>Strangely enough, I've heard this same complaint from all sorts
>of people in CS, in many different areas. "I know so much more
>than most people about
[ laundry list of CS topics ]
> that it surprises me every day!"
>Maybe the problem is partly that the whole field identified with
>the label "CS" is much bigger than you give it credit for being
>Pat
It's true that CS is a very big umbrella, and covers a wide, and sometimes
exotic range of topics.
However, out of your list, it's *still* surprising how little many programmers
know about: software complexity, theory of computation, algorithms, and
important concepts like data abstraction.
Complexity theory and theory of computation are absolutely basic for an
understanding of what computers do and why you can't do certain things, and,
much more importantly, why people are complaining about the performance of you
just-shipped product.
I've seen highly paid programmers use an algorithm that had exponential
complexity where they could have substituted one with logarithmic complexity
if they had a deeper understanding of algorithms.
I get paid to work on a product that implements a flavor of lisp, and uses a
more primitive, less efficient object representation than an interpreter I
wrote as an undergrad.
My (slightly unfocused) point is that there's a core of CS knowledge that's
common across all sub-fields, and it's disturbing how many programmers don't
know the theory behind what they do.
Adam
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
>It doesn't suprise me that so few programmers know as much CS as
>I do, and I really don't know much! I've still got a lot to learn,
>but in the areas that interest me, I seem to know vastly more than
>most programmers appear to. This shocks me, but others tell me that
>it isn't at all unusual.
I find it shocking too, but not surprising. One of the problems is that
colleges and universities aren't really teaching Computer Science anymore -
they're teaching C programming. In college I often got into heated arguments
with professors because they were teaching things which had no intellectual
value. I took a course in compiler design at Smith College which devoted 90%
of the course to parsing! We spent most of the semester on Lex and Yacc, and
barely even touched code generation and optimization. Everything I currently
know about compiler design and general language implementation came the hard
way - by doing it myself.
The rationale the professor gave me was that was of very little use to most
people (I had some harsh words for him at that point).
This is not to say that what's being taught in school is useless - I've been
as succesful as I've been in large part due to several exceptional faculty
members, but those exceptional faculty members are vastly overrun by
run-of-the-mill types who don't instill any sense of wonder or even *interest*
in their students.
>Are we overrun with "9 to 5" programmers, or are we too busy to
>learn anything more what is absulately necessary in order to do
>our jobs vaguely competently? I sometimes wonder.
I often wonder too.
>But yes, few of these books are compelling reading. I like the
>books with a little humour in them, but there are very few of them.
>Knuth's Art of Programming stands out, not just as a CS book (or
>books, to be pedantic), but as a fairly _readable_ example. Sadly,
>that's not saying much...
The entire world of computers needs a better sense of humour. I had two
professors in college who made the dry topics of data structures and theory of
computation *fun*. As a consequence, the knowledge stuck with me, and was more
accesible while I was still clueless.
Adam
······@brightware.com (Adam Alpern) writes:
>The entire world of computers needs a better sense of humour. I had two
>professors in college who made the dry topics of data structures and theory of
>computation *fun*. As a consequence, the knowledge stuck with me, and was more
>accesible while I was still clueless.
The best book about basic architecture I have ever seen (and learned a
lot from) is "the Cartoon Guide to Computer Architecture" by Larry Gonick.
You'd have to look quite hard for it though -- I found it by accident
among the cartoon books in the Humor section of a book shop, and had
never even seen it mentioned in any list of CS books.
--
Amos Shapir Net: ····@nsof.co.il
Paper: nSOF Parallel Software, Ltd.
Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551 Fax: +972 3 9388552 GEO: 34 55 15 E / 32 05 52 N
Amos Shapir wrote:
>
> The best book about basic architecture I have ever seen (and learned a
> lot from) is "the Cartoon Guide to Computer Architecture" by Larry Gonick.
> You'd have to look quite hard for it though -- I found it by accident
> among the cartoon books in the Humor section of a book shop, and had
> never even seen it mentioned in any list of CS books.
There's "The Cartoon Guide to the Computer", ISBN: 0-06-273097-5, but I
can't find one with "architecture" in the title.
--
Chris Perrott
In article <··········@world.std.com>, Will Ware <·····@world.std.com> wrote:
>What an interesting observation! You're right. When Dawkins came to Boston
>to promote his new book, I took pains to see him talk, and was happy to sit
>on the floor when there were no more chairs. I can't think of anybody in
>computer science I'd do that for.
I think maybe your problem is Boston.
While I like the really neat work done by friends at the Media Lab,
and some of the work done in surrounded companies, for a particular
conference which I sit on a steering committee, we hear "Don't move the
Conference ot Boston. There's nothing happening here." And that says
nothing of the many other schools around the Boston area.
I'll keep the lisp, because several of those making that comment
are early lispers.
Who would I sit on the floor for in CS?
Well, I am biased. I have a PARC-style bean bag chair in my office
(made by the same person who makes PARC bean bags).
I think I have slouched on the floor for Knuth, Minsky, Norman, Alan Kay,
[I am too respectful of Adele Goldberg to sit on the floor]. Never met
Admiral Grace. I had a chair when I met Seymour. I think there are CS
people around. The guy who wrote the Infoseek search engine had an over flow
crowd in the William Gates Building at Stanford. I didn't get a chair
(sat on a window sill), and people were out in the hall and stayed there.
On Dawkins specifically (since his books are in my to be read pile)(:
I phoned Gould about his comments about evolution and particle accelerators
(with E.O. Wilson) in Ontogeny and Phylogeny (he was reaching, but still
made interesting comments).
>I think this might be the reason, that "the converted" exist in such numbers
>and with such intensity of feeling in various areas of computer science
>(OSes, languages). Joe Weizenbaum talked about "compulsive programmers"
>and I think there was a little truth to that. There are lots of undergrads
>who are powerfully drawn to computer science, and there's no pressure on
>anybody to provide a greater incentive by writing really compelling books
>on computer languages that you just can't put down. Maybe this isn't the
>case for evolution; I don't recall ever meeting a "compulsive evolution
>hacker" when I was in school.
I think the reason for the converted in the feedback interaction speed
of machines (over people) especially when you are doing code development
and you get an error. The imperative nature of programming excites many
people who are able to make the creative vision.
>But you're right, really compelling computer science books would be a great
>thing, particularly as computers continue to impact the lives of average
>people. And even as somebody who is himself a slightly compulsive programmer,
>I often find computer science books pretty inaccessible if they're about a
>topic that's pretty new to me.
Knuth suggested that we ask ourselves: have you read a good program lately?
Not for work, but just for reading pleasure. Not many people do that.
It's funny you mention Weizenbaum, I think that Eliza is one such program
for people to read.
John Lion's original Unix books were recently reprint. That's version 6 Unix.
That's an OS I doubt anyone is running. Why? It's almost insane, well,
there are some interesting ideas inside.
But I think the field is still too young to have something like
The Origin of Species (a good book).
In article <··········@darkstar.ucsc.edu>, ······@cse.ucsc.edu says...
> While I like the really neat work done by friends at the Media Lab,
> and some of the work done in surrounded companies, for a particular
> conference which I sit on a steering committee, we hear "Don't move the
> Conference ot Boston. There's nothing happening here." And that says
> nothing of the many other schools around the Boston area.
Is there anywhere else in this world ? I thought civilization as we know
it ends at the Berkshires, and a few miles south of I90. :-)
Alberto.
In article <······························@news.tiac.net>,
Alberto C Moreira <········@nine.com> wrote:
>In article <··········@darkstar.ucsc.edu>, ······@cse.ucsc.edu says...
>> conference, we hear "Don't move the Conference to Boston.
>> There's nothing happening here." And that says
>> nothing of the many other schools around the Boston area.
>
>Is there anywhere else in this world ? I thought civilization as we know
>it ends at the Berkshires, and a few miles south of I90. :-)
Been there.
Wheeler and Capek and others come as well as NYC and Bell Labs people
(Ken Thompson showed his MiG-29 video, but that's not parallel computing).
But we are still told to meet in California (as the omni-present George
Michael says, "The land of the lotus eaters").
Our meeting has a reasonable pulse of what is happening in Japan from the high
end (we invite David Kahaner, and some day he will come) as well as low
end Yakhabara (I am butchering of my honorable ancestors' tongue).
I think our coverage of India might be a bit weak, but we see talent
from Europe and Russia.
It's not lisp except to say that I didn't get much time to talk with
Dick Greenblatt this year.
I think that in some ways California is overrated. But I am a native.
I guess a lot of people just don't like to shovel snow.
It was once believed that Illinois was the home of parallel machines and
computing. Or Rice/Cornell if you worked for Big Blue. The real
question will be the influence of Washington.
Some of the components of parallel computing need to be placed in the
hands of certain bright and knowledgeable people for a start, and maybe,
that will never be enough.
Alberto C Moreira (········@nine.com) wrote:
: I thought civilization as we know
: it ends at the Berkshires, and a few miles south of I90. :-)
The Berkshires?? You're generous! I think civilization is long gone by
the time you hit Worcester. Doesn't start up again til past Bridgeport, but
by then it's, as you say, not civilization as we know it. They have some
kind of strange red soup they call "clam chowder". Go figure.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
In article <··········@world.std.com>, ·····@world.std.com says...
> Alberto C Moreira (········@nine.com) wrote:
> : I thought civilization as we know
> : it ends at the Berkshires, and a few miles south of I90. :-)
>
> The Berkshires?? You're generous! I think civilization is long gone by
> the time you hit Worcester. Doesn't start up again til past Bridgeport,
but
> by then it's, as you say, not civilization as we know it. They have
some
> kind of strange red soup they call "clam chowder". Go figure.
Well... Amherst is nice; ever had pizza at Antonio's ?
Alberto
In article <··········@world.std.com>, Will Ware <·····@world.std.com> wrote:
>The Berkshires?? You're generous! I think civilization is long gone by
>the time you hit Worcester. Doesn't start up again til past Bridgeport, but
>by then it's, as you say, not civilization as we know it. They have some
>kind of strange red soup they call "clam chowder". Go figure.
In Alberto's defense, you do not have to have civilization, you merely
have to have critical-mass hacker culture. I should be able to put a
toy problem and watch a tinkering brain come up with a non-ordinary solution.
We need more of that kind of thinking away from the lawyers and managers
in NYC.
No longer architecture. F-Us combined. Lisp kept for historical reasons.
Supers.....Coin flip.
In article <······························@news.tiac.net>, ········@nine.com (Alberto C Moreira) writes:
>Is there anywhere else in this world ? I thought civilization as we know
>it ends at the Berkshires, and a few miles south of I90. :-)
Alberto is right. Civilization does end south of I-90.
What is south of I-90? Iowa.
Rob
--
Rob Peglar StorageTek, Network Systems Group
····@network.com 7600 Boone Ave N. Mpls. MN 55428
612.391.1028 612.391.1358 (fax)
Rob Peglar <····@network.com> wrote:
·········@nine.com (Alberto C Moreira) writes:
}>Is there anywhere else in this world ? I thought civilization as we know
}>it ends at the Berkshires, and a few miles south of I90. :-)
}Alberto is right. Civilization does end south of I-90.
}What is south of I-90? Iowa.
You are welcome to keep your `civilization', thank you.
John
--
John Hascall, Software Engr. Shut up, be happy. The conveniences you
ISU Computation Center demanded are now mandatory. -Jello Biafra
····@iastate.edu
http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud
From: Chris Pirih, proverbs at wolfenet dot com
Subject: Re: NIP (was: No longer Parallelism)
Date:
Message-ID: <omlet.32b07007wn@news.aa.net>
In article <··········@news.network.com>,
····@network.com (Rob Peglar) wrote:
| What is south of I-90? Iowa.
Have I wandered into comp.geography.bigot by mistake?
---
chris
Chris Pirih, proverbs at wolfenet dot com wrote:
>
> In article <··········@news.network.com>,
> ····@network.com (Rob Peglar) wrote:
> | What is south of I-90? Iowa.
>
> Have I wandered into comp.geography.bigot by mistake?
Actually... geography does have a lot to do with who we are.
In the beginning... there was Philadelphia. But hardly anybody
alive remembers. There are no know survivors of that tribe who
live on their fathers' land. There is a marker to show where
the tribe once lived.
Then came Poughkeepsie. But few people remember or care.
Then there was a company in Minneapolis that made thermostats
that saw computers as a logical extension of their product line.
A few members of the original tribe set out riding donkeys (or
were they burros? I always forget.) and headed west. They were
said to have been last seen near Blue Bell, Pennsylvania. No
one ever heard from them again.
Then there was Route 128. This is where many people think man
first learned to stand erect and is the beginning of modern
history. Tracy Kidder wrote a tear-jerking book about goings-on
there. Then there were more words which only The Old Ones remember,
like Eclipse and TOPS-10.
At the same time, a splinter group of a splinter group of the
thermostat company decided that there was something about the
cold that allowed them to make computers than ran faster. Deciding
that Minneapolis was not near cold enough, they moved to Chippewa
Falls.
Then Scott McNeily and the surfer boys discovered that you could
build computers *and* have nice weather. An oracle named Terman
had told Scott there wasn't anything indiginous to the water in
Boston that was essential to making computers and that made it
worth putting up with the winters in Boston.
The people on the Hudson, seeing the recruiting advantages for
new_grads for warmer climates, sent a scout party to Austin to
see if one could use the sand in Texas to make silicon wafers.
The scout party never returned. Their parents get Christmas
cards from them occassionally.
Shortly afterward, Jim Clark and George Lucas discovered that
under the right conditions of temperature and humidity, you
could make dinosaurs out of silicon in southern California.
Not long afterward, the housing market went in the tank in much
of the US. Unable to sell his house in Boston without taking a
bath, therefore unable to go join the fun and frolic in the sun,
and in a fit of anger, Ken Olson locked his entire fab team in
the lab and refused to let them see their wives until they
had developed something called "Alpha".
Most recently, archaeologists have become aware of a completely
new tribe in the Seattle area. Very little is known at this
time about the Seattle tribe. So far, this tribe appears to have
no genetic roots in any other previously-known tribe. The current
thinking is that this tribe traces its roots to Asia rather than
North America and that the early members of the tribe walked
across the land bridge which used to exist over the Bering Sea
between Russia and Alaska. Scholars theorize that this tribe has
eluded notice until this time due to the foul weather in Seattle.
Whether the gene pool evolved by this tribe in isolation is as
robust as the genes of the other tribes which have intermarried
is not yet known.
Now do you understand why we cherish our geographic roots?
--
Glen Clark
····@clarkcom.com
Glen Clark <····@clarkcom.com> wrote:
}Chris Pirih, proverbs at wolfenet dot com wrote:
}> In article <··········@news.network.com>,
}> ····@network.com (Rob Peglar) wrote:
}> | What is south of I-90? Iowa.
}> Have I wandered into comp.geography.bigot by mistake?
}Actually... geography does have a lot to do with who we are.
}In the beginning... there was Philadelphia.
In the beginning... there was Ames, Iowa.
}Now do you understand why we cherish our geographic roots?
John
--
John Hascall, Software Engr. Shut up, be happy. The conveniences you
ISU Computation Center demanded are now mandatory. -Jello Biafra
····@iastate.edu
http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud
In article <··········@darkstar.ucsc.edu>
······@cse.ucsc.edu "Eugene Miya" writes:
> But I think the field is still too young to have something like
> The Origin of Species (a good book).
Is that the 1st edition or the 9th edition? ;-)
I think the point that some of us here are making is that a lot
of CS books are like the 9th ed, when they should be more like
the 1st ed. I think that you may also be saying this!
Or have I completely misunderstood everyone?
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>I agree that more could be done popularise certain languages.
>It seems that the supporters of Lisp expect everyone to see how
>superior it is to other languages, and just accept it. However,
>whatever "superiority" it may or may not have, it's irrelevant
>when you have to first know the language to appreciate it, and if
>the language can alienate you as effectively as Lisp can, then
>you're only likely to learn it once you can appreciate it. Catch-22.
I think asserting that one language is "superior" to another is rather
like asserting that a hammer is "superior" to a screwdriver. ;-)
Steve
Stephen O Gombosi (···@rmi.net) wrote:
: I think asserting that one language is "superior" to another is rather
: like asserting that a hammer is "superior" to a screwdriver. ;-)
: Steve
or in the case of perl, a Swiss Army knife...
-eric
Gee, a citation about Kernighan and Plauger, I can see it now, we are
going to completely reinvent software engineering here..... 8^)
And I thought reinventing the ILLIAC was bad enough.
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>>I agree that more could be done popularise certain languages.
We don't want merely popular languages, we NEED useful ones.
>>It seems that the supporters of Lisp expect everyone to see how
>>superior it is to other languages, and just accept it.
...
>>Catch-22.
You can divide-and-conquer the LISP people
(i.e. set flames wars off if you study them carefully,
remember many great advances never seemed to get past
version 7, LISP never got reached 2.0).
In article <··········@rainbow.rmii.com>,
Stephen O Gombosi <···@rmi.net> wrote:
>I think asserting that one language is "superior" to another is rather
>like asserting that a hammer is "superior" to a screwdriver. ;-)
A useful but almost impossible document to find these days to understand
language wars is The Rationale for the Design of the Ada Language.
It represents (1980) the still largely current state of the art in
language design (see the syntax and justification for UNSAFE PROGRAMMING).
One of the things which became clear was that languages themselves were
not enough, thus was born the APSE the Ada Programming Support
Environment, others might call it a pseudo operating system,
most based on Unix (most of Ada was based on Pascal). The LISP answer
at the time was InterLISP. Hence you needed a tool kit......
There, we just jumped from K&P Elements of Programming Style to
K&P Software Tools. ....."What's a software tool?".....
We could collect: great errors in programming language design
(e.g., GOTOs [or not], the original FORTRAN DO-loop, etc.).
We'll reinvent UNICOS(tm) one of these days....... Mark my word!
Wow, and I called Judy at the Usenix offices today for the first time in years.
Deja news.....
with a reference to K&P and this being c.s.s. I should also note:
Bentley: Writing Efficient Programs
Dowd: High Performance Computing
as always.....
GAM just called. I'm away from net.news for the next 3 days, I'm taking
him down to UCSB to see Glen Culler and others so he can chew the fat
and recall even earlier supercomputing history.
Let me know when you guys make it to the mid-1980s.
In article <··········@darkstar.ucsc.edu>
······@cse.ucsc.edu "Eugene Miya" writes:
> You can divide-and-conquer the LISP people
> (i.e. set flames wars off if you study them carefully,
> remember many great advances never seemed to get past
> version 7, LISP never got reached 2.0).
I used to see hordes of C++ demonstrating hpw clueless they were
about compiler theory. Lisp programmers would patiently explain
what the C++ folk had misunderstood, sometimes refering them to
CS papers, implementations, and even applications.
The attacks seemed to stop last year. It may just be a coincidence
that the Java frenzy started around then. Hmm. I wonder...
All I know is that the "pro-Lisp" posts I've seen have been from
well-informed programmers and computer scientists, and the anti-Lisp
(not much doubt there, so no quotes) being based on special cases,
myths, and plain misunderstandings of what a compiler can do.
The only valid criticism I've seen made is that you don't see
many apps written in Lisp, to which the answer has been for
pro-Lisp advocates to list (no pun intended) various AI apps.
I don't think that many people count AI software as "apps".
It's also a little pointless claiming that operating systems
have been written in Lisp, as most people won't recognise
Lisp Machine software, like Genera, as an OS.
A design principle for Smalltalk-80 was that it didn't use an OS.
I remember when I first learned of Smalltalk, and thinking that
delivery would be a problem. I think that Lisp often has the same
problem, but only because few people seem to take it seriously.
On the other hand, C programmers have tended to take delivery
_very_ seriously - desipite the current complaints about code
bloat in, yes, apps written in C++.
I don't think that anyone has "got it right" yet, whether you're
using Lisp or C++. There are, however, a lot of solutions that
work for most people. What creates a lot of confusion are the
differences in values.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <··········@darkstar.ucsc.edu>,
Eugene Miya <······@cse.ucsc.edu> wrote:
>A useful but almost impossible document to find these days to understand
>language wars is The Rationale for the Design of the Ada Language.
>It represents (1980) the still largely current state of the art in
>language design (see the syntax and justification for UNSAFE PROGRAMMING).
I cited this document not to say either that Ada is the wave of the future
or that real-time embedded applications are "it,"
but more as document which gives insights into the thinking and
motivations for why languages are the way they are.
>We could collect: great errors in programming language design
>(e.g., GOTOs [or not], the original FORTRAN DO-loop, etc.).
P.S. A whole generation or two of programmers never saw the problems
with GOTOs. Whole generations of programmers never saw what the problem
with original DO-loops were (you could never NOT execute a loop without
resorting to use another branch: always executed one time was considered
a feature rather than a bug), and other empirically determined lessons.
In article <··········@rainbow.rmii.com> ···@rmi.net "Stephen O Gombosi" writes:
> I think asserting that one language is "superior" to another is rather
> like asserting that a hammer is "superior" to a screwdriver. ;-)
I agree. That's why I prefer to avoid arguments about such things.
Perhaps it's possible to disagree over whether a language is a
hammer or a screwdriver, but that's a little different! We can
often make the error of trying to count the number of angels that
can stand on the head of a pin. Some questions are just a matter
of terminology, like whether a language is interpreted or compiled.
It's better to say, "this one is interactive, while that one is
batch", as that's less easily misunderstood. You'd only be talking
about implementations, however, as many of them come in a variety
of forms.
So, first state your preferences (interactive, native code, etc),
and then your choices, and finally how well they work for you.
That way, you can acknowledge just how subjective such issues are.
It seems to me that language (and OS) "wars" are merely signs that
people don't always share the same values. That should be obvious!
So why do so many of us forget it?
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer wrote:
>
> In article <··········@rainbow.rmii.com> ···@rmi.net "Stephen O Gombosi" writes:
>
> > I think asserting that one language is "superior" to another is rather
> > like asserting that a hammer is "superior" to a screwdriver. ;-)
>
> I agree. That's why I prefer to avoid arguments about such things.
> Perhaps it's possible to disagree over whether a language is a
> hammer or a screwdriver, but that's a little different! We can
> often make the error of trying to count the number of angels that
> can stand on the head of a pin. Some questions are just a matter
> of terminology, like whether a language is interpreted or compiled.
>
> It's better to say, "this one is interactive, while that one is
> batch", as that's less easily misunderstood. You'd only be talking
> about implementations, however, as many of them come in a variety
> of forms.
>
> So, first state your preferences (interactive, native code, etc),
> and then your choices, and finally how well they work for you.
> That way, you can acknowledge just how subjective such issues are.
> It seems to me that language (and OS) "wars" are merely signs that
> people don't always share the same values. That should be obvious!
> So why do so many of us forget it?
> --
> <URL:http://www.enrapture.com/cybes/> You can never browse enough
> Future generations are relying on us
> It's a world we've made - Incubus
> We're living on a knife edge, looking for the ground -- Hawkwind
-----------------------------
In reguards to computer languages, I agree with Cyber Surfer. One
should take the view that each language have inhearant strengths and
weaknesses. Like tools, one language better suited in a set of tasks
than another, but one is not inhearantly superior.
Jeff Kavanaugh <········@internet1.net> writes:
} In reguards to computer languages, I agree with Cyber Surfer. One
}should take the view that each language have inhearant strengths and
}weaknesses. Like tools, one language better suited in a set of tasks
}than another, but one is not inhearantly superior.
On the other hand, there are languages which are clearly inferior.
--
Mike Gebis ·····@ecn.purdue.edu
·····@purcell.ecn.purdue.edu (Michael J Gebis) writes:
>On the other hand, there are languages which are clearly inferior.
True; sometimes people come up with inspired languages. I used to
program in something almost worse than Intercal. Let me put it this
way: Intercal has control structures (or a form thereof), and local
variables. Intercal allows code on more than one line. Intercal is
actually more readable.
I'm still not really sure how this pinnacle of misery was achieved, but
I can testify to programming it for about two years, off and on.
There's a reason why people use C...
--
Graham Hughes (·············@resnet.ucsb.edu)
·······················@A-abe.resnet.ucsb.edu".finger.look.examine
alt.homelike-page."http://A-abe.resnet.ucsb.edu/~graham/".search.browse.view
alt.silliness."http://www.astro.su.se/~robert/aanvvv.html".look.go.laugh
From: Tony Griffiths
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <32ACC7FB.126@OntheNet.com.au>
Graham Hughes wrote:
>
> ·····@purcell.ecn.purdue.edu (Michael J Gebis) writes:
>
> >On the other hand, there are languages which are clearly inferior.
>
> True; sometimes people come up with inspired languages. I used to
> program in something almost worse than Intercal. Let me put it this
> way: Intercal has control structures (or a form thereof), and local
> variables. Intercal allows code on more than one line. Intercal is
> actually more readable.
I doubt that any "inspired" language is of much use in the real world!
Most languages are the product of a lot of hard work...
>
> I'm still not really sure how this pinnacle of misery was achieved, but
> I can testify to programming it for about two years, off and on.
> There's a reason why people use C...
The reason people use C is the same reason Basic became so popular in
the PC world... there is a zero learning curve needed to write your
first 'working' program. Eg.
Basic: 10 print "Hello world"
20 end
C: #include <stdio.h>
main() {
printf("Hello world\n");
}
Most people can come to grips with the above!!! It is your second
working program where a degree of difficulty set in. ;-))
As for programming languages, I would switch back to Ada from C any time
given the opportunity. As a language is is "far" superior to C/C++
simply because more grey matter was applied before the language was
defined. I know it is not perfect, but what language is. I doubt that
you could define such a language! Modula 3, and now possibly Java, fall
into the same category as Ada although there is more "hope" for Java.
The ONLY reason I stick with C is it's universallity (is that a real
word?), but that fact remains that it is not a high quality programming
language.
> --
> Graham Hughes (·············@resnet.ucsb.edu)
> ·······················@A-abe.resnet.ucsb.edu".finger.look.examine
> alt.homelike-page."http://A-abe.resnet.ucsb.edu/~graham/".search.browse.view
> alt.silliness."http://www.astro.su.se/~robert/aanvvv.html".look.go.laugh
Tony
From: Graham Hughes
Subject: programming languages (was Re: Parallelism (superior(?) programming languages)
Date:
Message-ID: <58inee$9tt@A-abe.resnet.ucsb.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Tony Griffiths <·····@OntheNet.com.au> writes:
>I doubt that any "inspired" language is of much use in the real world!
>Most languages are the product of a lot of hard work...
The one I'm talking about was the product of a lot of hard work. :-)
Just the wrong type of work... Unfortunately, it was originally
concieved as a very simple addition to the program in question, and
capabilities (like list iteration and if/then statements) were grafted
onto it over a period of time. It is now Turing compliant, but you
wouldn't want to do much in it. Shows what can happen to a language if
you let enough incompetents hack at it for enough time.
>The reason people use C is the same reason Basic became so popular in
>the PC world... there is a zero learning curve needed to write your
>first 'working' program. Eg.
I don't know too much about that; the APL `first working program' is
just
__
|| <- "Hello World"
--
(compensated for lack of character set), but that doesn't mean people
use it anymore. I think lots of people started using C because it was
much more structured than the assembler and yet was fast enough to write
a Unix kernel, and the language grew from there. C has one major
benefit to an experienced programmer in that it will very happily stay
out of your way, even when you make mistakes. Some of us occasionally
like that trait.
>Most people can come to grips with the above!!! It is your second
>working program where a degree of difficulty set in. ;-))
Certainly true, though.
>As for programming languages, I would switch back to Ada from C any time
>given the opportunity. As a language is is "far" superior to C/C++
>simply because more grey matter was applied before the language was
>defined. I know it is not perfect, but what language is. I doubt that
>you could define such a language! Modula 3, and now possibly Java, fall
>into the same category as Ada although there is more "hope" for Java.
I actually looked at Ada for a while; it's nice in a number of ways
(like it's actually LALR(1)...), but I do most of my grunt work in C++
these days because I'm more comfortable with the object model.
Incidentally, C++ is a language where the features have been grafted on
after the fact, but Bjarne has done a much nicer job than I would of
making the language usable. Most of the cruftiness people associate
with C++ is inherited from the C subset, IMHO.
>The ONLY reason I stick with C is it's universallity (is that a real
>word?), but that fact remains that it is not a high quality programming
>language.
<shrug> The type declaration syntax I take exception with, the implicit
ints all over the place are a pain, and the switch statement really has
no business doing fallthroughs. Other than that, I like the language a
lot; it's very good at what it does.
- --
Graham Hughes (·············@resnet.ucsb.edu)
·······················@A-abe.resnet.ucsb.edu".finger.look.examine
alt.homelike-page."http://A-abe.resnet.ucsb.edu/~graham/".search.browse.view
alt.silliness."http://www.astro.su.se/~robert/aanvvv.html".look.go.laugh
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMqzhCCqNPSINiVE5AQGibgP/c8dO6Y8jJESeF3hgRRBR7MmvJ+/R2aFu
ddEuArOaorew0KcIgjp2sp/VxgnV+CdKds4Y+2wEuk8Jmlyk6e9BDnWVp05MNx+7
gpuFuxQYah85n6xE5SYshTRZvjGyPsoXVku7X5A2gukqIm1P8CRtS5QqUcnRI6VU
OM//v32DI7c=
=6asj
-----END PGP SIGNATURE-----
In article <··········@news.unocal.com>
·······@sugarland.unocal.COM (Richard Ottolini) writes:
>In article <··········@darkstar.ucsc.edu>,
>Eugene Miya <······@cse.ucsc.edu> wrote:
>>What's great about C is that it embodies a KISS principle which we
>>frequently need to be reminded.
Compared to what? I would say C is in direct opposition to the
Keep It Sweet and Simple principle, unless you are comparing
it to C++ or JAVA or something even more complex. I will agree
with you when you show me a C that can compile itself in a couple
of K of memory.
>In the KISS department, JAVA out-"C"s both C and C++,
>although its performance currently sucks.
>I am encouraged how much smaller my codes are in JAVA
>for equivalent functionally in C or C++.
It seems you judge complexity of the language by the length
of application source, while I would use the size of the
compiler source. When I see that many megabytes of source I don't
think of it as an example of simplicity.
Certainly C++ is even further away from KISS than C, but I would
say JAVA is in between. If you think these things are examples of
KISS what are you comparing them to?
Jeff Fox
From: Richard Ottolini
Subject: Re: superior(?) programming languages
Date:
Message-ID: <58mkp6$lij@news.unocal.com>
In article <··············@netcom.com>, Jeff Fox <····@netcom.com> wrote:
>Certainly C++ is even further away from KISS than C, but I would
>say JAVA is in between. If you think these things are examples of
>KISS what are you comparing them to?
I believe the keyword count in JAVA and C are about the same.
Some are replaced by more powerful analogies e.g. class replaces struct
and final replaces #define; some are dropped entirely like short and dereferencing; and a few are added such as catch-throw error handling and threads.
C++ adds lots of keywords to C.
The other measure of complexity is source code- which is significantly shorter
in JAVA than C and slightly short in JAVA than C++.
*But most of the Java interpreters still are inefficient.*
> The other measure of complexity is source code- which is significantly shorter
> in JAVA than C and slightly short in JAVA than C++.
The only really important measure of complexity is how long it takes
a person(s) to update a program to add some new functionality,
where the person(s) have not seen or understood the source code before
making the changes. This is where 90% of programmers time is spent
in the real world --- learning about an existing program and/or changing it.
-Kelly Murray ···@franz.com
Richard Ottolini wrote:
>
> In article <··············@netcom.com>, Jeff Fox <····@netcom.com> wrote:
> >Certainly C++ is even further away from KISS than C, but I would
> >say JAVA is in between. If you think these things are examples of
> >KISS what are you comparing them to?
>
> I believe the keyword count in JAVA and C are about the same.
> Some are replaced by more powerful analogies e.g. class replaces struct
> and final replaces #define; some are dropped entirely like short and dereferencing; and a few are added such as catch-throw error handling and threads.
> C++ adds lots of keywords to C.
Keyword count isn't the same as complexity. Better ask, which
Chomsky-level you need to parse the language. Forth can be parsed with a
state-machine (search for blank). Lisp's parser doesn't need a
lookahead, just count parenthesis and search for blanks. That's
simplicity. Same thing with "compiling": both do a symbol lookup
(string->pointer) and add this pointer to an array (Forth) or a linked
list (Lisp). Certainly there are more sophisticated implementations, but
you can't do this straight-forward approach with C, even if you want to.
> The other measure of complexity is source code- which is significantly shorter
> in JAVA than C and slightly short in JAVA than C++.
But still a factor of three or so times larger than if you do the same
thing in Forth or Lisp. And with Forth, you even can't complain about
performance, or binary compatibility (OpenBoot was cross-platform binary
compatible before Java).
> *But most of the Java interpreters still are inefficient.*
That's because the people at Sun had only one professional in writing
interpreted stack machines, Mitch Bradley (the author of the OpenBoot
interpreter), and AFAIK he left. On the other hand, the Java compiler is
clueless about how to use the stack (all local variables reside in the
stack frame instead around the top of stack when needed), and run-time
tests are performance killer.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
In <··············@netcom.com>, ····@netcom.com (Jeff Fox) writes:
> ...
>Compared to what? I would say C is in direct opposition to the
>Keep It Sweet and Simple principle, unless you are comparing
>it to C++ or JAVA or something even more complex. I will agree
>with you when you show me a C that can compile itself in a couple
>of K of memory.
How little is enough. It could compile itself on PDP11s in 64 KB,
coinhabiting them with Unix (but it didn't have function prototypes then).
> ...
Hartmann Schaffer
From: Rob Warnock
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <58ivka$949@tokyo.engr.sgi.com>
Tony Griffiths <·····@OntheNet.com.au> wrote:
+---------------
| The reason people use C is the same reason Basic became so popular in
| the PC world... there is a zero learning curve needed to write your
| first 'working' program. Eg.
|
| Basic: 10 print "Hello world"
| 20 end
|
| C: #include <stdio.h>
| main() {
| printf("Hello world\n");
| }
+---------------
Scheme:
(display "Hello world")
(newline)
Common Lisp:
(format t "Hello world~%")
So... Explain to me again how that "#include <stdio.h>" and "main(){}" stuff
represents a *ZERO* learning curve???
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
In article <··········@tokyo.engr.sgi.com>
····@rigden.engr.sgi.com "Rob Warnock" writes:
> Scheme:
>
> (display "Hello world")
> (newline)
>
> Common Lisp:
>
> (format t "Hello world~%")
>
> So... Explain to me again how that "#include <stdio.h>" and "main(){}" stuff
> represents a *ZERO* learning curve???
That's easy. Scheme and CL both use symbolic expressions, and
learning curve you have to climb before you can
1) understand what they are,
2) why they're there, and
3) why you'd want to use them
is way to steep for most people.
Perhaps those of us who Lisp use are only those who're fortunate
enough to
1) take a look at Lisp
2) persist long enough to discover 1) thru to 3)
[see above paragraph], and
3) can then find a job in which it's possible to write code in Lisp
I'm in the group of Lisp programmers who would choose Lisp,
but can't find anyone willing to employ us to actually code
in Lisp. So, I'm coding in C++, instead.
Meanwhile, for fun and in my spare time, I'm writing a simple
Lisp to C++ compiler in O'Caml. Don't ask why - my answer will
only be something annoying like, "because I can". Since I prefer
to do other things in my spare time besides programming, I'm
making _very_ slow progress, thus ensuring that a compiler with
absolutely no commercial value will also be of no practical value,
either, as it'll probably be perpetually unfinished.
I do _not_ code in C++ for fun. I did that 10 years ago, when a
C compiler was the only commercially available "high level" language
available to me. The alternative was assembly language. I used
both to write crude Forth and Lisp systems...which were _real_ fun.
On the other hand, it's fun to write multimedia software in C++
and know that, for example, hundreds of thousands of doctors are
using it.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Stanley Chow
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <58jua0$2bj@bcarh8ab.bnr.ca>
In article <··········@tokyo.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>Tony Griffiths <·····@OntheNet.com.au> wrote:
>+---------------
>| The reason people use C is the same reason Basic became so popular in
>| the PC world... there is a zero learning curve needed to write your
>| first 'working' program. Eg.
[Tony supplies complicated examples in Basic & C deleted]
[Rob supplies equally complicated examples in Scheme & Lisp]
>So... Explain to me again how that "#include <stdio.h>" and "main(){}" stuff
>represents a *ZERO* learning curve???
You are forgeting the "System" perspective.
For Basic and C, if the compiler/interpretor is not already on a
machine (any machine), any idiot can buy it at the corner computer
store and install.
For Scheme and Lisp, finding/buying/downloading and then compile/install
is distinctly not for people still learning to write "Hello World".
--
Stanley Chow; ·····@bnr.ca, ················@nt.com; (613) 763-2831
Bell Northern Research Ltd., PO Box 3511 Station C, Ottawa, Ontario
Me? Represent other people? Don't make them laugh so hard.
From: Steve Miklos
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <32B08462.2781E494@citicorp.com>
Stanley Chow wrote:
>
> You are forgeting the "System" perspective.
>
> For Basic and C, if the compiler/interpretor is not already on a
> machine (any machine), any idiot can buy it at the corner computer
> store and install.
>
> For Scheme and Lisp, finding/buying/downloading and then compile/install
> is distinctly not for people still learning to write "Hello World".
So you are saying that one of the qualities of a language is where you
can buy it? I'll remember that next time I'm creating a computer
language...get contracts with Egghead and K-Mart before writing the
technical spec.
Regards,
Steve
--
··············@citicorp.com, ··········@aol.com Steve Miklos @ home
Not speaking for the Big Bank
http://members.aol.com/pialamodem
From: Eugene Miya
Subject: Re: systems now was Parallelism (superior(?) programming languages
Date:
Message-ID: <58s8g6$ftq@darkstar.ucsc.edu>
In article <·················@citicorp.com>,
Steve Miklos <··············@citicorp.com> wrote:
>Stanley Chow wrote:
>> You are forgeting the "System" perspective.
>
>So you are saying that one of the qualities of a language is where you
>can buy it?
No, what Stanley is say was best said by Fred Brooks (now at UNC) in
The Mythical Man-Month:
A system reflects the bureaucracy which created/uses/etc. it.
From: Tony Griffiths
Subject: Re: programming languages (cost/availability .v. usage)
Date:
Message-ID: <32B3AD8E.4590@OntheNet.com.au>
Steve Miklos wrote:
>
> Stanley Chow wrote:
> >
> > You are forgeting the "System" perspective.
> >
> > For Basic and C, if the compiler/interpretor is not already on a
> > machine (any machine), any idiot can buy it at the corner computer
> > store and install.
which is by C/C++ and VB usage has become so wide spread.
> >
> > For Scheme and Lisp, finding/buying/downloading and then compile/install
> > is distinctly not for people still learning to write "Hello World".
>
> So you are saying that one of the qualities of a language is where you
> can buy it? I'll remember that next time I'm creating a computer
> language...get contracts with Egghead and K-Mart before writing the
> technical spec.
No, the quality of the language has absolutely NOTHING to do with it's
uptake. The Ada language is a perfect example of this. A high quality
language (leaves C for dead as I have previously stated) but almost zero
uptake, simply because of availability and cost! While the big vendors
(DEC, IBM, ...) did provide quality compilers their cost was
astronomical in mid-range systems and PC terms. The DEC
compiler/environment cost upward of $100,000 on a machine that was
barely adequate to support a single programmer. In the scheme of a
large defense contract, forking out 0.5 - 1.0 mill for multiple compiler
licenses probably would barely have appeared on the bottom line costing
of a project, but for everyone else it is QUITE significant and meant
that for your smaller project people would fall back on what was
available at affordable cost, ie. C!
There is probably some hope for a quality language (J++?!) given
availability at reasonable cost, although I don't think M$ is prepared
to give up the battle just yet.
Tony
In article <··········@srvr1.engin.umich.edu>,
Paul B. Graham <········@engin.umich.edu> wrote:
>Well, Ada seems no harder than C:
>
> with text_io; use text_io;
> procedure main is
> begin
> put("hello, world");
> new_line;
> end;
>
>Paul
What about Rexx?
say "hello, world";
Or EXEC 2, where you don't even need the quotes:
&print hello, world
Or S/390 assembler, for that matter, given that most run-time environments
have some kind of 'print' function. In the system I use, the program is:
USING *,12 Local addressability (one quickly gets used to this)
LA 1,ST Addr of string
LA 2,L'ST Length thereof
B $WRITE Write to terminal; ret via R14 with R15=0 (success)
ST DC C'hello, world'
COPY $LOW Run-time environment, includes definition of $WRITE
END
This was a complete program. In practice one would probably use a macro,
and I have a choice between one that requires a quoted string argument, and
one that eats raw source lines for better readability:
USING *,12 (The calling convention sets R12)
TYPE 'hello, world' This does roughly what was shown above
TELL -END This macro generates one call to $WRITE per line of text
Here is some free-form text.
I don't even have to worry about embedded quotes or other funny chars (&).
-END
SR 15,15 Claim success
B $RET Return to caller
COPY $LOW
END
(Flame bait? Perhaps, but that is not my intent. Some 15 years ago I used
this example in a talk that addressed the size of object files for small or
simple source programs. That talk *was* flame-bait: "The case against
High-Level Languages" -- the point being that many Hello_world object files
were huge (tens or hundreds of Kbytes), whereas my first example above had
a size dominated by the object file header; the code&text occupied 24 bytes
including the 12-byte string.)
Michel.
From: David Ecale
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <58lh0v$m5p@walter.cray.com>
Bowing down to that false god of computers, BAL, Michel Hack wrote:
USING *,12 *(The calling convention sets R12)
Hmmm.... Now that wouldn't be from sonething on entry like:
STM 13,12,12(13) *(IBM BAL Standard Linkage for Subroutine Calls)
Geeze, I ain't had so much fun since I wrote my last BXLE!
--
David Ecale
·····@cray.com Work = 612-683-3844 // 800-BUG-CRAY x33844
http://wwwsdiv.cray.com/~ecale Beep = 612-637-0873
In article <··········@walter.cray.com>, David Ecale <·····@cray.com> wrote:
>...
> STM 13,12,12(13) *(IBM BAL Standard Linkage for Subroutine Calls)
That's a standard OS/360 (and derivatives all the way to OS/390) linkage
convention. The assembler language (BAL) does not prescribe this. Some
environments (e.g. CMS) have a much simpler convention, and my programming
environment is simpler yet (an old experimental operating system).
Somebody mentioned Visual Basic a bit earlier in this thread (which evolved
from language support for parallelism to the ease of writing "hello world"
programs). I have never used VB, but was stunned once when I browsed a VB
book which took 20 pages to explain how to write a "hello world" program!
I'm sure COBOL can do better than that, even with all DIVISION declarations
included.
Michel.
In article <··········@walter.cray.com>, ·····@cray.com (David Ecale) wrote:
> Bowing down to that false god of computers, BAL, Michel Hack wrote:
>
> USING *,12 *(The calling convention sets R12)
>
> Hmmm.... Now that wouldn't be from sonething on entry like:
>
> STM 13,12,12(13) *(IBM BAL Standard Linkage for Subroutine
Calls)
>
> Geeze, I ain't had so much fun since I wrote my last BXLE!
It must have been a while, since the USING is an assembler directive, not
an runtime instruction, that says "use R12 for my default base register,
and assume that it has this location in it." The instruction to set this
up might have been a subroutine call or a
BALR 12,0
that told the 360 to "branch to register 0 and link using register 12".
Now, branching to register 0 is a special case that says don't branch at
all, so the only effect is to load R12 with the current PC (so it will work
as the base register for all those tiny 12 bit offsets.)
Next week's quiz will be on the translate instruction as used to count bits....
--
Michael
Michael Lyle (·····@wco.com)
In article <································@news.wco.com> ·····@wco.com (Michael Lyle) writes:
>In article <··········@walter.cray.com>, ·····@cray.com (David Ecale) wrote:
>
>Next week's quiz will be on the translate instruction as used to count bits....
Roger Moore (Hopper Award winner for APL\360) did this back in the
early 70's to perform the 3 common Boolean reductions in SHARP APL:
+/ x NB. Count of 1 bits in each row of array x
^/ x NB. Predicate for all bits in row of x being 1 (AND reduce)
or/x NB. Predicate for any bit in row of x being 1 (OR reduce)
He did this in two steps:
a. Copy a hunk of the array to a work area, then apply TR
with a translate table initialized to the number of 1 bits
in the corresponding byte.
b. (Here's where we part company from the norm) Perform
a loop over the translated data, A WORD AT A TIME, summing
the words into some GP register.
At the end of the loop perform a few operations to sum the
bytes in the register.
Exercise for extra credit: How long could the TR argument be,
maximum? Why? Hint: It's NOT 256.
Bob
ps: There was a bit of AND mask prolog when the array row did
not start/end on a byte boundary, of course.
From: David Ecale
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <58qpc3$ki5@walter.cray.com>
Michael Lyle (·····@wco.com) wrote:
<> Next week's quiz will be on the translate instruction as used to count
<> bits....
Piece of easy, just define a translation table (these are restricted to
2^8 characters with the correct bit count for a character in OS/360 BAL.
So, for example (represented here in binary):
<Tr Table Index> <Output table text after Index fetch>
Orig Char: Bit Count:
0000 0000 0000 0000
0000 0001 0000 0001
0000 0010 0000 0001
0000 0011 0000 0010
0000 0100 0000 0001
The text of the table would be (in hex):
00 01 01 02 01 02 02 03 01 02 02 03 02 03 03 04 ... 06 07 07 08
The real tough use of "tr" in BAL was in going from Fieldata (6-bit code)
to EBCDIC (8-bit code) to ASCII (7-bit code) and not losing special
character representations. Especially when the next computer in the
network invariably translated ASCII back to Fieldata! This nightmare was
(partially) resolved by FIPS-14 in 1975 (if memory serves me right).
<<Rule of translation: All foreign codes will be translated into the local
computer's native code for text processing. All text will be re-translated
back to the foreign code, or next outgoing target computer's foreign code
as a last step before transmission.>> Religious wars were fought for years
over the implementation and maintainence of this rule!
--
David Ecale
·····@cray.com Work = 612-683-3844 // 800-BUG-CRAY x33844
http://wwwsdiv.cray.com/~ecale Beep = 612-637-0873
From: Will Ware
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <E27nKp.8K0@world.std.com>
Rob Warnock (····@rigden.engr.sgi.com) wrote:
: Tony Griffiths <·····@OntheNet.com.au> wrote:
: +---------------
: | The reason people use C is the same reason Basic became so popular in
: | the PC world... there is a zero learning curve needed to write your
: | first 'working' program. Eg.
: |
: | Basic: 10 print "Hello world"
: | 20 end
: |
: | C: #include <stdio.h>
: | main() {
: | printf("Hello world\n");
: | }
: +---------------
: Scheme:
: (display "Hello world")
: (newline)
: Common Lisp:
: (format t "Hello world~%")
: So... Explain to me again how that "#include <stdio.h>" and "main(){}" stuff
: represents a *ZERO* learning curve???
He's got a point though: the whole infrastructure is in place for C, in a
way that it isn't for Lisp or Scheme. When you're a clueless newbie and you
first walk up to a computer, chances are it's set up for C (or maybe Basic)
and the whole environment around the computer is designed to support work
in C. The result is that you become another C programmer, and perpetuate
the whole thing.
People sometimes rage against the apparent conspiracy as if there were really
other people working somewhere to systematically wipe out Lisp, at whom the
first bunch ought to be angry. But of course, this isn't the case. Like
Adam Smith's invisible hand, the "conspiracy" that keeps C on top needs no
active sentient planners, just a lot of loosely coupled individuals each
pursuing their own ends.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
From: Steve Barnard
Subject: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <32B0C72D.15A@megafauna.com>
I like C because:
1. It has all the control structures and support for data structures
that I need.
2. It lets me get as close to the machine as I want to get.
3. Pointer arithmetic is the single greatest language feature I've ever
seen for a performance-oriented programmer (Java and Fortran90
notwithstanding).
4. It is extremely portable, if I decide that I want to write portable
code.
5. It doesn't take the stance that I'm an idiot and have to be protected
from my own mistakes. It lets me shoot myself in the foot if I want to.
6. At the same time, it allows me to use the compiler to detect many
programming errors, assuming I have the good sense to use function
prototyping.
I say this as a former Lisp hacker of many years (in my previous AI
life). The only problem I have with Lisp is that it hides the machine,
which is bad if your God is performance.
(I did like *lisp on the CMs.)
Steve Barnard
In article <············@megafauna.com>, ·····@megafauna.com wrote:
> 3. Pointer arithmetic is the single greatest language feature I've ever
> seen for a performance-oriented programmer (Java and Fortran90
> notwithstanding).
Jesus! Btw., pointers on a Lisp machine are called "Locatives".
> 5. It doesn't take the stance that I'm an idiot and have to be protected
> from my own mistakes. It lets me shoot myself in the foot if I want to.
This makes me *really* confident in your software.
> 6. At the same time, it allows me to use the compiler to detect many
> programming errors, assuming I have the good sense to use function
> prototyping.
Basic type errors - maybe.
> I say this as a former Lisp hacker of many years (in my previous AI
> life). The only problem I have with Lisp is that it hides the machine,
> which is bad if your God is performance.
Great! Lisp hides the machine!
Everything else is implementation depended.
Rainer Joswig
From: Steve Barnard
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <32B1725F.78BA@megafauna.com>
Rainer Joswig wrote:
>
> In article <············@megafauna.com>, ·····@megafauna.com wrote:
>
> > 3. Pointer arithmetic is the single greatest language feature I've ever
> > seen for a performance-oriented programmer (Java and Fortran90
> > notwithstanding).
>
> Jesus! Btw., pointers on a Lisp machine are called "Locatives".
>
> > 5. It doesn't take the stance that I'm an idiot and have to be protected
> > from my own mistakes. It lets me shoot myself in the foot if I want to.
>
> This makes me *really* confident in your software.
>
> > 6. At the same time, it allows me to use the compiler to detect many
> > programming errors, assuming I have the good sense to use function
> > prototyping.
>
> Basic type errors - maybe.
>
> > I say this as a former Lisp hacker of many years (in my previous AI
> > life). The only problem I have with Lisp is that it hides the machine,
> > which is bad if your God is performance.
>
> Great! Lisp hides the machine!
>
> Everything else is implementation depended.
>
> Rainer Joswig
You appear to be the type of person who likes religious wars. I say why
I like C and you seem to draw the conclusions that:
- I despise all other programming languages, and especially Lisp,
- I write bug-filled code, as of course all C programmers must.
It's as though I said why I'm a Muslim (I'm not), and you implied that I
must be anti-Christian and evil.
I really like Lisp, too. It is far more pleasant to use Lisp than C,
but you'd have to be a fool to use Lisp for performance-oriented
supercomputer codes, unless there have been some developments in the
last few years that I'm unaware of.
Steve Barnard
From: Christopher Oliver
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <58t7oq$k16@bert.traverse.com>
Steve Barnard (·····@megafauna.com) wrote in COMP.LANG.LISP:
: You appear to be the type of person who likes religious wars. I say why
: I like C and you seem to draw the conclusions that:
It takes more than a little gall to send a pro-C diatribe to a Lisp spec-
ific newsgroup, and then to complain of religious wars when you are scolded.
Quit pulling chains if you wish to live peacefully. I'm finishing a project
which is a Scheme/C hybrid, and I see quite definite uses for both. Lang-
uages are tools; do you repair all things with a mallet?
: - I write bug-filled code, as of course all C programmers must.
Many do. I've read and fixed more than a few disgusting things written
in C.
: but you'd have to be a fool to use Lisp for performance-oriented
: supercomputer codes, unless there have been some developments in the
: last few years that I'm unaware of.
But, being absolutely miserly with cycles is not a universal need in all
problem domains. Not all software are expensive numeric thingies or drive
realtime embedded controllers with low-power hardware; in fact with many
workstations, the CPU spends more than a small percent of its capacity
patiently waiting for keystrokes and mouse actions. (See the work on
CONDOR for a review of this.) Kelly Murray stated it best in that speed
is usually a vastly over-rated criterion. Unfortunately, in my opinion
it often comes in many minds before correctness.
I think most people in comp.lang.LISP are paid to write software, and not
to engage in protracted arguments over their choice of tools. I suspect
the typical members of the other groups in which this flame fodder was
cross-posted share similar concerns. I come to comp.lang.lisp as do
others to read about Lisp, and I instead see your needless chain yanking.
Avec politesse, s'il vous pla�t!
(Note new followup!)
--
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
······@traverse.com Traverse City, Michigan, 49684
The loop macro: because no language is complete without a little COBOL.
From: Steve Barnard
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <32B8D2B7.4FE6@megafauna.com>
Christopher Oliver wrote:
>
> Steve Barnard (·····@megafauna.com) wrote in COMP.LANG.LISP:
> : You appear to be the type of person who likes religious wars. I say why
> : I like C and you seem to draw the conclusions that:
>
> It takes more than a little gall to send a pro-C diatribe to a Lisp spec-
> ific newsgroup, and then to complain of religious wars when you are scolded.
> Quit pulling chains if you wish to live peacefully. I'm finishing a project
> which is a Scheme/C hybrid, and I see quite definite uses for both. Lang-
> uages are tools; do you repair all things with a mallet?
>
[etc., etc.]
So why did you set followup to misc.test, you asshole? Is that supposed
to be funny?
Gall and chain-yanking work both ways. I found a thread in my
newsgroup, comp.sys.super, with the predictable, tiresome theme of Lisp
vs. everything else. Well, everything else has a lot going for it. If
you don't want to hear something about efficient languages then keep out
of comp.sys.super.
Steve Barnard
In article <··········@bert.traverse.com>, ······@co.traverse.com
(Christopher Oliver) wrote:
> : - I write bug-filled code, as of course all C programmers must.
>
> Many do. I've read and fixed more than a few disgusting things written
> in C.
O.k., the real problem is not that **you** are writing bad code
with C, because you are incompetent. The real problem is
that you are writing bad code with C, because it is hard
to write robust and correct code fitting into system-wide
services.
Getting small software doing things right (what is "right"?)
is already hard, but if you are using C for large projects you will
sure get into trouble. Since
the language supports a kind of very implicit programming
the design intent is not obviously clear from looking at the
source code. Many C programmers are thinking on the level
of moving blocks of memory around. Instead they should try
to capture their design so that you are more programming
in a domain specific language. Even though you are trying
to do your best in C, you will have to use poorly written
OS code and you will have to integrate your code into that.
To give you an example: take UNIX. How many programmers have
written their own command parsers? Why? Parsing commands
could be easily defined by system libraries. Someone could
invest a bit of brainwork into that and come up with
a secure design for command parsers and make it standard.
Additional benefit might be the automatic integration into system wide
services (like help system, automatic documentation, ...).
Instead programmers on UNIX (C programmers!) are writing
their own command parsers. If you look at what people
are writing for bullshit to get input from the command line,
its incredible. This is one reason, why Unix has been
known for many security leaks and for its lack of
a comfortable and user friendly command interface
(these machines are shipping with sh and csh!).
Writing good and robust software in C is not impossible,
but it is not very easy and you will not get much support
from the current popular operating systems (MacOS, Window, Unix)
for that.
> : but you'd have to be a fool to use Lisp for performance-oriented
> : supercomputer codes, unless there have been some developments in the
> : last few years that I'm unaware of.
Well, there might be other choices (I'm not very familiar with
super computers) like Sisal. I have yet to see an argument
why it needs to be FORTRAN. There is an excellent infrastructure
(hardware and software)
for FORTRAN on supercomputers - but are there any theoretical
advantages that makes FORTRAN necessarily superior in this domain?
> But, being absolutely miserly with cycles is not a universal need in all
> problem domains. Not all software are expensive numeric thingies or drive
> realtime embedded controllers with low-power hardware; in fact with many
> workstations, the CPU spends more than a small percent of its capacity
> patiently waiting for keystrokes and mouse actions. (See the work on
> CONDOR for a review of this.) Kelly Murray stated it best in that speed
> is usually a vastly over-rated criterion. Unfortunately, in my opinion
> it often comes in many minds before correctness.
Speed is important. But currently personal computers have a lot of
speed and I'd like to see some of this speed being invested
into (runtime!) security and robustness.
We have been using a software that was written in PERL. It was
usable, but as data grew it was to slow for us. We then
used a C program (not written by us). Also very nice.
But as data grew it produced
negative results (well - a simple integer overflow). Since
these errors might not be detected at runtime, you can't
trust this software for anything. We would have been happy
if the C software would run half as fast, and either produce
a correct result (preferred) or tell us if it can't come
up with a correct result. Our Lisp software now runs
fast enough (also due to a clever design) and produces
usable results.
Rainer Joswig
In article <·································@news.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:
> In article <··········@bert.traverse.com>, ······@co.traverse.com
> (Christopher Oliver) wrote:
>
> > : - I write bug-filled code, as of course all C programmers must.
> >
> > Many do. I've read and fixed more than a few disgusting things written
> > in C.
>
> O.k., the real problem is not that **you** are writing bad code
> with C, because you are incompetent. The real problem is
> that you are writing bad code with C, because it is hard
> to write robust and correct code fitting into system-wide
> services.
I just want to make clear that this was *not* a *personal* attack on anyone
directly. It was about the class of programmers per se (which is even
worse). ;-)
Christopher Oliver did not wrote the first sentence
(which you can see if you follow the indentation).
Rainer Joswig
From: Peter da Silva
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <59cko1$giu@web.nmti.com>
In article <·································@news.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
> To give you an example: take UNIX. How many programmers have
> written their own command parsers? Why? Parsing commands
> could be easily defined by system libraries. Someone could
> invest a bit of brainwork into that and come up with
> a secure design for command parsers and make it standard.
Eric Allman released an excellent command parsing library called "parseargs"
that Brad Appleton of Harris and I turned into a nice generic framework that
let you write a single argument definition and have it parse correctly on
UNIX, VMS, MS-DOS, or AmigaDOS depending on which runtime you used.
It's pretty much disappeared without a trace, except for a few of us who
still use it. Which is a pity.
> Writing good and robust software in C is not impossible,
> but it is not very easy
It' *is* easy, but first you have to reinvent a few wheels. Routines
that read a line (word, object, ...) from a file and return a pointer to
a mallocced string, that manage a symbol table, and so on... these
things aren't hard to write (I spent a few weeks getting the factoring right
for my idea of how this stuff should be done, some years ago) and once
you've done it things just fall together.
I've published this stuff on the net, but nobody cares. I've snarfed
indefinite length arithmetic from the net, when I had a need for it, but
now I can't find it. And it's vanished into the great write-only world
wide web.
Hmmm... let's see if I can't dig this stuff up again...
--
UNIX Koan: Karels typed in his password and said, "To call
this a PC is to deny its nature, to call this a
workstation denies its substance. What is it?"
</peter>
From: Martin Cracauer
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <1996Dec16.112423.4543@wavehh.hanse.de>
Steve Barnard <·····@megafauna.com> writes:
>I really like Lisp, too. It is far more pleasant to use Lisp than C,
>but you'd have to be a fool to use Lisp for performance-oriented
>supercomputer codes, unless there have been some developments in the
>last few years that I'm unaware of.
See
http://www.cons.org/cracauer/lisp-c-fp-bench/
for floating point code that is not slower than C (even faster on some
platform/compiler combinations). This is at least the case if you use
CMU Common Lisp (http://www.cons.org/cmucl/). CMUCL has been around
for some years now.
I wrote many programs were I found C (no ++) to be a pleasure to use,
BTW.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
·····@nmti.com (Peter da Silva) writes:
> I've published this stuff on the net, but nobody cares. I've snarfed
> indefinite length arithmetic from the net, when I had a need for it, but
> now I can't find it. And it's vanished into the great write-only world
How about libgmp, available on any GNU site ?
Stefan
From: Peter da Silva
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <59grk8$cnd@web.nmti.com>
In article <··············@daffy.systemsx.cs.yale.edu>,
Stefan Monnier <·······@cs.yale.edu> wrote:
> ·····@nmti.com (Peter da Silva) writes:
> > I've published this stuff on the net, but nobody cares. I've snarfed
> > indefinite length arithmetic from the net, when I had a need for it, but
> > now I can't find it. And it's vanished into the great write-only world
> How about libgmp, available on any GNU site ?
That's not the one I was using, but cool.
--
UNIX Koan: Karels typed in his password and said, "To call this a PC is to
deny its nature, to call this a workstation denies its substance. What is it?"
`-_-' `-_-' `-_-' `-_-' Har du kramat din varg, idag? `-_-' `-_-' `-_-' `-_-'
<virus> :ex:?^.*[e]x:?s/.*\( ?^\)[.]/x:\1./|s/^/:e/|.w!>>~/.signature: </virus>
From: Roger Glover
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <58s1s2$3ul@walter.cray.com>
In article <············@megafauna.com>, Steve Barnard <·····@megafauna.com> writes:
> I like C because:
<snip>
> 3. Pointer arithmetic is the single greatest language feature I've ever
> seen for a performance-oriented programmer (Java and Fortran90
> notwithstanding).
Conversely, most Fortran HPC programming advocates consider C's
pointer *aliasing* constraints to be one of the more important
performance killers in C.
---------------- Cray Research ---------------- *** Roger Glover ***
---------- A Silicon Graphics Company --------- http://home.cray.com/~glover
From: Stanley Chow
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <58sduu$h52@bcarh8ab.bnr.ca>
I think this has really ventured out of the charters of the groups but
it seems like flamebaite to add comp.lang.c[++]; so I will wimp out by
leaving the groups alone.
In article <··········@walter.cray.com>,
Roger Glover <······@hikimi.cray.com> wrote:
>
>In article <············@megafauna.com>, Steve Barnard <·····@megafauna.com> writes:
>> I like C because:
>
><snip>
>
>> 3. Pointer arithmetic is the single greatest language feature I've ever
>> seen for a performance-oriented programmer (Java and Fortran90
>> notwithstanding).
>
>Conversely, most Fortran HPC programming advocates consider C's
>pointer *aliasing* constraints to be one of the more important
>performance killers in C.
My pet theory:
if the compiler has trouble with analysis of a program,
then the typical programmer will not understand that program.
Please note:
1) I am not saying the compiler is smarter. I am saying the compiler
"knows" more of the program than the typical maintainence guy
trying to make a little change.
2) I am not saying "ALL" programmers, just the typical. As in someone
who is not given enough time, has impossible deadlines, etc.
The C language is particularly rich with ways of writing a program
that totally hides the original design intent. And C++ has raised the
obscurity ante to the syntactic level - a real achievement.
--
Stanley Chow; ·····@bnr.ca, ················@nt.com; (613) 763-2831
Bell Northern Research Ltd., PO Box 3511 Station C, Ottawa, Ontario
Me? Represent other people? Don't make them laugh so hard.
From: Glen Clark
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <32B333DC.5FC32A25@clarkcom.com>
Stanley Chow wrote:
> The C language is particularly rich with ways of writing a program
> that totally hides the original design intent.
Some things are just so elegant, many of Frank Lloyd Wright's
designs come to mind, that you just want to stand and marvel
at them. I think the above one-liner is in that class.
--
Glen Clark
····@clarkcom.com
State College, PA
From: Peter da Silva
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <594ro9$ju1@web.nmti.com>
In article <·················@clarkcom.com>,
Glen Clark <····@clarkcom.com> wrote:
> Stanley Chow wrote:
> > The C language is particularly rich with ways of writing a program
> > that totally hides the original design intent.
> Some things are just so elegant, many of Frank Lloyd Wright's
> designs come to mind, that you just want to stand and marvel
> at them. I think the above one-liner is in that class.
It's a great one-liner, but it seems to me that if your code hides your
intent then you shouldn't have taken on that code, except perhaps as a
learning experience, in the first place. Sorta like the way Utson quit
halfway through the building of the Sydney Opera House because his design
was unworkable... the resulting structure is in my mind far more beautiful
than the low elliptical arches he wanted. He shouldn't have tried to
actually implement his inspiration...
--
</peter>
From: Stanley Chow
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <596s4c$bmu@bcarh8ab.bnr.ca>
In article <··········@web.nmti.com>, Peter da Silva <·····@nmti.com> wrote:
>In article <·················@clarkcom.com>,
>Glen Clark <····@clarkcom.com> wrote:
>> Stanley Chow wrote:
>> > The C language is particularly rich with ways of writing a program
>> > that totally hides the original design intent.
>
>> Some things are just so elegant, many of Frank Lloyd Wright's
>> designs come to mind, that you just want to stand and marvel
>> at them. I think the above one-liner is in that class.
Thanks Glen.
>
>It's a great one-liner, but it seems to me that if your code hides your
>intent then you shouldn't have taken on that code, except perhaps as a
>learning experience, in the first place.
Hmm, aren't you making some pretty strong assumptions?
"Your code", "your intent", "shouldn't take on", "learning".
Of course, I only ever write well-structured, clearly-commented,
trivial-to-understand, simple-to-modify, universially-portable,
algorithmicly-optimal and micro-efficent programs; and surely
your standard is similar. As I always say:
if you can't afford a year to write a hundred *good* lines,
you ought not be programming in C.
We are discussing those unwashed masses - not trained to appreciate
the subtle distinctions between pointer and array, unaware of how
some compiler writers take "implementation dependent" at face
value. Those fools actually have to take some grubby code and make
some changes, worse, they even have to meet deadlines or stop
feeding their kids! How barbaric can you get!
>Sorta like the way Utson quit
>halfway through the building of the Sydney Opera House because his design
>was unworkable... the resulting structure is in my mind far more beautiful
>than the low elliptical arches he wanted. He shouldn't have tried to
>actually implement his inspiration...
I am not sure what this means. Are you saying people should forget
their design and just write code? Or are you saying people should
adapt their design as the project progresses?
--
Stanley Chow; ·····@bnr.ca, ················@nt.com; (613) 763-2831
Bell Northern Research Ltd., PO Box 3511 Station C, Ottawa, Ontario
Me? Represent other people? Don't make them laugh so hard.
From: Peter da Silva
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <59clgn$j5m@web.nmti.com>
In article <··········@bcarh8ab.bnr.ca>, Stanley Chow <·····@bnr.ca> wrote:
> >Sorta like the way Utson quit
> >halfway through the building of the Sydney Opera House because his design
> >was unworkable... the resulting structure is in my mind far more beautiful
> >than the low elliptical arches he wanted. He shouldn't have tried to
> >actually implement his inspiration...
> I am not sure what this means. Are you saying people should forget
> their design and just write code? Or are you saying people should
> adapt their design as the project progresses?
I'm saying that if you pick tools and a design that don't work together,
it's your fault, not the tools. God knows I don't want to write everything
in C. I use Tcl for most of my stuff these days, and I use "eval" a lot.
It's got a lot of the good aspects of lisp, actually. And it's missing a lot
don't get me wrong...
But I do still use C a bunch, rather than C++ or Java or Perl, when Tcl
isn't fast enough or doesn't fit the problem domain. I enjoy working in
it, when I'm working on a job that fits it.
But writing a substantial program in C *does* involve building a lot of
supporting structure. That's part of the design process, for C. If
someone chooses not to do that, it's their fault. Utson didn't take the
time to see if his design was buildable with the materials he had available
and that cost a lot of time and redesign. He wasn't the right programmer
for the job...
But if they'd waited for the materials to be available to fit his design,
at a price they could afford, I don't think the thing would have been built.
(and no, I'm not making any assumptions about you personally. When I said
"your code" I was using it in a generic sense... not Stanley Chow, but
some random programmer who wrote code that obscured his design. I apologise
for my unclear intent. I wasn't trying to insult you... it just sort
of happened. I picked the wrong communication tools I guess.)
--
UNIX Koan: Karels typed in his password and said, "To call
this a PC is to deny its nature, to call this a
workstation denies its substance. What is it?"
</peter>
From: Martin Cracauer
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <1996Dec16.114937.4699@wavehh.hanse.de>
Steve Barnard <·····@megafauna.com> writes:
>1. It has all the control structures and support for data structures
>that I need.
So, has GWbasic all the constructs you'd need? No? IMHO, the features
a programmer feels a need for rely on what he did before.
People usually use a subset of what their language offers (mostly a
fairly complete subset). Since they already have some constructs they
don't need in their current langauge, the impression that more
powerful langauges offer no more features than needed is close.
The situation gets really bad when a programmers comes around to learn
a langauge where the number of features are minimized, but the
flexibilty of features is maximized (A dinfition of what Scheme is
intended to be).
At that point, one can get really frustrated with any number of
features as long as the langauge doesn't allow to define your own
implementations of features of the same power of they build-in
features of the language.
In other words: The point about Lisp is that you can work on a
'meta-level', in C you are bound to a number of language features.
>2. It lets me get as close to the machine as I want to get.
What about alignment in structures? The compiler doesn't support
control without non-ANSI extensions. You'll have to use byte arrays to
do so portably, but then you can do the same in Lisp.
>3. Pointer arithmetic is the single greatest language feature I've ever
>seen for a performance-oriented programmer (Java and Fortran90
>notwithstanding).
See below.
>4. It is extremely portable, if I decide that I want to write portable
>code.
printf is part of the language, no? So, could you please give me an
example how you can write a printf control string that prints a data
type where the actual type is hidden by a typedef inside an include
files that is machine-dependent?
This is obviously not a difficult part for (format ...)
The NetBSD folks who have an OS that is portable across a number of
machine already though of adding a printf %-directive that accepts a
control string where the data type to print is given. Something like
printf("%(off_t)I",some_off_t). Of course, such a solution would still
require that your output format is still the same for all types.
>5. It doesn't take the stance that I'm an idiot and have to be protected
>from my own mistakes. It lets me shoot myself in the foot if I want to.
A good Lisp compiler offers all the Guns you need. It is certainly
more difficult to use than in C, don't pointers to any lacation are
part of all high-quality Lisp implementations I know of.
>6. At the same time, it allows me to use the compiler to detect many
>programming errors, assuming I have the good sense to use function
>prototyping.
This is the usual static/dynamic typing debate and a matter of
taste. Common Lisp and Scheme clearly decided to be on the dynamic
side. You might want to look into SML if you want static typing. I
don't know too much about it, but my above points about low-level
features in high-quality Lisp implementation certainly apply to SML/NJ
as well. ML introduces some performance problems by definition, maybe
someone can point out a langauge that is Lisp-like, but to so much
functional-programming oriennted as ML (and has a descent compiler).
>I say this as a former Lisp hacker of many years (in my previous AI
>life). The only problem I have with Lisp is that it hides the machine,
>which is bad if your God is performance.
I like C, too and there are many point I don't like about Common Lisp
and Scheme, but performance is no longer the reason to prefer one of
the other. A C function in a Lisp program usually does its job as
well when I'm too lazy to beat on my Lisp compiler.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
From: Peter da Silva
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <594rr6$juf@web.nmti.com>
In article <·····················@wavehh.hanse.de>,
Martin Cracauer <········@wavehh.hanse.de> wrote:
> >4. It is extremely portable, if I decide that I want to write portable
> >code.
> printf is part of the language, no?
No.
--
</peter>
Peter da Silva (·····@nmti.com) wrote:
: > printf is part of the language, no?
: No.
printf() is part of ANSI/ISO C. But it's in the standard library, not
a keyword.
--
--token
·····@nmti.com (Peter da Silva) writes:
> > printf is part of the language, no?
>
> No.
No? You mean it's not part of the standard library, and a conforming ANSI C
programme is not allowed to use any and all parts of the standard library?
Jan
From: Roger Glover
Subject: Re: Parallelism (superior(?) programming languages
Date:
Message-ID: <58l37l$sf0@walter.cray.com>
In article <··········@tokyo.engr.sgi.com>, ····@rigden.engr.sgi.com (Rob Warnock) writes:
> Tony Griffiths <·····@OntheNet.com.au> wrote:
> +---------------
> | The reason people use C is the same reason Basic became so popular in
> | the PC world... there is a zero learning curve needed to write your
> | first 'working' program. Eg.
> |
> | Basic: 10 print "Hello world"
> | 20 end
> |
> | C: #include <stdio.h>
> | main() {
> | printf("Hello world\n");
> | }
> +---------------
>
> Scheme:
>
> (display "Hello world")
> (newline)
>
> Common Lisp:
>
> (format t "Hello world~%")
>
> So... Explain to me again how that "#include <stdio.h>" and "main(){}" stuff
> represents a *ZERO* learning curve???
Well **I** want to know about that "\n" thingy! What the heck is it
there for? AND WHY DIDN'T IT PRINT OUT?! Everything I printed in my
Basic program came out. See? What's wrong with this "C" sh*t?
---------------- Cray Research ---------------- *** Roger Glover ***
XXXX\ \ / \ /XXX \ / \ X \ /\\\ X///X /\\\ *** Software Instructor ***
/ \ / \/ /\ / \ / \X /\ X \ / \ X\ \ X DISCLAIMER HAIKU:
//X/ X\\\X //X/ X \ X X\\ / \ X/X \ X \\\ C R^H^H^H^H S G I may not
/ \ X///X / \/ X//XX X \ / \ X \\ X \ Share these opinions with me
/ \ X X /\\\/ X X X///X /XXX/ X///X /XXX/ This is not my fault
---------- A Silicon Graphics Company --------- http://home.cray.com/~glover
Veteran soldier^H^H^H^H^H^H^H^H instructor of many a C, C++, UNIX
Usage, Shell Programming, and (more recently) Java class
"Repeat after me: there is joy beyond the pain, there is joy beyond
the pain, there is ..."
This is my favorite topic to hate, so I think I will add my $.02 worth
:-)...
Tony Griffiths <·····@OntheNet.com.au> wrote in article
<············@OntheNet.com.au>...
> Graham Hughes wrote:
> >
> > ·····@purcell.ecn.purdue.edu (Michael J Gebis) writes:
> >
> > >On the other hand, there are languages which are clearly inferior.
Reall? I will get back to this later...
> >
> > True; sometimes people come up with inspired languages. I used to
> > program in something almost worse than Intercal. Let me put it this
> > way: Intercal has control structures (or a form thereof), and local
> > variables. Intercal allows code on more than one line. Intercal is
> > actually more readable.
>
When people say that a programming ,anguage is inferior they usually mean
that they don't like it or it doesn't suit a certain task well. As an
example, I took a two semester programming class; during the first semester
a language called ISetL was used (Interactive Set Language). As the name
suggests, it is a set language and crunches numbers quite well. However,
in the class it was used for everything from number crunching to string
manipulation (you know there is a flaw in your reasoning when you are
packing characters into a tuple in order to make a string :-). I like
ISetL, I didn't like ISetL as it was used in that class. There is also the
case of compiler/interpreter/platform dependencies. On MS-DOS ISetL is
very restricted as to memory usage and therefore was slooooooooow. It
would take several minutes to search a file containing Poe's "Raven" and
print out a word count. This implementation of ISetL is obviously inferior
to a 32-bit assembler version of "wc" on NT which can search the same file
instantly.
> I doubt that any "inspired" language is of much use in the real world!
> Most languages are the product of a lot of hard work...
I agree. There are tons of "neat" new (and old) languages out there that
no one uses because a) they attempt to introduce an entirely new paradigm
which makes them highly undesireable when writing mission-critical code, or
b) they do something that another language already does. Are they
inferior? Nope, just different. Are they inferior for a partcular purpose?
Yep.
>
> >
> > I'm still not really sure how this pinnacle of misery was achieved, but
> > I can testify to programming it for about two years, off and on.
> > There's a reason why people use C...
>
> The reason people use C is the same reason Basic became so popular in
> the PC world... there is a zero learning curve needed to write your
> first 'working' program. Eg.
>
> Basic: 10 print "Hello world"
> 20 end
>
> C: #include <stdio.h>
> main() {
> printf("Hello world\n");
> }
Hmmm...why is the "main" part outside of the parenthesis? And what do
those {} mean? Why aren't there any line numbers? :-) I think it is a
long shot to say that C has a zero learning curve for anything.
>
> Most people can come to grips with the above!!! It is your second
> working program where a degree of difficulty set in. ;-))
>
True, but your argument is non sequiter. What your saying is that because
the hello world program in C is easy, C became one of the most popular
programming languages.
> As for programming languages, I would switch back to Ada from C any time
> given the opportunity. As a language is is "far" superior to C/C++
> simply because more grey matter was applied before the language was
> defined. I know it is not perfect, but what language is. I doubt that
> you could define such a language! Modula 3, and now possibly Java, fall
> into the same category as Ada although there is more "hope" for Java.
>
How so? I see java as a hacked up C++...
> The ONLY reason I stick with C is it's universallity (is that a real
> word?), but that fact remains that it is not a high quality programming
> language.
Can you elaborate on what you mean by a high quality programming language?
Weak vs. strong typing? High level constructs?
Tony Griffiths <·····@OntheNet.com.au> wrote in article
><············@OntheNet.com.au>...
>> I doubt that any "inspired" language is of much use in the real world!
>> Most languages are the product of a lot of hard work...
In article <··························@aqualung>,
Phillip N Toland <······@epix.net> wrote:
>This is my favorite topic to hate, so I think I will add my $.02 worth
>:-)...
>I agree.
I will disagree. The problem is that every language is inspired to its
designer. The problems come over time when we ask languages to do
things they were never intended to do. Hence "environments."
Tony's statement while well intended is just slightly off the mark.
My big problem with a lot of computing is that it lack empirical
basis as a science. It's too young. We only learn about problems after
a period of time, not merely hard work.
>There are tons of "neat" new (and old) languages out there that
>no one uses because a) they attempt to introduce an entirely new paradigm
>which makes them highly undesireable when writing mission-critical code, or
>b) they do something that another language already does. Are they
>inferior? Nope, just different. Are they inferior for a partcular purpose?
>Yep.
We must accomplish a task, work, etc.
The problem is that we must balance that against featuritis.
That's by extensibility is important. People do use COMPLEX variables
in FORTRAN, but fewer do work in quarterions, should users have to balance
variable names because of the lack of user defined types?
The Little Languages philosophy is an important one. The second
language I attempted to learn was PL/1. Lots of lessons there.
>> C: #include <stdio.h>
>> main() {
>> printf("Hello world\n");
>> }
I will collect the Hellos and add them to the cft77, Pascal, Ada, C,
Scheme, and CL versions. Other versions can be mailed to me..... 8^)
and if a compiler runs on a Cray, I will HPM them.
>Can you elaborate on what you mean by a high quality programming language?
>Weak vs. strong typing? High level constructs?
"Strong typing is for weak minds...." famous quote.
First, a high quality programming language prevents me from
unintentionally shooting myself in the foot. Typing is merely one
attempt at a compile time solution.
Constructs, sure! User defined data types and structures: can be helpful.
But what about the compile and run-time environments?......
Big subjects. No time.
Eugene Miya wrote:
> But what about the compile and run-time environments?......
Make files should not be required, compiler should be able to figure
out dependencies on its own.
Language should be fully definable using EBNF.
I leave it to the reader to draw his own conclusions about the languages
popular today.
--------------------------------------------------------------------
Pascal Dornier ········@best.com http://www.best.com/~pdornier
Your Spec + PC Engines = Custom Embedded PC Hardware
--------------------------------------------------------------------
Pascal Dornier <········@best.com> wrote:
>
> Language should be fully definable using EBNF.
Including the semantics?
Tony.
--
Strc prst skrz krk
From: William Clodius
Subject: Re: superior(?) programming languages
Date:
Message-ID: <32AE079C.7DE1@lanl.gov>
Pascal Dornier wrote:
> <snip>
> Language should be fully definable using EBNF.
> <snip>
Thats a pretty meaningless language. EBNF specifies syntax but not
semantics. Describable using just EBNF means that all you can do is
parse the code and determine whether the code is syntactically correct.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
In <··········@darkstar.ucsc.edu>, ······@cse.ucsc.edu (Eugene Miya) writes:
> ...
>I will disagree. The problem is that every language is inspired to its
>designer. The problems come over time when we ask languages to do
>things they were never intended to do. Hence "environments."
>Tony's statement while well intended is just slightly off the mark.
My experience is that languages become popular when reasonably efficient
implementations become available in an environment where other alternatives
are, for whatever reason, less attractive. Given that learning a new
language is always an effort (even though pleasurable on occasion), they
will always run into some resistence as long as you can get away with using
the established languages in any given environment. Plus, there is always
the problem of "but we have so much invested in ...", "everybody knows ..."
Hartmann Schaffer
In article <············@nic.wat.hookup.net>, <········@wat.hookup.net> wrote:
>My experience is that languages become popular when reasonably efficient
>implementations become available in an environment where other alternatives
>are, for whatever reason, less attractive.
Sort of.
Languages became popular because fairly portable compilers written in
the languages themselves became available and popular. The Pascal P4
and the C pcc compilers did a lot to spread those languages around.
That a C compiler existed on the Cray-1 under COS done by the people who
did C gave CRI a 3-6 month head start on the CRI UNIX port.
Good languages also tend to have a small reasonable set of orthogonal
features.
Keeping compilers as intellectual property close to their authors adds
to a degree of detriment.
Some language designers tend to discount implementations (I lived
through the Ada period). You really need to have a compiler to know
where you designed the language wrong.
>Given that learning a new
>language is always an effort (even though pleasurable on occasion), they
>will always run into some resistence as long as you can get away with using
>the established languages in any given environment. Plus, there is always
>the problem of "but we have so much invested in ...", "everybody knows ..."
Oh yes.
Remember, too, the worn maxim:
Good people copy. Great people steal.
In article <··········@darkstar.ucsc.edu>
······@cse.ucsc.edu "Eugene Miya" writes:
> My big problem with a lot of computing is that it lack empirical
> basis as a science. It's too young. We only learn about problems after
> a period of time, not merely hard work.
Agreed. This applies to individual programmers, as well as to
programmers as a whole (and what a hole...)
> We must accomplish a task, work, etc.
> The problem is that we must balance that against featuritis.
> That's by extensibility is important. People do use COMPLEX variables
> in FORTRAN, but fewer do work in quarterions, should users have to balance
> variable names because of the lack of user defined types?
I'm not familiar with F90, but from what I've read about it, I'd
expect it to be possible to be able to cope with quarternions as
easily as C++ - once you've defined a Quarternion class, that is.
Neat things, quarternions. I'd love to get a video tape of the
4D (3D plus time) animation somebody did of quarternion fractals.
That's a great way to show how much fun these numbers can be!
> The Little Languages philosophy is an important one. The second
> language I attempted to learn was PL/1. Lots of lessons there.
There's another language that I'm unfamiliar with. No doubt I'm
better off not knowing more about it! If there's a version of
Colossal Cave written in PL/1, then I'd still dig out the Pascal
(p_system) version lurking on one of my old 5 1/4" floppies, and
see if I can port to something that I'm still using (Delphi?).
On the other hand, perhaps by avoiding PL/1, I've missed a class?
Hmmm.
> >> C: #include <stdio.h>
> >> main() {
> >> printf("Hello world\n");
> >> }
>
> I will collect the Hellos and add them to the cft77, Pascal, Ada, C,
> Scheme, and CL versions. Other versions can be mailed to me..... 8^)
> and if a compiler runs on a Cray, I will HPM them.
In Forth:
: hello ." Hello, World!" cr ;
Alternately, here's a Nepalese version:
: namaste! ." Namaste!" cr ;
> >Can you elaborate on what you mean by a high quality programming language?
> >Weak vs. strong typing? High level constructs?
>
> "Strong typing is for weak minds...." famous quote.
>
> First, a high quality programming language prevents me from
> unintentionally shooting myself in the foot. Typing is merely one
> attempt at a compile time solution.
Here's one of my favourite programming quotes:
"C makes it easy to shoot yourself in the foot. C++ makes it
harder, but when you do, it blows away your whole leg."
-- Bjarne Stroustrup on C++
BTW, I _like_ strong type checking. Just not all the time, ;)
On other words, I'm happy if the compiler can infer the type
of an object, and then _tell_ me what it thinks the type is.
This is why I like ML, and the O'Caml compiler in particular.
I also like compilers that report the first error and then
stop. Reporting 100 errors caused by a typo on a single line
is just plain silly. Perhaps this would be less of a problem
if "batch" (i.e. C/C++, etc) compilers could recover better.
> Constructs, sure! User defined data types and structures: can be helpful.
User defined abstractions, meta-programming: weird but wonderful.
> But what about the compile and run-time environments?......
I like the distinction. Not every language enviroment makes it.
Once upon a time, I couldn't find a Basic that made it. Now
it's hard to find one that _doesn't_.
Meanwhile, the Scheme to C compiler that seems closest to
working on my machine includes EVAL in the runtime. I think
of EVAL as a development tool, not a runtime tool.
See if you can guess why I don't want EVAL:
1,953 test.obj
76,357 _errors.obj
373,860 _eval.obj
4,314 c_intf.obj
1,777 main.obj
10,722 setup.obj
12,409 mem.obj
3,293 os.obj
Not that Lisp is unique in this respect...But on this particular
platform, the VB and VC++ runtime support can be shared between
apps. The solution is obvious - put the Lisp runtime in a DLL.
> Big subjects. No time.
There never is enough time, alas.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Michael Williams
Subject: Re: superior(?) programming languages
Date:
Message-ID: <58omt9$psg@sis.armltd.co.uk>
In article <··········@darkstar.ucsc.edu>,
Eugene Miya <······@cse.ucsc.edu> wrote:
>>> C: #include <stdio.h>
>>> main() {
>>> printf("Hello world\n");
>>> }
>
>I will collect the Hellos and add them to the cft77, Pascal, Ada, C,
>Scheme, and CL versions. Other versions can be mailed to me..... 8^)
>and if a compiler runs on a Cray, I will HPM them.
During my time at University a group of us undergraduates endeavoured
to create a collection of hello world programs, in over 30 languages.
I've put the collection on the web - though only on a part-time
web site (http://nsict.demon.co.uk/somewhere-or-other) - if I remember
I'll upload it to http://www.nsict.demon.co.uk/hello/ this evening.
(Contributions also welcomed. ;-)
Mike.
Eugene Miya wrote:
>
> Tony Griffiths <·····@OntheNet.com.au> wrote in article
> ><············@OntheNet.com.au>...
> >> I doubt that any "inspired" language is of much use in the real world!
I'll quality my use of the word "inspired" by comparing in to a 'road to
Damascus revelation' as opposed to a 'let's sit down for a year or so
and think about things'. Alternatively, "inspired" in a '60s sense
would mean under the influence of chemical compounds not normally
associated with clear thinking!!! ;-))
> >> Most languages are the product of a lot of hard work...
>
[stuff removed]
>
> >There are tons of "neat" new (and old) languages out there that
> >no one uses because a) they attempt to introduce an entirely new paradigm
> >which makes them highly undesireable when writing mission-critical code, or
> >b) they do something that another language already does. Are they
> >inferior? Nope, just different. Are they inferior for a partcular purpose?
This is true but it is often the square peg, round hole problem. Once a
language has come into existence, the proponents of that language try to
force it down everyone throat, saying it can be used to solve every
problem!
A perfect example is C. A great language for knocking up little (< a
couple of thousand line of code) utilities for Unix and other systems,
but God help you if you want to write 1 million lines of code
mission-critical systems in it. The testing/QA team had better be well
staffed and the Engineers writing the code had better be prepared to
spend a lot of their time in code reviews!!!
> >Can you elaborate on what you mean by a high quality programming
language?
> >Weak vs. strong typing? High level constructs?
>
> "Strong typing is for weak minds...." famous quote.
>
> First, a high quality programming language prevents me from
> unintentionally shooting myself in the foot. Typing is merely one
> attempt at a compile time solution.
Couldn't agree more... Again C is the perfect example of a language
that actually seems to encourage bad programming practices. All of
these obscure operators that constantly trick you up. As an example,
what you you prefer to see in some code you have just come across-
(a) mask &= ~some_random_bits; /* C syntax */
(b) mask := XOR(mask, some_random_bits); -- Ada syntax
In the second case, I would probably even rename XOR() to be BIT_CLEAR()
or some other name that clearly defined the function being performed.
Ie.
(b') mask := BIT_CLEAR(mask, some_random_bits);
Once you get into the area of objects/pointers C becomes even more
dangerous...
I hate to pick on only C but it is a commonly used language and so it
deserves more attention as to it's inadequacies. A similar problem with
Fortran where-
C Zero out array A
do 10 i=1.1000
a(i)=0.0
10 continue
is perfectly acceptable code (or at least it was back when I wrote
Fortran) but doesn't do what the programmer expects. Try finding this
bug in 10's of thousands of line of code in some complex simulation.
I spent about 3 years writing Ada and yes, I did need a 3 week course
before writing any "useful" code, and even the code I wrote in the first
3-4 months I eventually tossed away because it was basically shit. This
is a bit hard to swallow for management when you tell them that a quite
competent C programmer is not going to be productive in Ada for almost 6
months but the end result is (potentially) a far happier outcome.
Is Ada a perfect language? No, but I can see why DoD-type people insist
on using it. If I was asked to work on a system where people's lives
are at stake, then I would simply refuse if C (possibly even C++) were
being used.
I've lost enough sleep working on systems where only the factory stops
when a critical part of the system crashes! Hearing the scream of high
pressure steam being vented through pressure release valves while the
general manager stands behind you while you try to find the bug and fix
it it bad enough.
Is any language perfect? Definitely NO!
Are some languages superior? Definitely YES!
Tony
On Fri, 13 Dec 1996 12:22:58 +1000, Tony Griffiths
<·····@OntheNet.com.au> wrote:
[snip]
>Couldn't agree more... Again C is the perfect example of a language
>that actually seems to encourage bad programming practices. All of
>these obscure operators that constantly trick you up. As an example,
>what you you prefer to see in some code you have just come across-
>
>(a) mask &= ~some_random_bits; /* C syntax */
>
>(b) mask := XOR(mask, some_random_bits); -- Ada syntax
>
>In the second case, I would probably even rename XOR() to be BIT_CLEAR()
>or some other name that clearly defined the function being performed.
>Ie.
>(b') mask := BIT_CLEAR(mask, some_random_bits);
Please, don't tell me that Ada uses XOR to mask away bits intead of
toggling them, I refuse to believe that!
Terje
- <··············@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Tony Griffiths (·····@OntheNet.com.au) wrote:
:
: This is true but it is often the square peg, round hole problem. Once a
: language has come into existence, the proponents of that language try to
: force it down everyone throat, saying it can be used to solve every
: problem!
:
: A perfect example is C. A great language for knocking up little (< a
: couple of thousand line of code) utilities for Unix and other systems,
: but God help you if you want to write 1 million lines of code
: mission-critical systems in it. The testing/QA team had better be well
: staffed and the Engineers writing the code had better be prepared to
: spend a lot of their time in code reviews!!!
This is likely true of *any* language. You can write bad assembly
code and good assembly code. If you take the time, C code can be
just as easily supported as any other language. If you go the other
way, it can be just as difficult to understand as assembly language.
But "C" doesn't *make* the code bad, that's done by a *programmer*.
I've seen ugly APL, ugly ADA, ugly PASCAL, ugly SMALLTALK, ugly C++,
ugly VISUAL BASIC, even saw an unly truck the other day.. :)
:
: > >Can you elaborate on what you mean by a high quality programming
: language?
: > >Weak vs. strong typing? High level constructs?
: >
: > "Strong typing is for weak minds...." famous quote.
: >
: > First, a high quality programming language prevents me from
: > unintentionally shooting myself in the foot. Typing is merely one
: > attempt at a compile time solution.
:
: Couldn't agree more... Again C is the perfect example of a language
: that actually seems to encourage bad programming practices. All of
: these obscure operators that constantly trick you up. As an example,
: what you you prefer to see in some code you have just come across-
:
: (a) mask &= ~some_random_bits; /* C syntax */
:
: (b) mask := XOR(mask, some_random_bits); -- Ada syntax
fix it. If you look at my c code, you'd see
mask=And(mask, some_random_bits);
and you'd see that everywhere. The preprocessor can clean up a lot of
coding screwups given half a chance.. Note that the above is not a function
but a simple macro.
:
: In the second case, I would probably even rename XOR() to be BIT_CLEAR()
: or some other name that clearly defined the function being performed.
: Ie.
: (b') mask := BIT_CLEAR(mask, some_random_bits);
:
: Once you get into the area of objects/pointers C becomes even more
: dangerous...
Again it doesn't have to, just like handguns don't *have* to be dangerous
either. Of course they usually are, because they usually have loose nuts
attached to them. :)
:
: I hate to pick on only C but it is a commonly used language and so it
: deserves more attention as to it's inadequacies. A similar problem with
: Fortran where-
:
: C Zero out array A
: do 10 i=1.1000
: a(i)=0.0
: 10 continue
:
: is perfectly acceptable code (or at least it was back when I wrote
: Fortran) but doesn't do what the programmer expects. Try finding this
: bug in 10's of thousands of line of code in some complex simulation.
most good compilers catch that. even though do10i is a valid variable
name, it can still be used to produce a warning, just like this does in
most C compilers:
if (a=b) { };
most compilers make you write this as
if ((a=b))
if you want to stop the warning about a possible unexpected assignment
used as a truth value...
:
: I spent about 3 years writing Ada and yes, I did need a 3 week course
: before writing any "useful" code, and even the code I wrote in the first
: 3-4 months I eventually tossed away because it was basically shit. This
: is a bit hard to swallow for management when you tell them that a quite
: competent C programmer is not going to be productive in Ada for almost 6
: months but the end result is (potentially) a far happier outcome.
:
: Is Ada a perfect language? No, but I can see why DoD-type people insist
: on using it. If I was asked to work on a system where people's lives
: are at stake, then I would simply refuse if C (possibly even C++) were
: being used.
I'd be willing to bet that many programmers are "writing C programs in ADA
syntax". I've seen it hundreds of times. Practices learned years ago, and
then re-enforced by years of programming are going to be difficult to
overcome. I've not found a language that can solve this.
:
: I've lost enough sleep working on systems where only the factory stops
: when a critical part of the system crashes! Hearing the scream of high
: pressure steam being vented through pressure release valves while the
: general manager stands behind you while you try to find the bug and fix
: it it bad enough.
:
: Is any language perfect? Definitely NO!
: Are some languages superior? Definitely YES!
:
: Tony
In article <··········@juniper.cis.uab.edu>,
Robert Hyatt <·····@crafty.cis.uab.edu> wrote:
>I'd be willing to bet that many programmers are "writing C programs in ADA
>syntax".
I would amend that Bob with:
I'd be willing to bet that many programmers are "writing C/Ada programs in
Ada/FORTRAN syntax".
I checked the Ada news group before writing my paper. It's not simply
that they write the code in a scheme (pun) of another language, but
in some applications they intentionally gut the compiler (e.g., go from
a dynamic memory model to a static memory model). Better?
Depends on your view. At the time they were discussing the Boeing 777's
use of Ada. That's the aero community's view of programming language
(i.e., you don't want to get on a plane run by dynamic languages like LISP).
I learned a language called HAL/S by Intermetrics. It's not a language
that I would recommend learning (very PL/1ish, only worse, it was said
to be "FORTRAN"-Like, Ha!).
My point is that few computer people are willing to die or kill people
for their code. That's the beauty of rebooting and simulation.
"How many drops is this for you, Lt.?
"Thirty-eight ... simulated."
"How many *combat* drops?"
"Two ... including this one."
It's funny and tragic at the same time.
More in a moment on this thread.
I remind readers that we are diverging from supercomputers
and a little from architecture, and certain away from LISP.
If you really want to read about programming languages, get a book
(more than one of us has recommended the HOPL-II book)
or go over to comp.lang.misc or favorite group.
"Insisting on perfect safety is for people who don't have the balls to
live in the real world." -- Mary Shafer, NASA Ames Dryden
My company has had a safety program for 150 years. The program was instituted
as a result of a French law requiring an explosives manufacturer to live
on the premises with his family.
--Crawford Greenwalt, Former President of Dupont.
I had one other quote from Hackers about Gosper in the database, but
I'll skip it.
P.S. Just a reminder: Ada is named after a person, FORTRAN is an acronym.
From: Stephen O Gombosi
Subject: Re: superior(?) programming languages
Date:
Message-ID: <59fng0$one@rainbow.rmii.com>
In article <··········@juniper.cis.uab.edu>,
Robert Hyatt <·····@crafty.cis.uab.edu> wrote:
>This is likely true of *any* language. You can write bad assembly
>code and good assembly code. If you take the time, C code can be
>just as easily supported as any other language. If you go the other
>way, it can be just as difficult to understand as assembly language.
Those of us who cut our teeth on MACE/KRONOS know that it's quite
possible to write clear, comprehensible, elegant assembler code that
is wonderfully efficient yet much more easily understood than 99.99%
of the "high level language" programs out there. Unfortunately, there aren't
many programmers out there who are as intelligent and disciplined as
Mansfield and Cahlander were.
>But "C" doesn't *make* the code bad, that's done by a *programmer*.
Ain't that the truth.
Steve
From: Roger Glover
Subject: Re: superior(?) programming languages
Date:
Message-ID: <58s7j9$inf@walter.cray.com>
In article <·············@OntheNet.com.au>, Tony Griffiths
<·····@OntheNet.com.au> wrote to comp.arch, comp.sys.super, and
comp.lang.lisp:
<big snip>
> I hate to pick on only C but it is a commonly used language and so it
> deserves more attention as to it's inadequacies. A similar problem with
> Fortran where-
>
> C Zero out array A
> do 10 i=1.1000
> a(i)=0.0
> 10 continue
>
> is perfectly acceptable code (or at least it was back when I wrote
> Fortran) but doesn't do what the programmer expects. Try finding this
> bug in 10's of thousands of line of code in some complex simulation.
The example above passes for "correct" in Fortran 77 and in the
obsolete "fixed source form" in Fortran 90/95. However, it would be
rejected by the preferred "free source form" in Fortran 90 due to:
- the space after the word "do", or
- the lack of an "endpoint" number after the "startpoint" number 1.1000
(depending on whether the processor sees a flawed candlestick or two
flawed faces).
This is no longer even vaguely related to computer architectures,
supercomputers, or LISP, please note the Followup setting.
---------------- Cray Research ---------------- *** Roger Glover ***
XXXX\ \ / \ /XXX \ / \ X \ /\\\ X///X /\\\ *** Software Instructor ***
/ \ / \/ /\ / \ / \X /\ X \ / \ X\ \ X DISCLAIMER HAIKU:
//X/ X\\\X //X/ X \ X X\\ / \ X/X \ X \\\ C R^H^H^H^H S G I may not
/ \ X///X / \/ X//XX X \ / \ X \\ X \ Share these opinions with me
/ \ X X /\\\/ X X X///X /XXX/ X///X /XXX/ This is not my fault
---------- A Silicon Graphics Company --------- http://home.cray.com/~glover
Phillip N Toland wrote:
[huge snip]
> ISetL, I didn't like ISetL as it was used in that class. There is also the
> case of compiler/interpreter/platform dependencies. On MS-DOS ISetL is
> very restricted as to memory usage and therefore was slooooooooow. It
> would take several minutes to search a file containing Poe's "Raven" and
> print out a word count. This implementation of ISetL is obviously inferior
> to a 32-bit assembler version of "wc" on NT which can search the same file
> instantly.
Actually, it cannot do so instantly, but I know you know that. :-)
The fastest possible version of wc still needs to look at every
character, in some way, to determine word and line separators.
If we want a really general version, where the set of word and/or line
separators can be user-defined, what is the fastest possible
implementation?
I suspect a vector machine might be capable of filling a vector, do a
parallel table lookup on each element, and then combine pairs of results
to determine word boundaries.
How fast could this be done?
On the x86 platform I written code to do this that uses less than 1.5
cycles/char (Pentium or PPro), in both 16 and 32-bit mode, but I suspect
it might be possible to be even faster:
Convert 32 characters into a word/non-word bitmask, and use logic
operations to determine/count any 0->1 transitions.
The best C code I have been able to come up with seems to require about
5 RISC-style operations/pair of input characters, it is probably
load-bandwidth limited on most cpus.
Terje
PS. This code is definitely in the 'programming for fun' category:
Having a wc that is more than 10 times faster than a disk array is fast
enough. :-)
--
- <··············@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
In article <············@OntheNet.com.au>,
Tony Griffiths <·····@OntheNet.com.au> wrote:
>I doubt that any "inspired" language is of much use in the real world!
>Most languages are the product of a lot of hard work...
Some truth in this.
Available libraries tend to be a big part in the useability of a language.
If you have to write basic I/O for things like floating point you are
almost in trouble. See next comment
>The reason people use C is the same reason Basic became so popular in
>the PC world... there is a zero learning curve needed to write your
>first 'working' program. Eg.
>
>Basic: 10 print "Hello world"
> 20 end
>
>C: #include <stdio.h>
> main() {
> printf("Hello world\n");
> }
I did a simple but surprisingly important CUG'95 paper using hello world
(Calibrating the Cray HPM, I need to html it and make it a web page).
In a way you should not have to #include stdio.
C began popular: 1) because it came with Unix, 2) developed a momentum
from Universities who initially got $150 Unix licenses in a world where
vendors kept OSes complex and proprietary. An economic thing.
It lacks some useful support protection (relies heavily on its underlying OS
and library of system calls) for parallelism.
What's great about C is that it embodies a KISS principle which we
frequently need to be reminded. It survived a fairly harsh environment
of skepticism and change (The Labs and the phone company). It has a
run-time environment generally better than BASIC or FORTRAN.
It is important not over blow its significance. I'm not a C++ user.
Maybe I should be, maybe I should not. The problem is that it sometimes
takes years to embody and test a language, and evaluation suffers from biases
and other effects.
>Most people can come to grips with the above!!! It is your second
>working program where a degree of difficulty set in. ;-))
>
>As for programming languages, I would switch back to Ada from C any time
>given the opportunity.
>
>The ONLY reason I stick with C is it's universallity (is that a real
>word?), but that fact remains that it is not a high quality programming
>language.
It helps to have portable compilers (pcc, P4, whatever).
I would like to work more with Icon and I'm impressed with some of the
features of CLU. I'm far from a decent LISP programmer, but the problem
with languages is that THEY AREN'T solving a lot of problems. If they
are a tool, they are a distraction. No wonder why we have few parallel
languages.
I think what made BASIC key for computing was the fact that it was
interpreted and interactive. Supercomputers and parallel systems need
more interpreters, to allow people to prototype ideas (George Michael
would disagree with me). APL was also interpreted. But we have to try
many things...... And they will all be distractions, but if we expect
to advance, we will have to re-invent many wheels to get to steel belted
radials.
From: David Wright
Subject: Re: superior(?) programming languages
Date:
Message-ID: <58ksm1$2rm@clam.Hi.COM>
In article <··········@darkstar.ucsc.edu> ······@cse.ucsc.edu (Eugene Miya) writes:
[major snip]
>I think what made BASIC key for computing was the fact that it was
>interpreted and interactive.
It's a mistake to think that BASIC was intended as an interpreted
language, however. Oh, I know it's often been implemented that way,
but that was not the original intent of Dartmouth BASIC, which was
always compiled, as far as I know.
-- David Wright :: ······@hi.com :: Not an Official Spokesman for Anyone
These are my opinions only, but they're almost always correct.
"The difference between a printing press and a modern digital long-
distance network is that the press produces money much more slowly."
-- Neil Kirby, Lucent Technologies
From: Richard Ottolini
Subject: Re: superior(?) programming languages
Date:
Message-ID: <58kbg9$4hf@news.unocal.com>
In article <··········@darkstar.ucsc.edu>,
Eugene Miya <······@cse.ucsc.edu> wrote:
>What's great about C is that it embodies a KISS principle which we
>frequently need to be reminded. It survived a fairly harsh environment
>of skepticism and change (The Labs and the phone company). It has a
>run-time environment generally better than BASIC or FORTRAN.
>
>It is important not over blow its significance. I'm not a C++ user.
>Maybe I should be, maybe I should not. The problem is that it sometimes
>takes years to embody and test a language, and evaluation suffers from biases
>and other effects.
In the KISS department, JAVA out-"C"s both C and C++,
although its performance currently sucks.
I am encouraged how much smaller my codes are in JAVA
for equivalent functionally in C or C++.
Hope to see an efficient interpreter on a super soon.
From: Stephen O Gombosi
Subject: Re: superior(?) programming languages
Date:
Message-ID: <59fmgo$lhu@rainbow.rmii.com>
In article <··········@darkstar.ucsc.edu>,
Eugene Miya <······@cse.ucsc.edu> wrote:
>I think what made BASIC key for computing was the fact that it was
>interpreted and interactive. Supercomputers and parallel systems need
>more interpreters, to allow people to prototype ideas (George Michael
>would disagree with me). APL was also interpreted. But we have to try
Well, as one gentleman at the Applied Physics Lab pointed out to me
back in the Dark Ages (when Cray's Eastern region was thinking about
writing a Cray APL interpreter in order to secure a sale there), if you're
doing enough computation in each statement the overhead of interpretation is
just noise.
Since then, I've often thought that APL is the most natural language for
vector computers (and perhaps parallel ones, as well).
Too bad I can't remember how to program in it anymore. ;-)
Steve
In article <··········@rainbow.rmii.com> ···@rmi.net (Stephen O Gombosi) writes:
>In article <··········@darkstar.ucsc.edu>,
>Eugene Miya <······@cse.ucsc.edu> wrote:
>
>>I think what made BASIC key for computing was the fact that it was
>>interpreted and interactive. Supercomputers and parallel systems need
>>more interpreters, to allow people to prototype ideas (George Michael
>>would disagree with me). APL was also interpreted. But we have to try
>
>Well, as one gentleman at the Applied Physics Lab pointed out to me
>back in the Dark Ages (when Cray's Eastern region was thinking about
>writing a Cray APL interpreter in order to secure a sale there), if you're
>doing enough computation in each statement the overhead of interpretation is
>just noise.
The above statement is not always true, due to the nature of commercial
APL interpreters. In an expression such as "A+ B times C", where
A,B,C are arrays, the usual form of interpretation is a naive, one
primitive at a time method. Thus, the interpreter would multiply
(element by element) B times C, producing an array-valued temp T1.
Then the interpreter would perform "A+T1" (element by element).
Although the syntax analysis, conformability checking, semantic
analysis, and storage management overheads are indeed amortized
over the entire arrays, the array-valued temps can kill your
performance. IBM's APL2 interpreter, when executed on a 3090-class
machine running the vector facility, WILL effectively loop fuse
these operations, with substantial performance improvement.
Likewise, APEX -- my APL compiler -- generates loop-fused code
for such expressions, producing execution rates than can exceed
those of naive execution by an order of magnitude or more.
I do not believe any of the early supercomputer interpreters used
such techniques.
>Since then, I've often thought that APL is the most natural language for
>vector computers (and perhaps parallel ones, as well).
Me, too. Some of my preliminary measurements of compiled APL on
parallel systems tend to confirm this. However, execution speed
that is competitive with FORTRAN requires fairly sophisticated
compilation and analysis techniques, to eliminate superfluous
array generation such as the above, transpositions, reversals,
and subarray selection operations.
Bob
From: Stephen O Gombosi
Subject: Re: superior(?) programming languages
Date:
Message-ID: <59oq6k$r5b@rainbow.rmii.com>
Robert Bernecky <········@eecg.toronto.edu> wrote:
>In article <··········@rainbow.rmii.com> ···@rmi.net (Stephen O Gombosi) writes:
>>Eugene Miya <······@cse.ucsc.edu> wrote:
>>>I think what made BASIC key for computing was the fact that it was
>>>interpreted and interactive. Supercomputers and parallel systems need
>>>more interpreters, to allow people to prototype ideas (George Michael
>>>would disagree with me). APL was also interpreted. But we have to try
>>Well, as one gentleman at the Applied Physics Lab pointed out to me
>>back in the Dark Ages (when Cray's Eastern region was thinking about
>>writing a Cray APL interpreter in order to secure a sale there), if you're
>>doing enough computation in each statement the overhead of interpretation is
>>just noise.
>The above statement is not always true, due to the nature of commercial
>APL interpreters.
I believe the gentleman in question was making the implicit assumption
that the interpreter would not be written badly. This may, of course,
have been an unwarranted assumption - just as it sometimes is in the
case of compilers, libraries, and operating systems.
Steve
In article <··········@rainbow.rmii.com> ···@rmi.net (Stephen O Gombosi) writes:
>Robert Bernecky <········@eecg.toronto.edu> wrote:
>>In article <··········@rainbow.rmii.com> ···@rmi.net (Stephen O Gombosi) writes:
>>>Eugene Miya <······@cse.ucsc.edu> wrote:
>
>>>Well, as one gentleman at the Applied Physics Lab pointed out to me
>>>back in the Dark Ages (when Cray's Eastern region was thinking about
>>>writing a Cray APL interpreter in order to secure a sale there), if you're
>>>doing enough computation in each statement the overhead of interpretation is
>>>just noise.
>
>>The above statement is not always true, due to the nature of commercial
>>APL interpreters.
>
>I believe the gentleman in question was making the implicit assumption
>that the interpreter would not be written badly. This may, of course,
>have been an unwarranted assumption - just as it sometimes is in the
>case of compilers, libraries, and operating systems.
The gentleman in question (yours truly) was, in fact, assuming that
the interpreter was well-written. The CDC STAR-100 APL interpreter
was written by some of my colleagues at I.P. Sharp Associates
and I respect their work highly. The unstated "nature of commercial
APL interpreters" is a reflection of several properties of
real-world programs and commercial interpreters:
a. Interpreters (with only 1 exception I can think of) interpret
each function in an APL program at a time. Loop fusion and
sophisticated analysis are not performed, because the interactive
nature of interpreters makes this difficult to do in a reliable
manner. What I mean by this is that if you have an array
expression such as:
a+b times c
where a,b,c are all arrays, contemporary interpreters will
perform "tmp <- b times c", forming an array-valued temp.
Then, "a + tmp" will be performed.
There is no loop fusion, so a high amount of extra storage
traffic and storage manager overhead is invoked.
APL compilers, of course, do not have this problem.
b. Like any other programs, APL programs suffer from a
high percentage of operations on scalars, even though the
APL language has array primitives. In independent measurements made
by Willhoft (IBM Research), myself, and one other APL
implementor, we found that real applications (as opposed to
toy benchmarks), measured on production systems, have
about 50% of the primitives operating on arrays of one or
zero elements.
In these cases, the overheads of an interpreter -- syntax analysis,
conformability checking, storage management -- dominate the
computation time to the extent that no more than half of the
cpu cycles for large applications actually end up doing to
useful work.
Again, APL compilers are able to avoid these overheads by
doing much of the work at compile time.
If you are lucky enough to have a very simple application whose
execution time is totally dominated by a few APL primitives
whose computational complexity is fairly high, such as
matrix product (with dense arrays), then Eugene's comments
are sound.
Bob
In article <·····················@jarvis.cs.toronto.edu> ········@eecg.toronto.edu (Robert Bernecky) writes:
>In article <··········@rainbow.rmii.com> ···@rmi.net (Stephen O Gombosi) writes:
>>Robert Bernecky <········@eecg.toronto.edu> wrote:
>>>In article <··········@rainbow.rmii.com> ···@rmi.net (Stephen O Gombosi) writes:
>>>>Eugene Miya <······@cse.ucsc.edu> wrote:
>>
>>>>Well, as one gentleman at the Applied Physics Lab pointed out to me
>>>>back in the Dark Ages (when Cray's Eastern region was thinking about
>>>>writing a Cray APL interpreter in order to secure a sale there), if you're
>>>>doing enough computation in each statement the overhead of interpretation is
>>>>just noise.
>>
>>I believe the gentleman in question was making the implicit assumption
>>that the interpreter would not be written badly. This may, of course,
...>
>The gentleman in question (yours truly) was, in fact, assuming that
>the interpreter was well-written. The CDC STAR-100 APL interpreter
Oops. Misread the post. I was NOT the gentleman in question. Sorry.
Bob
In article <······················@jarvis.cs.toronto.edu>,
Robert Bernecky <········@eecg.toronto.edu> wrote:
>Oops. Misread the post. I was NOT the gentleman in question. Sorry.
Naw, the thing to do (netiquette) is either: 1) kill the follow up,
2) just snip off ALL attribution and edit the text leaving it to readers
to go back and use a service like dejaNews to get it straightened out,
then proceed with your commentary.
So next time, just snip off the headers.
In article <····················@hds01i3c12.ericsson.se>,
Robert Tjarnstrom <······@hds01i3c12.ericsson.se> wrote:
>We should not forget that the quality and properties of the code
>is not only due to the language used but also due to who is developing
>the code.
Years ago when I was working at JPL, I learned to play backgammon
at lunch time by looking over the shoulders of colleagues. I got pretty
good (except the doubling cube) after I did some distributions (the
wrong ones to think about are the simple distributes of standard rolls).
In the case of programming languages, George Michael likes to relate the
story of a fellow who learned Fortran by a similar manner. At that time
(punch cards era I presume) the guy wrote up his first code (be they
card images or real cards, it was not important), but being clever, he
decided to label each of his statements in advance (like BASIC).
But he knew about people modifying codes (he was smarter after all), so
he came up with a scheme which had the first character being a "1".
Needless to say, he didn't look close enough during lunch to learn about
carriage control. The LTSS printed many boxes of printer pages bare
except for one line on the top of each page. The boxes of course were
delivered to the man's office of course.
Unfortunately "God" is found in those kinds of details.
>A compilation of *Hello World programs* designed by various
>categories of *developer* follows.
Yes, I forgot about this joke post.
Programming will remain an art for some time to come.
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk (Cyber Surfer) writes:
| From: ············@wildcard.demon.co.uk (Cyber Surfer)
| Newsgroups: comp.arch,comp.sys.super,comp.lang.lisp
| Date: Wed, 11 Dec 96 08:09:19 GMT
| Meanwhile, the Scheme to C compiler that seems closest to
| working on my machine includes EVAL in the runtime. I think
| of EVAL as a development tool, not a runtime tool.
|
| See if you can guess why I don't want EVAL:
|
| 1,953 test.obj
| 76,357 _errors.obj
| 373,860 _eval.obj
| 4,314 c_intf.obj
| 1,777 main.obj
| 10,722 setup.obj
| 12,409 mem.obj
| 3,293 os.obj
|
| Not that Lisp is unique in this respect...But on this particular
| platform, the VB and VC++ runtime support can be shared between
| apps. The solution is obvious - put the Lisp runtime in a DLL.
Interesting argument, since I view EVAL as the source-level dynamic
loader of Lisp.
Or do you only mean shared libraries by DLLs?
The semantic "problems" presented by EVAL are no worse or different
than those introduced by any of the dynamic loaders on current
systems. The rest is just an issue of whether the compiler has an
API, and whether your components can be shipped as source.
In article <·················@hplgr2.hpl.hp.com>
···@hpl.hp.com "Guillermo (Bill" writes:
> Interesting argument, since I view EVAL as the source-level dynamic
> loader of Lisp.
EVAL is useful for creating an interactive language, but it's
not something I want to deliver to a client.
> Or do you only mean shared libraries by DLLs?
Yes, I'm refering to code sharing, via DLLs or similar means.
Since I'm developing for Windows, I'm interested in DLLs.
Programmers using other platforms might have a different name
for such things. I can't remember what the the P-system called
them, but I vaguely recall that the code was placed in a
"library" with 16 slots (?).
> The semantic "problems" presented by EVAL are no worse or different
> than those introduced by any of the dynamic loaders on current
> systems. The rest is just an issue of whether the compiler has an
> API, and whether your components can be shipped as source.
I don't wish to deliver a compiler to clients. They'd probably
object if I did, even if the the extra code size wasn't a problem,
which it could be, easily.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
* Cyber Surfer
| EVAL is useful for creating an interactive language, but it's
| not something I want to deliver to a client.
excuse me for saying this, but aren't you complaining all the time that you
don't _have_ any clients you could have delivered anything Lispy to at all?
once you get Lisp clients, you may find cause to reconsider.
people who are afraid of the name `eval' invent their own version of its
functionality, badly. just like people who are afraid of the name `lisp'.
#\Erik
--
Please address private replies, only, to "erik". Junk mail, spam,
stupid flames, courtesy copies, etc, should be sent to "nobody".
In article <················@naggum.no> ······@naggum.no "Erik Naggum" writes:
> excuse me for saying this, but aren't you complaining all the time that you
> don't _have_ any clients you could have delivered anything Lispy to at all?
> once you get Lisp clients, you may find cause to reconsider.
Excuse me, but I think I know my clients rather better than you do.
They don't give a shit about Lisp, but they do care about a great
many other things, like image size.
> people who are afraid of the name `eval' invent their own version of its
> functionality, badly. just like people who are afraid of the name `lisp'.
I've no use for EVAL. I've never used it in any of my code, nor
I expect to ever do so. Did you see the figures for code sizes
that I posted? Can you deny that EVAL was so much larger than
anything else in Gambit C? Can you convince me that I really need
all this code?
If I can live without it, then I will. And I do. Sadly, I don't
do it in Lisp, but I can certainly live without it. I've not yet
found a Lisp to C compiler that does what I'm looking for (mostly
Win32-specific things), but there are plenty that do things that
I don't want (e.g. EVAL).
Curiously, Smalltalk MT appears to do _all_ the things that I'm
currently interested in, and will soon be able to do some things
that will also be _very_ welcome. As standard. For a mere $295.
Forgive me if I'm misrepresenting you, but it often seems to me
that your argument is that everyone can and should use Lisp,
regardless of what anyone else thinks. If somebody would like to
pay me to write Lisp, instead of Windows, software...
Please note that distinction. I don't put Lisp first, and the OS
second. The job comes first, and the tools are often determined
by the work to be done. That in turn depends on a great many other
factors, not least of which are the clients' requirements.
If there's a way of satisfying them by using Lisp, then I'll be
very interested. However, I don't start by choosing Lisp, and
then looking for clients to write code for. Perhaps you're more
fortunate than I am...
I'm not knocking the free Lisp compilers available via the Internet.
That would be unfair. However, I'm more than happy to spent a little
money to get the features that I'm looking for, and to avoid those
features that I'd rather not "pay" for, at runtime.
With C++. I'm "paying" at development time. ;-) I'd like to avoid
that, too. If I can do it by using alternatives to Lisp, like
Smalltalk MT and eventually DylanWorks, then I will. BTW, when
I refer to Lisp, I include Scheme, ANSI Common Lisp, ISO Lisp,
and Standard Lisp, amoung other dialects. I think of Dylan as
a dialect of Lisp, even if some Lisp people don't. I'm not
dogmatic about using Lisp, or defining what it is or isn't.
Followups narrowed to: comp.lang.lisp,comp.arch
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
* Cyber Surfer
| Excuse me, but I think I know my clients rather better than you do.
no doubt, but we all know they are clients who don't want solutions, they
want to make decisions about random factors of the implementation, ...
| They don't give a shit about Lisp, but they do care about a great many
| other things, like image size.
... like image size.
| I've no use for EVAL. I've never used it in any of my code, nor I expect
| to ever do so.
can you think of Emacs without `eval'? or indeed any other Lisp system?
I rely on `eval' like nothing else in the Lisp systems I use.
| Did you see the figures for code sizes that I posted?
| Can you deny that EVAL was so much larger than anything else in Gambit C?
| Can you convince me that I really need all this code?
how the hell is anybody supposed to know what a figure like that means?
your numbers are _literally_ meaningless. like most statistics, they are
presented as if numbers alone had meaning. like anybody who has even an
inkling of understanding of statistics knows, it's what you have measured
that give the meaning, not the (numerical) measurement.
| Forgive me if I'm misrepresenting you, but it often seems to me that your
| argument is that everyone can and should use Lisp, regardless of what
| anyone else thinks. If somebody would like to pay me to write Lisp,
| instead of Windows, software...
first, there is a very fundamental difference between rejecting invalid
arguments and embracing the opposite of an invalid argument, whatever that
might be. you don't seem to understand this difference very well. just
because you offer so many invalid arguments and so much bullshit about how
hard Lisp is for your sorry case, and I object and reject them, does not
mean that any more of your invalid arguments, this time about what I think,
magically become true. you're illogical and irrational. that annoys me,
more so when you don't seem to recognize that more than just your arguments
are being rejected -- the entire set of premises from which you draw them
is being rejected.
second, there is nothing more destructive in a community of professionals
than the sickening tendency among people of lesser integrity to consider
_first_ what other people might think, _then_ what might be possible. I
make my living on the premise that the reverse order is the only valid one,
and frequently forget what other people might think. sometimes it takes a
lot of effort to ignore other people's objections, however.
third, "somebody" doesn't just call you up, saying "we'd like to pay you to
write Lisp". they call you up to ask for your assistance on a hard
problem, they listen to your suggestions and accept your design if you can
present it credibly, they are willing to fork over a lot of money for a
license to a supported, commercial Lisp development environment if you
present the case for it, but only if you present the case for it, and they
leave you alone for a month or five while you work out the magic. but you
don't get called like that just by sitting in your uncomfortable office
chair, writing Windows applications and airing your frustrations on
comp.lang.lisp -- I sure as hell wouldn't call you with an offer to work on
a Lisp project. it takes real-life effort, and may put tens of thousands
of pounds of your personal income on the line, in saying "this can save us
much more than it costs and much more than any alternative", and actually
prove it.
| If there's a way of satisfying them by using Lisp, then I'll be very
| interested. However, I don't start by choosing Lisp, and then looking for
| clients to write code for. Perhaps you're more fortunate than I am...
perhaps I just work harder at it than you do. perhaps I work on problems
that can't be solved in a realistic time frame in any other language than
Common Lisp and within a large Common Lisp system. perhaps this has cost
me three years of basically living off of writing articles and giving
lectures instead of programming. perhaps I succeed in what I want because
I don't waste my time and brain prostituting myself on Windows and Visual
whatever? perhaps I got so sick and tired of programming in stupid
languages like C and C++ that I wanted to sit down and invent my own
language, build up my own support organization and try to sell it to
others. or I could find a language that gave me all I needed, and as soon
as I found a client who was interested in more than trivial solutions, have
them fund my acquisition of tools from somebody who had already invented
and implemented such a language. I chose the latter. nonetheless, I enjoy
nitty-gritty details of implementation, _ONCE_. I'd like to do things only
until I learn to do them expertly, then move on.
| I'm not dogmatic about using Lisp, or defining what it is or isn't.
the net effect is that you're not programming in Lisp for any clients. you
can use whatever reasons you want to defend this position, if you think it
needs defending (and if my recollection of your postings here for the past
few months is correct, you portray a tremendous need to defend yourself and
your position). my impression is indeed that you are dogmatic about Lisp,
but not positively so, _negatively_ so: you repeat and stress how Lisp is
never the right solution for you, despite repeated examples and much
assistance to the contrary. this is very, very annoying. instead of
concluding that "Lisp is not right for the jobs that Cyber Surfer does",
the conclusion becomes "Cyber Surfer is not right or the jobs that Cyber
Surfer does". I would never hire you for your newspostings. several
people _have_ hired me for my newspostings.
I'm no longer interested in understanding why you hold the positions you
do, because I have yet to find any actually _constructive_ part to your
whining. also, I have proven that with a much effort and with a braveness
that I look back upon in awe -- I put much more on the line than I ever
realized -- I have managed to land two contracts that bring me out of the
Lisp wannabe camp, and right into the middle of a breakneck action movie.
I haven't had so much fun in many, many years. I don't know if I will come
out of this on top, but for the first time in at least five years, I can
say to myself "I want to be a programmer and I think I can make it".
and by "a programmer" I don't mean an assembly line worker who churns out C
or C++ or any of that shit. I want to build large structures and systems,
not just line up a lot of new copies of the same old stuff side by side and
call that a career. now I think I can pull it off, but I couldn't do it
without a major Lisp vendor giving me unparalleled moral and technical
support, and I couldn't do it without clients who really understand and
listen to what I have presented to them. incidentally, most of this has
happened in the past couple months, with _years_ of preparation on my part.
maybe I have just been very fortunate, but I don't think these things just
happen. still, I'm deeply grateful to the people who make it possible for
me to enjoy programming for pay, again -- this time in a language that lets
me think hard about hard issues, not waste all my time on trivial things.
#\Erik
--
users should be computer-friendly.
Cyber Surfer said:
>| I've no use for EVAL. I've never used it in any of my code, nor I expect
>| to ever do so.
Erik Naggum replied:
>can you think of Emacs without `eval'? or indeed any other Lisp system?
>I rely on `eval' like nothing else in the Lisp systems I use.
Emacs isn't a particularly good benchmark for making generalizations about
Lisp systems - elisp is a fairly old, quirky language without many of the
features of Common Lisp. I've written many hundreds of thousands of lines of
Common Lisp without ever calling eval once - and this was in dynamic, end-user
programmable environments (class & prototype based visual programming systems,
highly parallel blackboard systems with integrated rule engines), defining new
classes and methods on the fly, etc...
As for the rest : [ extensive dogmatic flamage deleted ]
Just chill out and discuss this like adults. I've always noted Cyber
Surfer's posts to be reasonable, intelligent, and open-minded, quite unlike
#\Erik's flamage.
-Adam
--
Adam Alpern <······@brightware.com>
* Adam Alpern
| I've written many hundreds of thousands of lines of Common Lisp without
| ever calling eval once - and this was in dynamic, end-user programmable
| environments (class & prototype based visual programming systems, highly
| parallel blackboard systems with integrated rule engines), defining new
| classes and methods on the fly, etc...
then it should be entirely safe for you to evaluate (fmakunbound 'eval) and
report how well your system works, or how well you work. right? if not,
please explain what you mean by "without ever calling eval once". just
because somebody else does it for you, doesn't mean you don't use it.
otherwise, you could just have a "designated eval caller" (a.k.a "the fall
guy") in any Lisp community, and he could write a wrapper with another name
which you could call. washing your hands of all eval, you can now use this
function, instead.
this is like some orthodox Jews who are forbidden to do work that involves
machinery of any kind during the Sabbath, and thus can't turn on electric
lights. to solve this problem, they have devised a stick that they can use
to turn the switch for them. it's not machinery, and they do get light.
it's also quite symptomatic and tragic that you didn't see the point in
what you deleted as "dogmatic flamage": _work_ hard and be prepared to
sacrifice a lot to realize the dreams you take seriously, don't just sit
there and _whine_ about a life you refuse to change. now, I suppose you
disagree with _this_, too.
#\Erik
--
users should be computer-friendly.
* Adam Alpern
| I've written many hundreds of thousands of lines of Common Lisp without
| ever calling eval once - and this was in dynamic, end-user programmable
| environments (class & prototype based visual programming systems, highly
| parallel blackboard systems with integrated rule engines), defining new
| classes and methods on the fly, etc...
at first I was impressed by this, but it didn't match the contents of your
article so I ignored it. then I looked you up on the Web, and found that
you have just (as of 1996-07-02) graduated from Hampshire College, and that
you don't mention this work in your resume.
at full speed, I write about 1 line of Lisp code per minute, including
think time. "many hundreds of thousands of lines of Common Lisp" would
translate, for me, into many hundreds of thousands of minutes, if we make
the invalid assumption that I can sustain this speed for a whole day at a
time. suppose now that we have 500 minutes a day available for programming
Lisp, and suppose that "many" means more than 5, we can safely assume that
you have been working on this system full time for at least three years,
five if you take vacations and weekends off. this flies in the face of
your resume, and must therefore be assumed to be an utterly foolish lie on
your part.
next time you feel a desire to brag like that, update your resume first.
<URL:http://hamp.hampshire.edu/~adaF92/Home.html>
<URL:http://hamp.hampshire.edu/~adaF92/Resume.html>
as for some real numbers, when I stopped writing C for fun and profit three
years go, at about the time you entered college. I estimated that I had
_written_ about a million lines of code over the preceding 15 years, but
published (i.e., made available to more than 10 people, either as source or
compiled code) less than a tenth of that. I can hope to have published
"many hundreds of thousands of lines of Common Lisp" when I celebrate my
40th anniversary. I would consider that a real achievement.
I regret that I wasted time on finding this information, but I would have
liked to know somebody who had written many hundreds of thousands of lines
of Common Lisp.
#\Erik
--
users should be computer-friendly.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Adam Alpern
>| I've written many hundreds of thousands of lines of Common Lisp without
>| ever calling eval once - and this was in dynamic, end-user programmable
>| environments (class & prototype based visual programming systems, highly
>| parallel blackboard systems with integrated rule engines), defining new
>| classes and methods on the fly, etc...
>
>at first I was impressed by this, but it didn't match the contents of your
>article so I ignored it. then I looked you up on the Web, and found that
>you have just (as of 1996-07-02) graduated from Hampshire College, and that
>you don't mention this work in your resume.
OK, to be the first to admit when I've spoken too quickly, I should have
changed "many" to "several" (yes, less than your cutoff of 5, but somewhere
around 3 1/2) before hitting the send button.
However, not everything I've done is on my resume (nor do I have access to
that account anymore) . A quick scan of the active projects folder on my hard
drive revealed a line count of 167,652 for all files ending in ".lisp" . Oh,
wait a minute - add about 10 to that for the function I wrote to count the
lines in every file. Most of the code in that folder has been rewritten
several times as well, and that's not counting old projects which have been
archived, or code that I no longer have access to, which amounts
You estimate that you've written about a million lines of code over 15 years.
I've been coding in Lisp for 5 years, and I estimate I've written about 1/3 of
a million lines - is it impossible to believe that someone else can code at
the same speed you can? I never said I had published everything I've written.
My point wasn't to say "Mine is bigger than yours", but to say that 'EVAL' is
not such a vital piece of code that significant and interesting systems can't
be built without it.
You've obviously extrapolated quite a ways beyond my original sentence.
>as for some real numbers, when I stopped writing C for fun and profit three
>years go, at about the time you entered college. I estimated that I had
>_written_ about a million lines of code over the preceding 15 years, but
>published (i.e., made available to more than 10 people, either as source or
>compiled code) less than a tenth of that. I can hope to have published
>"many hundreds of thousands of lines of Common Lisp" when I celebrate my
>40th anniversary. I would consider that a real achievement.
Published? When did I say publish? I said "written". To have published that
much code would indeed be a real acheivement, and I wish you luck.
-Adam
* Adam Alpern
| Oh, wait a minute - add about 10 to that for the function I wrote to
| count the lines in every file.
I see. but such numbers are wholly irrelevant. the only lines _I_ could
have counted are ones that got saved into a file or otherwise committed
that was not immediately overwitten with a new version.
| You estimate that you've written about a million lines of code over 15
| years.
just for fun, let's see how irrelevant this can get. if I hold down my
RETURN key, I can "write" a line of code every 18 ms once the autorepeat
kicks in. it would take me 5 hours to produce a million lines at that
speed. and if I wanted (god forbid!) to _cheat_, I could type C-x ( RET
C-u 1000000 C-x ) and have it done in about 2 seconds.
on a less useless note, you can measure somebody's typing speed in terms of
the number of keystrokes per second sustained average, and you can measure
it in terms of _successfully_ typed words per minute, where there are
penalities for mistakes, such as text saved on disk during a day. writing
prose text in news articles, I generally average 7.5 keystrokes per second
while writing, and this is no big deal. I make a small number of mistakes,
but I also rephrase myself several times over before I post, stop and
think, etc, so the average is down to 2 posted characters per second with
some articles.
I can't count all the throw-away code I have written any more than I can
(or will) count IRC or non-saved text in my literary production. if you
write five drafts for a book before it's published, you haven't written
five books. it's as simple as that.
| I've been coding in Lisp for 5 years, and I estimate I've written about
| 1/3 of a million lines - is it impossible to believe that someone else
| can code at the same speed you can?
not at all. Lotus, Inc, has estimated that there is en order of magnitude
difference in coding speed between their _good_ programmers. that is,
measuring code that the programmer gives somebody else. this is like the
secretary standard for typing speed compared to the raw "hack speed" -- a
hacker may well type like a maniac (10 keystrokes per second is not _that_
unusual), but still end up with less effective speed than a secretary who
types only 30 words per minute but never makes mistakes. (for purposes of
comparison, 1 keystroke per second is 10 words per minute.)
| You've obviously extrapolated quite a ways beyond my original sentence.
no, I took it at face value, and then got _really_ disappointed.
| Published? When did I say publish? I said "written". To have published
| that much code would indeed be a real acheivement, and I wish you luck.
thanks. I wish you well, too, after this cleanup job, but please don't use
"written" to mean "typed". that is not at all impressive. you should also
work harder to _reduce_ the number of lines of code you write (and type).
it's not the number of lines that count, but what you get done in them.
example: a student I had the pleasure of guiding through her thesis on
abstracting a document type definition from an SGML document instance,
wrote her first major Common Lisp program to prove her point, and she wrote
about 12 000 lines. I took over the code after that and worked a bit with
it to get it into production state. it had been reduced to 1500 lines when
we were all done, and ran 70 times faster. still, a naive reimplementation
of some of the functions in the admittedly procedural style she had used
required _twice_ the number of lines in Pascal! if a Pascal programmer
worked his ass off, he would appear 4 times more proficient than a Lisp
programmer, as he would probably spend nearly the same time thinking about
the problem as we did. Lisp gives the programmer more time to think, IMHO.
I saw a TV production about the Bill Gates imperium some time ago. at some
point, IBM wanted everything measured in "KLOCs", and somebody (Paul Allen,
I think) said "if we work smarter and write fewer lines, we don't want to
be punished for that". I agree with this sentiment, and thus find "lines
of code" to be a moderately useless measurement in the first place.
indeed, it can be construed that whoever writes too _many_ lines per unit
of time should stop expanding macros by hand and instead let the machine
write those lines. not to mention the fact that your carreer may be
measured in a fixed number of keystrokes due to various strain syndromes,
not unlike every living animal supposedly lives for about the same number
of heartbeats (within an order of magnitude difference, anyway).
(as long as we count useless things, my pulse while coding averages 60.)
#\Erik
--
users should be computer-friendly.
Someone who claimed to be Erik Naggum <····@naggum.no> wrote:
>just for fun, let's see how irrelevant this can get. if I hold down my
>RETURN key, I can "write" a line of code every 18 ms once the autorepeat
>kicks in.
>thanks. I wish you well, too, after this cleanup job, but please don't use
>"written" to mean "typed". that is not at all impressive. you should also
>work harder to _reduce_ the number of lines of code you write (and type).
>it's not the number of lines that count, but what you get done in them.
This seems like a lot of irrelevant and fairly malicious stuff.
Is it worth all this trouble just to make Adam Alpern feel lousy ?
__________________________________________________________________________
It is a tremendous Mitzvah to always be happy!
Reb Nachman of Breslov
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> * Cyber Surfer
> | Excuse me, but I think I know my clients rather better than you do.
>
> no doubt, but we all know they are clients who don't want solutions, they
> want to make decisions about random factors of the implementation, ...
Is that your definition of corporate users? They certainly want
solutions, and they get them.
> | They don't give a shit about Lisp, but they do care about a great many
> | other things, like image size.
>
> ... like image size.
Yep. Some people have finite resources. Perhaps they'e also pathetic
bean-counters who've forgotten what a bean is, but I'm not sure that's
true everyone who chooses software written in C++, VB, etc. It's
just possible that they have a different set of values to you or I.
> | I've no use for EVAL. I've never used it in any of my code, nor I expect
> | to ever do so.
>
> can you think of Emacs without `eval'? or indeed any other Lisp system?
> I rely on `eval' like nothing else in the Lisp systems I use.
_You_ do, I don't. So we use different programming styles. I'm
not suprised. BTW, I prefer not to use Emacs, but I recall that
you're an Emacs user. I'm currently looking for editors that can
use an ActiveX scripting engine, so that I can keep the choice
of language used for extending the editor independant of the
choice of editor. My choice of engine could be SCM...
The fact that you use Emacs speaks for itself.
> | Did you see the figures for code sizes that I posted?
> | Can you deny that EVAL was so much larger than anything else in Gambit C?
> | Can you convince me that I really need all this code?
>
> how the hell is anybody supposed to know what a figure like that means?
That EVAL adds a lot of code to a binary?
> your numbers are _literally_ meaningless. like most statistics, they are
> presented as if numbers alone had meaning. like anybody who has even an
> inkling of understanding of statistics knows, it's what you have measured
> that give the meaning, not the (numerical) measurement.
Code size is meaningless, right. That's not the message I get.
Pehaps you live in another world where such issues don't exist?
I donno, but if you can give me directions of how to get there,
and get a job working there, I'll be grateful.
We've had this debate before, Erik. As you may recall, I'm very
happy working where I am. I'm not a language bigot, so I can live
with using something other than Lisp.
> first, there is a very fundamental difference between rejecting invalid
> arguments and embracing the opposite of an invalid argument, whatever that
> might be. you don't seem to understand this difference very well. just
What I understand is that you find it hard to accept that not
everyone who uses Lisp shares the same values as yourself. Not
all of us see Lisp in the same way. Hence Dylan.
> because you offer so many invalid arguments and so much bullshit about how
> hard Lisp is for your sorry case, and I object and reject them, does not
I like being employed. ;-) It's a simple choice for me. I'm not
complaining (much), as I get paid well, the work is comfortable,
and it's getting better and better. Take a look at Smalltalk MT.
_That's_ the closer to what I'm looking for than any Lisp I've
seen so far. If Allegro CL for Windows could do the same things
(threading, OLE, OCX, delivery in a DLL, and soon ISAPI), then
I'd be more than happy to use it. What's more important is that
I'd also be able to use it professionally.
> mean that any more of your invalid arguments, this time about what I think,
> magically become true. you're illogical and irrational. that annoys me,
> more so when you don't seem to recognize that more than just your arguments
> are being rejected -- the entire set of premises from which you draw them
> is being rejected.
So you don't like what I have to say. Tough. Which premises are
you rejecting? Are you arguing that Lisp has a hard time competing
with C++ development tools for Windows? _That's_ the issue! There
are people who reject VB for the same reasons - they insist on
using features that C++ supports, but some other tools do not.
My argument is simply that if this changed, if there were Lisp
implementations for Windows that supported some of these features,
then we might see more people using Lisp. A _lot_ more people.
> second, there is nothing more destructive in a community of professionals
> than the sickening tendency among people of lesser integrity to consider
> _first_ what other people might think, _then_ what might be possible. I
> make my living on the premise that the reverse order is the only valid one,
> and frequently forget what other people might think. sometimes it takes a
> lot of effort to ignore other people's objections, however.
I _know_ what I get paid to do. What I think will be irrelevant,
if it's in conflict with the desires of a client.
See the "Functional languages in Software Engineering" thread,
currently running in comp.lang.functional. Language design and
implementation may determine who uses it, and which problems
they'll be interested in solving.
I admit that the problem domains that currently interest me
are rather narrow, which decreases the likelyhood that that
a particular language not directly supported by MS will suffer.
However, I didn't make those choices, and I'm willing to
discuss how Lisp might adapt to these demands.
Possibly some people (e.g MS) have biased things to make C++
look more attractive to developers. Possibly this may someday
change - see the MS Research website for details. I seem to
recall Henry Baker refering to an MS paper about "Lisp style"
macro processing for C++, and I suspect that he was thinking
of the MSR work, with some CS people at a certain Texas
university, called "Intentional Programming". This could
eventually introduce a lot of C++ programmers to some of the
ideas supposedly unique to languages like Lisp, e.g meta
linguistic tools.
So, Lisp could move closer to C++, in the sense that features
that many people think unique to C++ compilers might be available
to Lisp programmers, and that C++ could move closer to Lisp.
As I understand it, this was also one of the goals of Dylan...
The "state of the art" is constantly changing.
> third, "somebody" doesn't just call you up, saying "we'd like to pay you to
> write Lisp". they call you up to ask for your assistance on a hard
> problem, they listen to your suggestions and accept your design if you can
> present it credibly, they are willing to fork over a lot of money for a
> license to a supported, commercial Lisp development environment if you
> present the case for it, but only if you present the case for it, and they
> leave you alone for a month or five while you work out the magic. but you
> don't get called like that just by sitting in your uncomfortable office
> chair, writing Windows applications and airing your frustrations on
> comp.lang.lisp -- I sure as hell wouldn't call you with an offer to work on
> a Lisp project. it takes real-life effort, and may put tens of thousands
> of pounds of your personal income on the line, in saying "this can save us
> much more than it costs and much more than any alternative", and actually
> prove it.
I guess I get paid to work on "easy" problems. I'd like to
solve those problems using Lisp, but it looks like a "toy"
language like Smalltalk will have to suffice. Perhaps these
problems are just too "small" for Lisp?
So it goes.
> | If there's a way of satisfying them by using Lisp, then I'll be very
> | interested. However, I don't start by choosing Lisp, and then looking for
> | clients to write code for. Perhaps you're more fortunate than I am...
>
> perhaps I just work harder at it than you do. perhaps I work on problems
> that can't be solved in a realistic time frame in any other language than
> Common Lisp and within a large Common Lisp system. perhaps this has cost
> me three years of basically living off of writing articles and giving
> lectures instead of programming. perhaps I succeed in what I want because
> I don't waste my time and brain prostituting myself on Windows and Visual
> whatever? perhaps I got so sick and tired of programming in stupid
> languages like C and C++ that I wanted to sit down and invent my own
> language, build up my own support organization and try to sell it to
> others. or I could find a language that gave me all I needed, and as soon
> as I found a client who was interested in more than trivial solutions, have
> them fund my acquisition of tools from somebody who had already invented
> and implemented such a language. I chose the latter. nonetheless, I enjoy
> nitty-gritty details of implementation, _ONCE_. I'd like to do things only
> until I learn to do them expertly, then move on.
I feel the same way! How come most people want me to code in C++?
I could wait for a job using Lisp, but I prefer not to wait. So
I look for an alternative to C++ that does what I need. It doesn't
have to be Lisp - I'm currently using ML. I don't get paid to use
it, but sometimes I'm free to choose my tools, and sometimes ML
can do the job as well as anything else.
As I said, I'm not dogmatic about using Lisp. Not do I insist that
it should be Common Lisp. If I could write the code I'm paid for
in Lisp, then I would, but at present that's not the case. Perhaps
DylanWorks will suit me, which looks more than possible.
> the net effect is that you're not programming in Lisp for any clients. you
> can use whatever reasons you want to defend this position, if you think it
> needs defending (and if my recollection of your postings here for the past
> few months is correct, you portray a tremendous need to defend yourself and
> your position). my impression is indeed that you are dogmatic about Lisp,
> but not positively so, _negatively_ so: you repeat and stress how Lisp is
How many Lisps do you know that support ActiceX, OCX, ISAPI?
> never the right solution for you, despite repeated examples and much
> assistance to the contrary. this is very, very annoying. instead of
> concluding that "Lisp is not right for the jobs that Cyber Surfer does",
> the conclusion becomes "Cyber Surfer is not right or the jobs that Cyber
> Surfer does". I would never hire you for your newspostings. several
> people _have_ hired me for my newspostings.
I write Internet multimedia software for Windows. Take a
look at the Enrapture website for details. You might not
find many, but that's coz most of our recent work has been
web-based, and our site currently reflects that.
However, I'm probably closer to a typical Windows developer
than you are...and you have to admit, there's a hell of a lot
of these folks about.
> I'm no longer interested in understanding why you hold the positions you
> do, because I have yet to find any actually _constructive_ part to your
> whining. also, I have proven that with a much effort and with a braveness
> that I look back upon in awe -- I put much more on the line than I ever
> realized -- I have managed to land two contracts that bring me out of the
> Lisp wannabe camp, and right into the middle of a breakneck action movie.
> I haven't had so much fun in many, many years. I don't know if I will come
> out of this on top, but for the first time in at least five years, I can
> say to myself "I want to be a programmer and I think I can make it".
For years I've been reading UseNet posts from Lisp programmers
"whining" about how Lisp is not as popular as they think it
should be, wondering why more people are not using it, etc.
Well, my answer is simple. Lisp's alleged lack of "popularity"
reflects the way in which Lisp dialects and implementations have
targetted complex problem domains, like the kind that you've
refered to, instead of the simpler, but vastly more popular
problem domains that interest most other people.
I'm sure that you're aware of this, and appreciate it as well
as I do. So, is it possible that those who choose, let's say,
C++ have a different set of values to you or I?
> and by "a programmer" I don't mean an assembly line worker who churns out C
> or C++ or any of that shit. I want to build large structures and systems,
> not just line up a lot of new copies of the same old stuff side by side and
> call that a career. now I think I can pull it off, but I couldn't do it
> without a major Lisp vendor giving me unparalleled moral and technical
> support, and I couldn't do it without clients who really understand and
> listen to what I have presented to them. incidentally, most of this has
> happened in the past couple months, with _years_ of preparation on my part.
> maybe I have just been very fortunate, but I don't think these things just
> happen. still, I'm deeply grateful to the people who make it possible for
> me to enjoy programming for pay, again -- this time in a language that lets
> me think hard about hard issues, not waste all my time on trivial things.
Ahh, "C++ programmers write shit". That implies a lot of very
negative ideas. Isn't it curious how successful such software is?
I'm not claiming that such tools as C++ are "superior" to Lisp,
just successful. People use them _because they can_.
Perhaps this is coz most people are "too dumb" to use Lisp? Hmm.
That's debatable. I'm sure that a lot of people would disagree
with that. Still, that means that a hell of a lot of us will
be asked to use C++ - or an alternative tool that can do the
same things. If such a Lisp existed, for Windows, then I'd be
amoung the first to use it.
Not all of us writing software for Windows are "dumb". That's
just as easy way of explaining why so many people haven't yet
reached the enlightenment that you and I share. The difference
between us is that I'm not assuming that _anyone_ is dumb.
The existance of Smalltalk MT seems to support my point of view.
It's just a pity that nobody has yet produced a Lisp system with
Windows support as strong as this. It appeares that Harlequin
are endeavouring to change this, and I wish them luck.
Whether I write Internet and multimedia apps in Smalltalk, Lisp,
or Dylan makes little difference to me. I'll be happy enough.
If you write a different kind of software, then your mileage
may vary. As it apparently does,
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
280 lines???
Would you _both_ please take this off-line?
Thanks.
--
William A. Barnett-Lewis
······@mailbag.com
------------------------------------------------------------------------
-
"We are artists. Poets paint motion and light. Historians paint
stills. It can be dangerous to get history from a poet. It can also be
the greatest blessing."
------------------------------------------------------------------------
-
From: Big G
Subject: Re: superior(?) programming languages
Date:
Message-ID: <32B904D6.4BC6@en.com>
William A. Barnett-Lewis wrote:
>
> 280 lines???
>
> Would you _both_ please take this off-line?
> Thanks.
> --
> William A. Barnett-Lewis
> ······@mailbag.com
> ------------------------------------------------------------------------
> -
> "We are artists. Poets paint motion and light. Historians paint
> stills. It can be dangerous to get history from a poet. It can also be
> the greatest blessing."
> ------------------------------------------------------------------------
> -
I actually enjoy reading the debate.
FWIW, I am working on a project which uses both C++ for the guts and LISP for
dynamic interaction of objects. It works well and makes for easy online configuration.
I get the best of both worlds this way.
Hey, it takes all types to make a world :)
Flame on Dudes...
-G
* Cyber Surfer
| The fact that you use Emacs speaks for itself.
I don't know that, but the fact that you manage to produce this argument is
really the final piece of evidence to show that you really don't want to
understand or work with Lisp -- you want to whine and complain and insult
those who work with Lisp and are very happy and productive with it.
just stop annoying people with your complaints. haven't you noticed that
people around you have _done_ something about their situation while you are
still sitting in the same dump you did a year or two ago? doesn't that
_tell_ you something? it _truly_ speaks for itself, in my view.
#\Erik
--
users should be computer-friendly.
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> * Cyber Surfer
> | The fact that you use Emacs speaks for itself.
>
> I don't know that, but the fact that you manage to produce this argument is
> really the final piece of evidence to show that you really don't want to
> understand or work with Lisp -- you want to whine and complain and insult
> those who work with Lisp and are very happy and productive with it.
Now you can't accept that I don't like Emacs? Erik, has it occurred
to you that Emamcs and Lisp are _not_ the same thing? Perhaps some
people, like yourself, make this association, but not all of us do.
> just stop annoying people with your complaints. haven't you noticed that
> people around you have _done_ something about their situation while you are
> still sitting in the same dump you did a year or two ago? doesn't that
> _tell_ you something? it _truly_ speaks for itself, in my view.
What can I do? I'd be happy to write my own Lisp compiler, if I had
the time. However, what I _am_ doing is using alternative tools.
As I've said many times, I don't have to use _Lisp_, I just prefer to.
BTW, it's not a "dump". Is this another of your insults? I've said
before that I'm very happy working where I am. More than happy.
I only discovered Lisp about 10 years ago, so I've not had as much
time to use it as yourself (15+ years?), and I can barely say that
I've ever used Unix or Emacs. I've I'd been using all of these
things for 15+ years, perhaps I'd be agreeing with you. However,
my experiences appear to have been very different from yours,
and it would be easy to say that I'm not alone.
Why deny a tool as powerful and neat as Lisp to all these
programmers? Even when writing "shit" (as you call it), a
programmer can still appreciate a good tool. Such tools are
coming into existance (DylanWorks, Smalltalk MT, Dolphin
Smalltalk, and others). While it might initially appear that
this is about programming languages, I sometimes suspect,
when reading your posts, that it has more to do with attitudes
about OSs. For all I know, it's actually Windows and software
for that OS that you consider to be "shit". Am I wrong?
My feeling is that good tools should be available to all
programmers. Would you not call Lisp a good tool? In what
way would improving the support for the OS in Lisp tools
for Windows hurt you? That puzzles me. Nothing in the Lisp
tools that you use need change in the smallest way! As I
understand it, you use Unix, so how can Lisp software for
Windows hurt you?
I'm trying to be constructive. I'm not sure what you're doing,
but I hope we can discuss this like civilised people. I know
that there are many things on which we agree, so it should
be possible.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk (Cyber Surfer) writes:
| From: ············@wildcard.demon.co.uk (Cyber Surfer)
| Date: Fri, 20 Dec 96 07:18:29 GMT
|
| My feeling is that good tools should be available to all
| programmers. Would you not call Lisp a good tool? In what
| way would improving the support for the OS in Lisp tools
| for Windows hurt you? That puzzles me. Nothing in the Lisp
| tools that you use need change in the smallest way! As I
| understand it, you use Unix, so how can Lisp software for
| Windows hurt you?
I would love to see a good Lisp environment for Windows that allowed
complete interoperability with arbitrary libraries. Alas, I don't
expect one soon.
The traditional problem with making OS tools and Lisp cooperate does
not have to do that much with Lisp per-se as with memory management.
This problem also plagues ML and could plague Java.
You can have a version of Lisp without automatic memory management
(i.e. garbage collection) -- early MIT Lisp machines effectively
worked that way, but it is assumed by most Lisp programmers that
memory management is automatic at least to a first approximation.
The OS, and even more importantly, the libraries that programmers
often want to reuse, make their own assumptions about memory
management, often using explicit allocation and deallocation
(e.g. malloc and free). Furthermore, they sometimes cache pointers to
objects passed as parameters (e.g. strtok, callback functions and
data).
The two _styles_ do not mix well. The best attempts to marry them are
conservative collectors but they are not a complete solution.
The traditional answer from the Lisp community is (exaggerating quite
a bit): "We don't care about the other libraries, we'll just
reimplement what's useful and right, and do it better". Of course,
this is shortsighted since it forces the Lisp community to reinvent
the wheel (e.g. CLX).
The traditional answer from the OS and library writers is
(exaggerating only a bit): "Why should we care about you Lispers?
there aren't enough of you". Of course, this is unfortunate since it
is a catch-22 situation.
The situation, fortunately, may be changing although perhaps too late
for Lisp.
Java has automatic memory management of the same sort that Lisp has,
and to make it reliable and efficient, the same sort of constraints in
interoperability appear.
Because the OS and library writers care about Java (or at least they
pay lip service to it), they are likely to accommodate its memory
management needs (e.g. enforcing a discipline of using "handles"), in
the process accommodating Lisp, ML, and perhaps others.
I expect that if Java lives up to its promise, and Java-compatible
native libraries start appearing, a Lisp (or ML) implementation will
be able to make use of them very easily.
In article <·················@hplgr2.hpl.hp.com>
···@hpl.hp.com "Guillermo (Bill" writes:
> I would love to see a good Lisp environment for Windows that allowed
> complete interoperability with arbitrary libraries. Alas, I don't
> expect one soon.
Yes, it makes many of those APIs that MS are so busy creating
very hard to use. Look at the development tools that MS sell,
see what enables them to use the various APIs, then add those
same features to Lisp. If you have a C++ compiler, as almost
any serious Windows develop _must_ (MS assume this!), then
you can package an API, or the bits of it that you need, into
an OLE class. In some cases, like ActiveX, this has already
been done.
> The traditional problem with making OS tools and Lisp cooperate does
> not have to do that much with Lisp per-se as with memory management.
> This problem also plagues ML and could plague Java.
I'm not so sure of this. Somehow VB manages ok. It could be
that VB is written in VC++ (and some error msgs suggest this),
but I still wonder what makes it so easy for VB, but so hard
for Lisp (e.g. ACL for Windows). Can it really be so hard to
manage "alien" objects in Lisp?
> You can have a version of Lisp without automatic memory management
> (i.e. garbage collection) -- early MIT Lisp machines effectively
> worked that way, but it is assumed by most Lisp programmers that
> memory management is automatic at least to a first approximation.
There are, I believe, Lisps that can cope with "alien" objects.
For Unix, at least. So I guess it's been done.
> The OS, and even more importantly, the libraries that programmers
> often want to reuse, make their own assumptions about memory
> management, often using explicit allocation and deallocation
> (e.g. malloc and free). Furthermore, they sometimes cache pointers to
> objects passed as parameters (e.g. strtok, callback functions and
> data).
This is true. A lot of assumptions can be made by the "OS" - in
the case of Windows, it's sometimes hard to distinguish between
the OS and an API _added_ to the OS, when you know that MS may
well be shipping the DLLs with the next OS release. Anyway, the
problem is not the distribution of the DLLs, but the assumptions
made about the language that'll use them.
MS plan to make the entire Windows (that's Win32, of course) API
(err, APIs?) OLE based. That implies C++, VB, and any other tool
that can use OLE. No Lisp that I know of can do this, so far, but
I'm hoping that will change.
> The two _styles_ do not mix well. The best attempts to marry them are
> conservative collectors but they are not a complete solution.
Hmm. Smalltalk MT can, I believe, use OLE and OCX. Why not Lisp?
> The traditional answer from the Lisp community is (exaggerating quite
> a bit): "We don't care about the other libraries, we'll just
> reimplement what's useful and right, and do it better". Of course,
> this is shortsighted since it forces the Lisp community to reinvent
> the wheel (e.g. CLX).
I remember a major Lisp vendor, only a few years ago, stating that
they couldn't support shared libraries, as they couldn't support
them on every platform. I hope that attitude has changed! Shared
libraries are a little more popular than they used to be, even in
the Unix world.
BTW, many Lisp vendors now support CLIM, not CLX. As I understand it,
CLX is no longer a part of X Windows. CLIM, the Common Lisp Interface
Manager, is a proprietry alternative.
> The traditional answer from the OS and library writers is
> (exaggerating only a bit): "Why should we care about you Lispers?
> there aren't enough of you". Of course, this is unfortunate since it
> is a catch-22 situation.
Hence the death of CLX? Possibly. I wouldn't know, as I don't use
X Windows, never mind CLX (historical accident, rather than choice).
> The situation, fortunately, may be changing although perhaps too late
> for Lisp.
Too slowly, perhaps. I dunno about "too late".
> Java has automatic memory management of the same sort that Lisp has,
> and to make it reliable and efficient, the same sort of constraints in
> interoperability appear.
Take a look at Dylan. Dispite reports of Dylan's death (probably
due to some bitter Mac developers misinforming a journalist), it's
still alive and growing stronger. Dylan is closer to the kind of
Lisp that most people want than the kind of Lisp that Erik Naggom
uses. Happily, Erik and co will be able to continue to use the
"traditional" Lisp, while the rest of us get what we want, too.
> Because the OS and library writers care about Java (or at least they
> pay lip service to it), they are likely to accommodate its memory
> management needs (e.g. enforcing a discipline of using "handles"), in
> the process accommodating Lisp, ML, and perhaps others.
Dylan should be able to cope just as well. Ask Harlequin what
DylanWorks can do, today. It's not available yet, but apparantly
they've demonstrated what they've got so far, and in public.
It sounds like intergration with the "OS" way of doing things
will be no problem.
> I expect that if Java lives up to its promise, and Java-compatible
> native libraries start appearing, a Lisp (or ML) implementation will
> be able to make use of them very easily.
CMU are also working on a Dylan implementation. While I'll be
interested to see what can be done with Java, Dylan is much
closer to what I'm looking for. This shouldn't be suprising,
considering how it was designed - by some Lisp programmers
working for _Apple_. I think Apple have (or had) a much better
idea of what most developers want today than the designers of
Common Lisp, 15 years ago, I'm not knocking CL, but it does
show its age.
Dylan and Java, on the other hand, are rather more _modern_
languages. How well they address the needs of modern developers
has yet to be seen, but I think we can afford to be be patient.
Future generations are relying on us.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> Take a look at Dylan. Dispite reports of Dylan's death (probably
> due to some bitter Mac developers misinforming a journalist), it's
> still alive and growing stronger.
So strong, that it is almost completely invisible and has
almost no influence on developer choices at all. Where
is Dylan??? Apple Dylan is not really supported
(Digitool can only provide bug fixes), CMU hasn't delivered
anything exciting yet, Harlequin has not released anything.
But it is getting stronger everyday, huh? Until someone
releases something useful, I'll write my code in Common Lisp
or maybe even Scheme.
> BTW, many Lisp vendors now support CLIM, not CLX. As I understand it,
> CLX is no longer a part of X Windows. CLIM, the Common Lisp Interface
> Manager, is a proprietry alternative.
>
> > The traditional answer from the OS and library writers is
> > (exaggerating only a bit): "Why should we care about you Lispers?
> > there aren't enough of you". Of course, this is unfortunate since it
> > is a catch-22 situation.
>
> Hence the death of CLX? Possibly. I wouldn't know, as I don't use
> X Windows, never mind CLX (historical accident, rather than choice).
Sorry, but you don't seem to know a thing about CLX or CLIM.
Better be silent.
CLX is just some source code that gives you basic X support
for Common Lisp. It is free and you can port it to any version of
Common Lisp with TCP support in a few hours.
CLIM on the other hand is a large User Interface Management
System which is independent of the underlying window system.
It runs on top of CLX, Symbolics' window system, and some other
(Harlequin CAPI, ACL PC, ...).
> CMU are also working on a Dylan implementation. While I'll be
> interested to see what can be done with Java, Dylan is much
> closer to what I'm looking for. This shouldn't be suprising,
> considering how it was designed - by some Lisp programmers
> working for _Apple_. I think Apple have (or had) a much better
> idea of what most developers want today
So much, that Apple killed the project. Seemed not
that important to Apple. They are using C and C++
for their crashing OS (some of their stuff is actually
quite cool, but build on a shaky foundation).
> than the designers of
> Common Lisp, 15 years ago, I'm not knocking CL, but it does
> show its age.
It is so much showing its age. So much that Digitool recently
released version 4.0 of its Macintosh Common Lisp.
It does support native threads, native shared libraries,
almost all OS calls, deals with alien memory, supports
finalization, has ephemeral garbage collection, compiles
to native PowerPC code, has a large CLOS based and easy to
use UI library, has an integrated editor, does tail
recursion elimination, has enthusiastic users and excellent support,
and, yes, people are developing **real** applications
with MCL (some of them you can download on the Net).
Applications you can really *buy*. In Lisp. Isn't
this interesting?
Guys, I like to see you not waste your time with useless
nonsense discussion. We can use Common Lisp (and Scheme)
today and we have a *lot* to do.
Better let's get our act together and do something useful:
Useful hacking areas for advancing Common Lisp
==============================================
- CL-HTTP needs your hacking. We have ideas for the
entire next three centuries. Ask John Mallery about advice
(join ······@ai.mit.edu).
- We like to start a Free CLIM effort. Vendors were not
very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/)
has started a mailing list, which I think will get some discussion
started in the new year. Join now!
- Start thinking about CLIM 3.0.
- Get threads for CMU CL. Ask Martin Cracauer about that.
- support the Lisp Team (http://claretech.com/~tobinbs/lispteam.html)
in creating some business libraries for Common Lisp. This
is highly cool!
- Develop support for Common Lisp in ILU 2.0.
- Help the ALU to develop their new web presence - a cool prototype
is ready (done by Howard R. Stearns). But we want it to run
on CL-HTTP. Integrate the FAQ. This is very important
for the Lisp community.
- Develop a central code management system for the Common Lisp
community on the net.
- Develop an application server for Common Lisp.
- Identify a secure subset of Common Lisp for remote execution.
- Develop a free OODBMS for Common Lisp.
- Write a book about Common Lisp on Windows and MacOS.
- Develop better development tools for CLOS.
- Help developing SOM / QuickDraw 3d / QuickDraw GX /
OpenTransport / ... support for Macintosh Common Lisp. Ask
Digitool about SMP (symmetric multi-processing)
for the new PowerMacs.
- Yes and finally, but on every wishlist, develop
an object oriented portable DEFSYSTEM facility.
This would be useful for all of us. What is your contribution?
Sitting and waiting for a phone call from some company, while
writing completely useless postings to Usenet??? If only people would
stop writing device drivers for numerous useless Unix
variants and start something real cool.
Lisp User Group Meeting in Germany next Year
============================================
We are currently preparing the second Lisp User Group Meeting in
Germany (see http://www.lisp.de/). Soon (hopefully next week) we will
announce the agenda. We have got some interesting talks
about CL-HTTP application, Site management for the Web, EuLisp,
real distributed computing
with Scheme, the Statice OODMBS, etc.
We want people to join us in Munich. If you already know
that you will attend the Lisp User Group Meeting, send
us a note to ·············@lisp.de .
If you have a contribution, let us know about that.
Write to ·············@lisp.de , too.
Lisp User Group in Germany/Europe
=================================
We also want feedback on how to start an active Lisp User Group in
Germany/Europe:
**** Mail us your ideas about the ****
**** German/European Lisp User Group ****
**** at ··········@lisp.de ****
Rainer Joswig
In article <·································@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> > Take a look at Dylan. Dispite reports of Dylan's death (probably
> > due to some bitter Mac developers misinforming a journalist), it's
> > still alive and growing stronger.
>
> So strong, that it is almost completely invisible and has
> almost no influence on developer choices at all. Where
> is Dylan??? Apple Dylan is not really supported
> (Digitool can only provide bug fixes), CMU hasn't delivered
> anything exciting yet, Harlequin has not released anything.
It would be unfair to expect anything delivered so soon,
but if you count Mindy, then there's at least one "Dylan"
implementation available.
Some might consider Lisp to be dead, simply because they
hear nothing about it. Would that be fair? I think not.
> But it is getting stronger everyday, huh? Until someone
> releases something useful, I'll write my code in Common Lisp
> or maybe even Scheme.
I wouldn't you to do otherwise! I'm not pretending that
what's available today is "industrial strength".
Did I mention patience? I've been looking for a language
like Dylan since the early 80s. I can wait a little longer.
> Sorry, but you don't seem to know a thing about CLX or CLIM.
> Better be silent.
That's exactly what I mentioned it! I've seen posts from
people concerned for the future of CLX. Is that worth flaming
me for?
> So much, that Apple killed the project. Seemed not
> that important to Apple. They are using C and C++
> for their crashing OS (some of their stuff is actually
> quite cool, but build on a shaky foundation).
I think of Apple as the "Evil Empire", mainly coz of their
use of "hired guns" to compete with rivals. I didn't say that
Apple still supported Dylan, just that they started it.
Does Dylan die with Apple? Ask CMU and Harlequin.
> It is so much showing its age. So much that Digitool recently
> released version 4.0 of its Macintosh Common Lisp.
> It does support native threads, native shared libraries,
> almost all OS calls, deals with alien memory, supports
> finalization, has ephemeral garbage collection, compiles
> to native PowerPC code, has a large CLOS based and easy to
> use UI library, has an integrated editor, does tail
> recursion elimination, has enthusiastic users and excellent support,
> and, yes, people are developing **real** applications
> with MCL (some of them you can download on the Net).
Fortran 77 also shows its age, and yet is still being used.
That's no reason not to consider F90.
> Applications you can really *buy*. In Lisp. Isn't
> this interesting?
All it tells me is that people still use CL. See above.
Lisp isn't dead yet. I don't just mean CL. Perhaps your
definition of Lisp is limited to CL, but I doubt that.
Anyway, mine certainly isn't. While programmers use a
language, there should be room for change.
> Guys, I like to see you not waste your time with useless
> nonsense discussion. We can use Common Lisp (and Scheme)
> today and we have a *lot* to do.
Yep, but not enough. That's why I'm using C++. I'm not
asking for much, just a few things like OCX etc. Threading
would be really handy.
> - CL-HTTP needs your hacking. We have ideas for the
> entire next three centuries. Ask John Mallery about advice
> (join ······@ai.mit.edu).
CL-HTTP does indeed need some hacking.
While it well be possible to do it all in CL-HTTP, it would
require a lot of work to do it as well as commercial web servers
_and_ all the addon tools for them. I know they cost money,
but that's not a problem.
In fact, it may be necessary for CL-HTTP to do all that a
commercial web server can do _and more_, just to get noticed.
The marketing factor should not be ignored, unless you don't
have to convince anyone that CL-HTTP is capable.
A lot of work to do.
> - We like to start a Free CLIM effort. Vendors were not
> very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/)
> has started a mailing list, which I think will get some discussion
> started in the new year. Join now!
Ah, yes. CLX is not enough? This is the concern that I refered
to above.
> - Start thinking about CLIM 3.0.
Yes, start early.
> - Get threads for CMU CL. Ask Martin Cracauer about that.
Threads are very tasty. However, I've no chance of using
CMU CL any time soon, so I can't help.
You made many other fine suggestions.
> This would be useful for all of us. What is your contribution?
I'm working on a Lisp to C++ compiler, with the intention
of supporting any API I need to use. Progress has been slow
so far, due to other demands on my time.
> Sitting and waiting for a phone call from some company, while
> writing completely useless postings to Usenet??? If only people would
> stop writing device drivers for numerous useless Unix
> variants and start something real cool.
Actually, I've been coding in C++. I'm not proud of it,
but that's what I get paid for.
I don't expect my Lisp compiler to be useful by anyone
but me, as the code quality will be relatively poor,
compared to the existing Lisp compilers available.
(That's why I'd prefer to use a commercial compiler.)
It may also have a few quirks, like not being standard.
Still, if anyone wants to use it, I expect that the
code will be available online.
I was hoping to have a reasonable discussion about what may
(or may not) be done with Lisp to make it more "competitive"
(in the sense that implementations might be able to compete
with C++ compilers), but I guess that's not possible.
Flame away, Rainer. It won't change anything. I'm willing
to discuss these things with you, but I'm not sure what
the point would be. Why should you care whether a Lisp
for Windows supports OCX or not? In fact, why should _I_
care, when Smalltalk MT is available?
Happy New Year, BTW.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>In article <·································@news.lavielle.com>
> ······@lavielle.com "Rainer Joswig" writes:
>That's exactly what I mentioned it! I've seen posts from
>people concerned for the future of CLX. Is that worth flaming
>me for?
CLX is just an Xlib mapping for Lisp. There havn't been work on it for
a long time and that makes some people upset who needs more advanced
Xlib features.
But for me (and - obviously most other), the existing interface is
sufficient for what I'm going to do (I don't care for advanced Xlib
features, I need something I can use to display basic things and get
some feedback).
>> Applications you can really *buy*. In Lisp. Isn't
>> this interesting?
>All it tells me is that people still use CL. See above.
>Lisp isn't dead yet. I don't just mean CL. Perhaps your
>definition of Lisp is limited to CL, but I doubt that.
>Anyway, mine certainly isn't. While programmers use a
>language, there should be room for change.
There are points I don't like about Common Lisp. Therefore, I looked
into Scheme and SML and thought about waiting for Dylan.
I decided that Common Lisp is good enough and that the range of
availiable tools (cl-http, Screamer, Garnet, maybe someday CLIM,
books, other people pushing Lisp etc) is the greatest resource I can
think of.
Look at all those Java tools. I happen to like the language, but
almost all libraries I can get source for are pure junk (I like having
source, I need to learn from it). Not to speak of JVMs exploding under
the slightest data load.
Dylan's greatest drawback will of course be the lack of such resources
for my needs and without a free environment I can't expect free source
to show up.
>> Guys, I like to see you not waste your time with useless
>> nonsense discussion. We can use Common Lisp (and Scheme)
>> today and we have a *lot* to do.
>Yep, but not enough. That's why I'm using C++. I'm not
>asking for much, just a few things like OCX etc. Threading
>would be really handy.
Lack of threads in free CLs (except ECOLisp) is what I miss
most. Problem at hand: The problem is too tough for me to solve.
What's OCX?
>> - CL-HTTP needs your hacking. We have ideas for the
>> entire next three centuries. Ask John Mallery about advice
>> (join ······@ai.mit.edu).
>CL-HTTP does indeed need some hacking.
>While it well be possible to do it all in CL-HTTP, it would
>require a lot of work to do it as well as commercial web servers
>_and_ all the addon tools for them. I know they cost money,
>but that's not a problem.
>In fact, it may be necessary for CL-HTTP to do all that a
>commercial web server can do _and more_, just to get noticed.
>The marketing factor should not be ignored, unless you don't
>have to convince anyone that CL-HTTP is capable.
>A lot of work to do.
Could you give some examples what feature you are referring to? About
two third of all Web servers in the world are drive by apache. Apache
is just serving files, calling CGIs and pushing contents of Web pages
through a C api.
Server-side Java: Servlets look pretty nice, but it's not that cl-http
cannot install user code to generate HTML pages.
SLL: Who is actually using it? There's a commercial Apache version
with SLL, but as we see, most people can live without it.
What most people driving Web site today want:
- Pure file serving with a few gimmicks. Apache is just right
What most people drinving Web servers one-two years from now:
- Easiest setup to open your whole windows box to the net. MS will
take care of servers doing what they (the serverm not the user)
thinks is a nice gimmmick.
What people want who wants to do killer Web applications:
- Cleanest way to handle user input from server-side
application. Parts of cl-http take care of this.
- Cleanest way of presenting outout to the user without overloading
network. Parts of cl-http take care of this, as well as CLIM-related
projects.
- A lot of Web features that work around weaknesses in the stateless
HTTP protocol needs a clean programmer interface. Have you seen
cl-http's (http:with-cookie-values ...)? Have you see what it takes
to do the same from CGI-based C programs? If so, you could imagine
what I spent the last year with.
>> - We like to start a Free CLIM effort. Vendors were not
>> very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/)
>> has started a mailing list, which I think will get some discussion
>> started in the new year. Join now!
>Ah, yes. CLX is not enough? This is the concern that I refered
>to above.
I'm afraid I have to pick up Rainer's previous note and ask you to
have a brief look over CLX and CLIM.
To make it short: Yes, CLX is not enough to be counted as the only GUI
tool. Xlib isn't, either.
>I was hoping to have a reasonable discussion about what may
>(or may not) be done with Lisp to make it more "competitive"
>(in the sense that implementations might be able to compete
>with C++ compilers), but I guess that's not possible.
While Rainer is quite rough sometimes, he's one who actually pushes
Lisp forward (much more than me).
I'll try to say it as polite as I can, but you, Cyber (I'm sure that's
not your real name, but anyway) are someone you does acutal damage to
the Lisp community.
While you try to point out weaknesses of Lisp (that's a good thing, of
course), you suffer from commenting about things you don't know enough
about. For some years, if I remember right, this newsgroup sees
postings of yours that draw a wrong picture of the usefulness of some
of Lisp features. The other way round, of also named advantages of
Lisp that were pointless.
Remember, this is a public forum. Many people are looking for a new
language to use. In the past, those hint by C++, now those who took
the new freedom introduced by Java (its now possible to tell
management there *are* other languages).
If someone gets interested in Lisp, he/she usually monitors this
newsgroup for a while or even browsing message of a few days
once. When you post nonsense about a weakness and someone corrects
you, the new reader will have no idea who of you is correct. Those
people will count the point discussed as Lisp feature that is even
argued over in the Lisp community.
When you post wrong information about positive features, you might
lead people to try that out, recognize it was wrong and count it as
"the Lisp community either has no idea what is useful" or "All those
praised Lisp advantages turn out unuseable for other people".
Nowadays, it is even more important to keep the newsgroup's contents
in line. There's a great potential of hackers who actually can
contribute to free software. Today, many people are facing problem
that cry for a more dynamic language than C++, mostly feeding the
Web. When i look over the maintainer list of the current CMUCL effort,
I see a lot of people joining from usenet or public mailing lists.
Every newsgroup has people like your, but next to FreeBSD's Jesus
Monroe Jr. (he havn't been using his real name either), you are quite
outstanding how long you maintain to post about things you don't know
about. Sad. How much time did you spend to post to comp.lang.lisp this
week? I'm sure you could also had a quick look over the CLX manual and
into Ralf Moeller's excellent CLIM introdution on the Web. I'd say
that would have been a lot more useful for all of us.
I'll stop and resume reading cl-http's documentation, as I speak of
it.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <······················@wavehh.hanse.de>
········@wavehh.hanse.de "Martin Cracauer" writes:
> CLX is just an Xlib mapping for Lisp. There havn't been work on it for
> a long time and that makes some people upset who needs more advanced
> Xlib features.
Ah, that must be the "conern" that I refered to, then. I can
understand such a concern, tho in this case I can't share it,
having no (current) use for X Windows, never mind CLX. I am
curious about it, tho.
> But for me (and - obviously most other), the existing interface is
> sufficient for what I'm going to do (I don't care for advanced Xlib
> features, I need something I can use to display basic things and get
> some feedback).
Excellent.
> There are points I don't like about Common Lisp. Therefore, I looked
> into Scheme and SML and thought about waiting for Dylan.
I've recently been looking closely at SML, but for now O'caml
serves me well - for my personal projects, anyway. It would be
harder to use for work, but not impossible. For example, I can
write CGI code with it. If I'd discovered O'caml a few months
earlier, I might've been able to use it for my last CGI project.
In fact, I'm still tempted to re-write the C++ code I have in
O'caml, to see how easily (and quickly) it might be done.
> I decided that Common Lisp is good enough and that the range of
> availiable tools (cl-http, Screamer, Garnet, maybe someday CLIM,
> books, other people pushing Lisp etc) is the greatest resource I can
> think of.
Common Lisp has a lot going for it, once you've accepted that
Lisp can be used. That's no problem for you or I, of course.
> Look at all those Java tools. I happen to like the language, but
> almost all libraries I can get source for are pure junk (I like having
> source, I need to learn from it). Not to speak of JVMs exploding under
> the slightest data load.
YMMV. Most of the uses of Java that I see are trivial, but this
is expected to change, once the quality of JVMs improve. For example,
how many JVMs use a generational GC? Yet JVMs that generational GCs
are on their way.
I'm not a Java advocate, but if if my choice was between C++ and
Java, then I'd like to choose the latter. For many apps today,
Java is not a choice. That's why people say it'll change.
> Dylan's greatest drawback will of course be the lack of such resources
> for my needs and without a free environment I can't expect free source
> to show up.
I recall Harlequin refering to a demo of DylanWorks using OLE.
If the strength of support for other Windows APIs is as strong,
then I'd expect a lot of people to be interested - or at least
very curious. I guess it'll depend on whether you see Dylan as
an alternative to Lisp (Common Lisp, Scheme, whatever) or C++.
> Lack of threads in free CLs (except ECOLisp) is what I miss
> most. Problem at hand: The problem is too tough for me to solve.
Same here. How many free CLs with native code compilers are there?
To avoid licencing problems, I'd prefer a commercial compiler.
> What's OCX?
Like a Widget. (A 32bit VBX? That's a simple explanation, but
only if you know what a VBX is...) There's a _lot_ of support
for these things, esp in C++. Component based development is
the name of the game these days.
I hope that's clear. If not, please let me know, and I'll
try harder to explain it. I hesitate to go into details,
in case I say too much and bore everyone. ;-)
> Could you give some examples what feature you are referring to? About
> two third of all Web servers in the world are drive by apache. Apache
> is just serving files, calling CGIs and pushing contents of Web pages
> through a C api.
Take a look at some of the web servers for Windows. One of the
buzzwords now is ISAPI. This means dynamic linking to code in a
DLL, avoiding the overhead of starting a new process for every
CGI query.
However, the real problem may just be a marketing one. Most people
(using Windows) won't be impressed by CL-HTTP. They may simply be
ignorant, but don't underestimate the significance of ignorance!
Any learning curve is going to be a black mark against CL-HTTP,
and this app has two curves: one for itself, and another for CL.
If you already know of CL-HTTP, know CL, and it's your choice
alone to make, then it's easy. For my employer, the first choice
of Apache, running under Linux. Unfortunately, a Windows based
web server arrived and was running after a simple install, while
Apache may or may not have been running. I never found out.
The choice was not made due to ignorance, but due to a lack
of time. One server took longer to get running than the other
(which took _no time at all_).
None of which matters much, as it's only one example. It does,
however, illustrate how such important choices may be made,
even when Unix is an option, as it was in our case. It's
certainly too late to change the server, now, even if I could
convince anyone of the virtues of CL-HTTP, which would be
unlikely. It would have to compete with the code already written
for the current setup, and the fact that if we used Lisp, then
I'd be the only one who could maintain the CGI code. That would
be unacceptable.
I can't comment on the numbers of servers using Apache, as most
people I know with web servers are using NT. The OS seems to me
to be almost irrelevant, as the real issue is likely to be the
choice of language for the CGI code. as you may be aware, a great
many people choose Perl.
It's not all hopeless, but it would be a trully massive task to
compete with all that!
> Server-side Java: Servlets look pretty nice, but it's not that cl-http
> cannot install user code to generate HTML pages.
See above. CL-HTTP will be very often be competing with existing
solutions. If you're starting from scratch, in an area where no
existimg toopls exst (rare, but possible), then you may have an
edge that'll be enough.
> SLL: Who is actually using it? There's a commercial Apache version
> with SLL, but as we see, most people can live without it.
Secure sockets? I assume this is what you mean.
This is a feature that I've had no reason to look at, so far,
mainly because there are others who deal with this side of web
development at Enrapture. However, I'm sure it'll be used by
us in the forseeable future.
I know that others are interested in it, and not all of them
are using Apache. Who are they? I can think of a few names...
> What most people driving Web site today want:
> - Pure file serving with a few gimmicks. Apache is just right
I hope so - that'll give Enrapture an edge! Many of the web
developers that I know are going beyond the basics, but I'm
not sure how typical they are.
> What most people drinving Web servers one-two years from now:
> - Easiest setup to open your whole windows box to the net. MS will
> take care of servers doing what they (the serverm not the user)
> thinks is a nice gimmmick.
Gimmick? What gimmick?
> What people want who wants to do killer Web applications:
> - Cleanest way to handle user input from server-side
> application. Parts of cl-http take care of this.
Form handling is very basic stuff. If that's not enough, then
there are tools that can make it obscenely easy. You'd need a
well above average app to make _Perl_ necessary, never mind Lisp.
> - Cleanest way of presenting outout to the user without overloading
> network. Parts of cl-http take care of this, as well as CLIM-related
> projects.
Are you talking about a user over the web, or a local user,
configuring the web server? The CLIM reference leads me to
suspect that it's the latter.
> - A lot of Web features that work around weaknesses in the stateless
> HTTP protocol needs a clean programmer interface. Have you seen
> cl-http's (http:with-cookie-values ...)? Have you see what it takes
> to do the same from CGI-based C programs? If so, you could imagine
> what I spent the last year with.
At Enrapture, we're generally not using C/C++ for our CGI
coding. There are domain-specific tools available that make
C/C++, Perl, and any other general purpose programming
language a complete waste of time.
For Unix, perhaps MetaHTML will do cookies, but I believe
it'll do many of things that we're doing. If we were using
Unix instead of NT, then MetaHTML might well have been our
choice.
CL-HTTP may well make things easier than C, but so do a lot
of other tools, and they don't rely on Lisp. Unless you can
make CL-HTTP's use of Lisp transparent, the non-Lisp tools
have a big edge over CL-HTTP. In the same way, it gives them
an edge over the tools that use Perl, so this isn't merely a
language issue. It's a question of how transparent the language
can be, and what features are available "out of the box".
Of course, I'm making some assumptions. Perhaps the web authors
that I know aren't typical. However, if you're hoping to convert
C and Perl programmers to Lisp and CL-HTTP, I wish you luck.
I hope I'm not making it sound like any efforts using Lisp will
be wasted, as I don't believe that's true. I just have doubts
about web software, based on what I've seen done using tools
that don't use Lisp. YMMV - and I hope it does.
> While you try to point out weaknesses of Lisp (that's a good thing, of
> course), you suffer from commenting about things you don't know enough
> about. For some years, if I remember right, this newsgroup sees
> postings of yours that draw a wrong picture of the usefulness of some
> of Lisp features. The other way round, of also named advantages of
> Lisp that were pointless.
I'm _asking_ about things I don't know enough about. Please
don't make the "kill the newbie" error!
> Remember, this is a public forum. Many people are looking for a new
> language to use. In the past, those hint by C++, now those who took
> the new freedom introduced by Java (its now possible to tell
> management there *are* other languages).
Yes, Java has helped change the atmosphere,
> If someone gets interested in Lisp, he/she usually monitors this
> newsgroup for a while or even browsing message of a few days
> once. When you post nonsense about a weakness and someone corrects
> you, the new reader will have no idea who of you is correct. Those
> people will count the point discussed as Lisp feature that is even
> argued over in the Lisp community.
That's why I've narrowed the discussion to comp.lang.lisp.
However, I don't see any point in pretending that weaknesses
don't exist! Either ignore them (like Erik), deny that they're
weaknesses (like Rainer), or address them. Ok, I'm being a
little unfair to Erik and Rainer, but that's often how their
replies look to me. Neither of them has commented on the
issues I'm raising. Perhaps neither of them know what an
OCX is, but I don't recall either of them asking. At least
you did that, so that I can know that there's a communication
problem, and do something about it (like explaining OCXs).
BTW, what effect would Erik have, by insisting that EVAL
_must_ always be available? I have some idea, and it ain't
remotely positive. EVAL may well be useful to some Lisp
programmers, but it won't sell Lisp to anyone used to C++.
Not unless they're like me, i.e either already predisposed
towards Lisp, or _seriously_ curious.
> When you post wrong information about positive features, you might
> lead people to try that out, recognize it was wrong and count it as
> "the Lisp community either has no idea what is useful" or "All those
> praised Lisp advantages turn out unuseable for other people".
Which wrong info have I posted? The CLX comment was about the
concern about CLX that I've seen expressed in this newsgroup.
I didn't say that CLX had actually died.
Nor would I say that Dylan has died, and yet this is what some
people have said. I believe that to be untrue.
> Nowadays, it is even more important to keep the newsgroup's contents
> in line. There's a great potential of hackers who actually can
> contribute to free software. Today, many people are facing problem
> that cry for a more dynamic language than C++, mostly feeding the
> Web. When i look over the maintainer list of the current CMUCL effort,
> I see a lot of people joining from usenet or public mailing lists.
I agree. I don't think that's a good enough reason to avoid
discussing the disadvantages of current Lisp dialects and
implementations. Perhaps now is the best time to do it, when
Java is opening so many minds to new possiblities.
> Every newsgroup has people like your, but next to FreeBSD's Jesus
> Monroe Jr. (he havn't been using his real name either), you are quite
> outstanding how long you maintain to post about things you don't know
> about. Sad. How much time did you spend to post to comp.lang.lisp this
> week? I'm sure you could also had a quick look over the CLX manual and
> into Ralf Moeller's excellent CLIM introdution on the Web. I'd say
> that would have been a lot more useful for all of us.
I can't use CLX, and I'm not sure about CLIM. How much does it
cost? As I've explained, I'm not currently paid to code in Lisp.
Not that it matters - my concern isn't about Lisp for Unix, but
Lisp for Windows, and Lisp in general.
This thread began (way back when it had a different subject)
as a comment on EVAL.
> I'll stop and resume reading cl-http's documentation, as I speak of
> it.
I've also got the docs, somewhere. It's one of a great many
things that I'd like to read, when I have the time. CL-HTTP
isn't even a priority for me (even less for my employer),
but I still take an interest in it. I'll only be able to use
it as a personal web server, but if I can use it for knocking
up a demo for a client, to run on a laptop, then it might be
more useful. As I'm not currently involved with that stage of
development, this gives me plenty of time to prepare.
On other hand, I can't easily forget those blank looks I get.
I'm only a programmer, I can (and I frequently _do_) offer to
make things easier for colleages, but if they're happy with
the tools they have, there's not much more I can do. Let me
stress that these colleages are also my friends, and could
therefore be more inclined to listen to "nutty" suggestions
about tools they've never heard of.
So, _I_ don't have a problem. Erik doesn't have a problem.
Neither does Rainer, nor do you. It's the hordes of C++
programmers searching for enlightenment who have the problem!
That's one reason why, I believe, that there's so much
interest in Java. We're at a cusp. Discuss...
Martin Rodgers
Enrapture Limited (not speaking for Enrapture, of course)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>In article <······················@wavehh.hanse.de>
> ········@wavehh.hanse.de "Martin Cracauer" writes:
>> Look at all those Java tools. I happen to like the language, but
>> almost all libraries I can get source for are pure junk (I like having
>> source, I need to learn from it). Not to speak of JVMs exploding under
>> the slightest data load.
>YMMV. Most of the uses of Java that I see are trivial, but this
>is expected to change, once the quality of JVMs improve. For example,
>how many JVMs use a generational GC? Yet JVMs that generational GCs
>are on their way.
I'm not sure the quality of Java code will improve automatically when
better JVMs are availiable.
When comparing C and C++ class libraries, I often find C++ libraries
too much oriented towards nice effects attracting potential users and
not satisfying my need for a tool collection that allows greatest
flexibility in use.
I think the quality of availiable tools for a given language depends
on the people using that language. For a mainstream language on a
mainstream platform, it is almost impossible to place tools of my
preffered sort.
While I neither like Windows nor C++, I think there are actually quite
a number of Win/C++ tools that are well-designed, but only in areas
that are not that mainstream (advanced user interaction, advanced
databases).
I'm not in the business of advanced enduser GUI's or modeling advanced
databases.
For my needs, the community that drives some Lisp implementations and
tools provides tools that fit my taste. As do some C (not C++) based
projects like FreeBSD and NetBSD. While many in this group don't like
C, I think it is pretty obvious that these people actually try to do
things right and don't ruin their tools when going after the
mainstream.
>> Dylan's greatest drawback will of course be the lack of such resources
>> for my needs and without a free environment I can't expect free source
>> to show up.
>I recall Harlequin refering to a demo of DylanWorks using OLE.
>If the strength of support for other Windows APIs is as strong,
>then I'd expect a lot of people to be interested - or at least
>very curious. I guess it'll depend on whether you see Dylan as
>an alternative to Lisp (Common Lisp, Scheme, whatever) or C++.
We are talking about different kinds of libraries here. You talk about
interfacing to other modules in other languages, helping you to use
what your platform. I'm talking about modules within my language,
helping me to use whatever program structure I think of but can't
handle by myself in my head.
The point of cl-http, for example, is not that it is a high-level
interface to TCP sockets. cl-http is first of all a tool to provide
contents.
>> Lack of threads in free CLs (except ECOLisp) is what I miss
>> most. Problem at hand: The problem is too tough for me to solve.
>Same here. How many free CLs with native code compilers are there?
>To avoid licencing problems, I'd prefer a commercial compiler.
While free compilers have their shortcomings, I think licencing is not
one of them. CMUCL is the only free native CL Compiler, while Gcl and
ECOLisp are not conceptually slower than a native compiler. The point
about CMUCL is not that it's native.
>If you already know of CL-HTTP, know CL, and it's your choice
>alone to make, then it's easy. For my employer, the first choice
>of Apache, running under Linux. Unfortunately, a Windows based
>web server arrived and was running after a simple install, while
>Apache may or may not have been running. I never found out.
>The choice was not made due to ignorance, but due to a lack
>of time. One server took longer to get running than the other
>(which took _no time at all_).
Apache competes with those Windows based solutions in the area of
serving contents from other sources. cl-http focuses on providing
contents. I think Apache will have its niche for performance-oriented
Web sites sooner or later, the mainstream will be Windows boxes.
I'm pretty sure your Apache problems are in fact Linux problems,
BTW. Try FreeBSD.
>I can't comment on the numbers of servers using Apache, as most
About 60-65%. There's a website that tries all servers on the internet
it knows about and asks. Forgot the Url.
[...]
>> What people want who wants to do killer Web applications:
>> - Cleanest way to handle user input from server-side
>> application. Parts of cl-http take care of this.
>Form handling is very basic stuff. If that's not enough, then
>there are tools that can make it obscenely easy. You'd need a
>well above average app to make _Perl_ necessary, never mind Lisp.
HTML Forms and its extension Javascript are often seen as something
that needs to be replaced by Java as soon as possible. Using normal
CGIs, it is very difficult to build a real stateful application (I
know, I spent 1996 to do so).
Read about w3p (part of cl-http). You'll know that form handling can
be a matter of languages. You think you need a though problem to need
the expressive power (nice term :-) of Lisp. I'd say you also use the
expressive power of Lisp to let it handle the complexity involved when
using HTML forms, even when your application areas are of "normal"
complexity. Some CLIM-based efforts go other ways in the same
direction.
My customers aren't very existed when I tell I will have to base
advanced GUIs inside Web browsers on Java. Many people have browsers
without Java, many aren't permitted to use Java on their working place
machines etc etc etc. It is a competive advantage to be able to handle
HTML forms as good as possible.
>> - Cleanest way of presenting outout to the user without overloading
>> network. Parts of cl-http take care of this, as well as CLIM-related
>> projects.
>Are you talking about a user over the web, or a local user,
>configuring the web server? The CLIM reference leads me to
>suspect that it's the latter.
No, the user.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
> IIn article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> It would be unfair to expect anything delivered so soon,
> but if you count Mindy, then there's at least one "Dylan"
> implementation available.
"Toy" implementation, I would say. Nice, but a toy.
> > But it is getting stronger everyday, huh? Until someone
> > releases something useful, I'll write my code in Common Lisp
> > or maybe even Scheme.
>
> I wouldn't you to do otherwise! I'm not pretending that
> what's available today is "industrial strength".
ALMOST NOTHING COMMERCIALLY VIABLE IS AVAILABLE FOR DYLAN.
NOTHING.
EVERYTHING IS PURE VAPORWARE UNTIL NOW.
YOU MAY STILL BELIEVE THE PROMISES - I SIMPLY
CAN'T SEE ANYTHING OUT THERE.
> Did I mention patience? I've been looking for a language
> like Dylan since the early 80s. I can wait a little longer.
I can't wait. I have to do my work now. And I'm doing with
what is available, supported and what is fun. This is
excellent software like CL implementations, scsh, SIOD, XEmacs, ...
You may dream on.
> > Sorry, but you don't seem to know a thing about CLX or CLIM.
> > Better be silent.
>
> That's exactly what I mentioned it! I've seen posts from
> people concerned for the future of CLX. Is that worth flaming
> me for?
I have seen posts from people concerned about all kinds of things.
I'm not writing about it, because they do understand more
than me about these topics.
> > So much, that Apple killed the project. Seemed not
> > that important to Apple. They are using C and C++
> > for their crashing OS (some of their stuff is actually
> > quite cool, but build on a shaky foundation).
>
> I think of Apple as the "Evil Empire",
This is childish.
> mainly coz of their
> use of "hired guns" to compete with rivals.
This is even more childish.
> I didn't say that
> Apple still supported Dylan, just that they started it.
>
> Does Dylan die with Apple? Ask CMU and Harlequin.
Yeah, where is it? Can I use, buy it? Where are the libraries?
Pure Vaporware until now. I'll consider it again in five
years, if it is still around and has stabelized. You may talk
on about vaporware, while I prefer to use Common Lisp
and Scheme, which I can get from *existing* vendors
or from people who really have contributed something,
which has real *working* code out there.
> > It is so much showing its age. So much that Digitool recently
> > released version 4.0 of its Macintosh Common Lisp.
> > It does support native threads, native shared libraries,
> > almost all OS calls, deals with alien memory, supports
> > finalization, has ephemeral garbage collection, compiles
> > to native PowerPC code, has a large CLOS based and easy to
> > use UI library, has an integrated editor, does tail
> > recursion elimination, has enthusiastic users and excellent support,
> > and, yes, people are developing **real** applications
> > with MCL (some of them you can download on the Net).
>
> Fortran 77 also shows its age, and yet is still being used.
> That's no reason not to consider F90.
This comparison alone disqualifies you. Most people haven't even
realized the potential of Common Lisp.
> > - CL-HTTP needs your hacking. We have ideas for the
> > entire next three centuries. Ask John Mallery about advice
> > (join ······@ai.mit.edu).
>
> CL-HTTP does indeed need some hacking.
Have you tried it? I doubt that.
We are starting a project here in Hamburg. We will be using
CL-HTTP and are looking to combine KR with a web server.
Others are doing this already.
> In fact, it may be necessary for CL-HTTP to do all that a
> commercial web server can do _and more_, just to get noticed.
It does already more. What are you talking about?
> The marketing factor should not be ignored, unless you don't
> have to convince anyone that CL-HTTP is capable.
For every piece of software I have to convince the customer.
> Ah, yes. CLX is not enough? This is the concern that I refered
> to above.
How about looking into the CLX docs and into the CLUE and CLIO
docs? Then you may get an idea. Education does not come for
free. You have to read yourself to get the picture.
> I'm working on a Lisp to C++ compiler, with the intention
> of supporting any API I need to use. Progress has been slow
> so far, due to other demands on my time.
Let me guess ... you will fail to come up with anything useful.
Why? Because it is not easy. We already have enough Lisp
system. We need something where we don't start from zero.
Try standing on others shoulders. If you are really good,
you may offer others a place on your shoulders.
> Actually, I've been coding in C++. I'm not proud of it,
> but that's what I get paid for.
Hey, coding in C++ is not the problem. It can be fun.
You can create cool software. That's what brings
us forward.
> I don't expect my Lisp compiler to be useful by anyone
> but me, as the code quality will be relatively poor,
> compared to the existing Lisp compilers available.
> (That's why I'd prefer to use a commercial compiler.)
> It may also have a few quirks, like not being standard.
> Still, if anyone wants to use it, I expect that the
> code will be available online.
Tell us about that, and I'll think about shutting
my Symbolics down (o.k. not really ;-) ) and selling
Macintosh Common Lisp when your Lisp arrives.
Btw., how many man years do you think
the respective companies have invested in their
tools?
> I was hoping to have a reasonable discussion about what may
> (or may not) be done with Lisp to make it more "competitive"
> (in the sense that implementations might be able to compete
> with C++ compilers), but I guess that's not possible.
They are already competetive. You have not realized it yet.
LispWorks on a workstation gives you excellent productivity
and if you ever have seen a Lisp wizard using a Symbolics
you'll like to adjust your ratings. People are actually
working hard to make Lisp environments good citizens
in today's computing infrastructure. I just like
to mention the guys from Igortech who are creating
support for QuickDraw GX from within Macintosh Common Lisp.
There you can see how CLOS will make it easy to access
a complicated and feature rich graphics library.
This brings developers forward. Not your useless postings.
> Flame away, Rainer. It won't change anything. I'm willing
> to discuss these things with you, but I'm not sure what
> the point would be. Why should you care whether a Lisp
> for Windows supports OCX or not? In fact, why should _I_
> care, when Smalltalk MT is available?
That's the difference, I'm using this stuff today (actually
I'm typing this in a Lisp-based editor - no its not Emacs).
You may dream on.
Btw., Smalltalk MT may be a good choice. Once you
have experience with it, you could write a short report
how it compares to other development tools (Visual C++,
Visual Basic, Parcplace Smalltalk, Delphi, Allegro CL, ...).
Btw.2, just played my first levels of Crash Bandicoot.
While doing that, I was thinking about the none
existent use of Lisp in the commercial world you
often like to point out.
Rainer Joswig
In article <·································@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> I can't wait. I have to do my work now. And I'm doing with
> what is available, supported and what is fun. This is
> excellent software like CL implementations, scsh, SIOD, XEmacs, ...
That's why I'm still using C++.
> This is childish.
It's also history, as I recall Apple giving up that battle.
Using lawyers like that is not healthy, IMHO. I'm merely
making the point that YMMV.
Everyone has "tunnel vision", myself included. We can only
see things from the point where we stand. That can have a
profound effect on what you see. Look in any advocacy newsgroup,
and you'll see this.
For example, scsh and XEmacs don't run on every platform.
Nice examples, how many people use them? While that isn't
a measure of quality, it is a measure of _success_. Maybe
it's not your metric for measuring such things, nor mine.
So, none of this shit matters. Not too long ago, Erik called
the kind of software that most people will use "shit". What
more do I need to say? He's right, of course, but who gives
a shit? C++ is king. Tunnel vision is a good way to cope with
this unfortunate state.
Let me know when Emacs is king...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
I came across an "Internet entertainment magazine" called "Cyber Surfer"
today. my favorite magazine pusher has an uncanny ability to bring me all
sorts of things I appreciate but would never be able to order because I
don't know they exist. it's British. it's trash from cover to cover.
* Cyber Surfer
| C++ is king. ...
:
| Let me know when Emacs is king...
royalists be damned.
#\Erik
--
"He didn't care."
"They never do."
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> I came across an "Internet entertainment magazine" called "Cyber Surfer"
> today. my favorite magazine pusher has an uncanny ability to bring me all
> sorts of things I appreciate but would never be able to order because I
> don't know they exist. it's British. it's trash from cover to cover.
When I emailed them, earlier this year, I thought it was US.
Is this a personal attack, now? Tsk.
Have you heard of irony? I discovered a few years ago how easy
it is to wind up the "UseNet Elite", just by using this nickname.
These days, with so many newbies online, it rarely gets any
attention, but when it does...
> | C++ is king. ...
> :
> | Let me know when Emacs is king...
>
> royalists be damned.
Agreed. I hope you're not mistaking me for a C++ advocate!
If I were such a person, then I'd not be concerned about Lisp.
And yet there are so many jobs for C++ programmers...something
must be wrong.
Anyone unsure about this, take a look at my homepage (not
recommended, BTW). The links to things C++ related are hard
to find, and are greatly outnumbered by links to Lisp sites.
Go figure. Compliments of the season!
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
>>>>> "CS" == Cyber Surfer <············@wildcard.demon.co.uk> writes:
CS> Have you heard of irony? I discovered a few years ago how easy it
CS> is to wind up the "UseNet Elite", just by using this nickname.
And where was that? Boggle.
Erik Naggum wrote:
>
> I came across an "Internet entertainment magazine" called "Cyber Surfer"
> today. my favorite magazine pusher has an uncanny ability to bring me all
> sorts of things I appreciate but would never be able to order because I
> don't know they exist. it's British. it's trash from cover to cover.
>
> * Cyber Surfer
> | C++ is king. ...
> :
> | Let me know when Emacs is king...
>
> royalists be damned.
>
> #\Erik
Um, doesn't Norway have a king? It did the last time I was there. I travel to Norway
alot for business, and, well, in general, Norwegians don't seem to have much
in the way of business sense, but seem to be more elitist. Maybe it has to
do with the way the tax system is set up in that country or the lack of
social mobility, dunno. Correct me if I am wrong of course :)
-G
> --
> "He didn't care."
> "They never do."
······@lavielle.com (Rainer Joswig) writes:
>Useful hacking areas for advancing Common Lisp
>==============================================
And now for something completly different:
Implement a Java virtual machine in Common Lisp. Should not be that
hard given a thread interface (most other problems like GC and dynamic
loading are solved in every Lisp implementation anyway). Even a
Just-in-time-compiler will be easy (and working $#%$^&%^).
The points is of course to use all those advertised little Java
modules and/or Java beans components.
Examples:
- A http server could provide entry points for servlets like Jeeves
and Jigsaw offer. Mix Lisp and Java filters as you like, write your
Lisp filters, get some Java filters from the net.
- User all the tools advertised to generate Java beans components.
- Many Web servers claim to open their execution engine for Java
.class files from users. Example: Let two people provide .class
files to play a game and have a server that let them play against
each other. Java a JVM in Lisp and you can run a Java soltuion
against whatever you definde for Screamer in five minutes.
- The same applies for application custumization (i.e. killfile-like
functionality for newsreaders). With a JVM in Lisp we'd be able to
let people give init files as Lisp or .class files (should such a form
of application become real, I expect a lot of tools come up to help
people doing so).
- And - of course - use the .class files lying around. Doing so is a
lot more easy than to integrate C object files. A .class files
carries all the information you need. Not that there are many I'd
like to use...
The kawa project does the other way round (Scheme compiled to Java,
all runs insider Java), but that's performance-wise not the right
thing.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <······················@wavehh.hanse.de>
········@wavehh.hanse.de "Martin Cracauer" writes:
> Implement a Java virtual machine in Common Lisp. Should not be that
> hard given a thread interface (most other problems like GC and dynamic
> loading are solved in every Lisp implementation anyway). Even a
> Just-in-time-compiler will be easy (and working $#%$^&%^).
I like the idea of using a user interface (IDE?) built using Java,
comunicating with the Lisp system via sockets. That way, you get
an IDE that runs on every platform that has a JVM. If you don't
wish to use Java, an alternative might be Kawa compiler, for
compiling Scheme to JVM bytecodes.
It might be nothing more than a JVM-based widget server, but that's
a great (and cheap) way to make an IDE portable.
> The points is of course to use all those advertised little Java
> modules and/or Java beans components.
The IDE/JVM idea might also have this advantage.
> The kawa project does the other way round (Scheme compiled to Java,
> all runs insider Java), but that's performance-wise not the right
> thing.
It should be ok for the user interface, and a JVM that uses JIT
should beat any performance concerns. If that's not enough, write
a "native" version. This is an old idea, but I don't see why it
can't use the JVM, instead of less widely available bytecode engines.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>In article <······················@wavehh.hanse.de>
> ········@wavehh.hanse.de "Martin Cracauer" writes:
>> Implement a Java virtual machine in Common Lisp. Should not be that
>> hard given a thread interface (most other problems like GC and dynamic
>> loading are solved in every Lisp implementation anyway). Even a
>> Just-in-time-compiler will be easy (and working $#%$^&%^).
>I like the idea of using a user interface (IDE?) built using Java,
>comunicating with the Lisp system via sockets. That way, you get
>an IDE that runs on every platform that has a JVM. If you don't
>wish to use Java, an alternative might be Kawa compiler, for
>compiling Scheme to JVM bytecodes.
Emacs with ilisp is just that. Emacs is just the virtual machine you
can put on most platforms (many more than Java), ilisp is written to
run on that VM.
The problem with such solutions is that a *tigher* integration of Lisp
and environment tools is needed. The right program inspection tools
will need access to the Lisp image. The Lisp machine, Harlequin
Lispworks, CMU's Hemlock and probably others do so (the Dylan
environment from CMU will beat this to its limits, I'm sure).
>It might be nothing more than a JVM-based widget server, but that's
>a great (and cheap) way to make an IDE portable.
No, I'd say it is completly pointless.
>It should be ok for the user interface, and a JVM that uses JIT
>should beat any performance concerns. If that's not enough, write
Anyone who things a JIT can push Java's speed to that of C hasn't read
the specification of the Java VM. That is not possible. It is possible
to compile Java to native code without using .class files or the JVM,
but once you have a class-file, you have to obey the execution model
of the JVM. And that has efficiency drawbacks.
>a "native" version. This is an old idea, but I don't see why it
>can't use the JVM, instead of less widely available bytecode engines.
The JVM isn't a widly available bytecode engine. Emacs and Scheme-48,
to name two, are much more widly available (by platform count, that's
what is important for the tools *I* use). The Java VM is availiable
inside of Web browsers and that opens a lot of application
possibilties, but an environemt for Lisp is not one of them.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <······················@wavehh.hanse.de>
········@wavehh.hanse.de "Martin Cracauer" writes:
> The problem with such solutions is that a *tigher* integration of Lisp
> and environment tools is needed. The right program inspection tools
> will need access to the Lisp image. The Lisp machine, Harlequin
> Lispworks, CMU's Hemlock and probably others do so (the Dylan
> environment from CMU will beat this to its limits, I'm sure).
Tight integration is certainly a major attraction to an IDE,
for most people. I'm eager to see what CMU will do, with Gwydion.
> >It might be nothing more than a JVM-based widget server, but that's
> >a great (and cheap) way to make an IDE portable.
>
> No, I'd say it is completly pointless.
Hmm. So nobody is doing anything with IDEs? What's better than
a good IDE? Perhaps a portable IDE that can still exploit the
GUI for a platform.
> Anyone who things a JIT can push Java's speed to that of C hasn't read
> the specification of the Java VM. That is not possible. It is possible
> to compile Java to native code without using .class files or the JVM,
> but once you have a class-file, you have to obey the execution model
> of the JVM. And that has efficiency drawbacks.
Who needs the performance of C? I'm a great believe in doing
things simply because you can. That's how most people's efforts
look to me, from at least one perspective. Yes, it's a perspective
thing, another case of YMMV. Some people say "X is not possible",
when they really mean that it'll use more CPU cycles than X,
whatever X may be.
Whether a thing is worth doing may depend on nothing more than
the opinions of the people in a position to do it or not, or who
can tell other people to do it, or not. This is why there are
so many different things that people do with computers.
> >a "native" version. This is an old idea, but I don't see why it
> >can't use the JVM, instead of less widely available bytecode engines.
>
> The JVM isn't a widly available bytecode engine. Emacs and Scheme-48,
> to name two, are much more widly available (by platform count, that's
> what is important for the tools *I* use). The Java VM is availiable
> inside of Web browsers and that opens a lot of application
> possibilties, but an environemt for Lisp is not one of them.
Are you counting platforms or machines? Perhaps I should've
put "less widely available" in quotes, as I've just done.
That way, we know that we're talking about perceptions, rather
than objective fact. Whether not JVM is available on more
platforms, used on more machines, or has a higher profile than
some other bytecode engine is a matter of debate. One thing
you can be sure of is that not everyone will agree about this,
the significance of any one of the above distinctions, who
even the number of people who'll care.
This is the strange world that we find ourselves in. I'm using
an OS that I'm told can't be used as a web server, when what
those people perhaps mean is that it can't handles stress as
well as some other OS. Whether or not that's true or not may
be irrelevant, as the choice of OS is not always based on such
sensible criteria.
So, in order to see for myself, I wrote a program called estone.
It stresses a web server. I can now make the server that I use
for development fall over, in less than 10 mins. Not only that,
but sometimes the OS falls over too! I've now yet tested it with
a real web server setup, so perhaps my machine is just fragile.
I should try a few other servers.
What would happen if I made this program available, via the
Internet? I don't wish to enter the OS advocacy fray, so if I
do, then I probably won't announce it. It's such a simple util
that anyone who wants one like it can write it themselves.
The CL that I'm using right now is ACL Lite, and the heap limit
would likely make testing CL-HTTP meaningless. Perhaps someone
could try the Gstone benchmark with it, and post the results?
Preferably with a multi-threaded Lisp. That's another reason
why I have little to work with - I'm all too familiar with the
argument that "multi-threading is necessary for good performance,
and nothing less than excellent performace is usable". It can
certainly help, but the lack of multi-threading isn't so bad
that it makes everything impossible, as some would claim.
Benchmarking would give us the kind of hard evidence that could
convince people that CL-HTTP is a serious performer. With all the
advocacy BS that's flying around, anything pro-Lisp could be lost
in the Unix vs NT war. _Anything_ might be lost in that kind of
red mist.
That's why I wrote estone. Whether that program can prove anything
will be uncertain, until I can test it on a real web server.
Whether that kind of stress is a fair test or not is another matter!
I may find out in the New Year...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
······@lavielle.com (Rainer Joswig) writes:
>Useful hacking areas for advancing Common Lisp
>==============================================
>- We like to start a Free CLIM effort. Vendors were not
> very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/)
> has started a mailing list, which I think will get some discussion
> started in the new year. Join now!
·················@cons.org
Personally, I'm mostly after something to do my Web applications with,
but CLIM also is an excellent tool to implement a Web browser in. The
CLIM presentation model is a really close fit to HTML.
Imagine: A *working* Web browser with all the HTML features you
want. Really customizable. Real startup scripts. Stable, no more
coredumps. Comparable output on different platforms. Coupled with some
HTML and HTTP tools from cl-http (searching etc.).
I'd say if we want a full-featured HTML/HTTP browser with source, it's
more efficient to develop the CLIM subset needed to do so on top of
Express Windows, define a fine language to let the user specify a
HTML->presentation mapping and put in HTTP support from cl-http to
feed the beast. I'd say that takes less time than to start
reimplementing Netscape's Navigator.
>- Get threads for CMU CL. Ask Martin Cracauer about that.
Well, first of all I'd like somments on a suitable programmer
interface. See http://www.cons.org/cracauer/lisp-threads.html for an
overview of existing packages (the page is work in progress).
>- Develop support for Common Lisp in ILU 2.0.
Seconded.
To add one item to Rainer's list:
- Steal a few ideas for scripting from scsh and hack that into
CMUCL. The cl-http server (when it finally runs on CMUCL) will get a
lot more flexible in environments of existing WWW pages/text-based
databases. perl-like regulars expression scanning/replacement is
important, using their output from existing code management systems
like CVS, GNATS etc. ist important, too and needs the excellent
design work Olin Shiver did for scsh. I already have parts of a
regex package going, but Olins clever mapping for the
port/filedescriptor mapping is quite challenging.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
* Guillermo J. Rozas
| I would love to see a good Lisp environment for Windows that allowed
| complete interoperability with arbitrary libraries. Alas, I don't expect
| one soon.
well, _I_ got one delivered to a client of mine just last week, but until
then, I could have said "I expect one soon". quit whining and do some
research into what is available in the market _today_.
shit, I feel like a marketing person. "look what you made me do."
#\Erik
--
"He didn't care."
"They never do."
Someone who claimed to be ···@hplgr2.hpl.hp.com (Guillermo (Bill) J.
Rozas) wrote:
>I would love to see a good Lisp environment for Windows that allowed
>complete interoperability with arbitrary libraries. Alas, I don't
>expect one soon.
Franz's Allegro for Windowsseems reasonable.
I am futzing around with their free trial Win95/NT version that I
downloaded from their web site.
At about 4 meg ( includes a basic CLOS tutorial ) it is a fairly easy
download.
__________________________________________________________________________
It is a tremendous Mitzvah to always be happy!
Reb Nachman of Breslov
Erik Naggum <····@naggum.no> writes:
> * Guillermo J. Rozas
> | I would love to see a good Lisp environment for Windows that allowed
> | complete interoperability with arbitrary libraries. Alas, I don't expect
> | one soon.
>
> well, _I_ got one delivered to a client of mine just last week, but until
> then, I could have said "I expect one soon". quit whining and do some
> research into what is available in the market _today_.
I've been enjoying your flaming with Mr. Surfer for quite a while now.
Both of you write in a way that is both educational and entertaining.
Flame on, please!
On the other hand, please avoid clobbering innocent bystanders who are
observing the fight. I, too, have looked for an existing Common Lisp
or Scheme development environment (free or commercial) that integrates
well with arbitrary Windows libraries. I've also looked for support
for OLE and OS threads. I've spent an enormous amount of time
searching for such an environment, both for work and for personal use.
Unfortunately, I've come up empty-handed. I've been sending my
requests to the most likely Lisp vendor periodically, but I haven't
received a substantial response yet.
I would also like to add that Mr. Rozas, among others, put a heroic
amount of effort over many years into producing MIT Scheme and porting
it to Windows. MIT Scheme is a very good development environment, and
includes a compiler that generates native code for i386, HP-PA, MIPS,
Alpha, VAX, etc., a complete implementation of an Emacs-like editor
written in Scheme, etc. Unfortunately, it doesn't have good support
for programs that need to call external libraries and otherwise be
integrated with the world outside Scheme, and, because of the way the
system evolved over time, a large amount of work would be required to
add such support. The reason I mention MIT Scheme is that Mr. Rozas
is one of the last people who should be criticized for "whining" and
not doing something. The rest of us have to do some work, too.
Before you blast me as well for whining without doing anything, I'll
tell you that I've also been working on my own Scheme development
environment in the background while I work full time. It is a large
undertaking, and I'm not making much progress, but I'm trying. For
the most part, I would prefer to have someone else write it, and I'm
perfectly willing to pay for it. But I haven't given up on my own
meager efforts.
When you say that you "got one delivered to a client," do you mean
that you delivered a Lisp environment for Windows that integrates
completely with arbitrary libraries, or do you mean that you delivered
a successful program written using such an environment? In either
case, would it be possible for others to get hold of that environment?
hoping not to have offended anyone,
Arthur
* Arthur A. Gleckler
| On the other hand, please avoid clobbering innocent bystanders who are
| observing the fight.
you're absolutely right. my apologies to Guillermo J. Rozas.
| When you say that you "got one delivered to a client," do you mean that
| you delivered a Lisp environment for Windows that integrates completely
| with arbitrary libraries, or do you mean that you delivered a successful
| program written using such an environment? In either case, would it be
| possible for others to get hold of that environment?
no. what I meant was that we got Franz Allegro Common Lisp for Windows
delivered and then spent a day playing with various things we would need
for the application, which still remains to be ported to that environment.
(much of it has been written on my SPARC for CMUCL before we got Allegro,
and the porting effort is mostly due to my accretion of bad habits and my
not kwowing much about Windows. I ported it to Allegro for Unix in two
hours.) under Windows (NT), DDE is fully supported; we could talk to other
applications that we need in the project, and WinEmacs talked DDE to
Allegro. OLE2 is not fully supported, but we managed to talk to some
applications. we tried linking with a DLL and could list functions, but
the foreign function call interface was sufficiently complex that I didn't
get to call any functions before we had to leave for the day.
my Windows expert was very pleased with what we could accomplish from
inside Allegro, and I don't know the first thing about Windows, so all I
can do is trust his judgment for our needs.
#\Erik
--
"He didn't care."
"They never do."
In article <·············@zurich.ai.mit.edu>
······@zurich.ai.mit.edu "Arthur A. Gleckler" writes:
> I've been enjoying your flaming with Mr. Surfer for quite a while now.
> Both of you write in a way that is both educational and entertaining.
> Flame on, please!
It's good to know that one's efforts are being appreciated! ;-)
Thanks. However, my intention is not to flame anyone, as that
implies disrespect, and I have a great deal of respect for Erik.
This is simply an issue that we see differently. Perhaps my view
of Lisp is more general (vague?), while Erik's is more focused.
> On the other hand, please avoid clobbering innocent bystanders who are
> observing the fight. I, too, have looked for an existing Common Lisp
> or Scheme development environment (free or commercial) that integrates
> well with arbitrary Windows libraries. I've also looked for support
> for OLE and OS threads. I've spent an enormous amount of time
> searching for such an environment, both for work and for personal use.
Ah, yes. Threads.
Some people refused to take serious a language implementation that
doesn't support threads. While it's true that threading is important
for high performance server apps, I think it's a mistake to assume
that every app will suffer if threads can't be used.
Still, I'd greatly appreciate threading support in a Lisp for Windows.
This is something I frequently use in C++.
> Unfortunately, I've come up empty-handed. I've been sending my
> requests to the most likely Lisp vendor periodically, but I haven't
> received a substantial response yet.
Someday, someday. I'm encouraged by the thread support in
Smalltalk MT. Hopefully, Lisp vendors will follow Object
Connect's example. Nobody has a monopoly on such features!
> I would also like to add that Mr. Rozas, among others, put a heroic
> amount of effort over many years into producing MIT Scheme and porting
> it to Windows. MIT Scheme is a very good development environment, and
> includes a compiler that generates native code for i386, HP-PA, MIPS,
> Alpha, VAX, etc., a complete implementation of an Emacs-like editor
> written in Scheme, etc. Unfortunately, it doesn't have good support
> for programs that need to call external libraries and otherwise be
> integrated with the world outside Scheme, and, because of the way the
> system evolved over time, a large amount of work would be required to
> add such support. The reason I mention MIT Scheme is that Mr. Rozas
> is one of the last people who should be criticized for "whining" and
> not doing something. The rest of us have to do some work, too.
I agree. Anyone who reads the docs for MIT Scheme for Windows
will see that an FFI is high on the list of priorities.
> Before you blast me as well for whining without doing anything, I'll
> tell you that I've also been working on my own Scheme development
> environment in the background while I work full time. It is a large
> undertaking, and I'm not making much progress, but I'm trying. For
> the most part, I would prefer to have someone else write it, and I'm
> perfectly willing to pay for it. But I haven't given up on my own
> meager efforts.
You have my sympathy! We shouldn't need to implement our own
Lisp simply in order to use the language, esp when we're more
than happy to pay for it. Unfortunately, it's hard for a vendor
to please everyone.
This doesn't justify Erik's fierce defence of Lisp, as he sees it.
A little variety should be possible. This is why there's more than
one dialect of Lisp, and not all implementations are interactive.
> When you say that you "got one delivered to a client," do you mean
> that you delivered a Lisp environment for Windows that integrates
> completely with arbitrary libraries, or do you mean that you delivered
> a successful program written using such an environment? In either
> case, would it be possible for others to get hold of that environment?
Good questions. ;) Not all apps demand the same things from the
OS, nor do all clients demand the same features. It would be
foolish to think otherwise, esp given the variety of software
available today, and the OS features that support it.
I look at it this way: there's a difference between writing an
app for Windows that just happens to be written in Lisp, and
writing an app in Lisp that happens to run under Windows.
> hoping not to have offended anyone,
No problem. Welcome to the fray!
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
* Cyber Surfer
| Now you can't accept that I don't like Emacs?
no. what I don't accept is that your liking Emacs says anything about me
only because I like Emacs. you can like or dislike whatever you want, but
when you start to draw inferences from your unquestioned likes and dislikes
to the character of other people based solely on their likes and dislikes,
you have entirely left the world of coherent argumentation, and it proves
to be unfruitful to discuss anything with you that requires that you
separate between a premise and any arguments based on it or conclusions
drawn from it. vice versa, you need to realize that just because the only
premise you can think of that could produce an argument or a conclusion,
does not mean that somebody else even have something _close_ to those
premises backing up their conclusions.
this is such a basic ingredient in argumentation that I'm frankly amazed
that you violate it so blatantly. I don't know how to talk to anyone who,
upon hearing X, will accuse whoever said X of believing in whatever
blatantly false premises _you_ think you need, in a mockery of logic, to
produce X. now, if you could please try to understand that a conclusion
that somebody holds is _necessarily_ based upon _something_ constructive,
smart, and good, and look for that, instead of looking for the least valid
premises you can think of, we might get somewhere. however, this is just
like the silly EVAL arguments: people who argue against EVAL on the premise
that it would create a security hole were CL-HTTPD to accept random code
from any user, are clearly _bereft_ of all insight into what others are
actually arguing for.
I have, as I said, ceased thinking that there _is_ anything constructive in
your arguments. I can no longer imagine how you can go on the way you do,
based on something you would like to see happen, on something you would
like to do, on something you hope for, etc. I don't _see_ any traces of
goals, hopes, or dreams. I see a lot of frustration, and yet you say
you're happy where you are! you're a living, breathing contradiction!
| Why deny a tool as powerful and neat as Lisp to all these programmers?
your premise that it is being denied them is invalid. speaking of invalid
premises, your premise that one needs to work with something for 15 years
to appreciate it (or agree with anybody about it being good) is also dead
wrong. _I_ wouldn't agree with me if one would need 15 years of experience
with Lisp to agree with me. I decided on Lisp for real in early January
1994. up until then, I had had a few days every few years when I played
with Lisp systems, as if by rekindling a hope that looked less real than
Santa Claus (as in "yes, Virginia, there _is_ a better way").
| My feeling is that good tools should be available to all programmers.
"feeling"? "should"? "all"? _how_? by magic? or by hard work? but
above all, _why_? what do you _do_ with your "feeling"? all I can see is
that it can only lead to frustration and accusations of other people
somehow _denying_ others good tools if they don't give them away! this is
such an invalid piece of thinking that I cannot even _imagine_ what got you
on this line of reasoning in the first place!
| Would you not call Lisp a good tool? In what way would improving the
| support for the OS in Lisp tools for Windows hurt you? That puzzles me.
| Nothing in the Lisp tools that you use need change in the smallest way!
| As I understand it, you use Unix, so how can Lisp software for Windows
| hurt you?
*sigh!* _more_ completely invalid premises. whenever did supporting
Microsoft platforms ever _hurt_ me? where do you _get_ these sick ideas?
incidentally, I'm programming in Franz' Allegro for Unix on two projects,
one of them being deployed in Allegro for Windows, Microsoft NT, to be
exact. I'm building a moderately large applications that needs DDE
interfaces to other programs, we're using DLL's produced by Delphi to
handle the user interface, programmed by another programmer who feels it
more urgent to get a working user interface before he learns to do it in
Lisp, which he also wants. we're looking into the availability of OLE
Automation in the same Lisp system. this sounds like something you could
have wanted. indeed, this sounds like something you could have _done_.
still, I'm not at all interested in the Windows-specific cruft. I learn
how to use these things from the other programmer in this project who is an
expert on Windows and DDE and OLE2 and an amazing array of things I didn't
even know existed two months ago, and I find it fascinating that Allegro
makes so much of this possible for me without the lot of the annoying
menial labor needed in the C examples I see. incidentally, it seems the
Windows-specific parts will amount to 2% of the compiled code. this means
I can develop the rest of the system on my own SPARCstation and just bring
a few diskettes with me once a week to show them what has been done and to
have a "backup" on their system. life doesn't get better than this!
the seemless integration between Franz' Allegro and Emacs of various
flavors on both systems means that I can program from within Emacs, and not
have to learn any of the Windows cruft, like which unintuitive icon does
which unintuitive action. I talk to Emacs and Allegro, and that's _it_. I
do the same at home, so the differences are minor. I use logical pathnames
to save me all the trouble of operating-system specifics in that area, too.
the biggest difference is actually the ugly fonts and the small display
with the low screen resolution on the Windows appliance, compared to the
large displays and the high resolution and good fonts I have at home.
incidentally, it took a couple months (real time) for me to convince these
people that they should buy a commercial Lisp system for Windows. in the
other project, my (now) project manager called me up and asked if I could
do some network hacking in C for them. I looked at the problem and said
the network hacking would be trivial, but that they needed a much larger
support system to make it work they way they needed it to, and that that
support system should be written in Lisp for the flexibility and the uptime
requirements they have. yesterday, I got the final approval to buy Franz'
Allegro Common Lisp software for $15,000. that's more money than they had
originally planned to pay me for the trivial network coding job.
however, none of this was effortless or came for free! I have worked
15-hour days and slept at random intervals, barely being outdoors, etc,
since early November, and I can't even charge more than a couple hundred of
those hours to the projects! still, it would have taken me _much_ more
time and effort had it not been for my Lisp supplier's unyielding support
and good will throughout the process.
what do I want? I want people who would like to use Lisp to know that
someone out there managed not only to convince people that Lisp was the
best choice for the job, but also to buy a commercial Lisp system that was
never planned for in either of the projects. what do I want? I want to
see goal-directed _action_, and I'm sick and tired of people who say that
"hardly anyone talks about Lisp, anymore" or "Lisp support on Windows is so
insufficient that I can't use it". who cares how _big_ the audience is? I
care _who_ the audience is, especially if it's a client of mine. and who
cares what the free Lisp systems can do, when they're spending an order of
magnitude more money on programmer time than the acquisition costs of the
Lisp system?
get yourself Allegro for Windows and see what it can do for you. it's not
as great as Allegro for Unix, but it's still good. the free demo CD should
help you see what can be done. oh, it comes with an Emacs interface if you
buy the Professional version. be careful now, you might actually like it.
#\Erik
--
"He didn't care."
"They never do."
* Cyber Surfer
| I merely mentioned Emacs as an example of some software that has
| some "problems", but which you'll defend.
you _actually_ said "The fact that you use Emacs speaks for itself."
#\Erik
--
"He didn't care."
"They never do."
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> you _actually_ said "The fact that you use Emacs speaks for itself."
And it does. While Emacs is a fine piece of software, not
everyone likes it. You may be aware of some of the reasons.
(I won't go into details here, as I don't care enough, and
it might only provoke you into more flaming.) Whether you
consider those reasons valid or not is irrelevant, as other
people _will_. Flaming them won't change that.
Hence the expression, "Your mileage may vary". It basically
means that no matter how strongly _you_ feel that something
is fine, and has no problems, other people will disagree.
The use of EVAL in Lisp is another of those issues. Possibly
I'm flexible to find uses for Lisp without using EVAL, or
perhaps I'm just some heretic who's been currupted by using
other languages for too long (C, Smalltalk, ML?) - you choose.
I'm not suggesting that anyone should remove EVAL from Common
Lisp, just making it an _option_ at runtime. You seem to be
insisting that it always been available, and some of your
justifications apply only to _development time_, not runtime.
So, perhaps you've been flaming me for things you _think_
I'm saying, when you're actually doing nothing more than
misunderstanding or misrepresenting what I'm saying.
Also, I'm talking about _Lisp_, not Common Lisp. I've not yet
found any referernce to EVAL in the Scheme reference manual,
but perhaps my copy isn't the latest...
However, please don't flame me just for having a minor difference
of opinion. Even if I fail to appreciate all the virtues of EVAL,
does that invalidate everything I say? Is EVAL all there is to
Lisp? I hope not. All I hope to do is question an old practice
that may - just possibly - be linked to some of the so called
"overheads" that C programmers have used to attack Lisp with for
so many years.
So, there should be no way in which I'm hurting you, personally.
If this is not so, then please explain how this is possible.
Meanwhile, I'm baffled by your hostility.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/
nice Scheme->C compiler, grab yourself DJ C's 32-bit extending
compiler if you don't already have it, sit down and start cutting real
code. Compiles to executables. Its a wonderfully solid platform for
developing /the things you want/. It uses and can create shared
libraries on UNIX platforms that support them, only a bit of tweaking
by someone as skilled as yourself should enable it to produce DLLs.
It can already make use of modules written in C that already exist,
you can recycle code that does API'ing if you're so inclined. Write a
quick hack interface to ActiveX and impress us all and produce the
tool you want to work with instead of lamenting your pain of loss.
I've watched your posts to this newsgroup for some time and, frankly,
while I was sympathetic to begin with, you've rapidly shed that degree
of slack allowed. Not once have we seen something from you
/constructive/ other than `I'm working on my own interpreter.'
Reinvent the wheel and cry because your car don't run.
There are tools out there that go most of the way toward doing what
you've been crying for; don't expect them under the tree for Yule.
You'll have to go out and get them.
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
In article <·········@netnews.alf.dec.com>
·······@uxtlaser.alf.dec.com "Alex Williams" writes:
> Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/
> nice Scheme->C compiler, grab yourself DJ C's 32-bit extending
> compiler if you don't already have it, sit down and start cutting real
> code. Compiles to executables. Its a wonderfully solid platform for
> developing /the things you want/. It uses and can create shared
> libraries on UNIX platforms that support them, only a bit of tweaking
> by someone as skilled as yourself should enable it to produce DLLs.
I've got it. I like it, but I've not yet succeeded in getting the
_kernel.c (_kernel.scm, after being compiled by gsc) file to compile
without errors. I'd spend more time on this if there was any hope
of using Gambit C, but there's a more serious problem. See below.
> It can already make use of modules written in C that already exist,
> you can recycle code that does API'ing if you're so inclined. Write a
> quick hack interface to ActiveX and impress us all and produce the
> tool you want to work with instead of lamenting your pain of loss.
The FFI in the version I have doesn't appear to support callbacks.
This is a vital feature. Obviously, the FFI could be extended, but
I'll have to study the source code. I'll do that anyway, as there's
much to learn from this compiler. Meanwhile...
> I've watched your posts to this newsgroup for some time and, frankly,
> while I was sympathetic to begin with, you've rapidly shed that degree
> of slack allowed. Not once have we seen something from you
> /constructive/ other than `I'm working on my own interpreter.'
It's a compiler, actually.
> Reinvent the wheel and cry because your car don't run.
I think my original point had something to do with how most other
people look at Lisp, not how you or I see it. If all these things
can be done, why hasn't anyone done it yet? Have you seen how much
support there is for C++? I'm merely wondering how Lisp can compete.
In terms of Lisp, Windows is a very obscure and undersupported OS.
Meanwhile, there's no Windows feature that isn't supported by C++.
> There are tools out there that go most of the way toward doing what
> you've been crying for; don't expect them under the tree for Yule.
> You'll have to go out and get them.
Do you mean Gambit C? Sure, after a lot of work. A HELL of a lot
of work. That's why I'm more inclined to write my own compiler.
Neither will make _any_ difference to the popularity (i.e. success)
of Lisp for Windows.
On the other hand, Smalltalk support for Windows is much better.
Can anyone tell me what Smalltalk can do that Lisp can't? What
makes Smalltalk so special? It's a simple question, but nobody
has even tried to answer it! None of the other shit matters,
when you need a tool _right now_. That's why so many programmers
will choose C++.
Anyway, I can see that this has been discussed to death. Nobody
else wants to discuss the real issues. I'm ready to buy a Lisp
(please note that: I'd rather spend money than time) that does
what I need. I _know_ that I'm not alone. That's why we're always
being told that only C/C++ can do this or that.
Ok, I've been letting off some steam. Just a little. Sometimes
it's hard for me to believe that Lisp has to be just one thing,
instead of many. Gambit C is a good example of one of the
alternatives to the "traditional" Lisp, the kind that has a big
enviroment. In fact, you can use Gambit C as a batch compiler.
Here's my first point once again: most people will have no idea
what EVAL is for, nor will they appreciate the overheads for it,
however small we may say they are, however hard we justify them.
Some of us may say, "I'm all right jack", and ignore the problem.
I refuse to do that. Somebody has to. It's all relative.
If we all insisted that batch enviroments are wrong, and not for
Lisp, then Gambit C might be a very different kind of Lisp compiler.
It might not exist at all. Discuss...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Hi!
CS>The FFI in the version I have doesn't appear to support callbacks.
It does support callbacks. No hacking needed.
And if you need a FFI to C++, you should have a look at Mr. Ed: there you
can mix Scheme classes with C++ classes (you can inherit a Scheme class
from a C++ class, you can even inherit a C++-class from a Scheme class!).
Ok, Mr. Ed only has a bytecode-system beneath, but it's enough power for
most jobs. Actually it's quite preferable over Visual Basic.
CS>Do you mean Gambit C? Sure, after a lot of work. A HELL of a lot
CS>of work.
Yeah. A hell of 10 minutes while I waited for Visual C++ to finish the
compile. Ok, before I had to hack the makefiles - took another 10 minutes.
A HELL of a lot of work.
CS>On the other hand, Smalltalk support for Windows is much better.
No, don't think so. There are not that much more Smalltalk environments
then there are Lisp environments for Windows. Maybe you know more Smalltalk
environments, but that's alone your fault.
CS>Here's my first point once again: most people will have no idea
CS>what EVAL is for, nor will they appreciate the overheads for it,
Huh? Eval is only a overhead if you use it. And if you need it, you need it
bad! And in that case you don't care for the overhead it draws into your
application. And if you don't need it, you can ignore it. Gambit-C does
have EVAL and I don't see where there should come an overhead into play.
Oh, and Gambit-C has a interactive environment, too. Of course. Every nice
Lisp has it - it's just handy if you come to debugging.
bye, Georg
In article <···················@ms3.maus.de>
···········@ms3.maus.westfalen.de "Georg Bauer" writes:
> CS>The FFI in the version I have doesn't appear to support callbacks.
>
> It does support callbacks. No hacking needed.
2.4 certainly does.
> And if you need a FFI to C++, you should have a look at Mr. Ed: there you
> can mix Scheme classes with C++ classes (you can inherit a Scheme class
> from a C++ class, you can even inherit a C++-class from a Scheme class!).
> Ok, Mr. Ed only has a bytecode-system beneath, but it's enough power for
> most jobs. Actually it's quite preferable over Visual Basic.
Could you give a URL or some other contact info please?
> CS>Do you mean Gambit C? Sure, after a lot of work. A HELL of a lot
> CS>of work.
>
> Yeah. A hell of 10 minutes while I waited for Visual C++ to finish the
> compile. Ok, before I had to hack the makefiles - took another 10 minutes.
> A HELL of a lot of work.
Does it support OCX?
> CS>On the other hand, Smalltalk support for Windows is much better.
>
> No, don't think so. There are not that much more Smalltalk environments
> then there are Lisp environments for Windows. Maybe you know more Smalltalk
> environments, but that's alone your fault.
Please don't think that I'm saying that I'd rather use Smalltalk,
coz that's not true. If you think that, then either you're not
reading what I'm saying, or I'm saying it very badly.
Just take a look at Smalltalk MT, and then tell me where I can
find a Lisp with a similar spec: native code, multi-threading,
OCX, DLL, etc. Those are the features that most Windows developers
will be looking for. Whether you or I need them is irrelevant.
It just happens that I could use some of them. The next time I'm
asked to produce a DLL, I'd like to avoid writing it in C++.
I've not had time yet (less than a single day) to see if Gambit C
2.4 can produce DLLs. If it can, then I'll be _very_ happy. It's
about Lisp vs Smalltalk - or even Lisp vs C++. It's a case of
"What tool does X, Y, and Z?"
This isn't about what you or I can do. I personally can manage
without OCX etc. When I write for myself, I generally don't code
for a specific OS, even when I do use OS-specific features.
However, my personal projects are far from "typical". Windows
developers see things differently from us. Consequently, I have
a use for tools that support certain Windows features - the
features that I'm asked to use. In this sense, I'm like any
other Windows developer. I'm still atypical, as I'm aware that
Windows development doesn't begin and end with tools like VB,
VC++, and Delphi.
That's why I'm here, in comp.lang.lisp, when most Windows people
will be looking elsewhere for their tools. I'd like to do the
things in Lisp that most developers say are impossible in anything
but C++. And yes, some C++ people will slag off VB and Delpi
just as readily as Lisp, Smalltalk, Prolog, and other languages
available for Windows. The comp.lang.lisp newsgroup has seen
enough of these people and their stupid arguments, in the past.
By now you should've noticed that I'm far from pro-C++, and
that I consider Smalltalk to be a compromise. I'm simply not
an extremist. I don't like the "C++ or death" atttitude, but
I can't accept the "Lisp or death" attitude, either. Those kind
of polarised points of view don't help us, the developers who
just want to get things done, without all the politics. It's
hard enough to convince people that Lisp is a practical answer,
without this fanaticism getting in the way.
It could be that I'm being flamed for daring to compromise,
for considering the use of Smalltalk as a step - and nothing
more than a step - towards using Lisp as a tool for developing
certain kinds of software. I'd consider this to be a small
but very significant step in that direction, as a way of saying
that there are people interested in such tools. Eventually,
I hope that Lisp vendors will get the message, just as some
Smalltalk vendors now have.
In fact, it could be that Harlequin already are doing this.
That's debatable, of course. I can't comment on it, as I've
not seen the demo myself. Still, that's another produce that
I'll be interested in - even if it eventually turns out to be
vapourware, as someone here has suggested it could be. Whether
or not DylanWorks is available today is not important. For me,
it's merely frustrating, but as I've waited about 15 years so
far, I can wait a little longer.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>I've got it. I like it, but I've not yet succeeded in getting the
>_kernel.c (_kernel.scm, after being compiled by gsc) file to compile
>without errors. I'd spend more time on this if there was any hope
>of using Gambit C, but there's a more serious problem. See below.
Interesting; it compiled without a problem under Digital UNIX though
it wouldn't under ULTRIX 4.5. Not that I really expected it to.
>The FFI in the version I have doesn't appear to support callbacks.
>This is a vital feature. Obviously, the FFI could be extended, but
>I'll have to study the source code. I'll do that anyway, as there's
>much to learn from this compiler. Meanwhile...
Have you grabbed the latest 2.4 release? (I'm not sure that even it
allows callbacks from C to Schame, actually, but it is a bit nicer on
some fronts.)
>I think my original point had something to do with how most other
>people look at Lisp, not how you or I see it. If all these things
>can be done, why hasn't anyone done it yet? Have you seen how much
>support there is for C++? I'm merely wondering how Lisp can compete.
I think the simplest answer for the reason it hasn't been done by any
of us is that we don't need it. I know /I/ don't; Gambit-C might as
well not even have an FFI as far as my work using it is involved (as
an extremely high-level scripting language and CGI backend).
Lisp doesn't /have/ to compete with C++. When MIT implimented their
autonomous agent architecture, designed by Patty Maes, they didn't do
it in C++, they did it in Common Lisp. Who'd use AutoCAD if the
embedded language was a C++ interpreter with the associated overhead?
Would GNU standardize on C++ as the internal configuration language of
choice? In /none/ of these cases is C++ better suited to the job and
its not seen taking those niches.
This year, C++ is the ap coding language of choice. Next year it'll
probably be Java, for what its worth. The year after that, who knows?
Lisp, on the other hand, has been around since the 60's, has
maintainedd its presence as the right tool for the right job and
/maintained/. If you want Lisp to make inroads on the popular choice
for ap building, /you/ are the one that's going to have to do it.
Franz, apparently, doesn't see much need to do the things you want,
probably because they're selling compilers that are delivering the aps
/their/ customers want.
>In terms of Lisp, Windows is a very obscure and undersupported OS.
>Meanwhile, there's no Windows feature that isn't supported by C++.
MicroSloth /pushed/ the C++ wave through hype and lies, frankly. They
sell their own compiler for it, of /course/ all the Windows features
are supported through C++. Let's look at UNIX, on the other hand,
which has been a traditional bastion of C since its inception. Using
Gambit-C, you can do pretty much anything you want, as with Franz, GCL
and a host of other compilers. STk exists for those that want Scheme
hooks to the Tk toolkit or you could use Gambit-C and build the hooks
to call it from there, however you want. The tools are there.
I think pointing out the fact C++ is highly supported under Windows is
an indirect straw-man. When MicroSloth puts out a Lisp compiler, then
you can make a reasonable comparison. Until then, its in their best
interest /not/ to make it easy or direct to do so for anyone else.
>Do you mean Gambit C? Sure, after a lot of work. A HELL of a lot
>of work. That's why I'm more inclined to write my own compiler.
>Neither will make _any_ difference to the popularity (i.e. success)
>of Lisp for Windows.
I wouldn't say a HELL of a lot of work, but definitely a lot of work.
What, you thought porting a compiler to a different platform was an
easy task?
If Gambit-C were ported to Windows and were packaged with a set of
interfaces for the standard APIs, produced decent code and worked, it
still probably wouldn't affect the popularity of Lisp for Windows,
because MicroSloth doesn't want competition for its own product. So,
what else is new?
>On the other hand, Smalltalk support for Windows is much better.
>Can anyone tell me what Smalltalk can do that Lisp can't? What
>makes Smalltalk so special? It's a simple question, but nobody
>has even tried to answer it! None of the other shit matters,
>when you need a tool _right now_. That's why so many programmers
>will choose C++.
The difference is that somewhere, sometime, there was a Smalltalk
programmer that wanted to do cool things in Windows with his language,
got up off his ass, and coded it. Then he sold it and made bucks.
This shouldn't surprise you.
>Here's my first point once again: most people will have no idea
>what EVAL is for, nor will they appreciate the overheads for it,
>however small we may say they are, however hard we justify them.
>Some of us may say, "I'm all right jack", and ignore the problem.
>I refuse to do that. Somebody has to. It's all relative.
So don't use Eval in your code. What has this got to do with the
price of tea in China? Thee overhead for Eval is far less than the
overhead for an equivalent hunk of code in C++. There /is/ no
problem, no matter how much you lament it.
>If we all insisted that batch enviroments are wrong, and not for
>Lisp, then Gambit C might be a very different kind of Lisp compiler.
>It might not exist at all. Discuss...
All a batch environment consists of is an interpretive environment
running a pre-set script, if you want to look at it that way.
Differentiating between batch/non-batch is non-revealatory.
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
In article <·········@netnews.alf.dec.com>
·······@uxtlaser.alf.dec.com "Alex Williams" writes:
> Have you grabbed the latest 2.4 release? (I'm not sure that even it
> allows callbacks from C to Schame, actually, but it is a bit nicer on
> some fronts.)
No, the version Ihave is 2.3. I'll grab 2.4.
> I think the simplest answer for the reason it hasn't been done by any
> of us is that we don't need it. I know /I/ don't; Gambit-C might as
> well not even have an FFI as far as my work using it is involved (as
> an extremely high-level scripting language and CGI backend).
I'm hoping to also use it for CGI. Unfortunately, some of that
will mean delivering DLLs to interface with code written by
other people. That's why I'm looking for tools with DLL support.
Other Windows developers may be even more demanding, and almost
certainly less interest in Lisp. As Gambit C isn't a commercial
compiler, Marc Feeley might have no reason to add features to
Gambit C that make Windows development more attractive.
In fact, to do this well enough to make a difference would be
non-trivial, so I wouldn't recommend it. If it could make a big
enough difference to an individual to add a few features...
> Lisp doesn't /have/ to compete with C++. When MIT implimented their
> autonomous agent architecture, designed by Patty Maes, they didn't do
> it in C++, they did it in Common Lisp. Who'd use AutoCAD if the
> embedded language was a C++ interpreter with the associated overhead?
> Would GNU standardize on C++ as the internal configuration language of
> choice? In /none/ of these cases is C++ better suited to the job and
> its not seen taking those niches.
That's my point. In spite of this, a staggeringly large number of
programmers choose C++. Unless there's some marketing conspiracy,
it suggests that C++ is easier to sell to the masses. Erik seems
to suggest that they're not worth offering Lisp to, and yet claims
great advantages to those who use it. I agree with the latter,
but not the former.
> This year, C++ is the ap coding language of choice. Next year it'll
> probably be Java, for what its worth. The year after that, who knows?
Exactly. I'd like it to be Lisp, but I know that there are people
using Windows who look at these things with a very shallow perspective,
like using a feature checklist. If one tools has more items checked
than another, then it wins. Not suprisingly, since MS sell C++ and
VB compilers, they make damn sure that they have the biggest feature
lists. Lisp has some powerful features which _should_ outweigh all
the advantages of C++, but if what Lisp (pick any Lisp for Windows)
doesn't offer the right features, it'll lose.
Some people slag off VB for the same reasons (no native code, no
multi-threading, etc). Java is interesting, as it doesn't appear
to be competing with C++ in quite the same way.
> Lisp, on the other hand, has been around since the 60's, has
> maintainedd its presence as the right tool for the right job and
> /maintained/. If you want Lisp to make inroads on the popular choice
> for ap building, /you/ are the one that's going to have to do it.
> Franz, apparently, doesn't see much need to do the things you want,
> probably because they're selling compilers that are delivering the aps
> /their/ customers want.
Agreed. Of course, their customers are partly determined by what
their produce offers. See the above comments about checklists.
> >In terms of Lisp, Windows is a very obscure and undersupported OS.
> >Meanwhile, there's no Windows feature that isn't supported by C++.
>
> MicroSloth /pushed/ the C++ wave through hype and lies, frankly. They
> sell their own compiler for it, of /course/ all the Windows features
> are supported through C++. Let's look at UNIX, on the other hand,
> which has been a traditional bastion of C since its inception. Using
> Gambit-C, you can do pretty much anything you want, as with Franz, GCL
> and a host of other compilers. STk exists for those that want Scheme
> hooks to the Tk toolkit or you could use Gambit-C and build the hooks
> to call it from there, however you want. The tools are there.
Yes, MS depend heavily on features like callbacks and DLLs. Any tool
that fails to support them will look very unattractive to a Windows
developer. This is only significant because some vendors sell Lisps
for Windows.
> I think pointing out the fact C++ is highly supported under Windows is
> an indirect straw-man. When MicroSloth puts out a Lisp compiler, then
> you can make a reasonable comparison. Until then, its in their best
> interest /not/ to make it easy or direct to do so for anyone else.
I'm not comparing Lisp with C++. I'm comparing it with Smalltalk.
See <URL:http://www.objectconnect.com>.
> I wouldn't say a HELL of a lot of work, but definitely a lot of work.
> What, you thought porting a compiler to a different platform was an
> easy task?
Not porting it, but adding OLE,OCX,DLL,etc support...
Gambit C is only one Lisp. It only interests me coz it's Scheme,
but my interests aren't the issue here. Nor are yours, nor Erik's,
nor Rainer's.
> If Gambit-C were ported to Windows and were packaged with a set of
> interfaces for the standard APIs, produced decent code and worked, it
> still probably wouldn't affect the popularity of Lisp for Windows,
> because MicroSloth doesn't want competition for its own product. So,
> what else is new?
That's why I'm focusing on Lisp in general. Gambit C doesn't
specifically interest me - I think it was Erik who mentioned it.
> The difference is that somewhere, sometime, there was a Smalltalk
> programmer that wanted to do cool things in Windows with his language,
> got up off his ass, and coded it. Then he sold it and made bucks.
> This shouldn't surprise you.
That's my point. However, not all of us are compiler writers.
Given enough time, perhaps I could produce something that might
be better than a "toy", but I won't be given enough time.
Others have a head start, being Lisp vendors already.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>I'm hoping to also use it for CGI. Unfortunately, some of that
>will mean delivering DLLs to interface with code written by
>other people. That's why I'm looking for tools with DLL support.
So write one or pay someone to write one and stop whining at the rest
of us who're getting things done in Lisp.
>Other Windows developers may be even more demanding, and almost
>certainly less interest in Lisp. As Gambit C isn't a commercial
>compiler, Marc Feeley might have no reason to add features to
>Gambit C that make Windows development more attractive.
Because its free, anyone that wants those features can add those
features; I'm sure that Eric would love to see those features added.
Feel free.
>non-trivial, so I wouldn't recommend it. If it could make a big
>enough difference to an individual to add a few features...
If it really made that big a difference to you, you'd add them. You
haven't.
>That's my point. In spite of this, a staggeringly large number of
>programmers choose C++. Unless there's some marketing conspiracy,
>it suggests that C++ is easier to sell to the masses. Erik seems
>to suggest that they're not worth offering Lisp to, and yet claims
>great advantages to those who use it. I agree with the latter,
>but not the former.
For a staggaringly large number of the software-writing population,
C++ is a `good enough' solution for the problems they're addressing
with their software. More power to them, I say.
There /is/ `some marketing conspiracy' of course. The people with the
advertising dollars have C++ products ready to ship.
No, the rest of the software-writing population isn't worth my
stopping writing /my/ software to try and push Lisp down their
throats. Let them use whatever tools they like, I'm not bothered by
it at all. Yes, there are advantages to using Lisp. No, its not
worth my time to play hard-sell on the subject. If they want Lisp,
they can get Lisp. Its as simple as that.
>Exactly. I'd like it to be Lisp, but I know that there are people
>using Windows who look at these things with a very shallow perspective,
>like using a feature checklist. If one tools has more items checked
>than another, then it wins. Not suprisingly, since MS sell C++ and
>VB compilers, they make damn sure that they have the biggest feature
>lists. Lisp has some powerful features which _should_ outweigh all
>the advantages of C++, but if what Lisp (pick any Lisp for Windows)
>doesn't offer the right features, it'll lose.
Frankly, I don't care /what/ they're coding in for the masses in
15yrs. It may be Lisp, it may not be, but as long as excellent
compilers like Gambit-C are released in the Lisp domain, that's what
/I'm/ going to be using. And happily so. Lisp is /not/ some flash in
the pan language, here today and gone tomorrow; Lisp has proven its
ongoing utility by simply existing until today.
Lisp, therefore, will /never/ lose. I use a screwdriver for driving
screws. Anytime I need a screwdriver, I'll use a screwdriver. As
long as there's screws, I'll use a screwdriver.
>Yes, MS depend heavily on features like callbacks and DLLs. Any tool
>that fails to support them will look very unattractive to a Windows
>developer. This is only significant because some vendors sell Lisps
>for Windows.
Yet those venders don't see enough profit margin in adding those
features to their Lisps /yet still continue to sell Windows Lisps/.
Do you see the point? Is the big neon sign flashing brightly enough
for you there?
>I'm not comparing Lisp with C++. I'm comparing it with Smalltalk.
>See <URL:http://www.objectconnect.com>.
You can compare it with anything you want. The end analysis is that
/someone/ wanted the features badly enough to pay for them with time,
sweat or bucks.
>Gambit C is only one Lisp. It only interests me coz it's Scheme,
>but my interests aren't the issue here. Nor are yours, nor Erik's,
>nor Rainer's.
But they /are/. They're the only opinions that matter. I can point
to the vast world outside and say anything I want, but there's neither
proof nor support for those statements, they're just so much moving
air. If there was a clamour for the Windows support tools you go on
about in Lisp, there'd be support for them in Franz or GCL or
/something/. No one's seen enough need to create them. If /you/ do,
create them or have them created. If they're not important enough to,
stop grousing about it.
>That's my point. However, not all of us are compiler writers.
>Given enough time, perhaps I could produce something that might
>be better than a "toy", but I won't be given enough time.
>
>Others have a head start, being Lisp vendors already.
So offer them bucks to support the features. That's why they're
vendors, to make /money/. If you can't do it, you pay the one that
can. If Franz thought there was significant margin in supporting OCX,
DLL and the host of other brain-dead Windows interfaces, it'd be done.
We don't see it.
The final conclusion is easy to draw.
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
In article <··········@netnews.alf.dec.com>,
·······@uxtlaser.alf.dec.com says...
>
(snip)
>The final conclusion is easy to draw.
>
>--
> Alexander Williams ········@alf.dec.com / ······@photobooks.com}
> Prefect of the 8,000,000th Terran Overlord Government Experimental
> Strike Legion, Primary Transport TOG "Bellatores Inquieti"
>======================================================================
Yep.... Yawn.
--
William A. Barnett-Lewis
······@mailbag.com
------------------------------------------------------------------------
-
"We are artists. Poets paint motion and light. Historians paint
stills. It can be dangerous to get history from a poet. It can also be
the greatest blessing."
------------------------------------------------------------------------
-
In article <··········@netnews.alf.dec.com>
·······@uxtlaser.alf.dec.com "Alex Williams" writes:
> So write one or pay someone to write one and stop whining at the rest
> of us who're getting things done in Lisp.
See my "Lisp or death" post.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
·······@uxtlaser.alf.dec.com (Alex Williams) writes:
| Scott Schwartz <········@galapagos.cse.psu.edu> wrote:
| >Doesn't it strike you as simply amazing that a scheme system for unix
| >can exist that doesn't come with bindings for Tk or some other X11
| >toolkit? (If you're going to have a bloated runtime system anyway, it
| >doesn't seem like too much to ask!)
|
| STk doesn't count?
Heck no. The fact that one person cared enough to build
a custom system to interoperate with Tk serves only to highlight
all the other scheme systems that can't talk to Tk.
| I'd like to have one, I suppose, for Gambit-C but /I/ don't need one
| badly enough to code up the interface. It'd be `nice' but not
| necessary. I think that's what most coders in the field think about
| it, for the most part.
That's an interesting viewpoint. What's the point of a programming
language where no one can be bothered to provide good access to OS
services, like the window system?
| I can't really say Gambit-C has a bloated runtime. Its 1.4meg of
| shared library or so ... but there's a /lot/ of libraries there in
| /usr/lib, and most of them are Cs.
1.4M is very bloated. And if commercial unix has similarly bloated
libraries, that's equally bad. In practice, working set is the
important metric, but few implementors care to optimize that or even
measure that, and many OSes make it difficult to get the information
in any case (Solaris, for example.)
In article <··············@galapagos.cse.psu.edu>,
Scott Schwartz <········@galapagos.cse.psu.edu> wrote:
>Heck no. The fact that one person cared enough to build
>a custom system to interoperate with Tk serves only to highlight
>all the other scheme systems that can't talk to Tk.
Wait just a minute, let me get this straight ...
The fact that one tool exists to integrate with a library only
highlights the fact that no one else does it? That's ... that's
... ludicrous. What it would suggest is that no one else /wants/ to
use Tk with their Scheme. It suggests that if anyone wants to do that
sort of thing they apparently use STk.
There's a library for C that gives it automatic garbage collection.
The fact that there isn't a number of these, via your interpretation,
just highlights that C users all over the world don't have garbage
collection.
Well, duh. Nor do most of them want or need it. Likewise with Lisp
and Tk.
>That's an interesting viewpoint. What's the point of a programming
>language where no one can be bothered to provide good access to OS
>services, like the window system?
If it was widely needed, it'd be implimented. There are tons of
things you can do in a programming language without access to the
window system.
>1.4M is very bloated. And if commercial unix has similarly bloated
>libraries, that's equally bad. In practice, working set is the
>important metric, but few implementors care to optimize that or even
>measure that, and many OSes make it difficult to get the information
>in any case (Solaris, for example.)
Have you looked at the memory footprint of most of the applications in
wide use today, or the shared library size of most C aps? Even csh
under Digital UNIX 4.0a has a virtual set size of 2.6M. That's a
pretty simple program, relative to most of the crap that C and moreso,
C++, programmers are showing as their wares.
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
In article <··········@sue.cc.uregina.ca>,
·····@borealis.cs.uregina.ca (John Bayko) writes:
>In article <················@naggum.no>,
> Erik Naggum <····@naggum.no> wrote:
>>* John Bayko
>>| For comparison, I've written toy programs in LISP, and it's fun, but how
>>| would you write a windowing system or database in it? I'm sure LISP
>>| experts could do that with their eyes closed, but it's not obvious in the
>>| structure of the language...
>>
>>it isn't? if your argument is that I/O is made up of function calls in C,
>>I'm curious in what way you think I/O is _not_ function calls in various
>>Lisps.
>
> As I said, my experience in LISP is limited to some toy programs.
>I don't know what the equivalent of a file descriptor or window handle
>is in LISP, or how you could implement those entirely within LISP (as
>opposed to adding them to the language as basic types).
You cannot implement any of these things in a *portable* way in LISP or in
C or in any other language. That is why they are defined in libraries that
some standard can give you some guarantees about. (Usually the standard,
especially for C, guarantees far less than most people think). Especially
people in the Unix environment become quite accustomed to having every API
as a C-callable library, but this is by no means a general rule. On IBM
mainframes most API's are described as sets of assembler routines and macros
with predefined linkage and register demands. If you want to call them from C
you (or your compiler writer) have to write some translation stubs which will
require some knowledge of your compiler's calling convention. Even in Windoze,
your compiler needs to understand the __pascal and __cdecl conventions to get
to the Windows API, so you could not get your window handle there in C without
support from the compiler (and a non portable extension).
Of course, since C bindings are so ubiquitous and ``standard'', many other
languages such as C++, Modula-3 and Lisp provide C language bindings, in order
to facilitate the writing of interfaces to external API's.
>John Bayko (Tau).
>·····@cs.uregina.ca
>http://www.cs.uregina.ca/~bayko
Hi!
AW>Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/
AW>nice Scheme->C compiler, grab yourself DJ C's 32-bit extending
AW>compiler if you don't already have it, sit down and start cutting real
Or get Visual C++ and build a Win95 version (taks only 10 minutes on a
Pentium) with shared libraries, where one executable like helloWorld is
only about 5K. And it has a great FFI, so you can link it with all those
nice APIs from Microsoft. Even callbacks work - of course. And it produces
standard executables, and the performance is good. There are cases where I
prefer it over ACL/PC, just because of it's ability to build small
commandline utilities (the 1.5 MB of the gambc.dll doesn't count, the whole
Win95 is 50 times larger - even most of those stupid *X extensions for
Win95 are much larger. Even VBRUN400.DLL and Co. are much larger).
bye, Georg
Georg -
I'm plugging into this discussion rather late - looks like I missed
some interesting flaming. I'll download Gambit this afternoon to kick
the tires. To save some time (might be >> 10 minutes for me :-), do
you have makefiles for VC++ and/or any other info that might be
helpful?
(Others might appreciate it if you'd publish your response on the
net).
On Fri, 27 Dec 96 15:19:00 +0200, ···········@ms3.maus.westfalen.de
(Georg Bauer) wrote:
>Hi!
>
>AW>Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/
>AW>nice Scheme->C compiler, grab yourself DJ C's 32-bit extending
>AW>compiler if you don't already have it, sit down and start cutting real
>
>Or get Visual C++ and build a Win95 version (taks only 10 minutes on a
>Pentium) with shared libraries, where one executable like helloWorld is
>only about 5K. And it has a great FFI, so you can link it with all those
>nice APIs from Microsoft. Even callbacks work - of course. And it produces
>standard executables, and the performance is good. There are cases where I
>prefer it over ACL/PC, just because of it's ability to build small
>commandline utilities (the 1.5 MB of the gambc.dll doesn't count, the whole
>Win95 is 50 times larger - even most of those stupid *X extensions for
>Win95 are much larger. Even VBRUN400.DLL and Co. are much larger).
>
>bye, Georg
In article <·················@snews2.zippo.com>
·······@cat.bbsr.edu "Bill Hunter" writes:
> I'm plugging into this discussion rather late - looks like I missed
> some interesting flaming. I'll download Gambit this afternoon to kick
> the tires. To save some time (might be >> 10 minutes for me :-), do
> you have makefiles for VC++ and/or any other info that might be
> helpful?
If you have VC++ 4.0, then it compiles beautifully.
I can recommend tweaking the gambit.h file a little, so that
it defines a WinMain function instead of main. Start a 2nd
thread for the event handling, and you can create a window
just like any other non-console Win32 program. IPC techniques
can let the two threads talk to each other. A better way of
doing it would be to have a single thread that calls the Lisp
code, but that could be more work. Anyway, you may want multiple
threads.
Very tasty.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Hi!
BH> To save some time (might be >> 10 minutes for me :-), do
BH> you have makefiles for VC++ and/or any other info that might be
BH> helpful?
Actually I used the makefile that came with Gambit. I only needed to throw
out the complete installation-stuff, just because that makes no sense under
Win95. And you need a sed for Win32 - I took the stuff from Cygnus
(GNU-WIN32). If you have any problems, I will put my binary distribution on
my homepage. Just drop a note.
It really was easy to compile. My equipment: Visual C++ 4.2, GNU-win32 and
a Pentium 200 with 48 MB of Ram (there you get the 10 Minutes from ;-) ).
Only problem so far: the I/O with Gambit-C via (read-char) is awful slow -
almost unusable for reading large text files. I think that one thing that I
should build for Gambit-C is a interface to the standard Unix file-I/O
functions. Normal operation is fast enough and I like the FFI. It's one of
my prefered tools for writing utilities now - besides Objective CAML (that
one I like because of it's marvelous compiler).
I still have to find similar tools for my Mac. Ok, there is MCL for one,
but I do prefer free tools if I can get them in the right quality.
Currently I have a deep look into Clean, I like pure functional language
implementations that deliver good performance.
bye, Georg
>Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/
>nice Scheme->C compiler, grab yourself DJ C's 32-bit extending
>compiler if you don't already have it, sit down and start cutting real
>code. Compiles to executables. Its a wonderfully solid platform for
>developing /the things you want/. It uses and can create shared
>libraries on UNIX platforms that support them, only a bit of tweaking
>by someone as skilled as yourself should enable it to produce DLLs.
>It can already make use of modules written in C that already exist,
>you can recycle code that does API'ing if you're so inclined. Write a
>quick hack interface to ActiveX and impress us all and produce the
>tool you want to work with instead of lamenting your pain of loss.
He doesn't even need to get DJC, Visual C++ does a quite good job of
compiling workstation code to run under Windows NT, much better than
MS C did anyway.
Producing a foreign function interface from a language to allow it to call
a method exported by an OCX is fairly straightforward, all the information
you need can be read from the .TLB file.
Writing an ActiveX Scripting Engine isn't rocket science either, I put
together the framework for one at lunchtime today. Since he would be
using an existing language implementation this sort of framework would
be a sufficient starting point.
What *is* difficult, is mapping from an existing object system like
CLOS onto the MS Component Object Model. I suspect this is what Franz
is spending the time doing in order to produce a commercial product.
-------------------------------------
Robert Swindells - GenRad Ltd
···@genrad.co.uk - Work
···@fdy2.demon.co.uk - Home
············@wildcard.demon.co.uk (Cyber Surfer) writes:
| On the other hand, Smalltalk support for Windows is much better.
| Can anyone tell me what Smalltalk can do that Lisp can't? What
| makes Smalltalk so special?
Nice syntax. Nice GUI toolkit. Nice standard library. Nice quality
of implementation. And synergy amongst those things.
Same reason Tcl/Tk is popular, by the way.
| If we all insisted that batch enviroments are wrong, and not for
| Lisp, then Gambit C might be a very different kind of Lisp compiler.
| It might not exist at all. Discuss...
I have a pile of old Symbolics manuals that I use to prop up my X
terminal. At least they're good for something. :-)
In article <··············@galapagos.cse.psu.edu>
········@galapagos.cse.psu.edu "Scott Schwartz" writes:
> | On the other hand, Smalltalk support for Windows is much better.
> | Can anyone tell me what Smalltalk can do that Lisp can't? What
> | makes Smalltalk so special?
>
> Nice syntax. Nice GUI toolkit. Nice standard library. Nice quality
> of implementation. And synergy amongst those things.
I could live with Smalltalk.
BTW, have you been reading the "Functional languages in Software
Engineering" thread, in comp.lang.functional? Some of the same
issues are being discussed there.
> Same reason Tcl/Tk is popular, by the way.
Same with VB. Both give a fair number (I'm trying to be
diplomatic!) of people what they want. Have you seen
VisualTCL? Our reaction may be "yuk!", but our values may
be very different to most people.
> I have a pile of old Symbolics manuals that I use to prop up my X
> terminal. At least they're good for something. :-)
Ouch.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
·······@uxtlaser.alf.dec.com (Alex Williams) writes:
| The difference is that somewhere, sometime, there was a Smalltalk
| programmer that wanted to do cool things in Windows with his language,
| got up off his ass, and coded it. Then he sold it and made bucks.
| This shouldn't surprise you.
The surprise is that lisp has been around for so long, and has
enthusiastic proponents, and yet similarly cool results never seem to
materialize.
Doesn't it strike you as simply amazing that a scheme system for unix
can exist that doesn't come with bindings for Tk or some other X11
toolkit? (If you're going to have a bloated runtime system anyway, it
doesn't seem like too much to ask!)
In article <··············@galapagos.cse.psu.edu>
········@galapagos.cse.psu.edu "Scott Schwartz" writes:
> The surprise is that lisp has been around for so long, and has
> enthusiastic proponents, and yet similarly cool results never seem to
> materialize.
Hmm. C++ has been around for...how long? I'm not sure that the
age of a tool is significant. What people who use it expect from
it _does_. Perhaps people who use Smalltalk, C++, Lisp all expect
different things? I sometimes wonder about that. Smalltalk MT
suggests that not all Smalltalk programmers expect things very
different from C++ programmers. On the other hand, the Dylan
language was allegedly designed by Lisp programmers...
> Doesn't it strike you as simply amazing that a scheme system for unix
> can exist that doesn't come with bindings for Tk or some other X11
> toolkit? (If you're going to have a bloated runtime system anyway, it
> doesn't seem like too much to ask!)
Scheme/Tk? I've got a copy of it on my machine, and it doesn't even
run Unix! Are you sure about this? I wonder if there's a Visual Sc/Tk
(like Visual TCL <URLhttp://www.neuron.com/stewart/vtcl>) IDE?
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <··············@galapagos.cse.psu.edu>,
Scott Schwartz <········@galapagos.cse.psu.edu> wrote:
>Doesn't it strike you as simply amazing that a scheme system for unix
>can exist that doesn't come with bindings for Tk or some other X11
>toolkit? (If you're going to have a bloated runtime system anyway, it
>doesn't seem like too much to ask!)
STk doesn't count? Isn't there a Tk binding available for GCL, too?
I'd like to have one, I suppose, for Gambit-C but /I/ don't need one
badly enough to code up the interface. It'd be `nice' but not
necessary. I think that's what most coders in the field think about
it, for the most part. If you're a Lisp programmer and are doing
GUIs, you're using MCL. Self-selection.
I can't really say Gambit-C has a bloated runtime. Its 1.4meg of
shared library or so ... but there's a /lot/ of libraries there in
/usr/lib, and most of them are Cs.
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
> ·······@uxtlaser.alf.dec.com (Alex Williams) writes:
> | The difference is that somewhere, sometime, there was a Smalltalk
> | programmer that wanted to do cool things in Windows with his language,
> | got up off his ass, and coded it. Then he sold it and made bucks.
> | This shouldn't surprise you.
>
> The surprise is that lisp has been around for so long, and has
> enthusiastic proponents, and yet similarly cool results never seem to
> materialize.
I have to agree. There comes a time when you have to stop talking
about something and start coding. Usenet is full of people talking
about good ideas that never get implemented. And the surprising thing
is that with the availability of gcc,gdb,autoconf,CVS,Linux, etc...,
it has never been easier (although certainly not trivial) to create
large portable software.
So pick a project and start coding.
Richard Coleman
·······@math.gatech.edu
> >The FFI in the version I have doesn't appear to support callbacks.
> >This is a vital feature. Obviously, the FFI could be extended, but
> >I'll have to study the source code. I'll do that anyway, as there's
> >much to learn from this compiler. Meanwhile...
>
> Have you grabbed the latest 2.4 release? (I'm not sure that even it
> allows callbacks from C to Schame, actually, but it is a bit nicer on
> some fronts.)
Just for the record release 2.4 does allow callbacks from C to Scheme.
However, you can only use callbacks when the driving part of your
application is written in C (i.e. the Scheme part is acting as a
"server" to the C part). I'm hoping to remove this restriction in a
future release but this is not easy to do (for Gambit-C) as it
requires substantial changes to the way continuations are handled.
> If Gambit-C were ported to Windows and were packaged with a set of
> interfaces for the standard APIs, produced decent code and worked, it ...
Gambit-C is ported to Windows and does produce decent code. The only
bit missing is the interface to the standard APIs. If anyone is
interested in doing this please go ahead... I certainly don't have the
time to do so myself.
Marc
In article <··············@raptor.IRO.UMontreal.CA>
······@raptor.IRO.UMontreal.CA "Marc Feeley" writes:
> Just for the record release 2.4 does allow callbacks from C to Scheme.
Yep, I now have 2.4 and it works beutifully! Many thanks.
> However, you can only use callbacks when the driving part of your
> application is written in C (i.e. the Scheme part is acting as a
> "server" to the C part). I'm hoping to remove this restriction in a
> future release but this is not easy to do (for Gambit-C) as it
> requires substantial changes to the way continuations are handled.
I think I can replace the ___main function with one that contains
the usual WinMain gubbins. Unless I've missed something, all that's
really needed to do is initialise Gambit runtime, and then start
the event loop that normally sits in WinMain. (For those who don't
know, the difference between main and WinMain is the arguments.
Windows passes additional info to an app, like the initial window
state.) That should be easy to do.
> > If Gambit-C were ported to Windows and were packaged with a set of
> > interfaces for the standard APIs, produced decent code and worked, it ...
>
> Gambit-C is ported to Windows and does produce decent code. The only
> bit missing is the interface to the standard APIs. If anyone is
> interested in doing this please go ahead... I certainly don't have the
> time to do so myself.
I wasn't saying that these things hadn't been done, as it was a
list of features that a Windows develop might look for. Gambit C
2.4 certainly works! My comments applied more to 2.3, which was
the version I was using at the time.
The datestamp on the 2.4 file suggests that it was released shortly
after I last checked for a new version. See the comment about browsing
in my sigfile. ;-)
However, I should add that when this thread began, back in
comp.arch, we were discussing rather more general issues than
Gambit C. Excellent tho your compiler is, I can easily imagine
how most Windows developers will see it. That's fortunately
for me, as it may give me an edge, but not so good for Lisp
in general. On the other hand, Lisp appears to survive without
being perceieved as even remotely "mainstream", as have a fair
number of programming languages.
Anyway, I take great delight in telling people that I use such
languages, dispite those who say "it can't be done". In fact,
the more spceptical they are, the more I enjoy it! ;-) The blank
look on peoples' faces doesn't worry me much, as I provoke that
reaction in many other ways, too.
The only drawback is that sometimes a programmer can't work alone.
For example, a single Lisp programmer in a project could be at a
disadvantage if there's a policy of avoiding dependance on the
skills of a single programmer. Naturally, C++ could suffer in the
same way, in a team of Lisp programmers.
So, thanks again for your excellent compiler. I know I'll personally
find many uses for it. For example, some CGI code for my homepage.
I also have some commercial applications I'd like to write using
Gambit C, and not everything requires OCX etc. We'll have to discuss
the license, so I'll email you.
Thanks,
Martin Rodgers
Enrapture Limited
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
If you hang around on this newsgroup, or look at the web sites of the existing
lisp vendors, or look at the IAAI proceedings (start from the AAAI web site)
you'll see lots of cool examples of things people are doing with Lisp and
Scheme. Look at the miliary logistics software that was a major success of
the Gulf War (DOD estimates that savings from that program alone paid back
every penny of AI research funding they had
ever spent!), look at scheduling software, look at CAD extension languages,
the Hot Metal HTML editor (largely coded in Scheme), look at the new
generation of intelligent tutoring software, etc. Earlier on this newsgroup
there was a signal-processing company in California mentioned who used Scheme
as their "silver bullet" for their toolkit software. There's lots of
examples, if you just keep your eyes open.
If you want to develop commercial-quality really cool software under Windows,
Allegro Common Lisp for Windows does the job for many applications. I
wouldn't use it for real-time graphics, I wouldn't use it for tiny utilities,
but I do use it to create educational software that is used by people who
haven't the slightest idea that the two floppies they are getting and
installing like they would any other windows program actually uses Lisp under
the hood.
Just as there are multiple C++ environments out there, it would be really
great if someone buckled down and did a "Scheme as glue" for Win32. We've got
the start of one, a port of Scheme48 that one of our undergrads did this
summer which includes sockets support (take a look at the CS A11 web page on
www.cs.nwu.edu to get a copy, along with some other goodies, such as a first
draft web spider). I like Scheme48, but it isn't that lightweight, and we
haven't put a civilized layer over the Windows API for GUI-building -- we
bought a site license for ACL for Window from Franz instead for that kind of
thing, because their interface builder works quite well.
To sum up: (1) There >>are<< cool applications out there already. (2) There
>>are<< great Lisp development tools out there. (3) There's lots of room for
more applications and development tools -- go to it!
Ken
In article <··············@cypress.skiles.gatech.edu>,
Richard Coleman <·······@math.gatech.edu> wrote:
>>
>> The surprise is that lisp has been around for so long, and has
>> enthusiastic proponents, and yet similarly cool results never seem to
>> materialize.
>
>I have to agree. There comes a time when you have to stop talking
>about something and start coding. Usenet is full of people talking
>about good ideas that never get implemented. And the surprising thing
>is that with the availability of gcc,gdb,autoconf,CVS,Linux, etc...,
>it has never been easier (although certainly not trivial) to create
>large portable software.
>
>So pick a project and start coding.
>
>Richard Coleman
>·······@math.gatech.edu
·······@uxtlaser.alf.dec.com (Alex Williams) writes:
| What it would suggest is that no one else /wants/ to
| use Tk with their Scheme. It suggests that if anyone wants to do that
| sort of thing they apparently use STk.
Yep. I find that amazing.
| There's a library for C that gives it automatic garbage collection.
| The fact that there isn't a number of these, via your interpretation,
| just highlights that C users all over the world don't have garbage
| collection.
Yep.
| Well, duh. Nor do most of them want or need it. Likewise with Lisp
| and Tk.
Yep. Interesting, isn't it? Good technology is a hard sell.
| >1.4M is very bloated. And if commercial unix has similarly bloated
| >libraries, that's equally bad. In practice, working set is the
| >important metric, but few implementors care to optimize that or even
| >measure that, and many OSes make it difficult to get the information
| >in any case (Solaris, for example.)
|
| Have you looked at the memory footprint of most of the applications in
| wide use today,
Yep. They suck. That's no excuse.
| or the shared library size of most C aps? Even csh
| under Digital UNIX 4.0a has a virtual set size of 2.6M.
That's what happens when you put the top of the line alpha on the
developers' desks. They should be using 4M diskless vaxstation/2000s,
just as a sanity check.
By the way, I asked about *working set*, not "virtual set". A large
sparse address space isn't inherently bad. The problem is programs
that touch everything in the bloated shared library all the time.
| That's a
| pretty simple program, relative to most of the crap that C and moreso,
| C++, programmers are showing as their wares.
Csh is a notoriously bad program, and not simple at all.
On SunOS, /bin/sh is 88K of text and 16K of data, statically linked;
it mallocs about 32K when it runs. /bin/rc (unix port of the plan9
shell) is 77K; it mallocs about 80K when it runs. On the same system,
/bin/csh is about three times as big; still a far cry from 2.6M.
In article <·················@galapagos.cse.psu.edu>,
Scott Schwartz <········@galapagos.cse.psu.edu> wrote:
>| What it would suggest is that no one else /wants/ to
>| use Tk with their Scheme. It suggests that if anyone wants to do that
>| sort of thing they apparently use STk.
>
>Yep. I find that amazing.
Its not that amazing, its the same reason C pundits use C++ for OOP:
`Good enough programming.' If the code runs `good enough' or if the
output is `good enough' better technology loses out to systems that
are /only/ `good enough.'
If you'd like to impliment hooks to Tk from Gambit-C, please do; I'd
use them but I don't need them enough to write them. :)
>Yep. Interesting, isn't it? Good technology is a hard sell.
Not surprising, see above. Good technology generally means that those
that haven't been using the good technology's enabling technology
don't /want/ to come up on it. Java, for instance, is a prime example
of a `good enough' technology that incorporates some of the good
technology /we/ in Lisp have been using for years. Kawa, or another
Scheme compiler that backends onto the JVM would be a great move for
us to push. You don't see much of that.
>Yep. They suck. That's no excuse.
They're `good enough.' NT's overhead turns a screaming Alpha into a
wad of lugubrious garbage, but people still keep buying it. A large
working set doesn't seem to be a hinderance in that market.
>That's what happens when you put the top of the line alpha on the
>developers' desks. They should be using 4M diskless vaxstation/2000s,
>just as a sanity check.
Can't; Digital UNIX doesn't run on MIPS boxes anymore. They need to
be running 96meg AlphaStation 200 Mustangs with Alpha EV4/166s. If
your software'll run well there, with all the overheads of CDE, it'll
run well anywhere.
>By the way, I asked about *working set*, not "virtual set". A large
>sparse address space isn't inherently bad. The problem is programs
>that touch everything in the bloated shared library all the time.
I think that may be an inherent problem with modern programming
practice. Gambit-C programs don't touch everything in the library all
the time, in reality they turn out to be pretty efficent. Grab the
GC, grab a few functions and away.
>Csh is a notoriously bad program, and not simple at all.
Its quite simple compared to almost anything in Windows that has to
manage events from the GUI, backending on the actual data, etc. CSH
is nearly trivial compared to those.
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
In article <··········@netnews.alf.dec.com>
·······@uxtlaser.alf.dec.com "Alex Williams" writes:
> >Yep. I find that amazing.
>
> Its not that amazing, its the same reason C pundits use C++ for OOP:
> `Good enough programming.' If the code runs `good enough' or if the
> output is `good enough' better technology loses out to systems that
> are /only/ `good enough.'
Sadly, I see a lot of this.
> If you'd like to impliment hooks to Tk from Gambit-C, please do; I'd
> use them but I don't need them enough to write them. :)
That's how I feel about a lot of things. There's so much code
available that does stuff I need that I rarely need to write
these things myself - can just glue 'em together. This is a
common practice when the right software components are available.
When they'er not, people write new components.
> >Yep. Interesting, isn't it? Good technology is a hard sell.
>
> Not surprising, see above. Good technology generally means that those
> that haven't been using the good technology's enabling technology
> don't /want/ to come up on it. Java, for instance, is a prime example
> of a `good enough' technology that incorporates some of the good
> technology /we/ in Lisp have been using for years. Kawa, or another
> Scheme compiler that backends onto the JVM would be a great move for
> us to push. You don't see much of that.
Java has the advantage of using a syntax that many C/C++
programmers will be familiar with, thus reusing their
existing experience. The significance of this should not
be underestimated, IMHO. _We_ understand and appreciate
Lisp, and so it looks easy to us. To those used to C/C++,
Lisp will have a steep learning curve. Java helps get them
climbing that curve without realising it!
What comes after Java, I wonder? Hopefully something that
brings the Java converts another step closer to Lisp.
> >Yep. They suck. That's no excuse.
>
> They're `good enough.' NT's overhead turns a screaming Alpha into a
> wad of lugubrious garbage, but people still keep buying it. A large
> working set doesn't seem to be a hinderance in that market.
NT is seen by many as an alternative to _Netware_, not Unix.
Of course, Novell would like to offer them Unixware. This isn't
just a simple "Unix vs Windows" issue. Imagine how Netware
users see NT and Unix - they're both "alien".
> I think that may be an inherent problem with modern programming
> practice. Gambit-C programs don't touch everything in the library all
> the time, in reality they turn out to be pretty efficent. Grab the
> GC, grab a few functions and away.
This is just one of many reasons why I like Gambit C so much.
> >Csh is a notoriously bad program, and not simple at all.
>
> Its quite simple compared to almost anything in Windows that has to
> manage events from the GUI, backending on the actual data, etc. CSH
> is nearly trivial compared to those.
Which Windows do you mean? A process that uses the GUI features
of Windows will be very different to csh. It would be better to
compare csh to the Win32 version of bash. Let's try to compare
apples with apples, please. Scsh requires rather more memory than
csh, but it's still a "shell". How fair is _that_ comparison?
This isn't about "Unix vs Windows", unless you enjoy seeing the
world thru that kind of tunnel vision. However, I doubt that we'll
be able to discuss anything constructively if we let OS politics
get in the way. If X isn't good enough without bashing Y, then
it's in trouble.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Please remove the "nospam" if you want to email me. <sigh>
From: Richard Karpinski
Subject: Re: superior(?) programming languages
Date:
Message-ID: <dickkE46vAn.53B@netcom.com>
recently on these newsgroups:
>A lot of tools are good enough, but most people won't even know they
>exist, never mind consider using them. That's why I like to say that it's
>all about memes. [..] Nobody should doubt how aggressively MS spread
>_their_ memes.
And how! MS somehow tricked many keyboard manufacturers to put keycaps
with Windows logos on their keyboards. That is almost as slick as getting
the Windows logo added to the Ascii character set.
what's next? will kindergarten teachers in the future teach the windows
logo as the 27th letter of the alphabet?
--
Bill Gates: the guy just didnt seem that dangerous.
In article <··········@netnews.alf.dec.com>
·······@uxtlaser.alf.dec.com "Alex Williams" writes:
> Actually, I'm perfectly content to let everyone use whatever language
> they like, if they can interact via some mechanism. If several
> languages could (not necessarily /had/ to, but could) backend onto the
> JVM (or Scheme48's VM, or old Pascal p-code, or some VM not yet
> existant), I could write Scheme, you can write Common LISP, Joe Blow
> could write Jave, Gina Blow can write in C++, and they all have common
> mechanisms for communication, even if you have to use four different
> VM front ends to receive the environments.
I'd also love that. In a way, that's what MS have done with
ActiveX scripting, except that it's tied to a single OS. Still,
if the user can select the scripting language, then this may
be an interesting idea that could be applied for any OS, and
any language.
The VM way would be best, _if_ the VM is designed right, so
that it doesn't hinder anyone. Knowing how fussy people can be,
I'd bet that no VM could please everyone, but that's no reason
to not try.
> I'm not sure I'm totally KEEN on Guile, yet; it seems a bit confused,
> as a project right now and doesn't really address the things I need a
> system for, but its potential.
I feel the same way.
> BEING one of the `young punks,' I'm completely within my rights to
> slag them off. I hear from other `young punks' day in and day out,
> calling tech support because they just got a job that pays quadruple
> what mine does but they're too clueless to understand what they even
> need to be looking /at/, much less looking /for/. I'm different
> because I'm a `snot-nosed kid' that sucked up the Wisdom of the
> Ancients before he got suckered into doing their job.
Likewise. I was fortunate to meet an older programmer who
could lend me some of his books. While we never talked much
about programmer, I was able to absorb a lot of useful things.
This distinguishes me form the, as you put it, "snot nosed
kids". The trouble is, we seem to be heavily outnumbered!
> It /has/ been happening for years, but until now companies could
> actually pull off `just getting by.' Things are getting to narrower
> straights unless you can `keep up.' Young punks don't tend to keep
> up, they race on ahead, typically down the wrong road 85% of the time.
> Its only the 10% or so that end up going the `right way' /and/ have
> the luck and intelligence to stick with it that are the next gen. The
> rest die off in infancy. I'm absolutely sure they end up getting
> cushy SysAdmin jobs at middle-sized companies and calling tech support
> every time they want to install a new disk.
This sounds all too plausible to me.
> Not all people need or want the power of scsh, but most programmers
> /do/ want at least the power and expressability of basic Scheme.
Well, I've yet to meet many of them. Perhaps most of the
programmers I know just don't realise it yet?
> Definite targeting mistake; write to algorithm mags, write to
> application mags where you've used Scheme to extend the ap, write to
> OS mags and talk about how Scheme programming allows you to solve
> problems quickly and easily. Don't preach to the converted, preach to
> the streetcorners who might need to hear.
Yep, that's what I'm doing. The result is often a blank look,
but I'm used to that. My friends react that same way, whatever
the subject may be. ;-)
> Real programmers either work up a library of their own memory-handling
> procedures and thoroughly debug it before building aps and then
> calling their library, or use someone else's. In Scheme we just have
> someone else's built into the compiler. That saves us mondo time to
> /really/ get to the thing `real programmers' build, programs that
> execute algorithms, not just repeat code over and over.
This is what attracted me to Smalltalk, back when I barely knew
Basic, Pascal, and Forth. Perhaps Basic also gives a programmer
the same kind of safty net, but the tools end there.
C does very little to help you with "housekeeping".
> Problems in libraries will eternally plague us, no matter the language
> we work in. Problems can occur in SLIB as easily as they do in libc.
> Of course, since Scheme tends to be passed around as inspectible
> source, no matter what, then the liklihood of catching and killing
> those bugs is significantly heightened.
Yeah, but this was no bug - it was a design flaw. I've seen
C manuals that use the gets function. An inexperienced C
programmer might get the impression that this is a function
they should use. <shudder>
> >My attitude has always been: get it working before you worry
> >about how fast it works. If it crashes, speed won't help you.
>
> This is really the root of all my feeling on programming: is it
> working? Yes? NOW I can start putting optimizations in /if they're
> even needed./
I usually don't need to bother, esp recently. A good deal the
code I've written professionally during the last year or two
will spend most of its runtime in other people's code, not mine.
> (Sidreal issue: I still wish I had Common LISP-like variable
> declarations in Scheme. SoftScheme doesn't count. :)
This is just one of the reasons why I like Scheme so much. ;)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Martin Rodgers � Developer for Enrapture Limited � London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL." -- Dave
In article <··········@web.nmti.com>, Peter da Silva <·····@nmti.com> wrote:
>That's unfair to both VMS (it's not that slow) and UNIX (it's *definitely*
>not that unstable).
OK, point taken. I actually have the opportunity to work with single
machines with all three OS loaded on them and find that even VMS
doesn't make an Alpha 4100 run like a Pentium 60 the way NT does
... and I'm just cynical about Digital UNIX because, being Tech
Support, no one calls us up and says `hey, you know, our systems are
running /great/!'
--
Alexander Williams ········@alf.dec.com / ······@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
From: Peter da Silva
Subject: Re: superior(?) programming languages
Date:
Message-ID: <5c3afm$7j8@web.nmti.com>
In article <··········@netnews.alf.dec.com>,
Alex Williams <·······@uxtlaser.alf.dec.com> wrote:
> ... and I'm just cynical about Digital UNIX because, being Tech
> Support, no one calls us up and says `hey, you know, our systems are
> running /great/!'
Hey, you know, our systems are running /great/!
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
From: John Bayko
Subject: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5bu19l$ld2@sue.cc.uregina.ca>
In article <························@phu989.um.us.sbphrd.com>,
John R. Campbell <····@jtan.com> wrote:
[...]
> C is merely an enhanced macro-assembler originally written for
> the PDP-11 (if you look at the adressing modes in the -11 you'll
> recognize where C's come from). Unfortunately, for a language
> that combines the power of assembly language with the ease of
> use of assembly language, it has a wide following. I use it
> because everybody else does.
Theory #51 of "Why C became the most popular language": C was the
first language where I/O was *not* part of the language. All I/O was via
functions, so calling functions to to anything becomes second nature
from the very first 'hello world' program a user writes. And because
there's a variety of functions for different needs, it's no stretch at
all to switch to GUI-oriented functions for I/O.
For comparison, I've written toy programs in LISP, and it's fun,
but how would you write a windowing system or database in it? I'm sure
LISP experts could do that with their eyes closed, but it's not
obvious in the structure of the language...
Pascal was good because I/O *looked* like procedures at least, but
had its own limits - how do you extract the middle four bits in a
byte? When you access a field through a couple of structures and
pointers, which order to the ^ and . go in?
Basically, C was the first high level language that was low level
enough to be useful, getting rid of the conventional abstractions that
got in the way. Now we just take that for granted - when was the last
language you've seen designed where I/O was not a
function/procedure/method, and which didn't have most if not all of C's
operators?
That's another lesson - no new 'new idea' language will survive if
you have to give up something. That's why Object Pascal died, and C++
survived. And that's why Java's virtual machine is becoming popular,
even though it's basically the same as the USCD Pascal's p-Machine -
it doesn't make you give up C features or C++ features, while you lose
both switching to Pascal (not to mention the p-Machine was only 16
bits).
--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3062757753734625@naggum.no>
* John Bayko
| For comparison, I've written toy programs in LISP, and it's fun, but how
| would you write a windowing system or database in it? I'm sure LISP
| experts could do that with their eyes closed, but it's not obvious in the
| structure of the language...
it isn't? if your argument is that I/O is made up of function calls in C,
I'm curious in what way you think I/O is _not_ function calls in various
Lisps.
| Basically, C was the first high level language that was low level enough
| to be useful, getting rid of the conventional abstractions that got in
| the way. Now we just take that for granted - when was the last language
| you've seen designed where I/O was not a function/procedure/method, and
| which didn't have most if not all of C's operators?
if you design a language small enough, _all_ other languages will have to
have all operators that is also in that language. however, _I'd_ like to
have a language that defined the value of division of signed integers. C
doesn't. _I'd_ like to have a language that defined the width of integers.
C doesn't. _I'd_ like a _low-level_ language to handle integer overflow,
or at least give me access to this absolutely _vital_ information. C
doesn't. (in C, A+1 is either A+1 or 0 if A is unsigned or -(A+1) if A is
signed, and you have _no_ way of knowing which, short of testing for the
returned values, which is feasible only for a small number of operations.)
_I'd_ like to have a language that supported strings with any defined
_character_ in them. C doesn't. the list goes on.
so how come programmers thought this _loss_ of, e.g., overflow, was a good
thing? any assembly-language programmer worth his salt checked overflow.
(except those at Bell Labs, obviously.) any calculation with integers of
_unknown_ size must be _distrusted_ if you can't even know when an integer
operation has overflowed the range of the hardware. matter of fact, C is
the only _language_ I know that leaves the programmer totally in the dark
as far as such serious computational errors are concerned.
I'm now writing software in Common Lisp. I struggle with many profoundly
_counterproductive_ habits that I totally internalized in the 13+ years I
programmed in C under Unix -- such as caring about memory expenditure, such
as having flashes of angst due to the low performance of some piece of code
that is used _once_ in a program that runs for hours, such as disassembling
to see if a function was inlined. I have to learn _not_ to care about
these things, because they are _fundamentally_ unimportant to programming.
but my hunches still go in the direction of premature optimization. funny
thing is, I was _less_ obsessed with performance when I wrote in MACRO-10
for PDP-10 (the world's most beautful CPU) than I later was in C.
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> _I'd_ like a _low-level_ language to handle integer overflow,
> or at least give me access to this absolutely _vital_ information. C
> doesn't.
unsigned long u;
unsigned long v;
...
v += u;
if (v < u) overflow();
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3062850267355805@naggum.no>
* Erik Naggum
| _I'd_ like a _low-level_ language to handle integer overflow, or at least
| give me access to this absolutely _vital_ information. C doesn't.
* D. J. Bernstein
| unsigned long u;
| unsigned long v;
|
| ...
|
| v += u;
| if (v < u) overflow();
thank you. you prove my point most eloquently: C does not give programmers
access to arithmetic condition known as "overflow".
as I said, A+1 is either A+1, 0 or -(A+1) in C. you can test which of
these values you get, but you cannot detect overflow in the general case.
obviously, that claim cannot be refuted by producing one _more_ special
case.
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> thank you. you prove my point most eloquently: C does not give programmers
> access to arithmetic condition known as "overflow".
Nonsense. I proved the opposite: the concept of ``overflow'' for
unsigned additions is trivially expressible in C. A straightforward
peephole optimizer will use the hardware's carry bit, if there is one.
There are lots of good examples of common machine operations that are
difficult to express in C; why did you choose such a stupid example?
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3062969201915975@naggum.no>
* D. J. Bernstein
| I proved the opposite: the concept of ``overflow'' for unsigned additions
| is trivially expressible in C.
no, what you showed was one _example_ of an unrelated comparison after an
addition which could determine that the addition had produced the wrong
result. that should have been done by the compiler, and there should have
been a way for a program to be alerted to such overflows if it needed to
know, _without_ having to add code after every single operation using
explicit intermediate results, which is _very_ far from what I consider the
"trivially expressible".
what with exceptions C++, you'd expect that the desire for such primitive
exceptions would be very simple to request, but no, you can't, because C
and C++ has no intention to support such concepts as accurate arithmetic.
C++ has even retained C's bogus division operator!
a _proof_ would have required an exhaustive list of tests for all types.
a _proof_ that "overflow" is "trivially expressible in C" would have
included means to add overflow detection to basic integer operations.
you flunk, D. J. Bernstein.
| There are lots of good examples of common machine operations that are
| difficult to express in C; why did you choose such a stupid example?
I'm sorry to say so, but it looks stupid to you only because you aren't
bright enough to understand the issues I raised and you instead think this
is about machine operations, which, I agree, would have been stupid.
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
From: Mike Haertel
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c6iuh$1ur@news.jf.intel.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* D. J. Bernstein
>| I proved the opposite: the concept of ``overflow'' for unsigned additions
>| is trivially expressible in C.
>
>no, what you showed was one _example_ of an unrelated comparison after an
^^^^^^^^^
Not so. It was perfectly obviously related by data flow.
>what with exceptions C++, you'd expect that the desire for such primitive
>exceptions would be very simple to request, but no, you can't, because C
>and C++ has no intention to support such concepts as accurate arithmetic.
>C++ has even retained C's bogus division operator!
I wrote a bignum package in C once. I used unsigned ints
for everything. It was easy. It did accurate division
too. So I strongly disagree that C "doesn't support"
accurate arithemtic. The semantics of C have been
specified such that you *can* do accurate arithmetic when
it's needed. It may not be particularly convenient, but
you can do it, and moreover reasonable compilers (e.g. gcc)
can easily optimize it into clever code that uses fancy
machine instructions where appropriate.
>a _proof_ would have required an exhaustive list of tests for all types.
>a _proof_ that "overflow" is "trivially expressible in C" would have
>included means to add overflow detection to basic integer operations.
Here you are arguing over the definition of the problem.
My definition of "a language that supports integer overflow
detection" is "a language in which it is possible to write a
multi-precision add-with-carry loop in which each digit is
a maximum-width integer." C certainly qualifies. Pascal
doesn't, for example. I suspect this is Bernstein's definition
as well.
Your definition seems to be that the compiler must generate
the overflow checks for you, and provide an exception handling
mechanism as well. This is all very well and good, but it's
not C.
Both viewpoints are legitimate. But even if you disagree
about definitions, that hardly justifies flamage like:
>you flunk, D. J. Bernstein.
>[...]
>I'm sorry to say so, but it looks stupid to you only because you aren't
>bright enough to understand the issues [...]
Bernstein may have been acerbic, but note carefully he did
not call *you* stupid, just your choice of overflow
detection as an example of C's supposed deficiencies.
--
Mike Haertel <·······@ichips.intel.com>
Not speaking for Intel.
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063010349565028@naggum.no>
* Mike Haertel
| Here you are arguing over the definition of the problem.
sigh. D. J. Bernstein introduced his wrong answer with "I proved". but he
didn't. so I pointed out what a proof would have entailed. pay attention!
| Your definition seems to be that the compiler must generate the overflow
| checks for you, and provide an exception handling mechanism as well.
| This is all very well and good, but it's not C.
_precisely_!
| Bernstein may have been acerbic, but note carefully he did
| not call *you* stupid, just your choice of overflow
| detection as an example of C's supposed deficiencies.
if he had done that, it would at least have been to the point. but he
didn't. he argued in terms of "machine operations", which was never the
point. pay attention!
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
From: David Hanley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32E7159A.7C38@netright.com>
Erik Naggum wrote:
>
> * D. J. Bernstein
> but no, you can't, because C
> and C++ has no intention to support such concepts as accurate arithmetic.
> C++ has even retained C's bogus division operator!
This is certianly not an accurate complaint. C's arithmetic is very
accurate. As we know, scheme doesn't even do integer division properly.
>
> a _proof_ would have required an exhaustive list of tests for all types.
> a _proof_ that "overflow" is "trivially expressible in C" would have
> included means to add overflow detection to basic integer operations.
Why? You obviously don't understand what the term 'trivially
expressable' entails. It doesn't mean it's transparently implemented on
all types, to be sure.
>
> you flunk, D. J. Bernstein.
>
> | There are lots of good examples of common machine operations that are
> | difficult to express in C; why did you choose such a stupid example?
>
> I'm sorry to say so, but it looks stupid to you only because you aren't
> bright enough to understand the issues I raised and you instead think this
> is about machine operations, which, I agree, would have been stupid.
I'm afraid you're the one who is being less than open-minded here.
The complaint is stupid because it is pretty much a non-issue. I've
probably written well over 100,000 lines of C code during my life. A
lot of it was doing real integer math--simulations and the like. I was
never once bitten by integer overflow 'bugs'. I tested for integer
overflow in exactly two cases that I can think of, and it was trivial.
It's more stupid because there's a _lot_ of things you could rip on C
which people would have a hard time arguing with.
Hey, I'd like to see functional languages take over. I think they're
generally superior to imperative languages! Why haven't they taken
over? I think _one_ reason is that FPL designes and implementors often
live in an ivory tower and don't address real software programming
issues.
When you're writing code that has to make 60 screen updates a second,
and change 10,000 pixls on each of them, while the user is spell
checking a document, you don't _need_ integer overflow, rationals, and
bignums. You don't even _want_ them--they cause too much overhead.
Why not pick on the fact that C++ makes you declare everything in a
class -- ( data members and private functions ) in the class definition,
causing a lot of unnecessary recompiling? Why not pick on the bogus
declaration syntax?
--
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063011556585326@naggum.no>
* David Hanley
| The complaint [about overflow] is stupid because it is pretty much a
| non-issue. I've probably written well over 100,000 lines of C code
| during my life. A lot of it was doing real integer math--simulations and
| the like. I was never once bitten by integer overflow 'bugs'. I tested
| for integer overflow in exactly two cases that I can think of, and it was
| trivial.
I've seen accounting packages that used `awk' to sum list of numbers
overflow and lose money for a company. I've seen the uptime on a computer
overflow and cause the system to crash because that meant its notion of
time got warped. I've seen programmers use floating point because integer
arithmetic couldn't be trusted (and I've seen the cost of that decision).
in all of these cases, reasonable assumptions from users were not met. in
all of these cases, lack of support for a true integer type is the direct
cause. you can tell me you never had any problems. that doesn't mean
there never were any problems. and if I should listen to your experience,
why do you think your experience invalidates mine? just because you have
never had a car accident doesn't mean you don't buy insurance. most of
these "safety" things are there _because_ they will be used very rarely!
(if you had car accidents all the time, you would have had to calculate
them into your regular expenditures, right?)
| It's more stupid because there's a _lot_ of things you could rip on C
| which people would have a hard time arguing with.
I gave a list of five failings. D. J. Bernstein chose to jump only on
"overflow". go figure.
| Why not pick on the fact that C++ makes you declare everything in a class
| -- ( data members and private functions ) in the class definition,
| causing a lot of unnecessary recompiling? Why not pick on the bogus
| declaration syntax?
hey, this is almost as bad as "why not spend the money for a new weapons
program on the homeless?". no matter what I had picked as the failings,
you would have come up with another version of that rhetorical question.
when nothing can satisfy a predicate, there's no point even in trying.
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
David Hanley <·····@netright.com> writes:
> This is certianly not an accurate complaint. C's arithmetic is very
>accurate. As we know, scheme doesn't even do integer division properly.
(a) C unsigned integer arithmetic is precisely specified.
C signed integer arithmetic has several fairly large holes in the
standard definition, which have to be plugged by the implementor,
with consequent portability problems.
C floating point arithmetic cannot really said to be specified at
all; I can find no accuracy requirements for it in the standard.
For all the standard says to the contrary, 1.0 + 1.0 == 1.9.
(b) I must have missed something. Scheme does integer division using
the QUOTIENT, REMAINDER, and MODULO functions. I've been using them
for years and never found a problem. The Scheme *standard* says
Implementations should support exact integers and
exact rationals of practically unlimited size and precision,
and implement the above procedures [including QUOTIENT,
REMAINDER, and MODULO] and the / procedure in such a way that
they always return exact results when given exact arguments.
...
[QUOTIENT, REMAINDER, MODULO entries]
These procedures implement number-theoretic (integer) division:
For positive integers N1 and N2, if N3 and N4 are integers such
that N1 = N2*N3 + N4 and 0 <= N4 < N2, then
(quotient N1 N2) => N3
(remainder N1 N2) => N4
(modulo N1 N2) => N4
For integers N1 and N2 with N2 not equal to 0,
(= N1 (+ (* N2 (quotient N1 N2))
(remainder N1 N2))) => #t
provided all numbers involved in that computation are exact.
The value returned by quotient always has the sign of the
product of its arguments. Remainder and modulo differ on
negative arguments---the remainder is either zero or has the sign
of the dividend, the modulo always has the sign of the divisor:
What is there in this that is not done "properly"?
--
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> no, what you showed was one _example_ of an unrelated comparison after an
> addition which could determine that the addition had produced the wrong
> result.
``Unrelated''? Nonsense. It's an implementation of the partial function
``add uints but barf on overflow'' in C.
> and there should have
> been a way for a program to be alerted to such overflows if it needed to
> know, _without_ having to add code after every single operation using
> explicit intermediate results,
You said ``give me access,'' not ``give me access with the following
syntax restrictions.'' You were wrong. Stop weaseling.
> I'm sorry to say so, but it looks stupid to you only because you aren't
> bright enough to understand the issues I raised and you instead think this
> is about machine operations,
Your own words: ``_I'd_ like a _low-level_ language to handle integer
overflow, or at least give me access to this absolutely _vital_
information. C doesn't.'' (emphasis in original)
> which, I agree, would have been stupid.
Ah, yes. Perhaps you'd like to explain what you meant by ``low-level,''
if you _didn't_ mean ``close to machine operations.'' This should be fun
to watch.
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
In article <······················@koobera.math.uic.edu>,
D. J. Bernstein <···@koobera.math.uic.edu> wrote:
>In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>> thank you. you prove my point most eloquently: C does not give programmers
>> access to arithmetic condition known as "overflow".
>
>Nonsense. I proved the opposite: the concept of ``overflow'' for
>unsigned additions is trivially expressible in C. A straightforward
>peephole optimizer will use the hardware's carry bit, if there is
>one.
Great work!
Now, let's see your example for signed arithmetic, so we can compare
it to something like:
if (INT_OVERFLOW) {
:
:
}
in a hypothetical extension of C to detect overflow. Is your signed
int example as clean as your unsigned int example? What percentage of
real-world arithmetic is signed, do you suppose?
--
--------------------------------------------------------------------------
"I have prevented my kids from watching MTV at home. It's not safe for kids."
---- Tom Freston, MTV president, 4/14/95 Buffalo News.
||| ·····@virginia.edu (Clark L. Coleman)
From: David H. Thornley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c81q2$r0f@epx.cis.umn.edu>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Erik Naggum
>| _I'd_ like a _low-level_ language to handle integer overflow, or at least
>| give me access to this absolutely _vital_ information. C doesn't.
>
>* D. J. Bernstein
>| unsigned long u;
>| unsigned long v;
>|
>| ...
>|
>| v += u;
>| if (v < u) overflow();
>
>thank you. you prove my point most eloquently: C does not give programmers
>access to arithmetic condition known as "overflow".
>
>as I said, A+1 is either A+1, 0 or -(A+1) in C. you can test which of
>these values you get, but you cannot detect overflow in the general case.
>obviously, that claim cannot be refuted by producing one _more_ special
>case.
>
>#\Erik
OK, so this is off-topic, but I may yet manage to drag in some reference
to Lisp.
In C, unsigned integer arithmetic is modular, and therefore the above
trick works. If I remember aright, overflow in *signed* arithmetic,
which most people tend to use by default even if they don't need it,
is completely undefined. Therefore, any behavior is permitted by the
Standard, and what you'll usually get is what's convenient for the
implementor. On a 2s complement machine, A+1 will generally be A+1
or -(A+1); on a 1s complement machine, it will generally be A+1 or 0;
on a signed-magnitude machine (never worked on one, personally), who
knows? Of course, any of the above systems could also abort execution,
or write love letters to your coffeemaker, without violating the Standard.
Therefore, writing the above in signed integer format, we need
int u, v;
...
if ((unsigned)u + (unsigned)v > (unsigned)u) u += v;
else overflow();
...
(where, admittedly, some of the casts can be omitted). If you've got
a program that uses signed integers, and doesn't do this sort of thing
for *all* arithmetic operations that might conceivably cause overflow,
then it's not catching overflow. In C++, you could define a checked
integer class that would automatically check for overflow as above, and
throw an exception if overflow occurred, and this might be the right
thing to do if one really, really wants to detect overflow without
writing explicit if statements (or conditional expressions) for each
and every arithmetic operation. You can't rely on checking after a
series of operations to see if overflow has happened, in any portable
way. Of course, since the results of overflow are undefined, a
strictly conforming implementation can handle it in a useful way,
but the ones I use don't seem to do that.
In Lisp, of course, you can just check every so often to see that your
answers are fixnums, if you actually care (probably for performance
reasons). It won't lose data or do anything like that, but will just
run slower.
Of course, this doesn't exactly work if you declare (speed 3) (safety 0)
for optimization, and u and v and the sum as fixnums, but in that case
you're explicitly telling the compiler to damn the torpedos, and if
you overflow you know you're going to lose.
My personal opinion is that integer overflow is normally enough of a
problem that I'd like it checked for by default, provided I've got a
nice easy way to turn off the checking. This is the case with Common
Lisp (I am not familiar with how Scheme handles this). C provides no
protection, and if you want it you've got to forge your own in a rather
clumsy way. I prefer the Lisp way myself.
--
David H. Thornley, known to the Wise as ········@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
From: Kelly Murray
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cb4c7$sqb@sparky.franz.com>
In article <··········@epx.cis.umn.edu>, ········@cs.umn.edu (David H. Thornley) writes:
>> >* D. J. Bernstein
>> >| unsigned long u,v;
>> >| v += u;
>> >| if (v < u) overflow();
This doesn't work in complex expression with subexpression,
v = ((u + 10) * (v + 4))
Having to write all arithmetic as binary operations
and adding explicit overflow detection demonstrates
that C is not viable as a "language" for this type of programming.
However, it IS viable as an implementation language for
another language that supports the overflow handling.
I would not call that language "C", but something else.
My $0.02 on an otherwise useless discussion.
-kelly edward murray ···@franz.com
From: John Bayko
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cgmm9$k80@sue.cc.uregina.ca>
In article <··········@sparky.franz.com>,
Kelly Murray <···@franz.com> wrote:
>In article <··········@epx.cis.umn.edu>, ········@cs.umn.edu (David H. Thornley) writes:
>>> >* D. J. Bernstein
>>> >| unsigned long u,v;
>>> >| v += u;
>>> >| if (v < u) overflow();
>
>This doesn't work in complex expression with subexpression,
>
> v = ((u + 10) * (v + 4))
Personally, I'd do something like:
...as soon as you have your values...
if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) {
error_function("An error occurred at *this* point.");
/* The expression below is *not* an error. */
}
...sometime later...
v = ((u + 10) * (v + 4));
See, I think the issue of security/safety is not a language issue, but
a programming issue.
--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
>In article <······················@Alcatel.com.au>,
> Chris Bitmead <·············@Alcatel.com.au> wrote:
>>In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
>>
>>> ...as soon as you have your values...
>>> if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) {
>>> error_function("An error occurred at *this* point.");
>>> /* The expression below is *not* an error. */
>>> }
>>>
>>> ...sometime later...
>>>
>>> v = ((u + 10) * (v + 4));
>>>
>>>See, I think the issue of security/safety is not a language issue, but
>>>a programming issue.
>>
>>Are you joking? How many C programmers even *know* about MAXUINT, let
>>alone know exactly how to use it to find arithmetic errors, *let
>>alone* are able to get it right consistently with lots of complicated
>>calculations.
>
> How many programmers remember to check for getchar() == EOF?
>Doesn't matter - The language[1] provides it.
So what? Assembler also provides it. So does machine code for that
matter. The point is, C makes it difficult enough to code, that for
all intents and purposes it is impossible to do right, in most
situations. Most situations means where you can't afford to spend a
week coding and testing each function, and you've got programmers of
average ability.
As for your getchar comment; you've just pointed out another situation
where exceptions are desirable.
On 3 Feb 1997, Chris Bitmead wrote:
> In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
>
> >In article <······················@Alcatel.com.au>,
> > Chris Bitmead <·············@Alcatel.com.au> wrote:
> >>In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
> >>
> >>> ...as soon as you have your values...
> >>> if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) {
> >>> error_function("An error occurred at *this* point.");
> >>> /* The expression below is *not* an error. */
> >>> }
> >>>
> >>> ...sometime later...
> >>>
> >>> v = ((u + 10) * (v + 4));
> >>>
> >>>See, I think the issue of security/safety is not a language issue, but
> >>>a programming issue.
... actually - this is a good point FOR C programming. If you use [say]
C++, some Lisp engines, ANY Smalltalk, ... - you can never tell HOW much
overhead is being introduced to handle these issues. Even some compilers
for C do this [ick!]. If I wanted security/safety out of a common
language, rather than [say] performance; I'd code it in C++. I'm trying
to BUILD a Lisp engine without these difficulties - don't ask.
> >>Are you joking? How many C programmers even *know* about MAXUINT, let
> >>alone know exactly how to use it to find arithmetic errors, *let
> >>alone* are able to get it right consistently with lots of complicated
> >>calculations.
> >
> > How many programmers remember to check for getchar() == EOF?
> >Doesn't matter - The language[1] provides it.
>
> So what? Assembler also provides it. So does machine code for that
> matter. The point is, C makes it difficult enough to code, that for
> all intents and purposes it is impossible to do right, in most
> situations. Most situations means where you can't afford to spend a
> week coding and testing each function, and you've got programmers of
> average ability.
C - Assembly for everyone. Even if it's almost NEVER portable - it's
still readable enough to cross-port to any platform. Assembly is NOT
portable in ANY way. So use C. (actually, it's almost child's play to
implement a C compiler as a macro assembler.... hmmm...)
I can't see any arguments for C++. [I learned it BEFORE I learned C].
Languages such as [Scheme,Java,...] are great if you're into structure
and simplicity without all the complexities of a richer language. Use
them for scripts!
Lisp seems to have a lot of connections to assembly as well [I wonder why :]
On one side, I see this whole commentary as a bit silly.... well, the
comments abount not knowing about 'MAXUINT' and programming C... Learned
about that pretty fast from helpful help-files :) [actually - Posix says
'UINT_MAX' - and Posix code is pretty much cross-portable]
On the other side, it's quite serious. C isn't for everyone. It's for
people who want to code close to the metal without actually juggling knives.
Lisp isn't for everyone either. Not everyone thinks in such patterns.
It's also pretty bare-metal when looked at closely.
Exceptions, strong typing, and other such details are good in the
beginning but can hamper later if not properly implemented. C has all of
these if you want to bother - but I'd rather use a stronger language
[like Lisp/Java/C++/whatever] for these.
... Just trying to sanely answer remarks that were starting to look like
random flamage... <grin>
- Teunis
PS. What's a programmer of average capability? (don't answer - it's
mostly rhetorical) [personally I _REALLY_ don't know - but I don't know
any other programmers]
In article <·······································@sigil.wwe.net> Teunis Peters <········@comfo.ca> writes:
>> >>> ...as soon as you have your values...
>> >>> if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) {
>> >>> error_function("An error occurred at *this* point.");
>> >>> /* The expression below is *not* an error. */
>> >>> }
>> >>>
>> >>> ...sometime later...
>> >>>
>> >>> v = ((u + 10) * (v + 4));
>> >>>
>> >>>See, I think the issue of security/safety is not a language issue, but
>> >>>a programming issue.
>
>... actually - this is a good point FOR C programming. If you use [say]
>C++, some Lisp engines, ANY Smalltalk, ... - you can never tell HOW much
>overhead is being introduced to handle these issues.
Sigh. Why do you always want to know exactly how much overhead there
is just by examining the code? Wouldn't you rather have correct
behaviour as a starting point, and then figure out the overhead later
on, if you really really have to?
>Even some compilers
>for C do this [ick!]. If I wanted security/safety out of a common
>language, rather than [say] performance; I'd code it in C++.
If you wanted safety you'd choose C++? Interesting. :-))
>> > How many programmers remember to check for getchar() == EOF?
>> >Doesn't matter - The language[1] provides it.
>>
>> So what? Assembler also provides it. So does machine code for that
>> matter. The point is, C makes it difficult enough to code, that for
>> all intents and purposes it is impossible to do right, in most
>> situations. Most situations means where you can't afford to spend a
>> week coding and testing each function, and you've got programmers of
>> average ability.
>
>C - Assembly for everyone. Even if it's almost NEVER portable - it's
>still readable enough to cross-port to any platform. Assembly is NOT
>portable in ANY way. So use C. (actually, it's almost child's play to
>implement a C compiler as a macro assembler.... hmmm...)
So, assembly is never portable. C is hardly ever portable. Some other
languages are extremely portable. So choose C???
>On one side, I see this whole commentary as a bit silly.... well, the
>comments abount not knowing about 'MAXUINT' and programming C... Learned
>about that pretty fast from helpful help-files :) [actually - Posix says
>'UINT_MAX' - and Posix code is pretty much cross-portable]
Yes, you can read the header files and find that MAXUINT exists. The
application to arithmetic overflow is not obvious nor straightforard.
>On the other side, it's quite serious. C isn't for everyone. It's for
>people who want to code close to the metal without actually juggling knives.
>Lisp isn't for everyone either. Not everyone thinks in such patterns.
They don't think that way, because they wern't taught. That can be
corrected.
>It's also pretty bare-metal when looked at closely.
How so?
>Exceptions, strong typing, and other such details are good in the
>beginning but can hamper later if not properly implemented. C has all of
>these if you want to bother - but I'd rather use a stronger language
>[like Lisp/Java/C++/whatever] for these.
>
>... Just trying to sanely answer remarks that were starting to look like
>random flamage... <grin>
What is sane to one person is insane to another.
In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
>> v = ((u + 10) * (v + 4))
>
>Personally, I'd do something like:
>
> ...as soon as you have your values...
> if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) {
> error_function("An error occurred at *this* point.");
> /* The expression below is *not* an error. */
> }
>
> ...sometime later...
>
> v = ((u + 10) * (v + 4));
>
>See, I think the issue of security/safety is not a language issue, but
>a programming issue.
Are you joking? How many C programmers even *know* about MAXUINT, let
alone know exactly how to use it to find arithmetic errors, *let
alone* are able to get it right consistently with lots of complicated
calculations.
From: John Bayko
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cok5g$auq@sue.cc.uregina.ca>
In article <······················@Alcatel.com.au>,
Chris Bitmead <·············@Alcatel.com.au> wrote:
>In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
>
>> ...as soon as you have your values...
>> if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) {
>> error_function("An error occurred at *this* point.");
>> /* The expression below is *not* an error. */
>> }
>>
>> ...sometime later...
>>
>> v = ((u + 10) * (v + 4));
>>
>>See, I think the issue of security/safety is not a language issue, but
>>a programming issue.
>
>Are you joking? How many C programmers even *know* about MAXUINT, let
>alone know exactly how to use it to find arithmetic errors, *let
>alone* are able to get it right consistently with lots of complicated
>calculations.
How many programmers remember to check for getchar() == EOF?
Doesn't matter - The language[1] provides it.
[1] All right - 'language environment'.
--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
In article <··········@mamba.cs.Virginia.EDU> ·····@mamba.cs.Virginia.EDU (Clark L. Coleman) writes:
| From: ·····@mamba.cs.Virginia.EDU (Clark L. Coleman)
| Date: Fri, 24 Jan 1997 21:35:41 GMT
|
| Great work!
|
| Now, let's see your example for signed arithmetic, so we can compare
| it to something like:
|
| if (INT_OVERFLOW) {
| :
| :
| }
| in a hypothetical extension of C to detect overflow. Is your signed
| int example as clean as your unsigned int example? What percentage of
| real-world arithmetic is signed, do you suppose?
If you are willing to accept a solution for modular 2's complement
arithmetic (the sort that most machines support), it is not too
difficult to do. I realize that the C standard does not guarantee
this form of arithmetic, and I'm not a C lawyer, so I can't give you a
general solution given the guarantees (if any) that the C spec makes
about signed arithmetic. Given that, one simple solution (not
necessarily the most efficient on all hardware, other more
bit-oriented, less conditional-intensive solutions exist) is
int x, y, z;
z = x + y;
signed_overflow = ((x >= 0) ? (z < y) : (z >= y));
Of course, if either x or y is a constant, the expression becomes much
simpler and quite inexpensive.
Besides the aforementioned problem of lack of guarantees in the C
spec, this "solution" also has the following problems:
- Lack of optimization. It is possible for C compilers to do pattern
recognition and use the hardware's signed-overflow detection
mechanisms (if they exist, some architectures do not have them), but I
know of no compiler that does this at present.
- Reduction of C to assembly language. Although such signed
arithmetic with overflow can be captured into a C function so that it
_can_ be used as intermediates in expressions, the lack of a standard
inlining facility makes this undesirable. Thus we are given the
option of even slower but convenient code, or programming in an
assembly-language style where every intermediate must be named.
Now, going back to the higher-level argument of contrasting C's and
Lisp's arithmetic.
Although I am a hard-core Lisper, and believe that Lisp's generic
arithmetic is a better default for correctness, I think that neither
language has it right, and furthermore, when push comes to shove, C
comes out ahead.
Why (and I am not an apostate to the Lisp faith) do I say this?
Assuming some reasonable defaults (more on this later vis-a-vis Lisp)
such as 2's complement modular arithmetic, it is not too hard to write
an efficient "bignum" library in C. Such libraries already exist, and
hence you don't even need to write them. Given this, C gives me the
_choice_ between fast if error-prone integer arithmetic, and "correct"
if slow integer arithmetic. In fact, with judicious use of constructs
such as GCC's __inline__ keyword, the choice need be no less efficient
than Lisp's standard implementation technique of operating on fixnums
in line and everything else out of line. Yes, it is slightly
cumbersome for the writer, but the code can be shared as a library by
anyone who wants it.
When we look at Lisp/Scheme, on the other hand, the situation is much
less tenable. They may very well provide a better default. I
certainly believe that this is the case for naive programmers.
However, they do not give me a portable choice. Standard Scheme has
no portable way of specifying anything other than the default, hence I
have to resort to implementation-specific extensions that will make
the code hard to port.
CL provides standard declarations, e.g.
(declare (optimize (safety 0) (speed 3)))
but the meaning of this is pretty clearly also implementation-specific.
These declarations do not give me (as far as I can tell) any guarantee
of the sort of efficiency that I may desire, and give me fewer
guarantees on the semantics than the C solution does. Taking these
declarations to mean "use fixnums", I don't know how many bits of
range fixnums may have in this implementation (e.g. is it a BIBOP
implementation with word-sized fixnums like MacLisp, is it a low-tags
implementation with 2 bits of fixnum tag, is it a high-tags
implementation with 6 bits of tag, etc.), or what happens on
carry/overflow any more than with C. In fact, it is much easier to
guess right in C than in Scheme/Lisp when efficiency is an issue,
since C semantics follow the underlying hardware's choices so much
more closely.
Thus C would benefit from better specification of the semantics on
carry/overflow, from an efficient standardized mechanism for
detection, and from a standardized extended-precision library.
Lisp/Scheme would benefit from providing lower-level arithmetic
operators with well-specified semantics that would provide the
programmer with a real choice.
I think that MacLisp had it right (+ was word-sized fixnum, $+ was
word-sized flonum, PLUS was generic), and subsequent Lisps have made a
mistake by not providing this choice to programmers, even if they are
more elegant.
From: David H. Thornley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5crtnj$jv8@epx.cis.umn.edu>
In article <·················@hplgr2.hpl.hp.com>,
Guillermo (Bill) J. Rozas <···@hpl.hp.com> wrote:
>In article <··········@mamba.cs.Virginia.EDU> ·····@mamba.cs.Virginia.EDU (Clark L. Coleman) writes:
>
>If you are willing to accept a solution for modular 2's complement
>arithmetic (the sort that most machines support), it is not too
>difficult to do. I realize that the C standard does not guarantee
>this form of arithmetic, and I'm not a C lawyer, so I can't give you a
>general solution given the guarantees (if any) that the C spec makes
>about signed arithmetic. Given that, one simple solution (not
>necessarily the most efficient on all hardware, other more
>bit-oriented, less conditional-intensive solutions exist) is
>
> int x, y, z;
>
> z = x + y;
> signed_overflow = ((x >= 0) ? (z < y) : (z >= y));
>
Better to use something standard. If you cast to unsigned, the results
of arithmetic are defined (and probably, although not necessarily, efficient),
and you can do some sort of check like:
if (((unsigned) x + (unsigned) y > (unsigned) INT_MAX) ||
((unsigned) x + (unsigned) y < (unsigned) x)))
with perfect safety (assuming I got all the details right - I should do
the dishes and go to bed right now, rather than posting C code on the fly).
>Although I am a hard-core Lisper, and believe that Lisp's generic
>arithmetic is a better default for correctness, I think that neither
>language has it right, and furthermore, when push comes to shove, C
>comes out ahead.
>
I disagree. As I posted some time ago, Lisp does safe computation by
default and efficient computation fairly easily, while C does efficient
computation by default and safe computation awkwardly. Overall, I'd
call this a win for Lisp.
>Why (and I am not an apostate to the Lisp faith) do I say this?
>
>When we look at Lisp/Scheme, on the other hand, the situation is much
>less tenable. They may very well provide a better default. I
>certainly believe that this is the case for naive programmers.
>However, they do not give me a portable choice. Standard Scheme has
>no portable way of specifying anything other than the default, hence I
>have to resort to implementation-specific extensions that will make
>the code hard to port.
>
>CL provides standard declarations, e.g.
> (declare (optimize (safety 0) (speed 3)))
>but the meaning of this is pretty clearly also implementation-specific.
>
Certainly. The meaning of int x, y, z; ... z = x + y; is also implementation-
specific. The standard specifies the meaning of the language, not anything
like efficiency. It would be well within the rights of the implementor to
write a compiler that would include slow overflow checks for every operation,
and to try to email a description to the implementor so he/she could
chuckle about them.
The only reason C compilers do fast arithmetic is that people traditionally
write C compilers that do arithmetic fast. There is no requirement to
use fast, unchecked, arithmetic. This is an implementation issue, and
therefore we need to consider implementations. I think you'll find that
most good Lisp implementations provide nice fast code with the above
declarations, just as most good C implementations provide nice fast code
all the time.
>These declarations do not give me (as far as I can tell) any guarantee
>of the sort of efficiency that I may desire, and give me fewer
>guarantees on the semantics than the C solution does.
Huh? CL and C are pretty similar in the guarantees they make about
fixnums vis-a-vis ints. In each case, you have a guaranteed minimum
size with a method of finding the actual size. The difference between
C and CL is that, by default, CL detects overflows and switches to
bignums, while overflow of arithmetic on signed numbers in C has absolutely
*no* guarantee on semantics, or anything else. It's undefined, which
probably, but not certainly, means that it does whatever the processor
does on overflow.
>Taking these
>declarations to mean "use fixnums", I don't know how many bits of
>range fixnums may have in this implementation (e.g. is it a BIBOP
>implementation with word-sized fixnums like MacLisp, is it a low-tags
>implementation with 2 bits of fixnum tag, is it a high-tags
>implementation with 6 bits of tag, etc.), or what happens on
>carry/overflow any more than with C. In fact, it is much easier to
>guess right in C than in Scheme/Lisp when efficiency is an issue,
>since C semantics follow the underlying hardware's choices so much
>more closely.
>
So, what range do ints have in a C implementation? It's at least
-32767 to 32767, which is the guarantee CLtL2 gives me for fixnums.
Both languages have names defined for the maximum and minimum values.
I see no reason whatsoever why it's easier to guess right in C.
Further, C has no defined semantics relating to signed overflow, while
CL automatically switches to bignums if you don't tell it otherwise.
>Thus C would benefit from better specification of the semantics on
>carry/overflow, from an efficient standardized mechanism for
>detection, and from a standardized extended-precision library.
>
In my opinion, C would greatly benefit by some means of checking
arithmetic for overflow. If the standard would provide that there
be some way for the user to indicate that arithmetic is to be checked,
I'd love it. I don't see the need for more specification of the
semantics, and a standardized extended-precision library would be
cute but not really general.
>Lisp/Scheme would benefit from providing lower-level arithmetic
>operators with well-specified semantics that would provide the
>programmer with a real choice.
>
Are you comparing implementation to implementation? My implementation
(MCL) reduces an add declared as optimized fixnum to a simple add
instruction, and I suspect my C compiler would do the same. Seems
fair to me. With the proper declarations in place, we do have
the effect of lower-level arithmetic operators, with pretty much the
same semantics as C.
--
David H. Thornley, known to the Wise as ········@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
From: Steve Casselman
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32EFB4B7.2185@vcc.com>
Most languages would run better if they ran on special
machine designed for that language. I'm wondering what
the thoughts are on design a machine that accelerates
lisp in some way.
With FPGAs you can build anything you want check out
http://www.vcc.com/hotann.html
Steve Casselman
From: Vivek Sadananda Pai
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5copsh$q0m$1@joe.rice.edu>
In article <·············@vcc.com>, Steve Casselman <··@vcc.com> wrote:
>Most languages would run better if they ran on special
>machine designed for that language. I'm wondering what
>the thoughts are on design a machine that accelerates
>lisp in some way.
I believe that both Symbolics and TI used to build special-purpose
Lisp machines. However, consider the resources aspect: general-purpose
microprocessors can afford a higher design budget, and as a result,
are likely to run the language faster than a poorly-financed
special-purpose CPU. I believe this was part of the reason Lisp
machines died once. However, the wheel of reinvention might spin
again...
-Vivek
From: Steve Casselman
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F038C7.7CEA@vcc.com>
Vivek Sadananda Pai wrote:
>
> In article <·············@vcc.com>, Steve Casselman <··@vcc.com> wrote:
> >Most languages would run better if they ran on special
> >machine designed for that language. I'm wondering what
> >the thoughts are on design a machine that accelerates
> >lisp in some way.
>
> I believe that both Symbolics and TI used to build special-purpose
> Lisp machines. However, consider the resources aspect: general-purpose
> microprocessors can afford a higher design budget, and as a result,
> are likely to run the language faster than a poorly-financed
> special-purpose CPU. I believe this was part of the reason Lisp
> machines died once. However, the wheel of reinvention might spin
> again...
>
> -Vivek
Reconfigurable processing units come from FPGAs. There is a great
pressure to force down the price of reconfigurable logic for just
hardware engineering purposes. With the new reconfigurable logic
from Xilinx you can build hardware on the fly. The same piece of
silicon that can implement a lisp machine can also implement a
picojava. But more likely your might just impelment the inner
loop of some problem.
Check out http://dec.bournemouth.ac.uk/dec_ind/decind6/drhw_page.html
for a real idea of what is being done.
Steve Casselman
·····@cs.rice.edu (Vivek Sadananda Pai) writes:
> However, the wheel of reinvention might spin again...
Given how often this particular subject has come in comp.arch over the
years a wheel certainly does spin but it doesn't seem to be related to
Lisp-specific processors.
--
Andy Newman <····@research.canon.com.au>
From: William Paul Vrotney
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <vrotneyE4upHB.EF6@netcom.com>
In article <··········@horton.research.canon.com.au> ····@research.canon.com.au (Andy Newman) writes:
>
> ·····@cs.rice.edu (Vivek Sadananda Pai) writes:
> > However, the wheel of reinvention might spin again...
>
> Given how often this particular subject has come in comp.arch over the
> years a wheel certainly does spin but it doesn't seem to be related to
> Lisp-specific processors.
>
Perhaps only because currently dogmatism rules? Just a guess.
--
William P. Vrotney - ·······@netcom.com
From: Richard Tobin
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <E58KyJ.3Fp@cogsci.ed.ac.uk>
In article <·············@vcc.com> ··@vcc.com writes:
>Most languages would run better if they ran on special
>machine designed for that language.
What makes you think that? There are two good reasons why not:
- The speed may be limited by factors independent of the processor
itself, such as memory bandwidth. There's no point providing, say,
efficient type-tag dispatch if you can't get the data into registers
fast enough.
- Specialised hardware is likely to be older technology than general
purpose hardware. A lisp machine is not likely to have the resources
of Intel or even SGI behind it. I remember conference papers on Lisp
and Prolog hardware in the 80s where the fancy hardware could just
about beat the previous generation of 68Ks.
> I'm wondering what the thoughts are on design a machine that
> accelerates lisp in some way.
Well, there have been plenty of those. Some were good in some
respects; for example the Xerox machines we used didn't fall apart
when they started paging the way Suns did.
Lisp can be extremely fast with a good compiler, and it's much cheaper
to develop a good compiler than hardware, compiler, and OS.
-- Richard
--
"Cake is a bistrubile cranabolic amphetamoid"
In article <··········@cogsci.ed.ac.uk>, ·······@cogsci.ed.ac.uk (Richard
Tobin) wrote:
> - Specialised hardware is likely to be older technology than general
> purpose hardware. A lisp machine is not likely to have the resources
> of Intel or even SGI behind it. I remember conference papers on Lisp
> and Prolog hardware in the 80s where the fancy hardware could just
> about beat the previous generation of 68Ks.
>
> > I'm wondering what the thoughts are on design a machine that
> > accelerates lisp in some way.
>
> Well, there have been plenty of those. Some were good in some
> respects; for example the Xerox machines we used didn't fall apart
> when they started paging the way Suns did.
>
> Lisp can be extremely fast with a good compiler, and it's much cheaper
> to develop a good compiler than hardware, compiler, and OS.
I would kill for a Symbolics Ivory chip running at 200 Mhz.
--
http://www.lavielle.com/~joswig/
From: William Paul Vrotney
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <vrotneyE4svCw.53L@netcom.com>
In article <·············@vcc.com> Steve Casselman <··@vcc.com> writes:
>
> Most languages would run better if they ran on special
> machine designed for that language. I'm wondering what
> the thoughts are on design a machine that accelerates
> lisp in some way.
>
Why just accelerates Lisp, that's what was done on the Symbolics. Why not a
machine that in fact *is* a Lisp interpreter? I posted a rough approach to
doing this awhile back on this group.
> With FPGAs you can build anything you want check out
> http://www.vcc.com/hotann.html
>
I don't know much about the H.O.T. stuff, but one of the problems with
building a HISC (High Level Instruction Set Computer, just made that up) is
to make sure that it is based on chip generation software as opposed to just
reconfigurable hardware since the resulting machine might be too slow to
compete with say an Intel chip.
--
William P. Vrotney - ·······@netcom.com
From: Steve Casselman
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F03A98.4D99@vcc.com>
William Paul Vrotney wrote:
>
> In article <·············@vcc.com> Steve Casselman <··@vcc.com> writes:
> >
> > Most languages would run better if they ran on special
> > machine designed for that language. I'm wondering what
> > the thoughts are on design a machine that accelerates
> > lisp in some way.
> >
>
> Why just accelerates Lisp, that's what was done on the Symbolics. Why not a
> machine that in fact *is* a Lisp interpreter? I posted a rough approach to
> doing this awhile back on this group.
>
> > With FPGAs you can build anything you want check out
> > http://www.vcc.com/hotann.html
> >
>
> I don't know much about the H.O.T. stuff, but one of the problems with
> building a HISC (High Level Instruction Set Computer, just made that up) is
> to make sure that it is based on chip generation software as opposed to just
> reconfigurable hardware since the resulting machine might be too slow to
> compete with say an Intel chip.
>
> --
>
> William P. Vrotney - ·······@netcom.com
If you take the picojava as an example it runs java 15 times faster than
a Pentium.
(EE-Times jan 13 97 p56) so if a picojava runs at 33MHz it will take a
500MHz
Pentium to keep up. This artical also stated that the picojava ran 5 1/2
times
faster than just in time compilers.
Steve Casselman
From: Michael Williams
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cpvbm$nco@sis.armltd.co.uk>
In article <·············@vcc.com>, Steve Casselman <··@vcc.com> wrote:
>William Paul Vrotney wrote:
>If you take the picojava as an example it runs java 15 times faster than
>a Pentium.
>(EE-Times jan 13 97 p56) so if a picojava runs at 33MHz it will take a
>500MHz
>Pentium to keep up. This artical also stated that the picojava ran 5 1/2
>times
>faster than just in time compilers.
Or the same as a 180MHz Pentium? Okay, so the PicoJava is going to be
a lot cheaper, but that Pentium exists. There are even 200MHz
processors that aren't terribly expensive (can you guess which? :-).
But, here's the cruch, I feel. The JIT's are going to get better.
Sure, the PicoJava's will get faster clockrates, but then so will the
Pentiums. (And the StrongARMs, and the Hitachi SH's, and the MIPS, and
the PPCs, and the i960s. Well, not so sure about the i960s, but you
get the idea.)
There's lots of other marketing arguments against a Java chip (e.g. who
says we'll still be using Java in 18 months time? Who was 18 months ago?
I'd rather have elisp :-) but this thread isn't about those.
Mike.
Michael Williams wrote:
> But, here's the cruch, I feel. The JIT's are going to get better.
> Sure, the PicoJava's will get faster clockrates, but then so will the
> Pentiums. (And the StrongARMs, and the Hitachi SH's, and the MIPS, and
> the PPCs, and the i960s. Well, not so sure about the i960s, but you
> get the idea.)
There is nothing in JavaVM that prevents a good JIT to compile code that
is almost as fast as native code. OK, you have array index checking in
JavaVM, but on most benchmark loops you'll be able to eliminate this
code. Anton Ertl showed in his thesis that it's possible to compile
Forth to code that is about as performant as C code, so the stack
semantics of the JavaVM isn't the problem. Java's local variables can be
transformed into real local variables and used as registers like C does,
too, since JavaVM doesn't permit arbitrary addressing of memory (no
aliasing problem). BTW: without C's aliasing problems, a clever JIT
could compile JavaVM to faster code than plain C. The method calling
semantics could cause problems on deep pipelined machines, but that's
true for every OO language.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
From: Scott Draves
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F62AFC.DCC@cs.cmu.edu>
Bernd Paysan wrote
> OK, you have array index checking in
> JavaVM, but on most benchmark loops you'll be able to eliminate this
> code.
what evidence do you have for this statement?
i find it highly unlikely.
--
balance
equilibrium
death
http://www.cs.cmu.edu/~spot
Scott Draves wrote:
>
> Bernd Paysan wrote
>
> > OK, you have array index checking in
> > JavaVM, but on most benchmark loops you'll be able to eliminate this
> > code.
>
> what evidence do you have for this statement?
>
> i find it highly unlikely.
Typical loops are often in the form
for(i=xx; i<yy; i=i+1)
operate_on_(array[i]);
So it's enough to check that array indexes are valid for xx <= i < yy.
Other loop accesses are limited by the size of the type that becomes the
index. E.g. if you do a byte-translation, you know that your index is in
[0;255]. So although the computation itself uses unpredictable access
patterns, you can check beforehand if you need a check (array smaller
than [0..255]) or not.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
Scott Draves wrote:
>
> Bernd Paysan wrote
>
> > OK, you have array index checking in
> > JavaVM, but on most benchmark loops you'll be able to eliminate this
> > code.
>
> what evidence do you have for this statement?
>
> i find it highly unlikely.
OK, lets take small example:
void copy(int dest[], int src[], int len)
{
for (int i = 0; i < len; i++) {
dest[i] = src[i];
}
}
To make it possible to do range checking, the source and estination
arrays must be passed either as descriptors (with size and data
pointer), or with invisible size parameters passed along with every
array (it doesn't really matter for the case of this argument).
A naively interpreted version of the code above would do something like
this:
i = 0;
next:
if (i >= len) goto done;
if (i >= ARRAYSIZE(src)) error(RANGE_CHECK);
temp = src[i];
if (i >= ARRAYSIZE(dest)) error(RANGE_CHECK);
dest[i] = temp;
i++;
goto next;
done:
There is absolutely nothing to stop a JIT compiler from noticing that
this is a loop, with a minimum index of 0 and a maximum = (len-1) and
then convert the code to something like this:
if (len = 0) goto done;
if ((len > ARRAYSIZE(src) || (len > ARRAYSIZE(dest))
error(RANGE_CHECK);
i = 0;
next:
temp = src[i];
dest[i] = temp;
i++;
if (i < len) goto next;
done:
Since all range checking has been done outside the inner loop, the total
overhead has been reduced to two (presumably very rarely taken!)
compare/branch operations before startup.
The loop itself can now run at the same speed as if the code was
directly compiled from C or some other language.
Terje
--
- <··············@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: Mike Albaugh
Subject: Re: [++] JIT limitations (Was: Re: Theory #51 (superior(?) programming languages))
Date:
Message-ID: <5dd3b7$ctr@void.agames.com>
Terje Mathisen (··············@hda.hydro.com) wrote:
In a discussion of "code hoisting" to lessen the cost
of range checks:
: A naively interpreted version of the code above would do something like
: this:
: i = 0;
: next:
: if (i >= len) goto done;
: if (i >= ARRAYSIZE(src)) error(RANGE_CHECK);
: temp = src[i];
: if (i >= ARRAYSIZE(dest)) error(RANGE_CHECK);
: dest[i] = temp;
: i++;
: goto next;
: done:
: There is absolutely nothing to stop a JIT compiler from noticing that
: this is a loop, with a minimum index of 0 and a maximum = (len-1) and
: then convert the code to something like this:
: if (len = 0) goto done;
: if ((len > ARRAYSIZE(src) || (len > ARRAYSIZE(dest))
: error(RANGE_CHECK);
: i = 0;
: next:
: temp = src[i];
: dest[i] = temp;
: i++;
: if (i < len) goto next;
: done:
Sorry for the long quote, but it is important to the point
I'm trying to raise. The two versions are not equivalent, in that
the error is detected in the second case _before_ anything has been
copied. I know next to nothing about the Java spec, but in a general
case is this considered "Getting what was coming to it" on the part
of the program. There is a lot of enthusiasm for exceptions as the
be-all-and-end-all of error checking, and it would take an exceptional
exception handler to deal with both variants transparently. I'd suspect
that any programmer who missed the opportunity to do the range check
"out of line" explicitely would be _highly_ unlikely to account
for the difference in the exception handler. Also, history is
littered with examples of programmer who practiced "unwarranted
chumminess with the compiler":
1) Initializing the first element of an array, then moving the array
to itself with an offset, producing <n> copies of the first element.
2) Password cracking via the "user provided page-fault handler" on
PDP-10s.
The philosophical question I want to raise is "how far should
we go to preserve 'edge' semantics). In the PClone world, the answer
has traditionally been "all the way" to preserving the quirks of
the 8250 and the NEC 765 :-) Should we transform the above to:
new subscript_type tlen = len;
if (len = 0) goto done;
tlen = len;
if ( tlen > ARRAYSIZE(src) ) tlen = ARRAYSIZE(src);
if ( tlen > ARRAYSIZE(dest) ) tlen = ARRAYSIZE(dest);
i = 0;
next:
temp = src[i];
dest[i] = temp;
++i;
if (i < tlen) goto next;
if ( len > tlen ) error(RANGE_CHECK);
done:
This should preserve the original semantics, even those
the programmer should probably not have been depending on, but also
serves to strengthen Terje's point that such a transformation
can be relatively inexpesive and give relatively large performance
gains. The following is still true:
: The loop itself can now run at the same speed as if the code was
: directly compiled from C or some other language.
Mike
| ·······@agames.com, speaking only for myself
Mike Albaugh wrote:
>
> [ example of hoisting array range check out of a loop ]
>
> Sorry for the long quote, but it is important to the point
> I'm trying to raise. The two versions are not equivalent, in that
> the error is detected in the second case _before_ anything has been
> copied. I know next to nothing about the Java spec, but in a general
> case is this considered "Getting what was coming to it" on the part
> of the program. There is a lot of enthusiasm for exceptions as the
> be-all-and-end-all of error checking, and it would take an exceptional
> exception handler to deal with both variants transparently. I'd suspect
> that any programmer who missed the opportunity to do the range check
> "out of line" explicitely would be _highly_ unlikely to account
> for the difference in the exception handler.
The Java spec actually requires that the original semantics be
preserved. In architecture terms, exceptions must be precise.
Hoisting an array range check out of a loop is only legal if
it can never cause an exception to be thrown earlier than it
would have in the original code (or if the compiler can determine
that doing so would have no visible effects).
--Bob
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c3aum$95e@web.nmti.com>
[among some real nice things that C doesn't have]
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> _I'd_ like to have a language that defined the width of integers.
I wouldn't. I've been there, and the biggest pain porting PL/I programs from
one machine to another is you can't tell whether they really needed a 35
bit signed integer or they were just optimising for a 36 bit word (w/sign).
I'd like to be able to say "int:16" when I needed a 16 bit integer, but for
most cases it's been much easier porting programs from 16-32-64 bit over the
years than porting between 32 and 36 bit PL/Is.
> _I'd_ like to have a language that supported strings with any defined
> _character_ in them. C doesn't.
Actually, it does. It's the libraries that don't.
> I'm now writing software in Common Lisp. I struggle with many profoundly
> _counterproductive_ habits that I totally internalized in the 13+ years I
> programmed in C under Unix -- such as caring about memory expenditure, such
> as having flashes of angst due to the low performance of some piece of code
> that is used _once_ in a program that runs for hours, such as disassembling
> to see if a function was inlined.
Funny, I haven't picked up those habits. Well, except for caring about
memory expenditure... and that in a general sense.
And the world's most beautiful CPU is the PDP-11, suckah.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
From: Larry Kilgallen
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <1997Jan22.072945.1@eisner>
In article <··········@web.nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> [among some real nice things that C doesn't have]
>
> In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>> _I'd_ like to have a language that defined the width of integers.
>
> I wouldn't. I've been there, and the biggest pain porting PL/I programs from
> one machine to another is you can't tell whether they really needed a 35
> bit signed integer or they were just optimising for a 36 bit word (w/sign).
In Ada, one declares the size of integer which is a minimum requirement
for the program, and a compiler will typically implement it using a
larger value if that is convenient for the hardware. There may be
range checks included on results, but not necessarily on intermediate
values of a complex expression.
Declaration of integer types is the most straightforward approach
in Ada, rather than putting specific limits on each variable. In
most cases this is used to ensure protection against overflow
rather than to strictly limit the possible values. A maximum of
65535 is not taxing on contemporary hardware, although its full
capability is not needed when counting the number of cars in my
driveway. That application also has not much use for negative values :-)
>> _I'd_ like to have a language that supported strings with any defined
>> _character_ in them. C doesn't.
>
> Actually, it does. It's the libraries that don't.
But since C provides no other automatic support for strings, the
pragmatic effect is that C does not support strings with nulls in it.
There is a tremendous difference between "one can" and "most will".
You will be bitten by that difference periodically when you run
commercial software written in a lowest-common-denominator language.
Larry Kilgallen
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c67jh$amd@web.nmti.com>
In article <··················@eisner>,
Larry Kilgallen <·········@eisner.decus.org> wrote:
> >> _I'd_ like to have a language that supported strings with any defined
> >> _character_ in them. C doesn't.
> > Actually, it does. It's the libraries that don't.
> But since C provides no other automatic support for strings,
The correct phrase is that C provides no automatic support for strings,
other than creating anonymous initialized arrays.
It's *all* in the library.
> the
> pragmatic effect is that C does not support strings with nulls in it.
"This\0string\0has\0nulls\0in\0it."
> There is a tremendous difference between "one can" and "most will".
> You will be bitten by that difference periodically when you run
> commercial software written in a lowest-common-denominator language.
You mean one written using a lowest common denominator library. I've
given up complaining about stdio years ago. It's the real problem, not
the language itself. And one that's easily fixed, since the language
doesn't restrict you to that library.
Unlike, say, a language that uses byte-counted strings and doesn't let
you have strings longer than 255 characters, but has string operators
built in so you can't fix it even if you want to...
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> I'm now writing software in Common Lisp. I struggle with many profoundly
> _counterproductive_ habits that I totally internalized in the 13+ years I
> programmed in C under Unix -- such as caring about memory expenditure, such
> as having flashes of angst due to the low performance of some piece of code
> that is used _once_ in a program that runs for hours, such as disassembling
> to see if a function was inlined.
I apologize for assuming that this meant that Erik had failed to learn
how to program properly in C. He has contacted me in email and thoughtfully
provided me with an amazing amount of information about his programming
skills, and it appears that this paragraph must simply be exaggeration for
rhetorical effect. I apologize for taking it at face value, and retract
my comments about Erik's competence.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
From: John Bayko
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c398r$228@sue.cc.uregina.ca>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> wrote:
>* John Bayko
>| For comparison, I've written toy programs in LISP, and it's fun, but how
>| would you write a windowing system or database in it? I'm sure LISP
>| experts could do that with their eyes closed, but it's not obvious in the
>| structure of the language...
>
>it isn't? if your argument is that I/O is made up of function calls in C,
>I'm curious in what way you think I/O is _not_ function calls in various
>Lisps.
As I said, my experience in LISP is limited to some toy programs.
I don't know what the equivalent of a file descriptor or window handle
is in LISP, or how you could implement those entirely within LISP (as
opposed to adding them to the language as basic types).
And again, as I said, a LISP expert might be able to show me how
(and feel free to do so), but it's certainly not obvious to me.
>| Basically, C was the first high level language that was low level enough
>| to be useful, getting rid of the conventional abstractions that got in
>| the way. Now we just take that for granted - when was the last language
>| you've seen designed where I/O was not a function/procedure/method, and
>| which didn't have most if not all of C's operators?
>
>if you design a language small enough, _all_ other languages will have to
>have all operators that is also in that language.
Did I just happen to miss the bitwise-OR or ++ operators in
Pascal? I've certainly haven't found a way to do a bit shift operation
in Pascal without using a multiply, which certainly works, but doesn't
express what you're actualy trying to do.
C was particularly operator rich (excluding APL). Obviously you
don't always need all those operators, but they're pretty nice to have
when you do want them.
>however, _I'd_ like to
>have a language that defined the value of division of signed integers. C
>doesn't. _I'd_ like to have a language that defined the width of integers.
>C doesn't.
It kind of did, when it only ran on one platform (or just a few).
That is a weakness, but predefined MAXINT-type constants help, so it's
not fatal.
> _I'd_ like a _low-level_ language to handle integer overflow,
>or at least give me access to this absolutely _vital_ information. C
>doesn't.
That's a problem too, but it's not so bad since it doesn't happen very
often, and when it does, you can compare to predefined MAXINT type
constants and filter values before they overflow (instead of after,
which might be better for reliability in the long run anyway).
>_I'd_ like to have a language that supported strings with any defined
>_character_ in them. C doesn't. the list goes on.
The only character you can't include in a C string is \0. Though I
don't think anyone's really happy with C's string support...
But none of these problems are fatal. You can get around them if
you have to, and often enough you don't run into them anyway. If you
don't like C's strings for example, use arrays - same thing.
I wasn't trying to suggest that C is the best language for
anything, just why it's popular - in most (generally simple) cases,
programmers just don't have problems with it. And when they do, they've
invested enough effort that it's easier to just work around them than
restart in a better language... (another element of C popularity - the
simple/complex transition trap!).
--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3062873324634283@naggum.no>
* John Bayko
| >_I'd_ like a _low-level_ language to handle integer overflow, or at
| >least give me access to this absolutely _vital_ information. C doesn't.
|
| That's a problem too, but it's not so bad since it doesn't happen very
| often, and when it does, you can compare to predefined MAXINT type
| constants and filter values before they overflow (instead of after,
| which might be better for reliability in the long run anyway).
I guess this depends on what kind of programmer you are. I would rather
sacrifice speed than accuracy.
| If you don't like C's strings for example, use arrays - same thing.
I must have been unclear. C's arrays don't know how big they are, either.
the zero byte terminating C's strings is just one of the many possible ways
to handle this fundamental design flaw in C.
| And when they do, they've invested enough effort that it's easier to just
| work around them than restart in a better language... (another element of
| C popularity - the simple/complex transition trap!).
you cannot possibly work around all the problems in C. it would slow your
program (not to mention your _programming_) to a halt, and that highly
appreciated performance edge in C would just simply cease to exist. safe C
is extremely hard to write. buggy C is easy to write, in fact, _anybody_
can do it. and that's precisely what they do: it's what's makes a language
the "most popular".
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c5ghv$8gt@web.nmti.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> I must have been unclear. C's arrays don't know how big they are, either.
Sure they do:
sizeof "Hello\0Eric." == 12
strlen("Hello\0Eric.") == 5
> you cannot possibly work around all the problems in C. it would slow your
> program (not to mention your _programming_) to a halt, and that highly
> appreciated performance edge in C would just simply cease to exist.
I don't expect C to be any faster than any other competently implemented
compiled language. I just happen to like the language. It's not perfect,
but it's not near so bad as you're making out.
> safe C is extremely hard to write.
Given a proper I/O library, it's not that tough. I've written bits and
pieces that make it easier... including routines to handle indefinite
length strings.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
·····@nmti.com (Peter da Silva) writes:
> In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> > I must have been unclear. C's arrays don't know how big they are, either.
>
> Sure they do:
>
> sizeof "Hello\0Eric." == 12
> strlen("Hello\0Eric.") == 5
You're being silly. There's some local knowledge of the size of that
literal "string", but if you pass the array to another procedure that
knowledge is lost. Sure, you can also pass the length in a separate
parameter, but that merely underlines the point that C's arrays have
no inherent idea of their size. The fact that one is not prevented
from indexing off the end of a C array -- even one whose dimensions
are locally known -- is another such glaring indication.
Sheesh. Call a wart a wart.
regards,
-- Robert
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c5q0h$46s@web.nmti.com>
In article <··············@xena.mindspring.com>,
Robert Sanders <········@mindspring.net> wrote:
> ·····@nmti.com (Peter da Silva) writes:
> > In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> > > I must have been unclear. C's arrays don't know how big they are, either.
> > Sure they do:
> > sizeof "Hello\0Eric." == 12
> > strlen("Hello\0Eric.") == 5
> You're being silly. There's some local knowledge of the size of that
> literal "string", but if you pass the array to another procedure that
> knowledge is lost.
You don't pass the array to another procedure. You pass a pointer to the
array. Arrays and pointers are *not* the same thing, and if you want to
use a variable length string object in C (with the data needed to recover
the array size at runtime) you need to go to some more effort, and write
a library that supports it.
C doesn't carry a lot of information around with data that can be extracted
at runtime. That's a deliberate design decision, and goes *far* beyond the
question of wheteher automatically initialized character arrays and pointers
to characters "lose" information. You can argue with that decision, but
back-tracking from a particular effect to claiming that C's arrays don't
have a "size" is just plain silly.
C doesn't pass arrays to functions. C doesn't perform any validity checks
on pointers before it uses them. That's all true. But it *does* know the
size of arrays when they're in scope. And if you *want* to deal with sized
and checked strings it's not tough to write a library to manage them. The
one I use hides the extra info before the pointer that actually gets passed
around, but that's an implementation detail...
SYNOPSIS
#include <varstr.h>
vs = newstr(size);
vs = append(vs, s);
freestr(vs);
size = strsize(vs);
varstr *vs;
int size;
char *s;
If I need to use anything more complex than this, I operate on editing
buffers rather than strings, with a set of buffer routines:
SYNOPSIS
#include <buffer.h>
buffer = new_buffer();
delete_buffer(buffer);
mark = copy_mark(buffer, mark);
mark = search(buffer, mark1, mark2, string);
stat = delete_mark(buffer, mark);
stat = move_mark(buffer, mark, off);
off = locate_mark(buffer, mark);
ptr = text(buffer, mark1, mark2, &length);
ptr = open_text(buffer, mark, length);
close_text(buffer, new_length);
stat = delete_text(buffer, mark1, mark2);
extern char *buffer_error;
BUFFER buffer;
MARK mark, mark1, ...;
size_t off, off1, ...;
int stat, cnt;
char *ptr;
These buffers, by the way, allow any character in them including '\0'.
There's no magic in these routines, either. I'm not pretending to be an
ace C hacker... anyone competant could do as well in a day or so of
leisurely design. That people don't says more about the people than it
does about C.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
·····@nmti.com (Peter da Silva) writes:
> You don't pass the array to another procedure. You pass a pointer to the
> array.
Yes, yes, exactly. It just gets worse the more you examine it!
> Arrays and pointers are *not* the same thing, and if you want to
> use a variable length string object in C (with the data needed to recover
> the array size at runtime) you need to go to some more effort, and write
> a library that supports it.
The contention that C and its standard libraries don't support feature
X can often be countered by the response "you can implement that a
library." Do you really consider that a useful answer? Given enough
effort, C can support everything from garbage collection to lexical
closures -- but not necessarily very efficiently, and certainly not
very conveniently.
> C doesn't carry a lot of information around with data that can be extracted
> at runtime. That's a deliberate design decision, and goes *far* beyond the
> question of wheteher automatically initialized character arrays and pointers
> to characters "lose" information. You can argue with that decision, but
> back-tracking from a particular effect to claiming that C's arrays don't
> have a "size" is just plain silly.
Indeed it would be. However, nobody said they don't have a "size";
Erik claimed that they were unsafe and unsatisfactory because they
(and their associated operators, excepting of course sizeof) don't
*know* it and will not *enforce* it. I don't think there's any
misconception about whether this was designed into the language or a
horrible unforeseen accident. That such flaws are deliberate merely
adds insult to injury.
> C doesn't pass arrays to functions. C doesn't perform any validity checks
> on pointers before it uses them. That's all true. But it *does* know the
> size of arrays when they're in scope.
Hmm. I'm no ace C hacker either, so correct me if I'm wrong. It
knows the size in bytes -- that is, it can provide such information to
the program via sizeof -- but it doesn't know the limits of each
dimension. Of course, that flaw is somewhat ameliorated by the
inability to declare arrays with variable dimensions (though you may
coerce a block of memory into arrayhood with pointers).
> There's no magic in these routines, either. I'm not pretending to be
> an ace C hacker... anyone competant could do as well in a day or so
> of leisurely design. That people don't says more about the people
> than it does about C.
But your unmagical safe string routines don't work with my safe I/O
routines, and neither of them works with my colleague's hash tables.
That so many people *must* implement and continually re-implement such
basic capabilities in add-on libraries says a great deal about the
language to me.
regards,
-- Robert
P.S. I won't debate that C is a wonderful language for the
implementation of better languages. But that's not the point. Or
maybe it is; these threads all run together after a few years.
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c68g1$d4i@web.nmti.com>
In article <··············@xena.mindspring.com>,
Robert Sanders <········@mindspring.net> wrote:
> The contention that C and its standard libraries don't support feature
> X can often be countered by the response "you can implement that a
> library." Do you really consider that a useful answer?
Since I *have* implemented it in a library, of course I do!
> Given enough
> effort, C can support everything from garbage collection to lexical
> closures -- but not necessarily very efficiently, and certainly not
> very conveniently.
But it *can* support indefinite length byte strings containing any
character just as conveniently and efficiently as any other language can.
I'm no fan of the various efforts to turn C into a high level language.
My favorite high level language is Smalltalk. I just wish folks wouldn't
dive in and start griping that every shortcoming of everything associated
with C is inherent in the language itself. It's not, and the ones that
aren't are trivial to resolve.
That's not saying that C doesn't have shortcomings. It's relatively
weakly typed. It doesn't support objects (and arrays that carry their
sizes with them are primitive objects... and I'd much rather have a
general tool for carrying such information along with values than just
one special case (array sizes) that's popular because it's what Fortran
did). It's a low level language. It's great for writing O/S kernels and
other things that need low level access to machine objects. It's not
great for writing big applications. So? Don't use it for that.
> Hmm. I'm no ace C hacker either, so correct me if I'm wrong. It
> knows the size in bytes -- that is, it can provide such information to
> the program via sizeof -- but it doesn't know the limits of each
> dimension.
Sure it does. Using sizeof *array. Unless you're using a one dimensional
array as a two dimensional array.
> But your unmagical safe string routines don't work with my safe I/O
> routines, and neither of them works with my colleague's hash tables.
Well, I have safe I/O routines and hash tables as well... but...
> That so many people *must* implement and continually re-implement such
> basic capabilities in add-on libraries says a great deal about the
> language to me.
But your window system doesn't work with my runtime compiler system,
either. A Smalltalk programmer looks at that and says "why should such
basic capabilities of the language have to be add-on libraries". Where
you draw the line between "basic capabilities of the language" and "add-
on libraries" is a matter of degree, not type. C happens to draw that
line at a very low level. It doesn't put much in the language. Smalltalk
creates a whole *environment* as an integral part of the language. What's
the right balance point? I don't know... that depends on what you're
doing with the tool.
If you're using flaked obsidian core technology to build your house,
with stone axes and knives, you're crazy. But it makes excellent scalpels
for eye surgery.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
·····@nmti.com (Peter da Silva) writes:
> > The contention that C and its standard libraries don't support feature
> > X can often be countered by the response "you can implement that a
> > library." Do you really consider that a useful answer?
>
> Since I *have* implemented it in a library, of course I do!
Then there are hardly any programming languages that don't support
most of the features X I would care to use, and we're wasting our time
arguing about it. Well, I'll grant the latter even without the first.
Practically, the ability to implement feature X in a library doesn't
have the same effect as being able to rely upon feature X in most or
all implementations of a language. That so many network programs, for
example, can be turned into tools of host invasion by exploiting their
fixed size string buffers and the unsafe I/O calls in the standard
library is a testament to that fact.
> But it *can* support indefinite length byte strings containing any
> character just as conveniently and efficiently as any other language can.
I disagree with that. How convenient is having to abandon all the
standard string handling and string-related I/O functions? You can't
even use standard string literals as strings anymore!
> It's a low level language. It's great for writing O/S kernels and
> other things that need low level access to machine objects. It's not
> great for writing big applications. So? Don't use it for that.
Right. I don't even know how this argument started, but it looks like
we're agreeing on the general point without conceding any specifics.
Obviously, something makes C "not great for writing big applications."
Can the attributes of C arrays and strings that we've discussed here
really not be part of the cause?
> Sure it does. Using sizeof *array. Unless you're using a one dimensional
> array as a two dimensional array.
Arrgh. That's a perfectly reasonable answer to my fumbled attempt to
make my point. What I was trying to point out was that a) the only
arrays of which C knows the size are those with dimensions known at
compile time and b) even knowing the *size* of an array won't
necessarily help you stay within the proper array boundaries. Yes,
there are ways around that. No, I don't think they qualify as
convenient or safe. I'm not arguing that it can't be done, I'm just
agreeing in part with Erik (god help me) when he said:
> you cannot possibly work around all the problems in C. it would
> slow your program (not to mention your _programming_) to a halt, and
> that highly appreciated performance edge in C would just simply
> cease to exist.
(mostly with the _programming_ part, now that I re-read it.)
Anyway, I've managed to avoid this topic for years, and now that my
sanity has lapsed and I've tasted the forbidden fruit, I foresee my
imminent expulsion from the Garden of Eden. Excuse me while I go find
a nice fig tree.
-- Robert
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c8g6k$k0v@web.nmti.com>
In article <··············@xena.mindspring.com>,
Robert Sanders <········@mindspring.net> wrote:
> ·····@nmti.com (Peter da Silva) writes:
> > > The contention that C and its standard libraries don't support feature
> > > X can often be countered by the response "you can implement that a
> > > library." Do you really consider that a useful answer?
> > Since I *have* implemented it in a library, of course I do!
> Then there are hardly any programming languages that don't support
> most of the features X I would care to use, and we're wasting our time
> arguing about it.
I disagree. There are some features that are unacceptably hard to implement
in C. Garbage collection and operator overloading are the examples someone
used, and I would be the first to agree that C doesn't support these
features, and if you want them you shouldn't use C.
The example of proper string handling, on the other hand, is something
that can be efficiently and easily implemented in C.
> Practically, the ability to implement feature X in a library doesn't
> have the same effect as being able to rely upon feature X in most or
> all implementations of a language.
That's only true if you need access to the internals of the implementation
to implement that feature (garbage collection, scheduling, threads, operator
overloading, coroutines, etc...), or if you're lazy and don't want to make
the effort to learn how to write programs in that language.
> That so many network programs, for
> example, can be turned into tools of host invasion by exploiting their
> fixed size string buffers and the unsafe I/O calls in the standard
> library is a testament to that fact.
That's testament to the fact that the people who wrote those tools were
not and are not considering security in their design. Dan Bernstein's
qmail is a perfect counterexample.
> I disagree with that. How convenient is having to abandon all the
> standard string handling and string-related I/O functions? You can't
> even use standard string literals as strings anymore!
Sure you can. You just need to do something like this:
#define S(s) c_to_string(s, sizeof s)
Then when you need a string, replace "foo\0bar" with S("foo\0bar").
Oh, sure, it's a little more typing. But if you consider *that* a reason to
pick one language over another you must really hate most of the modern high
level programming languages. In fact a common complaint about C is that it's
too terse.
> Right. I don't even know how this argument started, but it looks like
> we're agreeing on the general point without conceding any specifics.
Well, if the general point is "C is not a good language for big applications",
yes. If the general point is "C is a sucky language and people who don't think
so are stupid" (which is a point the person I was originally responding to
keeps making) then no, I don't agree.
> Obviously, something makes C "not great for writing big applications."
The poverty of the standard libraries, the lack of strong type checking,
the lack of garbage collection, the lack of scheduling, sure, lots of
reasons. Like I said, I like Smalltalk.
> Can the attributes of C arrays and strings that we've discussed here
> really not be part of the cause?
No.
> > Sure it does. Using sizeof *array. Unless you're using a one dimensional
> > array as a two dimensional array.
> Arrgh. That's a perfectly reasonable answer to my fumbled attempt to
> make my point. What I was trying to point out was that a) the only
> arrays of which C knows the size are those with dimensions known at
> compile time
There are no other arrays in the language. If the dimensions of an object
are not known, then whatever it is it's not an array. It's probably a
pointer. The fact that C lets you use array syntax to declare pointers
is a genuine flaw of the language.
> I'm not arguing that it can't be done, I'm just
> agreeing in part with Erik (god help me) when he said:
> > you cannot possibly work around all the problems in C. it would
> > slow your program (not to mention your _programming_) to a halt, and
> > that highly appreciated performance edge in C would just simply
> > cease to exist.
I would agree, if you need some of the features of higher level languages
that are not available in C. It is not, however, true that you always need
those features, and I don't believe that the "performance edge" is real
in any case and is not the reason you write in C, and I don't beleieve that
the actual examples he used are examples of real problems.
I do believe that Eric never really learned how to write effective, safe,
and portable C code, and he's blaming the language for it. The list of bad
habits he had to unlearn are not bad habits that are inherent to C
programming.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063054324684392@naggum.no>
* Peter da Silva
| I do believe that Eric never really learned how to write effective, safe,
| and portable C code, and he's blaming the language for it. The list of
| bad habits he had to unlearn are not bad habits that are inherent to C
| programming.
you're really something, Peter. perhaps you should try to recover the
context when I gave that list of "bad habits" and why?
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
I think the bickering over integer overflow in C misses the point.
I think the issue here is one of safety and expectation.
It is certainly true that a programmer who knows a LOT about
a specific hardware platform, and a LOT about the details of
coding in C can write code that will properly detect integer
overflow (and a bazillion other tiny ways to get wrong answers).
However, many programs are being written by people whose skill
sets lie in economics, physics, chemistry, fluid dynamics, etc.
These people are NOT professional programmers -- they write in C
(C++,FORTRAN, etc) because they need to solve a problem and
it looks like a good tool for doing it. They are NOT going
be aware of the problems of integer overflow, and are going to
write code that assumes that the computer, pocket-calculator-like,
will give them the "right answer".
I believe the two sides of the argument boil down to:
a. Programmers need "safe languages" that handle such problems
automatically, so that average programmers can write
programs that are likely to work correctly under a large
set of operational conditions.
b. Programmers need "efficient languages" that let an expert programmer
write Really Fast Code. Average programmers should be using
spreadsheets or be willing to take the time to learn all
the nasty things about the language they are using.
You can't use a knife if it's dull, and if it's sharp, you
might get cut if you don't use it carefully.
I think both sides have their virtues, but I'll present one data point:
On Black Monday on Wall Street, there were several
ways that computers brought doom onto their trading users:
a. Slow computers gave traders information that was many
hours out of date. Traders used this information to trade
themselves (and their banks) into deeper pits.
b. Integer overflow (trade volumes, scaled currencies, etc)
caused systems to crash if the systems detected the overflow,
c. Integer overflow caused Very Wrong Answers if modulo arithmetic
was performed. This also gave traders Bad Advice.
Now, Morgan-Stanley Bank actually did NOT lose money on Black Monday.
They actually made a small (by their standards. It was probably enough to
finance a small war somewhere) profit that day. Their systems
were written in APL. The APL system detected integer overflow,
switched to floating point where needed, and kept going, giving them
good answers on time.
I consider this an argument for safe languages.
Bob
In article <·····················@jarvis.cs.toronto.edu>
········@eecg.toronto.edu "Robert Bernecky" writes:
> I believe the two sides of the argument boil down to:
>
> a. Programmers need "safe languages" that handle such problems
> automatically, so that average programmers can write
> programs that are likely to work correctly under a large
> set of operational conditions.
>
> b. Programmers need "efficient languages" that let an expert programmer
> write Really Fast Code. Average programmers should be using
> spreadsheets or be willing to take the time to learn all
> the nasty things about the language they are using.
> You can't use a knife if it's dull, and if it's sharp, you
> might get cut if you don't use it carefully.
I agree. Remember the Douglas Adams joke about which is the
superior species: humans or dolphins. Both think that _they_
are the superior species, and for exactly the same reasons.
That's why I don't expect this thread to lead to any profund
discoveries or conclusions, for most of us, at least. We believe
whatever we do because we're either a human or a dolphin - and
no amount of discussion will change that. If it could, then
it's likely to have happened some time ago.
The real effect that this thread may hav, constructive or
otherwise, will be on those who are reading it but whose
feelings and thoughts on this subject have not yet fossilised
(by whatever means, e.g. positive or negative experiences,
propaganda, brainwashing, enlightenment, etc).
> I think both sides have their virtues, but I'll present one data point:
>
> On Black Monday on Wall Street, there were several
> ways that computers brought doom onto their trading users:
>
> a. Slow computers gave traders information that was many
> hours out of date. Traders used this information to trade
> themselves (and their banks) into deeper pits.
>
> b. Integer overflow (trade volumes, scaled currencies, etc)
> caused systems to crash if the systems detected the overflow,
>
> c. Integer overflow caused Very Wrong Answers if modulo arithmetic
> was performed. This also gave traders Bad Advice.
>
> Now, Morgan-Stanley Bank actually did NOT lose money on Black Monday.
> They actually made a small (by their standards. It was probably enough to
> finance a small war somewhere) profit that day. Their systems
> were written in APL. The APL system detected integer overflow,
> switched to floating point where needed, and kept going, giving them
> good answers on time.
>
> I consider this an argument for safe languages.
<grin> There's also the Seymour Cray quote, but all that
does is remind us, in this context, that we can choose
speed or accuracy, but not necessarily _both_. Cray favoured
speed, while sacrificing accuracy, which is a fair choice
for the machines he designed, and the people who use them.
Not everyone will make the same choice, dispite the propaganda.
While Alan Perlis once said that, "Lisp programmers know
the value of everything and the cost of nothing", he could
just easily be paraphrased, "C programmers know the cost
of everything and the value of nothing".
So, C and Lisp programmers appear to make different choices.
I wouldn't call that a profund statement. It _should_ be very
obvious. Why then do so many of us miss this point, or forget
about it? Why do people feel so strongly about which language
_other people_ choose to use? Perhaps it's because we may have
to use their software, or that some of us feel that these
choices may effect them, and possibly limit _their_ choices?
I don't know. I use the tools that I do _because I can_. If
anyone has a problem with that, I'll remind them to get a life.
I'll not call them stupid, but I _will_ object to anyone who
thinks that they can tell me which choices to make.
You're all welcome to _offer_ me advise, but please understand
that I'm not obliged to follow it. ;-) That seems to me to be a
healthy attitude. If not, then I'm sure someone will tell me...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: Jerry Leichter
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32ECCF3D.19B2@smarts.com>
> While Alan Perlis once said that, "Lisp programmers know
> the value of everything and the cost of nothing", he could
> just easily be paraphrased, "C programmers know the cost
> of everything and the value of nothing".
Actually, you don't need to paraphrase; he said this much more directly.
The quote - I heard it many times, in, most likely, all four of the
different forms implied by the following - was:
"[C|Unix] has set back the state of computer science [10|15] years".
This was after his Epigrams were collected as Yale tech report - at the
time that report was produced, neither C nor Unix were very wide-spread,
and it was possible to believe that OS's and languages of the future
would build on high-level constructions like TOPS-20, APL, and LISP - so
it doesn't appear in the published lists.
-- Jerry
Jerry Leichter wrote:
>
> > While Alan Perlis once said that, "Lisp programmers know
> > the value of everything and the cost of nothing", he could
> > just easily be paraphrased, "C programmers know the cost
> > of everything and the value of nothing".
>
> Actually, you don't need to paraphrase; he said this much more directly.
> The quote - I heard it many times, in, most likely, all four of the
> different forms implied by the following - was:
>
> "[C|Unix] has set back the state of computer science [10|15] years".
The worse thing is: Bill Gates came and pushed Basic/DOS, and this
certainly is the way back to the early 50th (certainly to a date before
Lisp was invented ;-).
But as C and Unix were hacker projects around '70 and got public (in the
broader sense) at around '80, a step back by 10 years should be
expected, anyway. Basic was a Hacker project in the 60th, and DOS was
crap only. And that's what many people use now, although it's cluttered
with Windows, the worst GUI incarnation (from the CS point of view) the
world has seen yet.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063475763718260@naggum.no>
* Bernd Paysan
| But as C and Unix were hacker projects around '70 and got public (in the
| broader sense) at around '80, a step back by 10 years should be expected,
| anyway. Basic was a Hacker project in the 60th, and DOS was crap
| only. And that's what many people use now, although it's cluttered with
| Windows, the worst GUI incarnation (from the CS point of view) the world
| has seen yet.
a while ago, somebody posted a summary of programming cultures, noting that
Microsoft is basically growing a whole new culture from scratch, rejecting
all other cultures and what they have built. considering that it has taken
50+ years of research and very serious thinking by many more good people
than Microsoft could ever hire, we should _expect_ that programmers under
constant pressure to release products are no match for researchers. it's
just like C and DOS and those other products they build: they effectively
fail to recognize that cultures can be built "vertically", and instead
build them "horizontally".
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
From: Steve Casselman
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F2BFB2.5BBC@vcc.com>
> That's why I don't expect this thread to lead to any profund
> discoveries or conclusions, for most of us, at least. We believe
> whatever we do because we're either a human or a dolphin - and
> no amount of discussion will change that. If it could, then
> it's likely to have happened some time ago.
You sound like there is nothing and everyone is just running on
momemtum.
Look there is this new stuff called reconfigurable computing that lets
the
software programmer change the hardware on demand. It is so powerful in
some
ways that even the inventor of the microprossor said that reconfigurable
computing will rule the world(Fredico Faggin). If you look (not just
glance)
at http://dec.bournemouth.ac.uk/dec_ind/decind6/drhw_page.html you will
find
some stuff that might change your outlook. Under evolvable hardware look
for
Adrian Thompson's page. In one experiment they randomly configured an
xc6200
fpga in analog mode only. The task was to discrimanate between a 1KHz
and
10KHz signal and light a led for one frequency and not the other. They
ran
the analog signal straight into the part and started the genetic
algorithm
running. What happended was quite astounding. The part could tell the
difference between the to different frequencys and it did it by sending
out
pulses that look just like the output of the human neuron. So a some
silicon
ended up acting just like the human brain. I'm pretty sure you will have
a
hard time making any program running on any computer come up with the
same
output. There is something new happening and it has been worked on for
10
years. DARPA desided that reconfigurable computing deserved its own
program
and is fund research at the tune of $120 Million.
Steve Casselman
Virtual Computer Corp.
http://www.vcc.com
From: Steinar Bang
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <whraj5x1vq.fsf@tyr.metis.no>
>>>>> ·····@nmti.com (Peter da Silva):
[snip!]
> The example of proper string handling, on the other hand, is
> something that can be efficiently and easily implemented in C.
However, this is not a part of the standard libraries, and result in a
lot of reinvented wheels (to every man (*and* woman...) his own
support library, with strings and containers!).
But of course, you refer to this, further down:
[snip!]
>> Obviously, something makes C "not great for writing big applications."
> The poverty of the standard libraries, the lack of strong type
> checking, the lack of garbage collection, the lack of scheduling,
> sure, lots of reasons. Like I said, I like Smalltalk.
- Steinar
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5clrpl$imh@web.nmti.com>
In article <··············@tyr.metis.no>, Steinar Bang <··@metis.no> wrote:
> >>>>> ·····@nmti.com (Peter da Silva):
> > The example of proper string handling, on the other hand, is
> > something that can be efficiently and easily implemented in C.
> However, this is not a part of the standard libraries, and result in a
> lot of reinvented wheels (to every man (*and* woman...) his own
> support library, with strings and containers!).
That is a real problem. It's not, however, a shortcoming in the language.
It's a shortcoming in the standard libraries.
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
In article <··············@xena.mindspring.com>, Robert Sanders
<········@mindspring.net> wrote:
> ·····@nmti.com (Peter da Silva) writes:
>
> > > The contention that C and its standard libraries don't support feature
> > > X can often be countered by the response "you can implement that a
> > > library." Do you really consider that a useful answer?
> >
> > Since I *have* implemented it in a library, of course I do!
>
> Then there are hardly any programming languages that don't support
> most of the features X I would care to use, and we're wasting our time
> arguing about it. Well, I'll grant the latter even without the first.
>
> Practically, the ability to implement feature X in a library doesn't
> have the same effect as being able to rely upon feature X in most or
> all implementations of a language. That so many network programs, for
> example, can be turned into tools of host invasion by exploiting their
> fixed size string buffers and the unsafe I/O calls in the standard
> library is a testament to that fact.
Speaking PRACTICALLY, people code to an OS, not a set of language
features. If something is so gosh important, it will be placed in the
standard Mac/Windows/UNIX&X OS runtime environment and everyone can get at
it.
Last time I checked, IO and windows were supported in this way without
anyone complaining that they were not built into the C language.
Maynard
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
--
My opinion only
From: Mike McDonald
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5clrnr$gb0@fido.asd.sgi.com>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * Bernd Paysan
>| But as C and Unix were hacker projects around '70 and got public (in the
>| broader sense) at around '80, a step back by 10 years should be expected,
>| anyway. Basic was a Hacker project in the 60th, and DOS was crap
>| only. And that's what many people use now, although it's cluttered with
>| Windows, the worst GUI incarnation (from the CS point of view) the world
>| has seen yet.
>
> a while ago, somebody posted a summary of programming cultures, noting that
> Microsoft is basically growing a whole new culture from scratch, rejecting
> all other cultures and what they have built. considering that it has taken
> 50+ years of research and very serious thinking by many more good people
> than Microsoft could ever hire,
I think you are seriously underestimating Microsoft's profits. Bill is
spending BIG bucks hiring as many big named researchers as he can.
Mike McDonald
·······@engr.sgi.com
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063483897530724@naggum.no>
* Mike McDonald
| I think you are seriously underestimating Microsoft's profits. Bill is
| spending BIG bucks hiring as many big named researchers as he can.
I know. what are the results?
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
From: Steinar Bang
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <whu3o0vb99.fsf@tyr.metis.no>
>>>>> Erik Naggum <····@naggum.no>:
> * Mike McDonald
>> I think you are seriously underestimating Microsoft's profits. Bill is
>> spending BIG bucks hiring as many big named researchers as he can.
> I know. what are the results?
Indeed.
Anyways, I'm told that MicroSoft hires a lot of people. They also
don't grow much in absolute size. Which means one of two things:
1. people quit
2. MS fires them
In both cases, I think somebody at MS, is doing something wrong. You
either hire the wrong people, or it's too unpleasant to work in your
company.
But this could explain a lot of the quality of many MS releases.
I get visions of people being dragged in from the street, and given a
3 month deadline, to finish a product they've never laid their eyes
on...
- Steinar
PS sorry for the off-topic article, I just couldn't keep shut
In article <··········@fido.asd.sgi.com>
·······@engr.sgi.com "Mike McDonald" writes:
> I think you are seriously underestimating Microsoft's profits. Bill is
> spending BIG bucks hiring as many big named researchers as he can.
I frequently recommend browsing the MSR website. If this was all
you saw of MS, you might get a very different impression of them.
For example, they have researchers using Common Lisp and Haskell,
two of my favourite languages. Their papers can be read by anyone.
Alas, this gets very little attention. Instead, we get the "evil
empire" label again and again. Some of Erik's points are good,
but he's only refering to the surface, i.e. what MS are selling
_today_. MSR should be compared to places like MIT, CMU, etc.
I'd like to know how their work compares, given the relatively
short time MSR has existed.
The danger is that the "evil empire" hatemail will become an
self-fullfully prophecy, by slowly killing everything that isn't
"mainstream" enough, e.g. things like ActiveVRML. Do we want the
VR world dominated by "C/C++ of death" attitudes? I'd prefer a
world of people who're a little more open minded. Why not support
a fledgling idea, and help it grow into something powerful?
If we continually bash MS, and spread the idea that MS are a lost
cause with nothing to offer us, we may miss something valuable.
I have no intention of spending the next 10 years coding in C++!
Let's support the non-C++ technology being used, and in some cases
_developed_, by MS.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer wrote:
>
> I frequently recommend browsing the MSR website. If this was all
> you saw of MS, you might get a very different impression of them.
> For example, they have researchers using Common Lisp and Haskell,
> two of my favourite languages.
Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
Microsoft Common Lisp?
The rounding error on his interest could finance the whole thing. :)
Seriously, we could get up a petition explaining why MsCL would be a
great thing (newsgroup project) and all sign it.
Ken
==========================================================
Dear Mr. Gates,
Minor premise: Bill Gates is a programmer.
Major premise: Common Lisp is a Great Language.
SomeLatinus OrOtherus: Bill Gates should do Visual Common Lisp.
Common Lisp is garbage-collected, dynamic, introspective,
object-oriented, exceptions-enabled, compiled and ANSI Standard.
And it is not Java. :)
Anyway, /I/ would love to see a Visual Common Lisp.
Signed,
Ken Tilton, Missing Link Software
educational software developer (now using MCL)
····@bway.net
============================================================
In article <·············@bway.net> ····@bway.net "Ken Tilton" writes:
> Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
> Microsoft Common Lisp?
>
> The rounding error on his interest could finance the whole thing. :)
>
> Seriously, we could get up a petition explaining why MsCL would be a
> great thing (newsgroup project) and all sign it.
I'm hoping that this will indeed someday happen. Probably after
Intentional Programming has run out of steam.
> ==========================================================
> Dear Mr. Gates,
>
> Minor premise: Bill Gates is a programmer.
> Major premise: Common Lisp is a Great Language.
> SomeLatinus OrOtherus: Bill Gates should do Visual Common Lisp.
>
> Common Lisp is garbage-collected, dynamic, introspective,
> object-oriented, exceptions-enabled, compiled and ANSI Standard.
>
> And it is not Java. :)
>
> Anyway, /I/ would love to see a Visual Common Lisp.
>
> Signed,
>
> Ken Tilton, Missing Link Software
> educational software developer (now using MCL)
> ····@bway.net
>
> ============================================================
The flaw here is that Gates is a Basic fan. He stated in Byte
many moons ago (mid 80s?) that his intention was to make Basic
a universal scripting language. He's just succeeded in doing
that, for Windows. Happily for us, he's also made it possible
for other languages to use the same technology.
Who might have predicted that Basic would make this possible?
Was it actually Basic, or the whim of a successful business man?
That's a question for histories of the 22nd century, who'll no
doubt be reading an archive of this thread, trying to understand
where it all went right/wrong (you can bet that historians will
disagree about _that_).
One thing is certainly true. Money talks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Ken Tilton (····@bway.net) wrote:
> why don't we appeal to the hacker in Bill Gates and ask him to do a
> Microsoft Common Lisp? ...get up a petition explaining why MsCL would be a
> great thing (newsgroup project) and all sign it.
MSCL is an interesting idea, but Gates probably doesn't decide anything on
the basis of anything so egalitarian as a petition. Making a case for its
viability as a business decision would be more influential. An example might
be a petition, not asking that he develop and market MSCL, but representing
people who are pretty sure they would use it if he did. Show him some
market share and maybe he'll start to drool.
Another thing that might have some influence would be to point out cases
where a business had a win by using Lisp. I remember reading one of these
recently, probably in this newsgroup, but now I don't remember what the
story was. And it may be that Gates himself is unaware that Lisp is used
within Microsoft; it couldn't hurt to point that out.
Elsewhere in this thread, somebody pointed out Gates is a Basic fan. If he
allows his own preferences to affect his business decisions, perhaps he can
be won over with features of Lisp that are remniscent of Basic. The big one
that springs to mind is instant feedback, typing something and getting an
immediate response.
If MS came out with a Visual Common Lisp, it would violently thrust Lisp
into common usage. On the one hand, it would leave in its wake a vanguard
of people wearing "I hacked Lisp before Lisp was cool" T-shirts, and many
of them would rue the loss of Lisp's status as arcana. On the other hand,
there would quickly follow the creation of all kinds of tools and libraries
to make life easier for Lisp programmers (mostly commercial of course, but
the gnu-ish stuff would continue to thrive). And the world would be made a
better place for having Lisp in a much more prominent role.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
Will Ware <·····@world.std.com> wrote in article
<··········@world.std.com>...
> If MS came out with a Visual Common Lisp, it would violently thrust Lisp
> into common usage...
Surprise, been there and done that. At the time it hardly had the effect
you wish for. -:
From Byte, Mar. 1986:
p.32A: "Microsoft languages speak for themselves."
[an eight page insert describing Microsoft C,
Macro Assembler, FORTRAN, COBOL, Pascal,
QuickBasic, muMATH, and...Microsoft LISP:]
p.32H: "LISP: The language of Artificial Intelligence."
"What's Microsoft LISP got going for you? It runs significantly faster
than the competition. And this new version adds several advanced
libraries. Over 400 Common LISP functions, macros and
special forms. Most implemented in machine code."
"If you're putting AI on your PC, Microsoft LISP is your language."
Don't hold your breath for Microsoft Visual Standard ML either.
Speaking only for myself,
Jan Gray
Redmond, WA
//www3.sympatico.ca/jsgray
In article <··························@p5-166> ······@acm.org "Jan Gray" writes:
> Surprise, been there and done that. At the time it hardly had the effect
> you wish for. -:
>
> From Byte, Mar. 1986:
> p.32A: "Microsoft languages speak for themselves."
> [an eight page insert describing Microsoft C,
> Macro Assembler, FORTRAN, COBOL, Pascal,
> QuickBasic, muMATH, and...Microsoft LISP:]
>
> p.32H: "LISP: The language of Artificial Intelligence."
>
> "What's Microsoft LISP got going for you? It runs significantly faster
> than the competition. And this new version adds several advanced
> libraries. Over 400 Common LISP functions, macros and
> special forms. Most implemented in machine code."
>
> "If you're putting AI on your PC, Microsoft LISP is your language."
Was this a Lisp that was developed in-house? I doubt it.
Just below the Lisp section of that advert is...muMath.
Perhaps my memory is deceiving me, but I recall reading
a review of muLisp in the late 70s or very early 80s
that included muMath (and muSimp, an "algol"-like parser
for muLisp). Could it be that MS acquired a later version
of muLisp?
It's not impossible for a company to buy a product from
the people who developed it, and then not understand it
well enough to know what to do with it (e.g. Borland and
ObjectVision - a great development tool waiting to be born,
or a power data entry app? Borland couldn't decide).
Perhaps MS had the same problem with Lisp. Poor marketing
of Lisp, and excellent marketing of C, C++, Basic, etc,
could've been the cause of this product failure.
The previous page tells you about MS Pascal and QuickBasic.
MS Pascal is either no longer supported, or is so poorly
supported that MS keep it a secret. Did MS give up, rather
than compete with Borland Pascal, or was it an internal
political issue?
> Don't hold your breath for Microsoft Visual Standard ML either.
> Speaking only for myself,
I won't be holding my breath, but this is mainly because
I don't believe that any particular languages is _the_ tool
to use. I merely see a language as a tool that may be used.
I leave the politics and religious wars to other people.
Note that MS put Lisp right at the end of a series of pages
about various languages, with C at the front. Lisp and muMath
share the page with...Sort. Even then, MS treated Lisp as
a low priority. If potential Lisp developers failed to buy
Lisp, I think that they can hardly be blamed. Byte readers
would've at least had some small understanding of what Lisp
was and could do, dispite the dominance of C and Basic memes
in that publications.
When Byte stopped reviewing Lisp systems, it was only a matter
of time before I stopping reading that magazine. Since then,
Byte has done even more to promote C and Basic. Dick Pountain's
column has remained, spreading the memes of higher level languages,
but it's irregular. The message is not as positive as people
here on UseNet can find.
What should we conclude from this? That MS suck? MS are way
too big to generalise with such a statement. Do MSR also suck?
That's debatable. Does Byte suck? Is that an equally fair
statement? I don't know.
It's certainly relative. UseNet gives us news of developing
tools and technology, right from the horse's mouth. A magazine
has to select news, interprete it, and then present it in a
form that hopefully its readers will understand and appreciate.
That's a difficult task. MS have another challenge, which is
too sell (some of) it to (some of) us.
Today, Byte looks to me more like a fat commercial for MS
software - not that UseNet is entirely free of such bias,
either. We're only human, after all.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
>>>>> "MR" == Cyber Surfer <············@nospam.wildcard.demon.co.uk> writes:
MR> In article <··························@p5-166> ······@acm.org "Jan Gray" writes:
>> From Byte, Mar. 1986:
>> p.32A: "Microsoft languages speak for themselves."
>> [an eight page insert describing Microsoft C,
>> Macro Assembler, FORTRAN, COBOL, Pascal,
>> QuickBasic, muMATH, and...Microsoft LISP:]
>>
>> p.32H: "LISP: The language of Artificial Intelligence."
>>
>> "What's Microsoft LISP got going for you? [ ... ]
MR> Was this a Lisp that was developed in-house? I doubt it.
No, it was done by the Soft Warehouse, a Honolulu-based company.
(Indeed the same one that did muMath and muSimp.) Cool stuff, back
then.
Cheers =8-} Mike
·····@world.std.com (Will Ware) wrote:
>MSCL is an interesting idea, but Gates probably doesn't decide anything on
>the basis of anything so egalitarian as a petition. Making a case for its
>viability as a business decision would be more influential. An example might
>be a petition, not asking that he develop and market MSCL, but representing
>people who are pretty sure they would use it if he did. Show him some
>market share and maybe he'll start to drool.
It would probably be better to get some small, dynamic company to do
the project. Then show it to Microsoft, let them rip it off or buy the
original company, and then market it.
That way it would be done right, and expensive.
-- What you accomplish today is very important --
-- You're trading a day of your life for it. --
The reply-to email address on this post is false.
To send email to me, use this address, backwards:
········@hussar
·····@world.std.com (Will Ware) writes:
>If MS came out with a Visual Common Lisp, it would violently thrust Lisp
>into common usage.
Do you really think so? Is it the belief that MS merely has to stamp
something with its brand, and it instantly becomes accessible and
popular?
I'll grant that MS has great marketing, makes savy business deals, and
tends to stick to its guns when swaying the market, but its brand name
isn't all powerful.
I'm going to flick on the wayback machine and have it set to the early
80's.
Microcomputers were coming into their own, we had a plethora of
different "home" computers, and CPM was powering the bleeding edge
micro-business solutions.
Rogue HAM radio and Model Raliroading geeks were buried in their
basements, with their heads swimming in clouds of solder smoke, trying
to get their own franken-puters Alive(!).
Memory was scarce, mass storage was rated in "minutes" rather than
megabytes. Assembly language was the gurus choice...at least until
they could get ... BASIC.
For whatever reason, the micro-cpu world grabbed hold of BASIC, in
some form, and ran off into the night laughing. Was it because Gates
and Co. did the initial port to the Altair? Making it a readily
available high-level language for anyone calling? I don't know.
I do know that in 1977, Radio Shack sold their Model I computer with
4K and BASIC (MS-BASIC I might add) in ROM. Soon after, just about
every single pre-built standalone computer being sold had BASIC of
some kind. Apple, Commodore, Exidy, Ohio Scientific, Atari...even
Sinclair.
BASIC was being used to write zillions of vertical apps on CPM
machines. And every consumer computer magazine was dedicating pages
and pages to BASIC code listings.
Oh sure, there were other languages. FORTRAN and COBOL were being
ported. I remeber fighting with TRS-80 FORTRAN, but couldn't make
heads or tails because all of the books were talking about cards
readers and tape drives. I just wanted INPUT and PRINT.
Now, how many folks do you think had their first exposure to a
computer come from a home computer running BASIC? How many of these
skilled and erudite pundits in the press came up through the ranks of
Apples and Trash-80's? How many folks do you think may consider it a
crime that W95 dropped QBASIC...finally!
PC's were the next big thing, and it brought to life a product that
was simmering on CPM machines...Turbo Pascal. Who could go wrong for
$29? And how people complained about Pascal vs BASIC.
But Borland prevailed, getting a lot of mindshare and press with Turbo
Pascal.
In its heyday, there was Turbo Pascal, some C compilers, Modula-2,
etc. Anyone know that Borland created a Turbo Modula-2? They did, but
it didn't go anywhere and was sold off. FORTH, BASIC, Methods (early
Smalltalk V), etc. Bunches of languages.
There was Computer Languages magazine, Dr. Dobbs in its prime,
everything.
Borland came out with their product "Turbo Prolog". Big Name company,
nice system, WIERD language. No doubt in the midst of the AI hype.
Borland had more Language mindshare than MS did, was MS as focusing on
applications really, and did Prolog become the great redeemer?
No.
Now, maybe the implementation had lots of problems, I don't know.
Maybe Borland was too mainstream to market Prolog effectively. Perhaps
the systems were too limited to really let Prolog spread its wings and
fly.
But for whatever reason, Turbo Prolog died a nameless death.
Right now, the only languages that any real mindshare in the computing
populace are BASIC and C. The folks that would have learned BASIC on
their home computers in the past (because it was there), are now
choosing between VB or VC++...for a first language. Can you imagine
installing VC++ and going through a book "C++ in 21 days" to learn
programming? EGADS!
The best thing that MS could do with Lisp, is turn it into a COMPILED
BATCH module alternative for their C++ development system, and bundle
it with VC++. Enabling folks to do mixed language development. Putting
it instantly into the hands of a zillion developers. Whether they use
it or not, at least they now have a "Lisp" book sitting on their
shelf...err...CD.
A standalone version of MSCL would be considered as a niche product for
niche applications, and thereby ignored by the mainstream.
The press and the people would ask "Why do we need another language?
We got C for the fast stuff, and VB for the easy stuff! Why muddy the
waters?"
I downloaded a little program that someone wrote using VC++ from the
net. It was a utility for a board game. It was about 6MB of stuff.
300K of code, and the rest DLLs. MS supplied DLLs, including the
installer. I was horrified. "C++ makes small EXEs!" Harumph!
LISP is great for poking around and programming little things. It is
good for programming "interesting programs". It handles BIG stuff
pretty well. It is rich in its vast utilities, yet simple at its core
(save for, say, CLOS :-)).
MSs blessing of something does not make it "good", it does not make it
"better". About the only think that MSs blessing does for something is
make it available, and, perhaps, cheap.
And that's what people expect from MS. They want some full color
glossies, and they want it cheap. MS can do that, Bill could probably
fund that effort from the spare change on his dresser.
Visual CL exists today, in ACLs package. Cyber Surfer would like
better connectivity to Windows stuff. I think they should offer ODBC
out of the box (on their sampler CD), along with a decent DB Sample
App. It could also use a Source Code debugger/stepper.
Do that, and then bundle it in one of those "Free CD" issues with some
reasonable magazine shouting "FREE DYNAMIC OBJECT SYSTEM INSIDE".
But, Franz doesn't have the change that Bill has. It would be rather
expensive to pull off the advertisement, trying to promote a language
that is unlike everything else.
C++ and VB are easy to like, because "everybody" likes it. Its easy to
drift into the crowd and chant "Me TOO!". Its easy for beginners and
amateurs because MOST programmers are beginners. MOST programmers know
not what they do. They don't know why they bump into the limits they
do, because most are cook book, cut and paste programmers. They don't
do this for fun. Its not really interesting, just more interesting
than being a bank clerk or an auto mechanic. They'd rather be a
computer mechanic...less dirt under the finger nails. 9 to 5
programmers. Their interests lie elsewhere.
You can be a 9 to 5 programmer in Lisp, or anything else. If you don't
care about what you're coding, they you don't care about what you're
coding in. People work because they have to, not because they want to.
People code because its their job. If they're changing languages, its
because they want a new job. "I should learn XYZ so I can be more
marketable!".
I think LISPs next area should be intruding into the realm of Power
Builder and its ilk. These "4GLs" are mostly pretty horrible little
idiot savant languages that has easy access to databases. LISP should
mosey up next to Smalltalk, put its head down, and try to break
through.
MS could do something like this, but it would be at the expense of VB.
Pushing VB is good for MS because all of MS Office now has VB,
and VB is tight with W95. So, apps written in MSVB can easily leverage
MS Office on MS Windows. Of course, you can extend MS VB with MS C++.
The whole goal of MS is to sell MS stuff, and now that they have a
hard lock down on what 99% of the users do 99% of the time on 99% of
the computers, I don't see them rocking the boat much soon.
Umm, IMHO of course.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
In article <················@netcom.com> ······@netcom.com "Will Hartung" writes:
> I do know that in 1977, Radio Shack sold their Model I computer with
> 4K and BASIC (MS-BASIC I might add) in ROM. Soon after, just about
> every single pre-built standalone computer being sold had BASIC of
> some kind. Apple, Commodore, Exidy, Ohio Scientific, Atari...even
> Sinclair.
I was one of the geeks using a TRS-80 Model I. Like many others,
I learned a lot from the mistakes made with that machine, and
the many attempts to fix them (e.g. Newdos, LDOS, and other
alternatives to the horror that was TRS-DOS).
> Oh sure, there were other languages. FORTRAN and COBOL were being
> ported. I remeber fighting with TRS-80 FORTRAN, but couldn't make
> heads or tails because all of the books were talking about cards
> readers and tape drives. I just wanted INPUT and PRINT.
I fixed that problem by creating my own I/O functions, using
the superb MACRO-80 assembler. With DOS, MS took a step backward
by giving us MASM, which has none of the power of MACRO-80.
The name is a _big_ clue to the source of its power. ;)
> Borland came out with their product "Turbo Prolog". Big Name company,
> nice system, WIERD language. No doubt in the midst of the AI hype.
They bought it from somebody else...
> Borland had more Language mindshare than MS did, was MS as focusing on
> applications really, and did Prolog become the great redeemer?
Perhaps Borland had no idea what to do with Prolog? Could be.
> Now, maybe the implementation had lots of problems, I don't know.
> Maybe Borland was too mainstream to market Prolog effectively. Perhaps
> the systems were too limited to really let Prolog spread its wings and
> fly.
Turbo Prolog was certainly criticised at the time for being
"non-standard". I think that was a little unfair.
> But for whatever reason, Turbo Prolog died a nameless death.
Actually, no it didn't! It was sold back to PDC, who still
sell it today. Check out their website, and Visual Prolog. ;)
> The best thing that MS could do with Lisp, is turn it into a COMPILED
> BATCH module alternative for their C++ development system, and bundle
> it with VC++. Enabling folks to do mixed language development. Putting
> it instantly into the hands of a zillion developers. Whether they use
> it or not, at least they now have a "Lisp" book sitting on their
> shelf...err...CD.
It would certainly have to intgrate well with their existing
tools, like VC++ and VB. That would mean being able to compile
code directly to a DLL, supporting all the wierd tricks that
MS use to make Windows run (exports, imports, C, C++ _and_ MS
style Pascal linkage), plus multi-threading (to keep the
("it can't do multi-threading, so must be crap" brigade from
killing it, as they're trying to do with VB and Delphi).
I've said all this before, and been shot down. It'll probably
happen this time, too. We have to incompatible orthodoxies
here, and MSCL would have to be acceptable to _both_ of them.
That's tough to do, but not impossible IMHO.
> I downloaded a little program that someone wrote using VC++ from the
> net. It was a utility for a board game. It was about 6MB of stuff.
> 300K of code, and the rest DLLs. MS supplied DLLs, including the
> installer. I was horrified. "C++ makes small EXEs!" Harumph!
I feel the same way. There's a lot of propaganda floating
about, and it doesn't just hurt Lisp. The difference between
Lisp and VB is that few people care whether VB is "less
efficient" than C++. There are enough people prepared to
accept the "deficiencies" of VB in order to get the software
they want within a reasonable period of time. Since a lot
of it will b built using components written in C++, there's
very little to complain about.
MSCL will have to fully support ActiveX. At the very least,
there are political reasons for this, but we can expect that
a lot of Windows developers will be less interested in a tool
that doesn't support the masses of components available.
Where would VB be today, if it didn't support VBX?
> Visual CL exists today, in ACLs package. Cyber Surfer would like
> better connectivity to Windows stuff. I think they should offer ODBC
> out of the box (on their sampler CD), along with a decent DB Sample
> App. It could also use a Source Code debugger/stepper.
Support ActiveX would be very tasty, too. This is stuff that
would appeal to staggeringly larger numbers of developers!
There are Lisps for Unix that can do impressive database things,
and perhaps some of them to it as standard, but I can't remember.
VC++ and VB come with this kind of support as standard, so MSCL
would need it, too.
> Do that, and then bundle it in one of those "Free CD" issues with some
> reasonable magazine shouting "FREE DYNAMIC OBJECT SYSTEM INSIDE".
>
> But, Franz doesn't have the change that Bill has. It would be rather
> expensive to pull off the advertisement, trying to promote a language
> that is unlike everything else.
Yes, being smaller than MS has its disadvantages.
> Umm, IMHO of course.
Likewise. ;)
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>······@netcom.com "Will Hartung" writes:
>
>> Maybe Borland was too mainstream to market Prolog effectively. Perhaps
>> the systems were too limited to really let Prolog spread its wings and
>> fly.
>
>Turbo Prolog was certainly criticised at the time for being
>"non-standard". I think that was a little unfair.
I think that criticisms of Turbo Prolog as being non-standard
were entirely fair, given that Turbo Prolog is about as similar
to standard Prolog as Java is to C++.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
In article <··········@mulga.cs.mu.OZ.AU>
···@murlibobo.cs.mu.OZ.AU "Fergus Henderson" writes:
> >Turbo Prolog was certainly criticised at the time for being
> >"non-standard". I think that was a little unfair.
>
> I think that criticisms of Turbo Prolog as being non-standard
> were entirely fair, given that Turbo Prolog is about as similar
> to standard Prolog as Java is to C++.
Yep, and how standard is VB? Conforming to a standard is no
guarantee of success, just as non-conforming is no guarantee
of failure. PDC Prolog aka Visual Prolog aka Turbo Prolog is
still available. In what way did Turbo Prolog fail? If this
is similar to VB's "failure", then I hope that it has much
more of the same!
Some of the problems of langage politics is a blind insistance
on adhering to standards. We may whinge about MS when they
ignore a standard, but if it's hurting them, it's hard to tell.
If I'm mistaken about Turbo Prolog's history, then I apologise.
I realise that you're know far more about Prolog than I do,
and probably ever will, do I'd prefer to bow to your superior
knowledge. However, what I recall of Turbo Prolog was that
it was a capable system, as capable as PDC Prolog is today.
The fact that the dialect and implementation are the same is
a minor issue for some programmers, and they're hardly a
minority. That's what gives me a few doubts.
This is one of life's great mysteries.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>···@murlibobo.cs.mu.OZ.AU "Fergus Henderson" writes:
>
>> I think that criticisms of Turbo Prolog as being non-standard
>> were entirely fair, given that Turbo Prolog is about as similar
>> to standard Prolog as Java is to C++.
>
>Yep, and how standard is VB?
Well, I haven't actually used VB, but my guess is that
it does a fair job of backwards-compatibility.
I'll bet you could find a bunch of simple programs such as
10 PRINT 'HELLO WORLD'
20 REM is it single quotes or double-quotes?
30 REM long time since I wrote any basic ;-)
40 FOR I FROM 1 TO 100
50 PRINT I
60 NEXT I
and run them in VB. Of course, taking a typical VB program
and trying to run it on anything else is a hopeless task.
Similarly, Turbo Pascal was pretty non-standard, but
you could convert standard Pascal programs to Turbo Pascal
without much difficulty. The non-standard aspect was that
it had a large number of non-standard extensions.
In constrast, Turbo Prolog had several important non-standard
features that could be construed as *restrictions*, e.g.
the requirement that everything be statically typed,
and the lack of standard builtins such as functor/3 and arg/3.
In fact, the syntaxes of Turbo Prolog and standard Prolog are entirely
non-intersecting: it is not possible to write a program which is
valid in both. The upshot of all this was that taking a
standard Prolog program and converting it to Turbo Prolog
was a quite difficult exercise, and in some cases might require
completely redesigning your program. It's probably easier to convert a
typical C++ program to Java or vice versa than to convert a Prolog
program to Turbo Prolog.
>However, what I recall of Turbo Prolog was that
>it was a capable system, as capable as PDC Prolog is today.
Turbo Prolog *was* a quite capable system, as is PDC Prolog today.
The point is that the differences in languages were so great
that calling Turbo Prolog "Prolog" was really a misnomer
invented by marketing. When people found out that Turbo
Prolog wasn't really Prolog as they knew it, and that they
couldn't use it to run their Prolog programs, they were
understandably critical.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
In article <··········@mulga.cs.mu.OZ.AU>, ···@mundook.cs.mu.OZ.AU
says...
> >Yep, and how standard is VB?
>
> Well, I haven't actually used VB, but my guess is that
> it does a fair job of backwards-compatibility.
> I'll bet you could find a bunch of simple programs such as
>
> 10 PRINT 'HELLO WORLD'
> 20 REM is it single quotes or double-quotes?
> 30 REM long time since I wrote any basic ;-)
> 40 FOR I FROM 1 TO 100
> 50 PRINT I
> 60 NEXT I
>
> and run them in VB. Of course, taking a typical VB program
> and trying to run it on anything else is a hopeless task.
Altho line numbers are rare - if ever - used in VB programs,
they're still supported. At least VB2 supported them. I don't
know about VB4.
On the other hand, there are plenty of VB features that get
used far more often than GOTO that probably won't be found in
many other Basics.
I should add that I've never seen the ANSI Basic spec, and it's
been years since I last read anything about that dialect.
> Similarly, Turbo Pascal was pretty non-standard, but
> you could convert standard Pascal programs to Turbo Pascal
> without much difficulty. The non-standard aspect was that
> it had a large number of non-standard extensions.
Turbo Pascal was in fact far more standard than MS Pascal.
When the British Standards Institute tested these two compilers,
plus Prospero Pascal, only the latter passed the validation
suite without errors. MS Pascal failed two thirds of the tests.
Not that this is likely to have killed MS Pascal. Nor do I
think that VB's comformity (or lack of of it?) to ANSI Basic
is the reason for its success.
> In constrast, Turbo Prolog had several important non-standard
> features that could be construed as *restrictions*, e.g.
> the requirement that everything be statically typed,
> and the lack of standard builtins such as functor/3 and arg/3.
This is a far more serious problem IMHO. I had doubts about
this, at the time, and I still do.
> In fact, the syntaxes of Turbo Prolog and standard Prolog are entirely
> non-intersecting: it is not possible to write a program which is
> valid in both. The upshot of all this was that taking a
> standard Prolog program and converting it to Turbo Prolog
> was a quite difficult exercise, and in some cases might require
> completely redesigning your program. It's probably easier to convert a
> typical C++ program to Java or vice versa than to convert a Prolog
> program to Turbo Prolog.
A lot of Windows programmers will be given C++ source code. This is
what you get from MSDN (the MS Developes Network). The fact that MS
support Windows with masses of examples in C/C++ doesn't help non-C/C++
languages. VB isn't as well supported by MSDN, but it has other
strengths, like the easy use of components.
I don't like seeming to argue in favour of MS tools, but if you find
yourself developing Windows software, this stuff is hard to ignore.
A little like IBM in the mainframe and mini world? Perhaps. We don't
have to like them, and our feelings are unlikely to change anything.
A significant portion of the corporate world has chosen Windows,
and C++. Whether MS embrace standards or spit on them, they won't
go away. Worse, the "Embrace, Extend, Eliminate" strategy may give
them an _edge_ of those who "play fair" and adhere to the standards.
> >However, what I recall of Turbo Prolog was that
> >it was a capable system, as capable as PDC Prolog is today.
>
> Turbo Prolog *was* a quite capable system, as is PDC Prolog today.
That's my opinion, too. I just don't know whether I'd want to use it.
If a "Visual Lisp" looked something like this, disregarding standards
in the same way, would it be so different from the way in which MS
have disregarded other standards? I can imagine them doing it and
_succeeding_. I just don't expect them to do it any time soon.
> The point is that the differences in languages were so great
> that calling Turbo Prolog "Prolog" was really a misnomer
> invented by marketing. When people found out that Turbo
> Prolog wasn't really Prolog as they knew it, and that they
> couldn't use it to run their Prolog programs, they were
> understandably critical.
Yes, the _existing_ Prolog programmers. Lack of good marketing
failed to attract programmers new to Prolog. That may be where
MS, PDC, etc have an edge. I wouldn't touch VB with a barge pole,
but that's coz I remember an earlier dialact of Basic (from MS,
BTW), and VB disregards _that_, by using DIM to define global
variables. It's also inconsistant, by using LOCAL for local vars.
I'd have expected GLOBAL, but no, they used DIM - which used to
mean DIMension an array.
Perhaps my disgust with what VB has done to Basic is similar to how
many existing Prolog programmers felt when they saw Turbo Prolog?
Someone who'd nevr seen Prolog before might've felt more positive
about it, but with the lack of education (i.e. marketing) they
were probably unlikely to appreciate it. Hence the "failure".
Of course, I could be wrong. If there are more programmers for
Windows using standard Prolog than than VB, then I might not doubt
the value of standards. I know that's an odd way to look at it,
but VB appears to be a bigger commercial success than VB, so
perhaps that's more popular than having a powerful language, like
Prolog? Visual Prolog offers the kind of features I'm looking for
in a Prolog system, and yet it has all these "problems" - just
as VB does!
So, what should I use? Most of the time, I don't really case, as long
it's not VB or C++. Even with all of its problems, Visual Prolog still
beats those two, and oddly enough, it's closer to standard Prolog than
VB and C++ will _ever_ be. That's coz VB and C++ are not Prolog...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
On Wed, 5 Feb 1997 16:41:24 -0000, Cyber Surfer wrote:
>If a "Visual Lisp" looked something like this, disregarding standards
>in the same way, would it be so different from the way in which MS
>have disregarded other standards? I can imagine them doing it and
>_succeeding_. I just don't expect them to do it any time soon.
BTW:
A product called "Visual Lisp" already exists! Wonder if they already
protected it as trademark. It's a simple AutoLISP editor by a company
called Sierra Hermitage.
see http://xarch.tu-graz.ac.at/autocad/lsp_tools/visual-lisp.html
(they have only compuserve accounts)
but this would be as i guess no major problem for the microshloft imperium.
;|Reini - All opinions expressed are probably wrong|;
With a mighty <·················@news.sime.com>,
······@buehnen-graz.com wibbled into the void...
> BTW:
> A product called "Visual Lisp" already exists! Wonder if they already
> protected it as trademark. It's a simple AutoLISP editor by a company
> called Sierra Hermitage.
I wasn't aware of that, thanks.
> see http://xarch.tu-graz.ac.at/autocad/lsp_tools/visual-lisp.html
> (they have only compuserve accounts)
>
> but this would be as i guess no major problem for the microshloft imperium.
> ;|Reini - All opinions expressed are probably wrong|;
Yes, I'm sure some arrangement could be made. ;-)
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
: >···@murlibobo.cs.mu.OZ.AU "Fergus Henderson" writes:
: >
: >> I think that criticisms of Turbo Prolog as being non-standard
: >> were entirely fair, given that Turbo Prolog is about as similar
: >> to standard Prolog as Java is to C++.
: >
: >Yep, and how standard is VB?
One more thing to note about this. I think no one trys VB because he/she
is looking for a Basic Compiler for Windows. We use it (and *I* do
myself) because it is a language suitable for writing code for Windows,
and Windows applications (Office etc.).
Basic is not something any software developer I know of, is looking for.
Prolog is. The feeatures lacking in Trubo (PDC) Prolog make its use for
Prolog tasks hard.
Since Basic lacks any unique feature that would cause you to try
programming in it (aside from ease of use, which I also would dispute),
calling something Basic doesn't cause too many programmers to use it - in
order to achieve *with ease* certain defined tasks.
This is the kind problems that arise when you try to use Trubo Prolog
for Prolog tasks.
--
Ehud Lamm ······@pluto.mscc.huji.ac.il
In <············@wildcard.demon.co.uk> Cyber Surfer (············@nospam.wildcard.demon.co.uk) wrote of times long forgotten:
: PDC Prolog aka Visual Prolog aka Turbo Prolog is
: still available. In what way did Turbo Prolog fail?
Strict typing for predicates, no type polymorphism,
very artificial way to achieve type coercion (add another predicate).
Add that to standard Prolog problem: necessity to use '!' (cut)
for any performance, which is worse than 'go to' for program logic,
and very hard to debug due to backtracking intermixed with frivolous cuts.
Scheme after that (a nice PC-Scheme from TI) was a heaven.
Talking of Prolog, why did Micro-Prolog fail (even in Prolog camp)
is more of a question.
: The fact that the dialect and implementation are the same is
: a minor issue for some programmers, and they're hardly a
: minority. That's what gives me a few doubts.
Turbo Prolog wasn't Prolog. Period. Marketing trick
at a time when AI was buzz-word du jour.
Re: Common LISP, MS or otherwise.
Besides already discussed evident reasons I'd like to look
into statistics about who uses different languages.
A table of programmers IQ averages per language, suitably normalized,
might be suprising. That is, Common Lisp is too complex for many.
Garry,
who doesn't programm his VCR and uses exclusively
C and assemblers for the last 7-8 years.
--
Garry Belka ·····@attel.com Attel Technologies San Jose, CA, USA
In article <··········@news.aimnet.com> ·····@attel.com "belka" writes:
> : PDC Prolog aka Visual Prolog aka Turbo Prolog is
> : still available. In what way did Turbo Prolog fail?
>
> Strict typing for predicates, no type polymorphism,
> very artificial way to achieve type coercion (add another predicate).
> Add that to standard Prolog problem: necessity to use '!' (cut)
> for any performance, which is worse than 'go to' for program logic,
> and very hard to debug due to backtracking intermixed with frivolous cuts.
A _technical_ failure, perhaps. However, it can and apparently
still is being used by developers. Curious...
> Scheme after that (a nice PC-Scheme from TI) was a heaven.
Ah, more language politics. Yes, I too prefer Scheme, but so
what? If that was enough to ensure the failure of a produce,
then VB would be history. Instead, it's a _major_ commercial
success. If that's your idea of "failure", then I'd lik to have
some of that!
> Talking of Prolog, why did Micro-Prolog fail (even in Prolog camp)
> is more of a question.
I know very little about Micro-Prolog, so I can't comment.
> : The fact that the dialect and implementation are the same is
> : a minor issue for some programmers, and they're hardly a
> : minority. That's what gives me a few doubts.
>
> Turbo Prolog wasn't Prolog. Period. Marketing trick
> at a time when AI was buzz-word du jour.
Tell PDC, not me. I don't give a shit. My choice of Prolog
would be LPA or perhaps Amzi. An "MS Prolog" would probably
look just like Visual Prolog does today, except that it might
be given some kiss-ass marketing to make it a killer. Not
that this is likely to happen!
> Re: Common LISP, MS or otherwise.
>
> Besides already discussed evident reasons I'd like to look
> into statistics about who uses different languages.
> A table of programmers IQ averages per language, suitably normalized,
> might be suprising. That is, Common Lisp is too complex for many.
I wonder if a "Visual Scheme" might be better? I suspect it
would be just as "difficult". Mind you, C++ can be challenging
for a great many programmers!
A good tutorial can help. I'd love to see a "Common Lisp for
C++ Programmers", or a similar book for Scheme. What we usually
get are books aimed at advanced Lisp people. I'm grateful for
the technical subjects (e.g. compiler theory) in many Lisp books,
but I'm very comfortable with subject. However, most C++ programmers
appear to feel rather differently. Either compiler theory is
being introduced very badly (perhaps C++ people should think
of it as merely a specilised area of string handling?), or
most programmers just can't cope with it. A "CL for C++ dummies"
tutorial might avoid such things, just as some of the more basic
Lisp tutorials already do.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
>I wonder if a "Visual Scheme" might be better? I suspect it
>would be just as "difficult". Mind you, C++ can be challenging
>for a great many programmers!
Of course it would be better. The problem with C++ is that it
*encourages* errors. Even cool (IMHO) features were implemented
stupidly so that in some cases, the parsers don't really handle likely
constructs properly (e.g., specifying templates for arguments in
templates -- list<dummy, allocator<dummy>> [boom!]).
Actually, from this perspective, the best (commercially) thing about
C++ is that it allows poorly debugged, poorly written and
architecturally deranged code to be marketed commercially despite
common failures, because most of the crashes wont happen at the same
time / same feature. This does wonders for tech support -- "We need
you to be able to reproduce the problem, you understand . . ." -- and
also seems to be a popular development strategy these days.
>A good tutorial can help. I'd love to see a "Common Lisp for
>C++ Programmers", or a similar book for Scheme.
If anyone knows of such a book -- written by someone who actually
knows C++ -- please! add it to the FAQ!
Followups out of comp.arch.
RSR
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://www.wam.umd.edu/~rsrodger (updated 2/2/97)
please discontinue use of ···@msn.com
············@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>> Talking of Prolog, why did Micro-Prolog fail (even in Prolog camp)
>> is more of a question.
>I know very little about Micro-Prolog, so I can't comment.
Micro-Prolog ran on Z80-class machines. The syntax was Lispish, and the
data structures were a bit Lispier than "Edinburgh" Prologs. Perhaps if
Micro-Prolog can be said to have failed, it may have been the Lispy
syntax. Micro-Prolog was originally developed for Z80-class machines,
in which area it had few if any competitors. Prolog programmers were
prepared to put up with a strange syntax if it meant they could do work
on small machines. My then supervisor Alan Bundy was very happy with it,
I recall. When larger "micros" became common, so did competitors on the
same machines, and those competitors could offer "compatible" syntax.
Expert Systems Ltd Prolog, ALS Prolog, &c. Indeed, LPA themselves were
prompt to bring out an "Edinburgh-compatible" Prolog. To this day, the
_people_ who were responsible for Micro-Prolog are still in business
selling good Prolog systems. And LPA went on do develop "added value"
products such as APES and FLEX, and found compatibility with "Edinburgh"
Prolog to be advantageous to themselves, because it meant that they could
sell the "added value" products to customers running other vendor's
Prolog systems on machines to which LPA Prolog had not yet been ported.
I don't see Micro-Prolog as having _failed_ in any way. It just came to
the end of its useful life and was replaced by new products from the same
company. LPA started earlier than Quintus and are still in the Prolog
business. If that's failure, give me some of it!
>> Turbo Prolog wasn't Prolog. Period. Marketing trick
>> at a time when AI was buzz-word du jour.
>Tell PDC, not me. I don't give a shit.
Then why do you keep on yelling that it is so a Prolog?
>I wonder if a "Visual Scheme" might be better?
The snazzy Scheme system from Rice looks to me pretty "visual".
>However, most C++ programmers
>appear to feel rather differently. Either compiler theory is
>being introduced very badly (perhaps C++ people should think
>of it as merely a specilised area of string handling?), or
>most programmers just can't cope with it.
Yow. "String handling" is the _last_ thing you should think of
in connection with compilers.
I'm supervising a student compiler project this year, for a language
in the same general class of langauges as Matlab. Prolog (or better
yet, Mercury) would be IDEAL for this. Lisp or Scheme would be lovely.
But they have to know C for the run time system of the language, so
the whole thing is going to be in C. I was even advised against asking
them to use Noweb. "They haven't time to learn a new language." *Sigh*
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
With a mighty <············@goanna.cs.rmit.edu.au>,
··@goanna.cs.rmit.edu.au wibbled into the void...
> I don't see Micro-Prolog as having _failed_ in any way. It just came to
> the end of its useful life and was replaced by new products from the same
> company. LPA started earlier than Quintus and are still in the Prolog
> business. If that's failure, give me some of it!
This matches what I've read about Micro-Prolog, in various places,
but you've given me some more details. Thanks.
> Then why do you keep on yelling that it is so a Prolog?
I'm just not convinced that incompatibilty with members of a family is
the same as not being a member of that family. Perhaps I've used too
many languages where this is so, and that Prolog is somehow unique, in
that it's possible to have members which are syntactically and
semantically incompatible, and yet one apparent member is still not a
"true" member, for something reason that nobody can adequately explain
to me.
> >I wonder if a "Visual Scheme" might be better?
>
> The snazzy Scheme system from Rice looks to me pretty "visual".
I've not seen it, but as I understand it,. Scheme systems usually use
_text_ for the source code. If you're not sure what I mean, then I'd
the comp.lang.visual FAQ (most people don't, unfortunately). I'd be
interested in _any_ Scheme for Windows, of course.
If you _do_ know what I mean by "visual", then I'd be very interested
to know how a Scheme system might visually represent (and presumably
edit) source code. I'd be even more interested in _using_ such a
system, but so far, very few general purpose visual languages are
available for the platform I'm cursed to use. The good news is that
I'm currently playing a Windows version of Prograph, and it reminds me
a lof of Lisp and various functional languages, with OOP features.
> Yow. "String handling" is the _last_ thing you should think of
> in connection with compilers.
Perhaps. However, this was the approach used in an excellent article
in Byte, on parsers. It used Prolog, BTW, showing how you can parse a
"string" (e.g. a file) into a tree, and then turn the tree back into a
string. That could (crudely) describe a great many compilers!
> I'm supervising a student compiler project this year, for a language
> in the same general class of langauges as Matlab. Prolog (or better
> yet, Mercury) would be IDEAL for this. Lisp or Scheme would be lovely.
I agree. My current favourite choice would by Haskell, but Prolog
would make writing a backtracking parser just as easy.
> But they have to know C for the run time system of the language, so
> the whole thing is going to be in C. I was even advised against asking
> them to use Noweb. "They haven't time to learn a new language." *Sigh*
I like writing simple compilers in Lisp. The only problem is that they
produce C source code, and I _hate_ doing that. It's bad enough just
coding in C, but when I code in Lisp at the same time, it lets me see
the contrast even more clearly.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·························@news.demon.co.uk>, ············@wildcard.demon.co.uk (Cyber Surfer) writes:
...deleted
>I'm just not convinced that incompatibilty with members of a family is
>the same as not being a member of that family. Perhaps I've used too
>many languages where this is so, and that Prolog is somehow unique, in
>that it's possible to have members which are syntactically and
>semantically incompatible, and yet one apparent member is still not a
>"true" member, for something reason that nobody can adequately explain
>to me.
...deleted
As Mr O'Keefe (··@goanna.cs.rmit.edu.au) has already made a very good
answer to this question re Prolog in another place I will insert it
here (if this quoute is deemed inappropriate by Mr O'Keefe I apologise,
and withdraw it):
it ceases to be USEFUL to call a language Prolog
when the cost of converting programs everyone agrees
to be Prolog (as described in Clocksin & Mellish, Sterling
& Shapiro, or the ISO standard) becomes too high.
However, I think that there are two things to distinguish between:
Families of languages (discussed by Cyber Surfer?)
Dialects of languages (discussed by Mr O'Keefe?)
A family (like the Lisp family) can contain Scheme, MacLisp, Common Lisp, xxx
A dialect of Scheme would be ELK, MacGambit, yyy
To be syntactically and semantically incompatible inside a family is ok,
almost given, since it is ideas/concepts (not implementations) that
creates the family.
But to be syntactically and semantically incompatible towards a
language, but still be a dialect, no I don't think that is possible.
So, is Prolog a language, or a family of languages?
--
Best Wishes, Bengt
--------------------------------------------------------------------
Email: ·············@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
the direction of that applied rotation is all downhill.'' ······@netreach.net
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>I'm just not convinced that incompatibilty with members of a family is
>the same as not being a member of that family.
Let me see if I can clarify this.
Are we agreed that Algol 60, Simula 67, Algol W, Pascal, and PL/I are
all members of an "Algol family"? (By the way, I would tend to place
Turbo Prolog in _this_ family rather than the Prolog family, but that's
not my current.) I never had the chance to _write_ any Algol W, but I
read a book full of it once. My impression is that
Algol 60 -> Algol W *usually* straightforward
Algol W -> PL/I *usually* straightforward
Pascal -> Algol W doable
Pascal -> PL/I *usually* straightforward
others -> Pascal *usually* very painful
Now there is no question of direct compatibility here. For example,
Algol 60 does *not* require declaration before use, does *not* require
procedure parameters to be declared, *does* have some hairy label stuff,
and *does* have arrays with run-time bounds. In fact, the absence of
run-time bounds from (old) Pascal (the current Pascal standard includes
them in the same way as Ada) is probably _the_ major problem in adapting.
Converting in the "usually straightforward" directions is largely
mechanical, and for the most part *local*. (There is someone in this
department who promotes PL/I at every opportunity, and when you look
at C, which is what most people are using instead, you can see why he
thinks of PL/I as a better language.)
Anyway, would anyone seriously deny that these languages are closely
related? Not me.
On the other hand, would anyone in his or her right mind tolerate
calling PL/I "Algol 64"? Or for a more apt comparison, would anyone
tolerate calling Pascal "PL/I version 2"?
The point is, the people who you have been arguing against were never
denying that there was _some_ relationship between Prolog and Turbo `Prolog',
only that in observed reality, the name did in fact suggest a _far stronger_
relationship between the two languages than actually obtains. NOBODY has
denied that Turbo Prolog is a member of the "LOGIC PROGRAMMING family"
(think: genus), only that it is a member of the "Prolog clan" (think: species,
or perhaps even subspecies).
>Perhaps I've used too
>many languages where this is so, and that Prolog is somehow unique, in
>that it's possible to have members which are syntactically and
>semantically incompatible, and yet one apparent member is still not a
>"true" member, for something reason that nobody can adequately explain
>to me.
It has been explained OVER AND OVER AND OVER.
Nobody denies that Turbo `Prolog' and Prolog are both members of *some*
family of programming languages, just as Fortran, Algol 60/W/68, Pascal,
PL/I, and Ada are all members of *some* family of programming languages.
There is a "Fortran" family of languages which are to a large extent
upwards compatible, just as there is a "Prolog" family of languages
which are largely mutually compatible. The thing is, you insist on
using "Prolog" to refer to the family of logic programming languages,
which is a lot like insisting on using "Fortran" to refer to the family
of imperative procedural programming languages. If you ordered a
"Fortran" compiler from someone, and received a Pascal compiler, you
would be seriously unhappy. In the same way, and for the same reason,
some people who ordered a "Prolog" compiler from Borland and got a
"Turbo Prolog" compiler were seriously unhappy.
The key point is the *cost* of moving between one member of a "family"
and another. You can move most Algol W programs to PL/I using _local_
transformations. You cannot move Prolog programs to Turbo Prolog using
_local_ transformations.
(For what it's worth, I expect to be able to routinely move Fortran 77 code
to Ada using _local_ transformations, except for I/O formatting. It's
"tedious rather than difficulty" to use one of my pet phrases.)
As far as I am concerned, there is no _theoretical_ point here of the
kind that Cyber Surfer is demanding. It is simply that the differences
between Turbo Prolog and Prolog have crossed the threshold where if you
have an existing body of code, it is cheaper to buy a "Professional
Prolog" from _any_ other vendor than to use a _free_ copy of Turbo Prolog.
Let's take an example from the past.
Suppose a University had a B6700, which came with a "Burroughs Algol"
compiler. Suppose they had a choice of
a. converting 100 000 lines of IBM Algol to Burroughs Algol
b. modifying the B6700 compiler to accept IBM Algol
+ writing new runtime routines for it
c. buying in an "IBM Algol" compiler + runtime for the B6700.
d. Convert to PL/I at the source end, and use PL/I on the B6700.
e. Rewrite the program from scratch.
Let's imagine that a programmer's time cost NZ$100/day.
a. I'd have started by writing a SNOBOL program to to 99% of the translation.
Estimated effort to write and test that program: 5 days.
Estimated effort to do the rest of the translation: 15 days.
(I'm including reasonably thorough testing.)
Total cost: $2000.
b. The sources of the Burroughs Extended Algol compiler were available,
and very readable. Lots of people outside Burroughs modified it.
However, the B6700 compiler was strict one pass, so handling "full"
Algol would require major changes. Lexical analysis would be easy
to change. I would estimate 60 days minimum.
Cost: $6000.
c. I never saw any such compiler for sale. The market would have been
small. The price would probably have been high.
Cost: $10 000?
d. Do 98% of the work with SNOBOL on the IBM machine.
Fix and test the translation on the IBM machine.
Test the translation again on the B6700 (different arithmetic).
Estimated cost: $3000.
Advantage: original and translation can be compared on the SAME
machine.
e. Estimated cost: $50 000.
By the cost criterion, "IBM Algol" and "Burroughs Algol" are _close_
members of the "Algol family", while PL/I is further from them both.
"Dialect" conversion is clearly the cheapest approach; very much
cheaper than a rewrite, cheaper than buying or building a compiler,
and cheaper than going via a related but different language.
_This_ is the kind of analysis I have in mind. There is nothing hidden,
esoteric, unusual, or in any way mysterious about it. Sometimes changes
in quantity _do_ amount to changes in quality, sometimes they don't.
IBM Algol and Burroughs Algol were close enough to be regarded as
dialects of a common language, because it was cheap enough to *ACT* on
that belief. Turbo `Prolog' and Prolog were *not* close enough to be
regarded as dialects of a common language, because it was *expensive*
to *ACT* on that belief.
Of *course* if you are developing new code, this criterion does not
apply, and the people who are successfully and happily using Turbo/PDC/Visual
Prolog are precisely the ones who were not trying to port existing
applications but were developing *new* DOS applications.
>> >I wonder if a "Visual Scheme" might be better?'
>>
>> The snazzy Scheme system from Rice looks to me pretty "visual".
>I've not seen it, but as I understand it,. Scheme systems usually use
>_text_ for the source code. If you're not sure what I mean, then I'd
>the comp.lang.visual FAQ (most people don't, unfortunately). I'd be
>interested in _any_ Scheme for Windows, of course.
Ah. I'm aware of visual programming languages, but since Visual C++
is nothing of the kind, I wasn't sure what you meant. Scheme systems
use _trees_ for the source code, and just how that is obtained is a
matter of indifference. The Scheme from Rice _does_ work on Windows,
and it has the graphics toolkit from which a visual Scheme-based
language might be built.
>> Yow. "String handling" is the _last_ thing you should think of
>> in connection with compilers.
>Perhaps. However, this was the approach used in an excellent article
>in Byte, on parsers. It used Prolog, BTW, showing how you can parse a
>"string" (e.g. a file) into a tree, and then turn the tree back into a
>string. That could (crudely) describe a great many compilers!
But the guts of what happens in a modern compiler concerns the manipulation
of graphs and sets. Your goal is to get _away_ from strings as fast as
possible and _stay_ away from them as long as possible.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
With a mighty <············@goanna.cs.rmit.edu.au>,
··@goanna.cs.rmit.edu.au wibbled into the void...
> Now there is no question of direct compatibility here.
I didn't say there was, nor did I say there should be.
> Anyway, would anyone seriously deny that these languages are closely
> related? Not me.
We're _agreeing_ about this.
> The point is, the people who you have been arguing against were never
> denying that there was _some_ relationship between Prolog and Turbo `Prolog',
> only that in observed reality, the name did in fact suggest a _far stronger_
> relationship between the two languages than actually obtains. NOBODY has
> denied that Turbo Prolog is a member of the "LOGIC PROGRAMMING family"
> (think: genus), only that it is a member of the "Prolog clan" (think: species,
> or perhaps even subspecies).
That's exactly what I've been saying all along. The confusion may have
come from the use of a name to refer to both a language and a language
family. This is a common practice. Even the name "Pascal" is assumed
to refer to a single language, when it is in fact a family of dialects
that more or less share a common subset. This appears to be how the
name Prolog is used in the Prolog FAQ.
> Nobody denies that Turbo `Prolog' and Prolog are both members of *some*
> family of programming languages, just as Fortran, Algol 60/W/68, Pascal,
> PL/I, and Ada are all members of *some* family of programming languages.
Check the Prolog FAQ, as it includes PDC Prolog without suggesting
that PDC Prolog is _not_ Prolog. It merely makes a reference to the
typing used in PDC Prolog.
> The key point is the *cost* of moving between one member of a "family"
> and another. You can move most Algol W programs to PL/I using _local_
> transformations. You cannot move Prolog programs to Turbo Prolog using
> _local_ transformations.
I don't see how the cost of moving code from one language or language
dialect to another defines what is or is not Prolog. The cost may be
significant to programmers wishing to avoid dependancies on one
implementation, but if that was enough for a language definition, then
we might just as easily say that VC++ is not C++, simply because most
code written with VC++ will be substantially non-standard. The sad
truth is not that very few programmers using VC++ will care, even if
they do understand what you're saying.
Richard, you seem to be missing an important point here, dispite
the number of times I've made it, which is that not all programmers
will need to move code from one compiler to another. For a platform
like Windows, there may even be more important issues, like what kind
of OS support is provided, how well the IDE supports ActiveX
tools, etc.
> As far as I am concerned, there is no _theoretical_ point here of the
> kind that Cyber Surfer is demanding. It is simply that the differences
> between Turbo Prolog and Prolog have crossed the threshold where if you
> have an existing body of code, it is cheaper to buy a "Professional
> Prolog" from _any_ other vendor than to use a _free_ copy of Turbo Prolog.
Unless that "Professional Prolog" fails to support some important
platform dependant feature that you need. This is just one reason why
VC++ is more popular for Windows development than, say GNU C++. It's
not because of any failing of the compiler itself to support the
language - it just doesn't provide all the extras that allows it to
compete in terms of rapid Windows development. There's nothing unique
about Prolog that makes it an exception to this, apart from the fact
that most Windows developers probably don't even know that Prolog
exists, never mind that compilers are available for Windows.
I think that we agree on a lot of things discussed here, but we may
disagree about the significance of code compatibility. If you can't
afford more than one compiler, if you need to add all that cosmetic
GUI features to your apps, and if you have to get it done _yesterday_,
then code compatibility be as critical. It might not even be your
problem! I know this is an unprofessional attitude, but it can be
found here and there. It could be the price of the high demand for
productive programmers, or the poor understanding that some managers
have for development issues.
All I know is that I've yet to find a good argument against a Windows
developer using PDC Prolog, instead of a more standard Prolog. This is
why I mentioned VC++ vs GNU C++ above. If porting code was more
important than using platform dependant features, then I wouldn't
hesitate to choose GNU C++.
This should tell you a lot about the state of Windows software...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
[comp.arch removed]
* Cyber Surfer
| Some of the problems of langage politics is a blind insistance on
| adhering to standards.
adhering, yes; blind, no.
language standards are specifications to which implementors (vendors) are
held responsible. without such specifications, implementors would seek to
implement anything they wanted that seemed useful, and thus making the
_language_ less reliable and less useful. I'm a language guy, and so to me
the stability of a language is directly related to how much I dare express
in that language. if I were an "app" guy, I would probably be interested
more in how much I _could_ express in a language to "get some work done".
put another way, I ask what an expression in a language means, and if I
worry about what an expression _does_, it is only because what it means is
not sufficiently well-defined for me to trust it. I believe the Sapir-Worf
hypothesis that languages determine what we can think about, and I worry
that if language loses meaning and instead is redefined in terms of actions
or operations, we lose sight of the main value of languages: abstraction.
however, Microsoft (and others) does not seem to think that specifications
are at all useful until long after the fact. many programmers think
specifications are a drag, and try to avoid them. by requiring that a
vendor adhere to the specifications for what they say they are selling, we
do nothing more than is already required in any other industry. it is when
we accept that a vendor can produce anything it wants and push changes on
its customers with impunity that we do make serious departures from
established practice in good engineering. I don't think this merits a
label like "blind adherence".
unfortunately, standards are themselves political vehicles, and whether a
standard is good or bad depends on many factors. however, when a standard
is no good, you don't see very many people adhere to it, although you may
still find parts of the corporate culture buying very expensive hype, in
blatant disrespect for technical expertise. this is symptomatic of the way
standards are treated -- decisions are made by non-technical people who are
more interested in pecuniary matters than either technical or human.
I found http://www.javasoft.com/people/jag/StandardsPhases/index.html to be
a succinct summary of the many thoughts I have also made during the 5 years
I worked with ISO standardization (1991-1996). I grew to hate the
political nonsense and the growing desire for ISO to push uniqueness the
way commercial entities do to attract customers. instead of serving the
technical communities, ISO has changed its focus to serve the marketing
departments, with the attendant lack of interest in technical problems.
ideally, Working Groups should be working groups, and the political stuff
should not take place until after the drafts and recommendations reached
Sub-Committee (or Technical Committee, where the WG or Special WG is
directly under the TC) level. however, to an increasing degree, vendors
send political representatives to WG meetings who don't contribute with
technical expertise, but rather block progress for non-technical reasons.
or they make political "demands" instead of presenting their case in such a
way as to encourage others to follow. ideally, a working group should only
vote for technical reasons, not for political reasons.
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> directly under the TC) level. however, to an increasing degree, vendors
> send political representatives to WG meetings who don't contribute with
> technical expertise, but rather block progress for non-technical reasons.
> or they make political "demands" instead of presenting their case in such a
> way as to encourage others to follow. ideally, a working group should only
> vote for technical reasons, not for political reasons.
You've said a lot here that I agree with. Alas, I see no
evidence that things are otherwise.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <··········@news.aimnet.com> ·····@gral.attel.com (belka) writes:
>Re: Common LISP, MS or otherwise.
>
>Besides already discussed evident reasons I'd like to look
>into statistics about who uses different languages.
>A table of programmers IQ averages per language, suitably normalized,
>might be suprising. That is, Common Lisp is too complex for many.
Are you saying that if statistics showed that CL programmers were
smarter, you would therefore conclude that CL was harder?
Fergus Henderson (···@murlibobo.cs.mu.OZ.AU) wrote:
: ············@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
: >Turbo Prolog was certainly criticised at the time for being
: >"non-standard". I think that was a little unfair.
: I think that criticisms of Turbo Prolog as being non-standard
: were entirely fair, given that Turbo Prolog is about as similar
: to standard Prolog as Java is to C++.
As someone who started programming Prolog on Turbo Prolog, I feel I have
to testify that one can not learn Prolog from Turbo Prolog since they are
different lanaguages.
The real fact is that even though Turbo Prlog is a nice system, it lacks
so many Prolog features, making lack most of Prolog strength.
First time I head of a DCG (that the grammer extension that let's you
write parsers quick) - first Turbo Prolog frustration.
First time I heard of setof/3 - another point down against Turbo.
And so the list grew.
Result was I decided Turbo Prolog is a nice language for writing quick
applications, that use Prolog as a smart database; but that when you need
to use some of Prolog 's best features you should look elsewhere.
I still feel that way.
You can program Turbo Prolog for years - and not know what Prolog is.
Sad but true.
--
Ehud Lamm ······@pluto.mscc.huji.ac.il
With a mighty <··········@news.huji.ac.il>,
······@pluto.mscc.huji.ac.il wibbled into the void...
> Fergus Henderson (···@murlibobo.cs.mu.OZ.AU) wrote:
> : ············@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>
> : >Turbo Prolog was certainly criticised at the time for being
> : >"non-standard". I think that was a little unfair.
>
> : I think that criticisms of Turbo Prolog as being non-standard
> : were entirely fair, given that Turbo Prolog is about as similar
> : to standard Prolog as Java is to C++.
>
>
> As someone who started programming Prolog on Turbo Prolog, I feel I have
> to testify that one can not learn Prolog from Turbo Prolog since they are
> different lanaguages.
>
> The real fact is that even though Turbo Prlog is a nice system, it lacks
> so many Prolog features, making lack most of Prolog strength.
>
> You can program Turbo Prolog for years - and not know what Prolog is.
This is my point. You can still use it! It may be "wrong", but doesn't
stop everyone.
> Sad but true.
Agreed. I wish it could be otherwise, but alas, language standards
are not laws, and the means by which they're enforced are considerably
different. Not necessarily weaker, but certainly different. If they're
not powerful enough to either stop programmers from using PDC Prolog, or
to encourage PDC to make their Prolog more standard, then I believe that
this is unfortunate.
I wouldn't be suprised if PDC feel differently...but I'd be a lot happier
if they feel the same way that we do. If that's the case, then we should
asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
non-standard as it is, and yet continues to sell.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>······@pluto.mscc.huji.ac.il wibbled into the void...
>> Fergus Henderson (···@murlibobo.cs.mu.OZ.AU) wrote:
>> : I think that criticisms of Turbo Prolog as being non-standard
>> : were entirely fair, given that Turbo Prolog is about as similar
>> : to standard Prolog as Java is to C++.
>>
>> As someone who started programming Prolog on Turbo Prolog, I feel I have
>> to testify that one can not learn Prolog from Turbo Prolog since they are
>> different lanaguages.
[...]
>> You can program Turbo Prolog for years - and not know what Prolog is.
>
>This is my point. You can still use it! It may be "wrong", but doesn't
>stop everyone.
Sure. Using Turbo Prolog is not wrong. Calling it Prolog is wrong.
>> Sad but true.
>
>Agreed. I wish it could be otherwise, but alas, language standards
>are not laws, and the means by which they're enforced are considerably
>different. Not necessarily weaker, but certainly different. If they're
>not powerful enough to either stop programmers from using PDC Prolog, or
>to encourage PDC to make their Prolog more standard, then I believe that
>this is unfortunate.
I don't think that it is sad that Turbo Prolog is different from
Prolog. I'm quite happy with variety in the logic programming
community. I don't think PDC should change their product to conform to
the ISO Prolog standard. I just think it is entirely misleading
advertising to name it "Prolog".
The very idea that PDC should "make their Prolog more standard"
is premised on a fundamental misunderstanding, namely that PDC
have a Prolog. They don't. PDC couldn't possibly make Turbo
Prolog standard. The only way PDC could produce an ISO Prolog
conforming product would be to start again virtually from scratch.
Asking PDC to make their Prolog more standard is like asking
someone to make their Fortran compiler conform to the C standard.
(Except that Fortran is probably closer to C than PDC Prolog is
to Prolog.)
>If that's the case, then we should
>asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
>non-standard as it is, and yet continues to sell.
It continues to sell because it is a useful programming language.
Again, your comment seems to be premised on a fundamental misunderstanding.
It is like asking why someone's Fortran compiler continues to sell,
even though it's not C. The reason is because they are different
languages.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <··········@mulga.cs.mu.OZ.AU>,
···@murlibobo.cs.mu.OZ.AU wibbled into the void...
> >This is my point. You can still use it! It may be "wrong", but doesn't
> >stop everyone.
>
> Sure. Using Turbo Prolog is not wrong. Calling it Prolog is wrong.
This is the same argument that I'd use to claim that VB is neither
"Visual" nor "Basic". Sadly, it's unlikely to influence MS. Regardless
of what we call a produce, the vendor will call it whatever they please,
and people will use it. My point is that PDC Prolog aka Visual Prolog
is being used.
We may quible over a minor point, like what language _dialect_ a product
implements, but my guess it is that Visual Prolog is far closer to
what you call Prolog than VB or VC++ will _ever_ be.
> I don't think that it is sad that Turbo Prolog is different from
> Prolog. I'm quite happy with variety in the logic programming
> community. I don't think PDC should change their product to conform to
> the ISO Prolog standard. I just think it is entirely misleading
> advertising to name it "Prolog".
Well, tell 'em, then! And maybe I'll tell MS that they should change
Visual Basic's name, too. Hmm, Form Basic?
> The very idea that PDC should "make their Prolog more standard"
> is premised on a fundamental misunderstanding, namely that PDC
> have a Prolog. They don't. PDC couldn't possibly make Turbo
> Prolog standard. The only way PDC could produce an ISO Prolog
> conforming product would be to start again virtually from scratch.
You're assuming that everyone wants an ISO Prolog. A lot of people just
want a development tool. Visual Prolog looks like it has excellent
Windows support, in the sense that it uses an IDE with a form designer,
toolbar and menu support, etc. Some developers will be more concerned
about that than compatibility with a language standard. Perhaps enough to
sustain a market for a product like Visual Prolog.
> Asking PDC to make their Prolog more standard is like asking
> someone to make their Fortran compiler conform to the C standard.
> (Except that Fortran is probably closer to C than PDC Prolog is
> to Prolog.)
NO, I strongly disagree here. C and Fortran appear to me to differ more
than Visual Prolog differs from standard Prolog. The differences may be
_important_, but that's not the same thing. The ISO Prolog committee may
define ISO Prolog, but I don't feel they can decide what is and is not
_Prolog_, the family of Prolog dialects. Visual Prolog is close enough to
members of this family for me to call it Prolog, while C and Fortran are
very distant. When we look at these languages and Prolog dialects
together, Visual Prolog is not so different from other Prologs.
Let's call them distant cousins, and call C and Fortran completely
different species, rather than relatives to _any_ Prolog.
> >If that's the case, then we should
> >asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
> >non-standard as it is, and yet continues to sell.
>
> It continues to sell because it is a useful programming language.
> Again, your comment seems to be premised on a fundamental misunderstanding.
> It is like asking why someone's Fortran compiler continues to sell,
> even though it's not C. The reason is because they are different
> languages.
IMHO it's more likely that not enough people care about language purity.
Hence VB, VC++, and other atrocities. Perhaps the people who sell Visual
Prolog aren't as concerned about such things as yourself? I guess so.
So, complain to PDC. Perhaps they'll listen and do something about it.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>···@murlibobo.cs.mu.OZ.AU wibbled into the void...
>
>> >This is my point. You can still use it! It may be "wrong", but doesn't
>> >stop everyone.
>>
>> Sure. Using Turbo Prolog is not wrong. Calling it Prolog is wrong.
>
>This is the same argument that I'd use to claim that VB is neither
>"Visual" nor "Basic".
But VB works fine for
10 PRINT "HELLO WORLD"
and many other "standard" BASIC programs. Why shouldn't they call it BASIC?
I have disagreement with people calling a *superset* of BASIC "BASIC".
But Visual Prolog is not a superset of Prolog (in fact, it's not even
a subset either).
>We may quible over a minor point, like what language _dialect_ a product
>implements, but my guess it is that Visual Prolog is far closer to
>what you call Prolog than VB or VC++ will _ever_ be.
Sure. But the differences between Visual Prolog and Prolog are more
than dialect issues. They're fundamental ones.
>> The very idea that PDC should "make their Prolog more standard"
>> is premised on a fundamental misunderstanding, namely that PDC
>> have a Prolog. They don't. PDC couldn't possibly make Turbo
>> Prolog standard. The only way PDC could produce an ISO Prolog
>> conforming product would be to start again virtually from scratch.
>
>You're assuming that everyone wants an ISO Prolog.
No, I'm certainly _not_ assuming that. You must have misunderstood
something.
>> Asking PDC to make their Prolog more standard is like asking
>> someone to make their Fortran compiler conform to the C standard.
>> (Except that Fortran is probably closer to C than PDC Prolog is
>> to Prolog.)
>
>NO, I strongly disagree here. C and Fortran appear to me to differ more
>than Visual Prolog differs from standard Prolog.
Let's see:
VP -> Prolog Fortran -> C
Syntax: Small-to-medium differences Very big differences
Type system: Huge differences Small-to-medium differences
Underlying operational semantics:
Similar Similar
Features to add:
Garbage collection dynamic memory allocation
Preprocessing (term_expansion) C preprocessor
User-defined operators
DCGs
Pointers
Bitfields
functor, arg, univ
higher-order stuff (call)
meta-programming stuff
(clause, assert, retract)
Exception handling
So the differences between VP and Prolog seem to me to be at least as
great as the differences in Fortran and C. Perhaps you are placing too
much emphasis on the syntax, which is about the only aspect where
C differs from Fortran more than Prolog differs from VP.
>The differences may be
>_important_, but that's not the same thing. The ISO Prolog committee may
>define ISO Prolog, but I don't feel they can decide what is and is not
>_Prolog_, the family of Prolog dialects.
Sure. I agree. There's plenty of non-ISO-conforming systems that I
would quite hapily call "Prolog".
But the differences between Turbo Prolog and Prolog are large enough,
IMHO, that Turbo Prolog is a different language, not just a dialect.
>Visual Prolog is close enough to
>members of this family for me to call it Prolog, while C and Fortran are
>very distant. When we look at these languages and Prolog dialects
>together, Visual Prolog is not so different from other Prologs.
Turbo Prolog and Prolog are both logic programming languages.
Fortran and C are both imperative languages.
>Let's call them distant cousins,
I'll be happy to call Visual Prolog and Prolog cousins, if you'll
call C and Fortran cousins.
But I wouldn't call Fortran C.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <··········@mulga.cs.mu.OZ.AU>,
···@murlibobo.cs.mu.OZ.AU wibbled into the void...
> But VB works fine for
>
> 10 PRINT "HELLO WORLD"
>
> and many other "standard" BASIC programs. Why shouldn't they call it BASIC?
> I have disagreement with people calling a *superset* of BASIC "BASIC".
VB deviates from the language that I remember as Basic, a language that
used DIM to dimension arrays instead of declare global variables. VB is
still a dialect of Basic, regardless of such issues.
> But Visual Prolog is not a superset of Prolog (in fact, it's not even
> a subset either).
Is Scheme a subset of CL? I think not. It may be that there are some
features not found in Scheme, but present in CL, but as another thread
not a million newsgroups from here has shown, Scheme and CL are Lisp
dialects that bother offer features not found in the other, and not
easy to implement in the other.
I think that the superset/subset issue is an interesting one, but not
enough to convince me that Visual Prolog is not a _dialect_ of Prolog.
It may be a non-standard dialect, but I can live with that, just as
I can live with all the non-standard Lisps.
> >We may quible over a minor point, like what language _dialect_ a product
> >implements, but my guess it is that Visual Prolog is far closer to
> >what you call Prolog than VB or VC++ will _ever_ be.
>
> Sure. But the differences between Visual Prolog and Prolog are more
> than dialect issues. They're fundamental ones.
So you say. I say the same thing about VB, but I don't expect anyone
to take any notice. With Basic, it seems (or has done, in the past) that
there are as many dialects as implementations. I've been lead to believe
(by a number of Prolog books, and other sources of information) that
Prolog implementations are often unique dialects, but most of them
have a common subset. The exceptions to have included Prolog dialects
like Prolog II and Prolog III. Do you seen these languages as Prolog, or
do you claim that these too are not Prolog?
How far to we take language purity?
> >You're assuming that everyone wants an ISO Prolog.
>
> No, I'm certainly _not_ assuming that. You must have misunderstood
> something.
I wonder what that might have been. If you can explain to me at what
point a language ceases to be Prolog, then I'd greatly appreciate it.
I've been puzzled by this question for years.
> So the differences between VP and Prolog seem to me to be at least as
> great as the differences in Fortran and C. Perhaps you are placing too
> much emphasis on the syntax, which is about the only aspect where
> C differs from Fortran more than Prolog differs from VP.
How did you quantify the language differences? This is the same argument
that I use to claim that VB is not Basic, nor is it visual, so I have an
interest in how this may be done, plus how large numbers of people may be
pursuaded by your argument.
> >The differences may be
> >_important_, but that's not the same thing. The ISO Prolog committee may
> >define ISO Prolog, but I don't feel they can decide what is and is not
> >_Prolog_, the family of Prolog dialects.
>
> Sure. I agree. There's plenty of non-ISO-conforming systems that I
> would quite hapily call "Prolog".
Then this could be purely subjective, could it not? We would need to show
some objective evidence, to strongly support a claim that a compiler is
not an implementation of a language that is a member of the languages
called Prolog.
> But the differences between Turbo Prolog and Prolog are large enough,
> IMHO, that Turbo Prolog is a different language, not just a dialect.
Fair enough, I'll accept that this is your opinion. I remain unconvinced,
but that be due to seeing to many abuses of languages over the 15 or
more years that I've been programming. Some of this abuses were performed
by people who were (rightly) more concerned with getting a job done, and
creating a tool to help them do that. I'm not sure if that makes the
abuses forgivable, of course.
> Turbo Prolog and Prolog are both logic programming languages.
> Fortran and C are both imperative languages.
This is my point! PD Prolog and the familiy of Prolog dialects share
enough distingishing features, IMHO, that I'm happy to call PDC Prolog
a member of that family. It may be an illegitimate child, but I don't
feel that this is important. You may feel differently, and it appears
that you do. Fair enough.
> >Let's call them distant cousins,
>
> I'll be happy to call Visual Prolog and Prolog cousins, if you'll
> call C and Fortran cousins.
I most certainly am. ;-) In-breed, of course.
> But I wouldn't call Fortran C.
Neither would I. However, Ido frequently refer to C and C++ as "C", which
may be stretching the truth a little, but a lot of people will know what
I mean. I don't feel that the differences are important, as I dislike
them equally. In the same way, I feel that both Scheme and CL are Lisp,
and I like them equally.
My question still remains: who will stop PDC from calling their product
Prolog? Nobody, I suspect. So, this could be a non-issue. IMHO the only
issue is whether or not a tool can do what is claimed for it or not,
whether or not it can do what a developer demands from it, and whether or
not it will continue to be available in the future. That's where the
degree of compatibility with other compilers can matter.
If you use a language for teaching, then the name might be significant,
but I can't comment on that, nor I can I feel any great concern about it.
I'd love there to be more Prolog programmers, and I wouldn't wish to tie
their education to the product of any single vendor, but that's the full
extent of my concern for this issue.
I guess that's coz I'm more interested in general, language independant,
programming skills, and coz I've seen little evidence of that in the
C/C++ code that I see a lot of. Apart from what I write myself, that is.
The question of which language to use and what to call it seems pretty
silly to me, when there're so many bigger issues to worry about.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: William Clodius
Subject: Re: Microsoft Common Lisp?
Date:
Message-ID: <32FE4841.794B@lanl.gov>
Minor quibles:
Modern Fortran has dynamic memory, something it calls pointers (they are
actually descriptors which may carry array shape information), and bit
manipulation routines that provide most of the functionality of
bitfields. It doesn't have a language defined preprocessor, but many
people use the C preprocessor anyway, (which can be a problem if, for
instance, the preprocessor thinks that // starts a C++ comment). The
standards bodies currently are trying to decide whether or not to add a
simple conditional compilation mechanism, or something cpp based which
is more aware of Fortran syntax. In those terms C and Fortran are even
more comparable than Fergus implies.
However Fortran 90 does have a more sophisticated type system than C,
less low level operational semantics, and a far more sophisticated
notion of array.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>So you say. I say the same thing about VB, but I don't expect anyone
>to take any notice. With Basic, it seems (or has done, in the past) that
>there are as many dialects as implementations. I've been lead to believe
>(by a number of Prolog books, and other sources of information) that
>Prolog implementations are often unique dialects, but most of them
>have a common subset. The exceptions to have included Prolog dialects
>like Prolog II and Prolog III. Do you seen these languages as Prolog, or
>do you claim that these too are not Prolog?
I don't actually know a lot of details about Prolog II and Prolog II,
but from what little I have heard, I'd call them Prolog.
>> >You're assuming that everyone wants an ISO Prolog.
>>
>> No, I'm certainly _not_ assuming that. You must have misunderstood
>> something.
>
>I wonder what that might have been.
Well, I didn't say anything about what people _want_. I was talking
about what is or is not Prolog, not about whether people want it.
>If you can explain to me at what
>point a language ceases to be Prolog, then I'd greatly appreciate it.
>I've been puzzled by this question for years.
Well, obviously it's a fuzzy border. You could certainly image a lot
of borderline cases. But Visual Prolog is clearly on the other side of
the border, IMHO.
>> So the differences between VP and Prolog seem to me to be at least as
>> great as the differences in Fortran and C. Perhaps you are placing too
>> much emphasis on the syntax, which is about the only aspect where
>> C differs from Fortran more than Prolog differs from VP.
>
>How did you quantify the language differences?
Using the best tool for reasoning with fuzzy logic known to date --
a human brain ;-)
But you saw the table comparing TurboProlog->Prolog with Fortran->C
in my previous post, didn't you?
>Then this could be purely subjective, could it not?
It's not _purely_ subjective, but yes there are subjective aspects.
>We would need to show
>some objective evidence, to strongly support a claim that a compiler is
>not an implementation of a language that is a member of the languages
>called Prolog.
Well, one particularly strong piece of completely objective evidence is
that the intersection of the set of legal Turbo Prolog programs and the
set of legal Prolog programs is empty.
There are lots of other pieces of evidence which may not be completely
objective but which are nevertheless real -- I listed some of those
in the feature comparison table.
>> Turbo Prolog and Prolog are both logic programming languages.
>> Fortran and C are both imperative languages.
>
>This is my point! PD Prolog and the familiy of Prolog dialects share
>enough distingishing features, IMHO, that I'm happy to call PDC Prolog
>a member of that family.
But the name of the family is "logic programming", not "Prolog".
"Prolog" is the name of a particular language and it's dialects,
and Turbo Prolog is no closer to Prolog than Fortran is to C.
>The question of which language to use and what to call it seems pretty
>silly to me, when there're so many bigger issues to worry about.
I think the question of which language to use can make a lot of
difference, but yes I certainly agree that the question of what to
call it is not a big issue. (Usenet bandwidth is not proportional
to importance ;-)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <··········@mulga.cs.mu.OZ.AU>,
···@mundook.cs.mu.OZ.AU wibbled into the void...
> I don't actually know a lot of details about Prolog II and Prolog II,
> but from what little I have heard, I'd call them Prolog.
And they are incompatible with what many call Prolog. This is because
of the differences in syntax and semantics. I'm not sure what it is that
makes PD Prolog not "Prolog", while you accept Prolog II and Prolog III.
> >> No, I'm certainly _not_ assuming that. You must have misunderstood
> >> something.
> >
> >I wonder what that might have been.
>
> Well, I didn't say anything about what people _want_. I was talking
> about what is or is not Prolog, not about whether people want it.
That's what I thought you meant. I therefore assume that I've understood
you correctly. if I have misunderstood something, then you've yet to give
me any idea what that might be. Could you please explain?
> >If you can explain to me at what
> >point a language ceases to be Prolog, then I'd greatly appreciate it.
> >I've been puzzled by this question for years.
>
> Well, obviously it's a fuzzy border. You could certainly image a lot
> of borderline cases. But Visual Prolog is clearly on the other side of
> the border, IMHO.
What is it that is missing from Visual Prolog? While I'm aware of the
differences, I don't see anything that stops Visual Prolog from being a
member of the Prolog family of languages. It may well fail _your_
definition, of course, so you'll have to explain why this should matter
to anyone (or indeed, everyone) looking for a Prolog.
> >How did you quantify the language differences?
>
> Using the best tool for reasoning with fuzzy logic known to date --
> a human brain ;-)
Ah, a purely subjective argument? Ok, I guess this has been a complete
waste of time.
> It's not _purely_ subjective, but yes there are subjective aspects.
That's good enough for most people.
> Well, one particularly strong piece of completely objective evidence is
> that the intersection of the set of legal Turbo Prolog programs and the
> set of legal Prolog programs is empty.
"Legal"? Sure, Visual Prolog isn't ISO Prolog. So what? Does that mean
that it isn't a member of the family of languages called Prolog?
> But the name of the family is "logic programming", not "Prolog".
> "Prolog" is the name of a particular language and it's dialects,
> and Turbo Prolog is no closer to Prolog than Fortran is to C.
I didn't think that I was talking about "logic programming", but about
the family of languages called "Prolog". PDC Prolog is a lot closer to
"Prolog" than imperative languages like Fortran and C. Your argument is
loaded with subjective statements, as is mine. I therefore conclude that
we shall never agree on this, and that we should stop wasting our time.
> >The question of which language to use and what to call it seems pretty
> >silly to me, when there're so many bigger issues to worry about.
>
> I think the question of which language to use can make a lot of
> difference, but yes I certainly agree that the question of what to
> call it is not a big issue. (Usenet bandwidth is not proportional
> to importance ;-)
The reason that I say that the question of which language to use is silly
is that IMHO people use the tools they do _because they can_. The
suitability of those tools to the problem is general irrelevant, esp when
compared to the necessity of getting the problem solved. The result is
often poor, but it would be a whole lot worse if there was no solution at
all. This is my own experience, but perhaps yours is different.
If you have can give PDC a good reason to change the name of their
product, please do so. Otherwise, this is just hot air. They can call it
Prolog because they can, just as someone may call a spade a shovel.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>With a mighty <··········@mulga.cs.mu.OZ.AU>,
>···@mundook.cs.mu.OZ.AU wibbled into the void...
>
>> I don't actually know a lot of details about Prolog II and Prolog II,
>> but from what little I have heard, I'd call them Prolog.
>
>And they are incompatible with what many call Prolog. This is because
>of the differences in syntax and semantics.
Could you elaborate?
>I'm not sure what it is that
>makes PD Prolog not "Prolog", while you accept Prolog II and Prolog III.
Well, I thought that Prolog II and Prolog III were backwards compatible
with Prolog, just adding some additional features. I could well be
wrong about that, though. If that's not the case, then I'd need to
know more about them before I could decide whether it is reasonable
to call them Prolog.
>> Well, I didn't say anything about what people _want_. I was talking
>> about what is or is not Prolog, not about whether people want it.
>
>That's what I thought you meant.
Then why did you say that I was assuming that people wanted ISO Prolog?
I didn't say anything of the sort.
>> Well, obviously it's a fuzzy border. You could certainly image a lot
>> of borderline cases. But Visual Prolog is clearly on the other side of
>> the border, IMHO.
>
>What is it that is missing from Visual Prolog?
arg, functor, and '=..'; call; assert/retract of code; DCGs;
term_expansion; user-defined operators; dynamic typing / polymorphism;
polymorphic modes; if-then-else; garbage collection (well, maybe that's
an implementation feature, not a language features); exception
handling; and I'm sure the list goes on.
>> Well, one particularly strong piece of completely objective evidence is
>> that the intersection of the set of legal Turbo Prolog programs and the
>> set of legal Prolog programs is empty.
>
>"Legal"? Sure, Visual Prolog isn't ISO Prolog.
I mean "legal" in the sense of "accepted by the compiler",
not "conforming to the standard".
>So what?
So that means that there are *no* programs that will work under both
Turbo Prolog and Prolog.
>Does that mean
>that it isn't a member of the family of languages called Prolog?
Yes, unless there is some strong evidence to the contrary,
I would take "empty intersection" as prima facie evidence
that two languages/dialects are in fact different languages
rather than different dialects.
>> But the name of the family is "logic programming", not "Prolog".
>> "Prolog" is the name of a particular language and it's dialects,
>> and Turbo Prolog is no closer to Prolog than Fortran is to C.
>
>I didn't think that I was talking about "logic programming", but about
>the family of languages called "Prolog". PDC Prolog is a lot closer to
>"Prolog" than imperative languages like Fortran and C.
I'm not denying that! Yes, PDC Prolog is closer to Prolog than Fortran
is to Prolog. But, PDC Prolog is further away from Prolog than Fortran
is away from C, and Fortran and C are different languages, therefore PDC
Prolog and Prolog are different languages.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <··········@mulga.cs.mu.OZ.AU>,
···@murlibobo.cs.mu.OZ.AU wibbled into the void...
> >I didn't think that I was talking about "logic programming", but about
> >the family of languages called "Prolog". PDC Prolog is a lot closer to
> >"Prolog" than imperative languages like Fortran and C.
>
> I'm not denying that! Yes, PDC Prolog is closer to Prolog than Fortran
> is to Prolog. But, PDC Prolog is further away from Prolog than Fortran
> is away from C, and Fortran and C are different languages, therefore PDC
> Prolog and Prolog are different languages.
Ok, I'll take your word for it. I guess PDC are misleading everyone about
the nature of PDC Prolog. If names mean nothing, which appears to be the
case, then none of this matters. If the name _does_ mean something, and
if this makes a difference, then PDC are undermining the value of the
name, and should be stopped. Is the name "Prolog" trademarked?
Y'see, I'm not disagreeing with you. What I'm doing is trying to
understand how this can matter, when PDC can commit such abuse. My guess
is that there are simply too many people who couldn't give a toss about
it. Considering how many people think that C++ is a "Good idea", I don't
think that this is our biggest problem.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>You're assuming that everyone wants an ISO Prolog.
No, fjh explicitly denied that. In fact, he said people wanted Turbo
Prolog *because* it wasn't ISO Prolog.
>A lot of people just
>want a development tool. Visual Prolog looks like it has excellent
>Windows support, in the sense that it uses an IDE with a form designer,
>toolbar and menu support, etc.
Once again I would like to point out that LPA WinProlog has *superb*
integration with the Win32 environment.
>NO, I strongly disagree here. C and Fortran appear to me to differ more
>than Visual Prolog differs from standard Prolog.
Hmm. Fortran 90 lacks C pointer arithmetic. C89 lacks Fortran 90
string handling (I'm talking about the supplementary standard for
variable length strings), array arithmetic, module system, and overloading.
In other respects, Fortran and C are pretty darned close. It is, for
example, quite easy for Fortran and C to intercall each other without
"glue" code on most systems: scalars, arrays, records, and pointers are
close enough for a very large proportion of cases to map across quite
simply.
No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".
>The ISO Prolog committee may
>define ISO Prolog, but I don't feel they can decide what is and is not
>_Prolog_, the family of Prolog dialects.
Let's not play at Humpty-Dumpty here.
The question is "what is the POINT of calling two things by the same name?"
The answer is "we call two things by the same name when the advantages of
identifying them outweigh the disadvantages of confusing them, in the light
of the cost of finding out which one you have".
For a lot of people, the cost of finding out was the cost of buying the
product. What are the advantages of identifying them? Little or none.
Yes, Turbo/Visual/PDC Prolog *IS* a logic programming language. So is
the much better language Trilogy. If you wish to *avoid* using logic
programming languages, it is useful for you to identify Prolog, Turbo/
Visual/PDC Prolog, Trilogy, Mercury, Goedel, and many others, so it
_helps_ you to use the same name for them. (LP). Speaking as someone
who has actually tried to move substantial Prolog programs between
different dialects:
- "Prolog" unqualified is generally construed as "Clocksin &
Mellish core"
- It is fairly straightforward to move programs between C Prolog,
Quintus Prolog, Arity Prolog (up to version 4), LPA Prolog,
LPA MacProlog, Open Prolog, SICStus Prolog, ECLIPSE, NU Prolog,
IBM Prolog, Poplog provided they don't stray too far outside
the core.
- It is essentially imposssible to move between Turbo/Visual/PDC
Prolog and any of the above dialects. In fact, it is EASIER
to move between "Clocksin & Mellish" Prolog and Lisp (whether
Scheme, Common Lisp, or Interlisp) than between Prolog and
T/V/P `Prolog'.
- I will go further. I personally find it easier to translate
Fortran to C, Pascal, *and* Ada (that is, to produce all three
translations) than to translate between T/V/P `Prolog' and
"Clocksin & Mellish" Prolog. Heck, I've even found it easier
to translate Fortran to Prolog (yes, I've done that).
So for people who _do_ want to use a logic programming language,
- if they _do_ want to use one similar to the language described in the
books that talk about Prolog, it is UNhelpful to confuse T/V/P `Prolog'
with that family
- if they _don't_ want to use a member of that family, it is UNhelpful
to confuse T/V/P `Prolog' with that family.
>Visual Prolog is close enough to
>members of this family for _me_ to call it Prolog
Yes, but that tells us nothing unless you tell us what _use_ you make
of the name. Are you someone with a substantial amount of Prolog code
that you want to run on a PC? Are you someone with a substantial amount
of Turbo Prolog code that you want to run on a Mac?
>Let's call them distant cousins, and call C and Fortran completely
>different species, rather than relatives to _any_ Prolog.
fjh's point was that C and Fortran are more closely related to _each other_
than T/V/P `Prolog' is to C&M Prolog. And this is undeniably true.
>> It continues to sell because it is a useful programming language.
>> Again, your comment seems to be premised on a fundamental misunderstanding.
>> It is like asking why someone's Fortran compiler continues to sell,
>> even though it's not C. The reason is because they are different
>> languages.
>IMHO it's more likely that not enough people care about language purity.
>Hence VB, VC++, and other atrocities. Perhaps the people who sell Visual
>Prolog aren't as concerned about such things as yourself? I guess so.
Purity was never the issue. That is a straw man dressed up as a red
herring. COMPATIBILITY is the issue. I see computing as an engineering
discpline. From where I sit, the bottom line is that for any conceivable
useful Prolog program, it is cheaper to buy the most expensive PC Prolog
and do a bit of dialect conversion (for which a number of tools exist)
than to buy Turbo/Visual/PDC Prolog at *any* price and do the total
rewrite that will be called for. I don't give a crumb of reremouse
droppings for purity. I do care about whether the darned thing will
compile my programs.
>So, complain to PDC. Perhaps they'll listen and do something about it.
Unlikely. People have been complaining for about a decade.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: James Giles
Subject: Re: Microsoft Common Lisp?
Date:
Message-ID: <32FF1C85.4D35@cris.com>
Richard A. O'Keefe wrote:
[...]
>
> >NO, I strongly disagree here. C and Fortran appear to me to differ more
> >than Visual Prolog differs from standard Prolog.
>
> Hmm. Fortran 90 lacks C pointer arithmetic. [...]
Of course, there are those of us who believe that pointer arithmetic is
a bad idea. Indeed, any use of pointers is a bad idea if you have an
efficient alternative available.
Pointers for which only the operations of ALLOCATE, DEALLOCATE, and
dereferencing are available are usually better than more general
pointers (Fortran ALLOCATABLE does this). Pointers for which pointer
assignment is also defined are worse, but not as bad as pointers on
which arithmetic operations are defined (Fortran POINTER sort of does
this - it ability to reference array slices is a mess). Pointers that
may only point to dynamically allocated objects (like in Pascal) are
better than pointers which can point everywhere (Fortran's pointers can
point to dynamic and TARGET objects - so it's sort of midway between
constrained and unlimited).
Whatever pointers you have, you should use as limited a subset of their
capabilities as you can get by with. This makes your program more
robust, and possibly faster.
--
J. Giles
Ricercar Software
With a mighty <············@goanna.cs.rmit.edu.au>,
··@goanna.cs.rmit.edu.au wibbled into the void...
> No, fjh explicitly denied that. In fact, he said people wanted Turbo
> Prolog *because* it wasn't ISO Prolog.
I'm refering to the (apparent) assumption that conforming to a standard
is required before a product may be called "Prolog". Perhaps this
assumption is incorrect, in which case I trust that Fergus will say so.
> Once again I would like to point out that LPA WinProlog has *superb*
> integration with the Win32 environment.
The same may be true of a great many systems, e.g. VB, but that does't
make them Prolog, nor does it exclude other systems. I like LPA Prolog,
and it would probably be my own choice, if I were to use Prolog. However,
that may well depend on factors which have nothing to do with Prolog.
> No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".
Are you agreeing with me, that the differences between Fortran and C are
greater than the differences between a PDC Prolog and...what? We should
really be talking about specific implementations, since PDC Prolog is not
a standard.
> - It is essentially imposssible to move between Turbo/Visual/PDC
> Prolog and any of the above dialects.
This is the assumption that I'm questioning. Not every programmer will
wish to move existing code from one Prolog to another, nor is the fact
that this may be hard proof that a particular language is not a dialect
of a family of languages.
If this were actually the case, the we could claim that newLisp was _not_
Lisp, because it isn't compatible with any other Lisp dialect, like CL or
Scheme.
Some programmes will be very happy to choose a single product and then
stick with it. I agree that choosing PD Prolog will then tie you to that
product. However, I know that a large number of developers don't let such
details stop them.
Even if this were not so, would it mean that PDC Prolog is not "Prolog"?
I don't think so. If you applied the same argument to VB or VC++, in a
room full of VB/VC++ programmers, you'd probably be laughed out the door.
At best, you might get a lot of blank looks.
I've made this point in another post, but here it is again. People use
the tools they do _because they can_, and details like language purity
and compatibility with other tools are mere luxuries. If programmers
using Prolog tend to enjoy such things more than programmers using
VB/VC++, then I'm pleased, as this is as it _should_ be.
Alas, most of us live in a truely _ugly_ world of software development.
This is the world that Visual Prolog is marketed at. It would be easy to
just blame the marketing folk for such abuses, but I doubt it's that
simple. In any case, few of these people will even understand your
concerns, never mind share them. I expect that few of _them_ will take
any interest in Prolog, so I wonder just who PDC's customers are? Perhaps
a minority of Prolog programmers who're prepared to accept a few quirks?
As I've said in an earlier post, this has puzzled me for years.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: William Clodius
Subject: Re: Microsoft Common Lisp?
Date:
Message-ID: <32FF6A5E.59E2@lanl.gov>
Cyber Surfer wrote:
>
> With a mighty <············@goanna.cs.rmit.edu.au>,
> ··@goanna.cs.rmit.edu.au wibbled into the void...
>
> <snip>
>
> > No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".
>
> Are you agreeing with me, that the differences between Fortran and C are
> greater than the differences between a PDC Prolog and...what? We should
> really be talking about specific implementations, since PDC Prolog is not
> a standard.
No! Read the O'Keefe's sentence again (and its accompanying text which
you omitted). He is saying that the differences between Fortran and C
are far less than the differences between PDC prolog and any other
Prolog dialect with which he is familiar. He subsequently does cite
specific implementations, in a good deal of detail, i.e.
> - "Prolog" unqualified is generally construed as "Clocksin &
> Mellish core"
>
> - It is fairly straightforward to move programs between C Prolog,
> Quintus Prolog, Arity Prolog (up to version 4), LPA Prolog,
> LPA MacProlog, Open Prolog, SICStus Prolog, ECLIPSE, NU Prolog,
> IBM Prolog, Poplog provided they don't stray too far outside
> the core.
>
> - It is essentially imposssible to move between Turbo/Visual/PDC
> Prolog and any of the above dialects. In fact, it is EASIER
> to move between "Clocksin & Mellish" Prolog and Lisp (whether
> Scheme, Common Lisp, or Interlisp) than between Prolog and
> T/V/P `Prolog'.
>
> - I will go further. I personally find it easier to translate
> Fortran to C, Pascal, *and* Ada (that is, to produce all three
> translations) than to translate between T/V/P `Prolog' and
> "Clocksin & Mellish" Prolog. Heck, I've even found it easier
> to translate Fortran to Prolog (yes, I've done that).
Consider the last two points. He has found in practice that the best
known members of the language family termed Lisp are closer in semantics
to most languages thought of as Prolog than is the semantics of the
language T/V/P `Prolog'. He has even found a subset of the Fortran
language with closer semantics to that of the familly of languages most
often thought of as Prolog than the language T/V/P `Prolog'. Taken
literally that means he would rather consider Fortran to be a dialect of
Prolog than consider T/V/P 'Prolog' to be a dialect of Prolog.
> <snip>
> > - It is essentially imposssible to move between Turbo/Visual/PDC
> > Prolog and any of the above dialects.
>
> This is the assumption that I'm questioning. Not every programmer will
> wish to move existing code from one Prolog to another, nor is the fact
> that this may be hard proof that a particular language is not a dialect
> of a family of languages.
> <snip>
The above is incongruous. The statement
"Not every programmer will wish to move existing code from one Prolog to
another, nor is the fact that this may be hard proof that a particular
language is not a dialect of a family of languages,"
does NOT question the "assumption"
"It is essentially imposssible to move between Turbo/Visual/PDC Prolog
and any of the above dialects,"
First, O'Keefe's statement is not an "assumption" it is a statement of a
fact based on extensive experience. Second, your statement does not
question the content of his statement it ignores that content. To
question O'Keefe's statement you would have to say that you (or others
that you know of) have tried the translation of T/V/P Prolog to other
dialects of Prolog, and have not found it to be as difficult as he
claims. (As near as I can tell you have not said that at any point.) If
your statement questions anything, it is his and Fergus's contention
that the only objective criteria for deciding whether two languages are
related is the relative degree of ease of translating code from one
language to another. However, unless you can propose a specific
alternative to that criteria (and I have not seen such alternative
mentioned in this tread), then your question is rhetorical and should be
dismissed.
(Note the statement "Not every programmer will wish to move existing
code from one Prolog to another" does not question any of their
assumptions or statements. They agree with that statement. They would
probably phrase it more clearly as "Not every programmer will wish to
move existing code from Turbo/Visual/PDC Prolog to another language
calling itself Prolog or from another language calling itself Prolog to
Turbo/Visual/PDC Prolog" and go on to dismiss that statement as
irrelevant to their argument. Their argument is that for programmers not
interested in such porting the question as to whether two language are
related is relatively unimportant and only for that subset that wants to
perform such a translation is the question of significance. (This subset
however often includes those who want to use code from a textbook as a
means of learning a language.) Further, if programmers not interested in
porting such code have an abstract interest in the relatedness of two
languages, they will find the judgements of those that have ported code
to be more usefull than any other criteria that Fergus or O'Keefe (or
myself) are aware of.)
> <snip>
> Even if this were not so, would it mean that PDC Prolog is not "Prolog"?
> I don't think so. If you applied the same argument to VB or VC++, in a
> room full of VB/VC++ programmers, you'd probably be laughed out the door.
> At best, you might get a lot of blank looks.
Irrelevant. Fergus and O'Keefe would argue that they are not discussing
whether VB or VC++ are not Basic or C++ respectively. They are saying
that T/V/P Prolog is not Prolog. They have in fact consistently argued
that by their criteria VB is a dialect of Basic and VC++ is a dialect of
C++, because it is possible to use them to write code that is very
easily ported to other dialects of Basic or C++ respectively. (Whether
or not such portable code is often written in practice is irrelevant to
their case.) They argue that it is NOT possible AT ALL to write ANY code
in T/V/P Prolog that is easilly portable to other Prologs.
> <snip> I expect that few of _them_ will take
> any interest in Prolog, so I wonder just who PDC's customers are? Perhaps
> a minority of Prolog programmers who're prepared to accept a few quirks?
As I understand it, Fergus and O'Keefe take strong exception to the
qualifier "few quirks". That would imply that it is possible to work
around the language differences. They consistently argue that in its
very fundamentals T/V/P Prolog differs from that of the other Prologs.
They have argued that those fundamental differences are larger than the
fundamental differences between Fortran and C, between Lisp and Scheme,
indeed between Lisp and the other Prologs. While the comparisons have
not come up I suspect that they would argue that the differences between
Haskell and Lisp, between Dylan and Haskell, even ANSI-ISO Basic and
VC++ are all small compared to the differences between T/V/P Prolog and
other Prologs.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
With a mighty <·············@lanl.gov>,
········@lanl.gov wibbled into the void...
> (Note the statement "Not every programmer will wish to move existing
> code from one Prolog to another" does not question any of their
> assumptions or statements. They agree with that statement. They would
> probably phrase it more clearly as "Not every programmer will wish to
> move existing code from Turbo/Visual/PDC Prolog to another language
> calling itself Prolog or from another language calling itself Prolog to
> Turbo/Visual/PDC Prolog" and go on to dismiss that statement as
> irrelevant to their argument. Their argument is that for programmers not
> interested in such porting the question as to whether two language are
> related is relatively unimportant and only for that subset that wants to
> perform such a translation is the question of significance. (This subset
> however often includes those who want to use code from a textbook as a
> means of learning a language.) Further, if programmers not interested in
> porting such code have an abstract interest in the relatedness of two
> languages, they will find the judgements of those that have ported code
> to be more usefull than any other criteria that Fergus or O'Keefe (or
> myself) are aware of.)
I have no problem with that. That just leaves the issue of PDC calling
their product Prolog...If this issue is so important, I wonder what's
being done about it? Does anyone care about this enough to do something,
has it be tried, and did the attempt fail or is it still occuring?
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer <············@wildcard.demon.co.uk> wrote in article
<·······················@news.demon.co.uk>...
> ... That just leaves the issue of PDC calling
> their product Prolog...If this issue is so important, I wonder what's
> being done about it? Does anyone care about this enough to do something,
> has it be tried, and did the attempt fail or is it still occuring?
There's really not much to be done. Prolog was not trademarked or
copywrited when
it was created. As far as legalities go, you can't get them for not
complying with a
standard (or even coming close). As far as I know (note: I am NOT a
lawyer) I could
put a Lisp interpreter in a box, call it Fortran-99 and legally sell it
(this may not be the
way to achieve a high customer satisfaction rating, though). As long as I
don't make
stupid and false claims like:
Compiles ANSI standard FORTRAN!
or:
Makes your DO loops run in 0 time!
that are provably false, I cannot even be sued for false advertising. In
fact, it would be
even harder for a "technically savvy" user of an "advanced programming
language" to
claim that he didn't know he would be raped - I mean such people would do
some
due diligence reasearch on the product before buying it, wouldn't they?
So basically, even though you can make intellectual and moral claims that a
company
that diverges from so many other standards SHOULD do the user community the
service of changing the language name, you can make no legal clame that
they MUST
do so.
I guess that leaves only one course of action, the one that probably should
have been
pointed to earlier in this debate - if it isn't Prolog and you want Prolog,
don't buy it, make
sure people who ask you don't buy it, and don't associate with the type of
person who
would buy it...
Frank A. Adrian
······@europa.com
With a mighty <··························@truth>,
············@firstdatabank.com wibbled into the void...
> I guess that leaves only one course of action, the one that probably should
> have been
> pointed to earlier in this debate - if it isn't Prolog and you want Prolog,
> don't buy it, make
> sure people who ask you don't buy it, and don't associate with the type of
> person who
> would buy it...
Excellent advise. Not always practical, but that's a different kind of
problem. I wonder if some of the alternatives to Visual Prolog are as
good at supporting Windows development? Imagine a developer who is
more concerned about _that_ than issues like code compatibility?
I know these people exist, tho I don't know any that wish to use
Prolog.
This makes me wonder just what kind of develper uses PDC Prolog.
If Richard is right, then they're probably not Prolog programmers at
all, but some lower form of life that is either unable to distinguish
between Prolog and PDC Prolog, or just unconcerned by the differences.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>With a mighty <············@goanna.cs.rmit.edu.au>,
>··@goanna.cs.rmit.edu.au wibbled into the void...
>
>> No, fjh explicitly denied that. In fact, he said people wanted Turbo
>> Prolog *because* it wasn't ISO Prolog.
>
>I'm refering to the (apparent) assumption that conforming to a standard
>is required before a product may be called "Prolog". Perhaps this
>assumption is incorrect, in which case I trust that Fergus will say so.
That assumption is incorrect.
>> - It is essentially imposssible to move between Turbo/Visual/PDC
>> Prolog and any of the above dialects.
>
>This is the assumption that I'm questioning.
What Richard wrote above is true, whether you question it or not.
>Not every programmer will
>wish to move existing code from one Prolog to another,
Sure.
>nor is the fact
>that this may be hard proof that a particular language is not a dialect
>of a family of languages.
It may not be "hard proof", but I think it constitutes very strong
prima facie evidence, and in the absence of any strong evidence to the
contrary, I think you should conclude that they are different languages,
not dialects.
>I've made this point in another post, but here it is again. People use
>the tools they do _because they can_, and details like language purity
>and compatibility with other tools are mere luxuries.
As Richard said, language purity is a red herring.
Sure, people use what they can. Good on them!
I'm not arguing that people should use ISO Prolog.
(They should use Mercury! Mercury is far from standard Prolog -- but
it doesn't claim to be Prolog, instead it claims to be better than Prolog.)
The question is not about whether computer languages should be "pure" --
it's English we're arguing about. it's about whether English words
should be subject to Humpty-Dumpty abuse.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
William Clodius <········@lanl.gov> wrote lots that I agree with,
and a one small thing I would like to clarify:
>Fergus and O'Keefe would argue that they are not discussing
>whether VB or VC++ are not Basic or C++ respectively. They are saying
>that T/V/P Prolog is not Prolog. They have in fact consistently argued
>that by their criteria VB is a dialect of Basic and VC++ is a dialect of
>C++, because it is possible to use them to write code that is very
>easily ported to other dialects of Basic or C++ respectively. (Whether
>or not such portable code is often written in practice is irrelevant to
>their case.) They argue that it is NOT possible AT ALL to write ANY code
>in T/V/P Prolog that is easilly portable to other Prologs.
That last sentence is probably overstating things slightly.
It is _possible_ to write code in Turbo/Visual/PDC Prolog that is
"easily" portable to other Prolog's, though porting would certainly not
trivial (the effort would consist mostly of deleting type declarations,
perhaps using some different predicate names, etc.).
It is the reverse direction that is the real problem.
So to summarize: no T/V/P Prolog applications would be trivially
portable to Prolog; most T/V/P Prolog applications not be easily
portable to Prolog; no Prolog programs would be easily portable to
T/V/P Prolog; and most Prolog applications would in fact be _very_
difficult to port to T/V/P Prolog.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>This makes me wonder just what kind of develper uses PDC Prolog.
>If Richard is right, then they're probably not Prolog programmers at
>all,
True of course, since PDC Prolog isn't Prolog...
>but some lower form of life that is either unable to distinguish
>between Prolog and PDC Prolog, or just unconcerned by the differences.
I don't think so. They're probably just people who wanted a strongly
typed logic programming language with a compiler that can generate
efficient code for PCs and which has good support for Windows.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <··········@mulga.cs.mu.OZ.AU>,
···@murlibobo.cs.mu.OZ.AU wibbled into the void...
> ············@wildcard.demon.co.uk (Cyber Surfer) writes:
>
> >This makes me wonder just what kind of develper uses PDC Prolog.
> >If Richard is right, then they're probably not Prolog programmers at
> >all,
>
> True of course, since PDC Prolog isn't Prolog...
And I repeat: tell this to PDC. They're confusing the hell out of me.
> >but some lower form of life that is either unable to distinguish
> >between Prolog and PDC Prolog, or just unconcerned by the differences.
>
> I don't think so. They're probably just people who wanted a strongly
> typed logic programming language with a compiler that can generate
> efficient code for PCs and which has good support for Windows.
I agree. This is what "unconcerned by the differences" refered to.
The result is that some people will call this language Prolog, which
appears to be what PDC are doing.
It makes no difference. If it did, perhaps accusing MS of being an
"evil empire" would stop people from buying their software. I suspect
that it has no such effect, but I could be wrong. However, MS _appear_
to be growing, in spite of their apparent failings. If a vendor like
PDC can call their product Prolog, who cares whether it's what you,
Richard, myself, or anyone else might call Prolog? Just try stopping
them, and I'll wish you luck. You may need it.
On the other hand, if you don't wish to do anything about it, why
worry about it? Just remove entry for PDC Prolog from the
comp.lang.prolog FAQ, and replace with an entry that states that PDC
Prolog is not Prolog. At the very least, it should note that PC Prolog
is not Prolog, rather than merely strongly typed.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·························@news.demon.co.uk>, ············@wildcard.demon.co.uk (Cyber Surfer) writes:
> ..deleted
> we should
>asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
>non-standard as it is, and yet continues to sell.
Because the buying public (programmers) doesn't care about real Standards.
They are only interested in making money.
(real Standards => the ones that are created by more than one company).
--
Best Wishes, Bengt
--------------------------------------------------------------------
Email: ·············@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
the direction of that applied rotation is all downhill.'' ······@netreach.net
With a mighty <············@euas20.eua.ericsson.se>,
······@eua.ericsson.se wibbled into the void...
> Because the buying public (programmers) doesn't care about real Standards.
> They are only interested in making money.
This appears to be the case. There's certainly _more_ interest in making
money than following standards, and this is reasonable. If a company
can't stay in business, their choice of language may soon be acedemic.
> (real Standards => the ones that are created by more than one company).
I guess it'll be a while before we see ISO Erlang? ;-)
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer (············@wildcard.demon.co.uk) wrote:
: With a mighty <··········@news.huji.ac.il>,
: ······@pluto.mscc.huji.ac.il wibbled into the void...
: > Fergus Henderson (···@murlibobo.cs.mu.OZ.AU) wrote:
: > : ············@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
: >
: > You can program Turbo Prolog for years - and not know what Prolog is.
: This is my point. You can still use it! It may be "wrong", but doesn't
: stop everyone.
:
: > Sad but true.
:
: Agreed. I wish it could be otherwise, but alas, language standards
: are not laws, and the means by which they're enforced are considerably
: different. Not necessarily weaker, but certainly different. If they're
: not powerful enough to either stop programmers from using PDC Prolog, or
: to encourage PDC to make their Prolog more standard, then I believe that
: this is unfortunate.
Question is how many people use it to achieve the taks Prolog is supposed
to be good at. Since Turbo Prolog wasn't Prolog it failed in tasks witch
are pretty simple to do in any "real" Prolog. The thing is that since
Turbo Prolog wasn't Prolog, the name only serves as an easy marketting
tag. I don't think language laws are so important as to raise issues of
Truth In Advertising here, but I do think that you may fall into
unexpected black holes of coding and uncalled for work - if you try to
use Turbo Prolog for regular Prolog tasks.
Same thing about any implimentation that is far enough from the base
language as to cripple it.
As opposed to Visual Basic (also featured in this thread), Turbo Prolog
didn't only enhance the language (by adding compilation, PC stuff etc.)
but also cut down features. This can cause an innocent programmer some
distress....
These issues tend to boil down to religious wars. These wars are cool in
their own right - but let's not forget that language standards are here
to help us a programmers choose a right tool, and protect our investment
both in tools and in training.
--
Ehud Lamm ······@pluto.mscc.huji.ac.il
With a mighty <··········@news.huji.ac.il>,
······@pluto.mscc.huji.ac.il wibbled into the void...
> As opposed to Visual Basic (also featured in this thread), Turbo Prolog
> didn't only enhance the language (by adding compilation, PC stuff etc.)
> but also cut down features. This can cause an innocent programmer some
> distress....
VB also cut out valuable features. I miss using an interactive Basic.
I also loath the curruption of the language, with the misuse of names
like DIM. That's a good enough reason for me to hate it.
> These issues tend to boil down to religious wars. These wars are cool in
> their own right - but let's not forget that language standards are here
> to help us a programmers choose a right tool, and protect our investment
> both in tools and in training.
It's too bad that so many programmers don't even know what these
standards are, never mind care about them. I'd love to boycott VB and
Visual Prolog, but I'm unlikely to use either of them anyway. I advise
others not to use them, of course.
Unfortunately, it's often productivity that counts, not language
standards, or consistancy with historical usuage. So it goes.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Will Hartung (······@netcom.com) wrote:
: C++ and VB are easy to like, because "everybody" likes it. Its easy to
: drift into the crowd and chant "Me TOO!". Its easy for beginners and
: amateurs because MOST programmers are beginners. MOST programmers know
: not what they do. They don't know why they bump into the limits they
: do, because most are cook book, cut and paste programmers. They don't
: do this for fun. Its not really interesting, just more interesting
: than being a bank clerk or an auto mechanic. They'd rather be a
: computer mechanic...less dirt under the finger nails. 9 to 5
: programmers. Their interests lie elsewhere.
Amazingly accurate - and here I thought it was just my workplace <sigh>
: You can be a 9 to 5 programmer in Lisp, or anything else. If you don't
: care about what you're coding, they you don't care about what you're
: coding in. People work because they have to, not because they want to.
: People code because its their job. If they're changing languages, its
: because they want a new job. "I should learn XYZ so I can be more
: marketable!".
And this bites totally - but people also get bit by it - after all,
people gotta work ...
On 3 Feb 1997, Kirt Undercoffer wrote:
*Will Hartung (······@netcom.com) wrote:
*
*: C++ and VB are easy to like, because "everybody" likes it. Its easy to
*: drift into the crowd and chant "Me TOO!". Its easy for beginners and
*: amateurs because MOST programmers are beginners. MOST programmers know
*: not what they do. They don't know why they bump into the limits they
*: do, because most are cook book, cut and paste programmers. They don't
*: do this for fun. Its not really interesting, just more interesting
<snip>
this is so true! the only formal programming class i ever took was a
1 semester BASIC class in jr. high! and yet here i find myself,
wordprocessing on a number of systems, examining how many different
languages work, spending hours online at home (like now, should be
sleeping), mostly reading newsgroups of substance, i use linux at
home, have managed to get my x window system running, am learning to
write shell scripts, i have learned html, i have learned cgi . . . the
whole point of the bravado on my part is not to say look how smart i
am, but to express how much joy i get from examining what i am
writing, why it works that way, etc. i guess it's the philosophy as
much as the technical part of computers i like. but not the
philosophy as regards online communities, people, etc. bleah. but
show me ai-related, unix-related, programming related, i am there. so
perhaps my job is not programming but my heart is!
ta
······@pheret.com
(ooh, good .sig)
In article <················@netcom.com>, ······@netcom.com says...
>
>The press and the people would ask "Why do we need another language?
>We got C for the fast stuff, and VB for the easy stuff! Why muddy the
>waters?"
The press and the people swallowed Java easily enough...
All the press need is an angle. Casting half an eye over the history of X11
and NeWS, a suitable angle might be ``Lisp does everything Java does, is
more mature, runs on more platforms, and isn't owned by Sun''. :-)
============================================================================
Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ
···@five-d.com Tel: +44 1767 601 361 Fax: +44 1767 312 006
Info on Jaws and 5D's other products on http://www.five-d.com/5d
============================================================================
`Save string while you're young. Then when you're older, you'll have a ball.'
···@five-d.com (Ian Kemmish) writes:
>In article <················@netcom.com>, ······@netcom.com says...
>>
>>The press and the people would ask "Why do we need another language?
>>We got C for the fast stuff, and VB for the easy stuff! Why muddy the
>>waters?"
>
>The press and the people swallowed Java easily enough...
>
>All the press need is an angle. Casting half an eye over the history of X11
>and NeWS, a suitable angle might be ``Lisp does everything Java does, is
>more mature, runs on more platforms, and isn't owned by Sun''. :-)
Yes, that might be a suitable angle, but the press reports NEWS, and
Lisp isn't new.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
So if I'm programming in kanji, for example, what do left and right
parentheses look like?
I'm wondering if lisp plays easier in languages where parenthetical
delimiters aren't quite the slim ascender that latin alphabets use. It
get's a lot easier to read with nested syntax coloring on just the ()
characters, for example. They just don't stand out from each other with
much emphasis when they are all the same color on a monitor displaying
ascii code pages or latin1.
I was wondering about emacs, which gets roundly criticized by people
who prefer fast and small for it's bulk and at times lethargic lisp
foundations on some hardware configurations. But emacs should benefit over
time from the same developments that make it easier to use gui
environments: cheap ram, cheap disks, and faster processors. If you have
enough ram and a fast enough machine and you can easily tell one ( from
another in (((((, either because each nesting colors the parentheses
differently or because they are an altogether more emphatic character in a
particular language's glyphs, does elisp (and common lisp and scheme by
exension) get more convenient to use and acquire the sort of do all
programming persona now enjoyed by tools like C, perl, and tcl?
Regards, Clayton Weaver ······@eskimo.com (Seattle)
In article <··········@mulga.cs.mu.OZ.AU>,
Fergus Henderson <···@murlibobo.cs.mu.OZ.AU> wrote:
>
>Yes, that might be a suitable angle, but the press reports NEWS, and
>Lisp isn't new.
You know what would be new? Lisp for JVM!
Who wants to start it?
--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
In article <··········@sue.cc.uregina.ca>,
John Bayko <·····@borealis.cs.uregina.ca> wrote:
> You know what would be new? Lisp for JVM!
> Who wants to start it?
I've already done it, if you consider Scheme to be Lisp.
Kawa compiles Scheme to Java byte codes.
See http://www.cygnus.com/~bothner/kawa.html.
A beta of Kawa 1.2 is available from ftp://ftp.cygnus.com/pub/bothner.
--
--Per Bothner
Cygnus Solutions ·······@cygnus.com http://www.cygnus.com/~bothner
In article <············@rtl.cygnus.com>,
Per Bothner <·······@cygnus.com> wrote:
>In article <··········@sue.cc.uregina.ca>,
>John Bayko <·····@borealis.cs.uregina.ca> wrote:
>> You know what would be new? Lisp for JVM!
>> Who wants to start it?
>
>I've already done it, if you consider Scheme to be Lisp.
There is another one called "UnCommon Lisp."
Paul Prescod
From: Peter da Silva
Subject: Re: Microsoft Common Lisp?
Date:
Message-ID: <5ddj8d$950@web.nmti.com>
In article <··········@mulga.cs.mu.oz.au>,
Fergus Henderson <···@murlibobo.cs.mu.OZ.AU> wrote:
> Yes, that might be a suitable angle, but the press reports NEWS, and
> Lisp isn't new.
Define a new language that looks like lisp and has all the lisp features
and runs standard lisp programs, but don't call it lisp, and make it so
you can write programs that look sorta pascalish... maybe borrow from Logo
or Smalltalk for the "new" syntax. People like algol-style syntax, even
if it's as variant as VB's or C's.
That'd be news, yes?
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
* Peter da Silva
| Define a new language that looks like lisp and has all the lisp features
| and runs standard lisp programs, but don't call it lisp, and make it so
| you can write programs that look sorta pascalish... maybe borrow from
| Logo or Smalltalk for the "new" syntax. People like algol-style syntax,
| even if it's as variant as VB's or C's.
|
| That'd be news, yes?
it sort of sounds like Apple's Dynamic Language (Dylan) to me.
#\Erik
--
my other car is a cdr
From: Peter da Silva
Subject: Re: Microsoft Common Lisp?
Date:
Message-ID: <5dg3ql$7hc@web.nmti.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> it sort of sounds like Apple's Dynamic Language (Dylan) to me.
Never heard of it, probably because it doesn't have a spiffy marketing-
friendly turbovisualhyper++ name. *g*
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
In <··········@web.nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> ...
>Define a new language that looks like lisp and has all the lisp features
>and runs standard lisp programs, but don't call it lisp, and make it so
>you can write programs that look sorta pascalish... maybe borrow from Logo
>or Smalltalk for the "new" syntax. People like algol-style syntax, even
>if it's as variant as VB's or C's.
C's syntax is more Algol like than Pascal's (both Algol60 and Algol68)
Hartmann Schaffer
On 6 Feb 1997 21:42:37 GMT, ·····@nmti.com (Peter da Silva) wrote:
>In article <··········@mulga.cs.mu.oz.au>,
>Fergus Henderson <···@murlibobo.cs.mu.OZ.AU> wrote:
>> Yes, that might be a suitable angle, but the press reports NEWS, and
>> Lisp isn't new.
>
>Define a new language that looks like lisp and has all the lisp features
>and runs standard lisp programs, but don't call it lisp, and make it so
>you can write programs that look sorta pascalish... maybe borrow from Logo
>or Smalltalk for the "new" syntax. People like algol-style syntax, even
>if it's as variant as VB's or C's.
>That'd be news, yes?
How about my dream language I'm working on:
- Lists are more abstract than Lisp/Scheme; not necessarily chains of
cons cells. As such, they can be easily implemented as vectors in
certain circumstances etc. at the compiler's whim
- Decent object system
- Impure function like Scheme
- Assertions to make compiler's job easier in type inferencing, ie we
can assert that a function parameter is of a certain type, in a
certain range, etc. so the compiler can tell it can use 32 bit
integers safely, and if not, the point at which arithmetic could
overflow and the compiler must switch to 64 bit ints of variable size
ints
- Unspecified syntax. Code comes in binary form as a tree structure
like Java bytecode. It can be rendered in one's favourite syntax.
- Good parallelism support in the kernel
- Proper abstract association type [ name: value name: value ] as
opposed to lists (value value value)
- Tail recursive
- Higher order functions and classes (ie, paremetric types / as
values)
- delay (lazy evaluation) and future (arbitary evaluation), and
promises of either type are automatically forced by primitive
functions except for those that merely pass data on (let, define,
apply, etc)
- Core library is less minimal than Scheme, but more structued than
CL. Primitives include:
- Standard helper functions (map, filter, apply, etc)
- Knowledge base library (bring AI to the real world by giving
programmers the power to create intelligentish software), not Prolog
predicate calculus but something a little more interesting. I'm not
sure exactly what right now, since I haven't performed more than a
brief survey of AI techniques available yet.
- A standard for the serialisation of all the basic types (numbers
etc) which is adhered to well, so code and data are very portable.
I'm working on this to be part of my dream OS, ARGON. The ARGON page
is at http://www.abwillms.demon.co.uk/os/, but the ARGOT language
section is a little dated now; take my utterances above as overriding
that. The rest is still valid.
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
Peter da Silva (·····@nmti.com) wrote:
: In article <··········@mulga.cs.mu.oz.au>,
: Fergus Henderson <···@murlibobo.cs.mu.OZ.AU> wrote:
: > Yes, that might be a suitable angle, but the press reports NEWS, and
: > Lisp isn't new.
: Define a new language that looks like lisp and has all the lisp features
: and runs standard lisp programs, but don't call it lisp, and make it so
: you can write programs that look sorta pascalish... maybe borrow from Logo
: or Smalltalk for the "new" syntax. People like algol-style syntax, even
: if it's as variant as VB's or C's.
Yeah, and maybe even architect it so you can have 'sealed' libraries
with a strong bias towards final-compiled performance, and small footprint,
and.....
: That'd be news, yes?
Yeah, the news is Apple set the Dylan pointer to nil.
······@netcom.com (Will Hartung) writes:
>Borland came out with their product "Turbo Prolog".
They bought it in. I used to work for a Prolog company. We had a chance
to buy the system that became known as Turbo Prolog, and we turned it down
because while it seemed like a neat product, it was about as incompatible
with other Prolog systems (inlcuding our product) as it could possibly be.
>Borland had more Language mindshare than MS did, was MS as focusing on
>applications really, and did Prolog become the great redeemer?
Borland managed to get glossy ads for Turbo Prolog into all sorts of
places. In our more cynical moments, we blamed "ordinary" Prolog's
failure to take off the way we'd hoped on people's disappointment with TP.
The classic "Prolog" textbook is Clocksin & Mellish. All the code in that
book worked in every Prolog known to the authors. Turbo Prolog accepted
NONE of it. TP actually sold a lot of copies, for a Prolog product, but
a lot of copies stayed on shelves when the purchasers found they couldn't
actually _use_ it to do what they'd bought it for.
>Now, maybe the implementation had lots of problems, I don't know.
The implementation was a fine implementation of a good language,
it just wasn't the language that people expected when they saw the
name "Prolog". Like, can you imagine selling as "Lisp" something
that wouldn't run _any_ examples from _any_ previously written Lisp
textbook?
>Maybe Borland was too mainstream to market Prolog effectively.
Borland didn't develop the original system. Obviously they were more
committed to their "core product line".
>But for whatever reason, Turbo Prolog died a nameless death.
Turbo Prolog is neithr nameless nor dead.
The people who developed the thing in the first place are
_continuing_ to develop and to market it under the name "PDC Prolog".
By all accounts it's a very effective DOS programming tool.
(But then, so is LPA Prolog for Windows, which seems to have excellent
integration with the Win32 environment.)
>The best thing that MS could do with Lisp, is turn it into a COMPILED
>BATCH module alternative for their C++ development system, and bundle
>it with VC++.
As a matter of fact, there is an extremely important reason why MS
_need_ something like Lisp.
OLE.
C++ is clearly the wrong programming language for OLE. (Anything that
requires *manual* reference counting is a disaster waiting to happen.)
The hacks they need to get "reflection" in C++ in order to support OLE
Automation are duck soup in Lisp.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
In article <·············@bway.net>, ····@bway.net wrote:
> Cyber Surfer wrote:
> >
> > I frequently recommend browsing the MSR website. If this was all
> > you saw of MS, you might get a very different impression of them.
> > For example, they have researchers using Common Lisp and Haskell,
> > two of my favourite languages.
>
> Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
> Microsoft Common Lisp?
Ask his wife. She should already know about this stuff ("BOB").
--
http://www.lavielle.com/~joswig/
>Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
>Microsoft Common Lisp?
Why would Microsoft be interested in such a large standardized ball
of wax? Obviously, Microsoft Visual Lisp will look something like this:
define fact (x)
if (x eq 0)
return 0;
else
return x * fact (x - 1);
end fact;
[BIG SMILEY HERE]
Sam
--
408-749-8798 / ····@webnexus.com
I speak for xyne KS since I AM xyne KS.
Resisitance is not futile! http://www.be.com/
····@webnexus.com (Samuel S. Paik) writes:
>Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
> >Microsoft Common Lisp?
>
> Why would Microsoft be interested in such a large standardized ball
> of wax? Obviously, Microsoft Visual Lisp will look something like this:
>
> define fact (x)
> if (x eq 0)
> return 0;
> else
> return x * fact (x - 1);
> end fact;
>
> [BIG SMILEY HERE]
No, no, that's not right. Wrong syntax, buggy, statement oriented rather than
expression oriented...
define method fact (x)
if (x = 0)
1;
else
x * fact (x - 1)
end if;
end method;
Or even better...
define method fact (x)
local ff (x, t);
if (x = 0)
t;
else
ff(x - 1, t * x);
end if;
end method;
ff (x, 1);
end method;
Now, I could live with a language like that. And it could even happen -- it's been
*months* since Microsoft stole something from Apple...
-- Bruce
--
...in 1996, software marketers wore out a record 31,296 copies of Roget's
Thesaurus searching for synonyms to the word "coffee" ...
>Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
>Microsoft Common Lisp?
Oh, and obviously they would call it "Microsoft Visual L++"
Sam,
who was initially confused why Microsoft would want to do an enhanced
J (APL successor).
--
408-749-8798 / ····@webnexus.com
I speak for xyne KS since I AM xyne KS.
Resisitance is not futile! http://www.be.com/
Why so much debate about MS releasing LISP, are we all so governed
by MS's dominance of the software market to be slaves to whatever
they decide to do?. I know its some sort of David and Goliath thing
but surely it would be better to promote the various LISP
implementations we use than to provide MS with yet another niche
to overwhelm?.
(mind you if we were successfull, MS would just buy up whatever
LISP implementations were flavour of the month :) )
Graham
----------------------------------------------------------------------
Graham Bevan | Lead Instructor in Applied AI | NBCC Miramichi
# 506-778-6537 | email ······@nbnet.nb.ca |
"Get the facts first, You can distort them later." - Mark Twain
In article <·············@nbnet.nb.ca> ······@nbnet.nb.ca "Graham Bevan" writes:
> Why so much debate about MS releasing LISP, are we all so governed
> by MS's dominance of the software market to be slaves to whatever
> they decide to do?. I know its some sort of David and Goliath thing
> but surely it would be better to promote the various LISP
> implementations we use than to provide MS with yet another niche
> to overwhelm?.
The reasons is simple. Whatever we think about MS, they appear
to understand what large numbers of people want. Those people may
be wrong, but that's acedemic. We're outnumbered.
Take a look at VB and VC++. A "Visual Lisp" (either Scheme or CL)
might offer the same strength of support for Windows features,
APIs etc. MS appear to either go all the way with a language, or
they ignore it. VB and VC++ are excellent examles of this. They're
unbelievably good Windows development systems, by beating everything
else in terms of support for MS Windows, tools, APIs, etc.
So, I'd expect Visual Lisp to either exist and have full support
for ActiveX, OLE, multithreading, etc, or to not exist at all.
The same might be true of MS APL. BTW, there's at least one APL
that can save the workspace as an OLE object, which can then be
embedded in a document. Imagine how such an APL system could
compliment apps like spreadsheets!
Because of the politics that plagues programming languages, there
may be no middle ground. There will always be critics who attack
a tool for being an apple, and not an orange. A compromise may
be even worse - in some peoples' eyes.
On the other hand, MS have the kind of power to make something
work, regardless of what other people think of it. The only
condition would be that _they_ want it, and understand it well
enough to market it. That may be how VB came to be...
> (mind you if we were successfull, MS would just buy up whatever
> LISP implementations were flavour of the month :) )
Yes, and probably completely redesign it, to fit in with the
way that Windows people look at development software. ;)
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer wrote:
>
> In article <··········@fido.asd.sgi.com>
> ·······@engr.sgi.com "Mike McDonald" writes:
>
> > I think you are seriously underestimating Microsoft's profits. Bill is
> > spending BIG bucks hiring as many big named researchers as he can.
>
> I frequently recommend browsing the MSR website. If this was all
> you saw of MS, you might get a very different impression of them.
> For example, they have researchers using Common Lisp and Haskell,
> two of my favourite languages. Their papers can be read by anyone.
>
> Alas, this gets very little attention. Instead, we get the "evil
> empire" label again and again. Some of Erik's points are good,
> but he's only refering to the surface, i.e. what MS are selling
> _today_. MSR should be compared to places like MIT, CMU, etc.
> I'd like to know how their work compares, given the relatively
> short time MSR has existed.
>
If you look into MS's research pages and bio's you will find several
developers that do their work in Scheme too. (Check compilers group)
chuckb
PS I'll go on record and say microsoft is OK with me. I have a stable
(relatively) platform that works for what I need (C++, VB, Scheme and
Forth!). I've even grown to find VB pretty fun. Obviously I'm not
going to write a Rec. Descent Parser in VB but it gets the UI job done
fast and now with gambit's compiler life is looking up.
"Nothing optimal is pure." - Unknown
········@eecg.toronto.edu (Robert Bernecky) writes:
> I think both sides have their virtues, but I'll present one data point:
>
> On Black Monday on Wall Street, there were several
> ways that computers brought doom onto their trading users:
[...]
I'm actually interested in this example, apart from the general
discussion on overflow and languages. Do you have a reference for it?
In article <··············@cruella.bfr.co.il> Aaron Gross <···@netvision.net.il> writes:
>········@eecg.toronto.edu (Robert Bernecky) writes:
>
>> I think both sides have their virtues, but I'll present one data point:
>>
>> On Black Monday on Wall Street, there were several
>> ways that computers brought doom onto their trading users:
>
>[...]
>
>I'm actually interested in this example, apart from the general
>discussion on overflow and languages. Do you have a reference for it?
I have never seen anything written on this.
My connection with this was more direct:
I was the manager of the APL development group at I.P. Sharp Associates
at the time, and Morgan-Stanley Bank in NYC was using our SHARP APL
product extensively for a lot of their work.
The information in my posting came from post-Black-Monday
discussions with our contacts at Morgan. I'm not sure who
to point you at to chase harder data than I presented, because
major reorganizations of bankers at that level appears to happen
on a monthly basis. I'm also somewhat reluctant to name names
in a spam-ridden medium.
Bob
>So, C and Lisp programmers appear to make different choices.
>I wouldn't call that a profund statement. It _should_ be very
>obvious. Why then do so many of us miss this point, or forget
>about it? Why do people feel so strongly about which language
>_other people_ choose to use? Perhaps it's because we may have
>to use their software, or that some of us feel that these
>choices may effect them, and possibly limit _their_ choices?
>
>I don't know. I use the tools that I do _because I can_. If
>anyone has a problem with that, I'll remind them to get a life.
>I'll not call them stupid, but I _will_ object to anyone who
>thinks that they can tell me which choices to make.
>
>You're all welcome to _offer_ me advise, but please understand
>that I'm not obliged to follow it. ;-) That seems to me to be a
>healthy attitude. If not, then I'm sure someone will tell me...
I goes without saying that you are not obliged to follow Usenet
advice, or any other advice for that matter.
But people in the computer industry naturally have strong feelings
about these issues. If you are contracting others to build software
you'll know that it's hardly ever on time and hardly ever works. If
you are personally building it, you'll know that you are often forced
to use inappropriate technology, or at least technology which severly
impairs the chances of a successful outcome. If you are an end user of
software, you'll know that the number of bugs in a lot of software is
often appalling high. And it's also clear that almost all technology
is used, not on it's own merits, but simply because other people are
using it. How many companies or individuals carefully weighed how
appropriate C++ vs Smalltalk, vs CLOS vs whatever would be for their
project and then made an appropriate decision? Unlikely.
Thus unless all you are doing is hacking away on your own little
project, it is probable that whatever choice you make will affect many
others, whether that is your employer, the user, the person who has to
fix what you built, or some future maintainer. And the language you
use will greatly affect the outcome.
In article <······················@Alcatel.com.au>
······@ThePla.net "Chris Bartlett" writes:
> But people in the computer industry naturally have strong feelings
> about these issues. If you are contracting others to build software
> you'll know that it's hardly ever on time and hardly ever works. If
> you are personally building it, you'll know that you are often forced
> to use inappropriate technology, or at least technology which severly
> impairs the chances of a successful outcome. If you are an end user of
> software, you'll know that the number of bugs in a lot of software is
> often appalling high. And it's also clear that almost all technology
> is used, not on it's own merits, but simply because other people are
> using it. How many companies or individuals carefully weighed how
> appropriate C++ vs Smalltalk, vs CLOS vs whatever would be for their
> project and then made an appropriate decision? Unlikely.
That's why I'm currently writing CGI code in Haskell. Hopefully,
a few people will notice this (like anyone reading this post!),
and see that the choice of tool doesn't just inclide Perl and C.
In fact, I know of CGI support for Lisp, Prolog, Smalltalk, and
other languages.
> Thus unless all you are doing is hacking away on your own little
> project, it is probable that whatever choice you make will affect many
> others, whether that is your employer, the user, the person who has to
> fix what you built, or some future maintainer. And the language you
> use will greatly affect the outcome.
I won't dispute this. I'm not sure whether you're using the
word 'you' to refer to me specifically, or to programmers in
general, but I can say a few things about my own experience.
Some of it may be shared by most programmers, but I suspect
that a few things will _not_.
It could be that very few people will notice my code (one app
is used by only 1/4 million people), and even fewer will know
or care what language was used, but I'm happy to tell anyone who
asks programming tools I'm using. It's only the Windows specific
tools, like libraries etc, that I might have to keep "secret".
It's likely that more of my CGI code will be used this year
than my multimedia code, and I can see very little reason to
write much of that in C/C++.
The choices I make will certainly effect my employer, which
may be one reason why I'm allowed so few of them. Few of my
programming skills overlap with my colleagues. This isn't
likely to be a problem - yet - and even if it was, using C++
wouldn't help, as that's one of the _my_ skills.
While it should be easy to find additional C++ programmers,
my C++ coding style is influenced by a lot of the languages
I've used, so some of it should look a little "odd" to some
of them. I'm assuming that it wouldn't be so easy to find
C++ programmers with my range of experience, but I could be
wrong.
So, while I may be writing code that could be hard to maintain
if I left, this isn't a unique problem. The same might be true
of a single VB programmer in a C++ shop. I can't do a thing with
VB, Excel, Word, etc, but I work with people who can. Since we
can't all share the same skills, any choice may create problems!
Perhaps this is how languages like C++ and COBOL survive?
You don't avoid choice by using the same tools as the majority,
nor do you avoid the problems.
Followups adjusted.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: Mike McDonald
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cmd60$c8o@fido.asd.sgi.com>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * Mike McDonald
>| I think you are seriously underestimating Microsoft's profits. Bill is
>| spending BIG bucks hiring as many big named researchers as he can.
>
> I know. what are the results?
>
> #\Erik
Well, I'm not sure but I'd guess he has two goals. Make even more money and
keep those "bright fellows" from coming up with anything that might challenge
his supremacy. As for adopting any so called superior technology that we think
would be a boost to the software industry, I doubt Bill is that dumb. It's very
difficult to build a monopoly when someone else owns and controls your base
technologies. It's much easier to make up something uniquely yours that you can
convince to world to accept. Whether it's better or worse from a technical
standpoint is almost irrelevant.
Mike McDonald
·······@engr.sgi.com
P.S. Don't get me wrong. I'm no fan of Microsquish. I only run windows95 so I
can run Quicken.
·······@engr.sgi.com (Mike McDonald) writes:
> I think you are seriously underestimating Microsoft's profits. Bill is
> spending BIG bucks hiring as many big named researchers as he can.
I'd like to hear the names of some of the `big named researchers' he has
already acquired.
(I can think of only one offhand but I don't follow MobyLimp very closely.)
------------------------------------------------------------------------------
Michael R. Blair --. ·····@ai.mit.edu | MIT Artificial Intelligence Lab
(617) 253-0765 \\ ···@lcs.mit.edu | MIT Labor. for Computer Science
,,Lambda Calculus... /\\_ ...uber alles!'' | 545 Technology Square--Room 439
http://www-swiss.ai.mit.edu/~ziggy/ziggy.html| Cambridge, MA USA 02139-3594
·····@montreux.ai.mit.edu (Michael R. Blair) writes:
> I'd like to hear the names of some of the `big named researchers' he has
> already acquired.
Gordon Bell, Jim Gray and Rick Rashid, for example.
You Will Be Assimilated.
Thomas
--
Thomas Lindgren, Uppsala University
·······@csd.uu.se, ········@sics.se
http://www.csd.uu.se/~thomasl/
In article <··············@groucho.csd.uu.se>
·······@groucho.csd.uu.se "Thomas Lindgren" writes:
> ·····@montreux.ai.mit.edu (Michael R. Blair) writes:
>
> > I'd like to hear the names of some of the `big named researchers' he has
> > already acquired.
>
> Gordon Bell, Jim Gray and Rick Rashid, for example.
> You Will Be Assimilated.
I believe that they've also worked with researchers _outside_
MS, like some CS people at a certain university in Texas.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <········································@eskimo.com> Clayton Weaver <······@eskimo.com> writes:
I'm wondering if lisp plays easier in languages where parenthetical
delimiters aren't quite the slim ascender that latin alphabets use. It
get's a lot easier to read with nested syntax coloring on just the ()
characters, for example.
Most Lisp programmers do not see parens. If you show the definition
(define (foo x)
(if (or (zero? x)
(< x 10)
(- x 1))
(- x 1)))
to a Lisp programmer, he will see it as
(define (foo x)
(if (or (zero? x)
(< x 10))
(- x 1)
(- x 1)))
Indenting Lisp code is so easy to do right automatically that at least
I have a background assumption that code is correctly intended. The
essential information in the above is thus retained even in
define foo x
if or zero? x
< x 10
- x 1
- x 1
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of Technology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>Is Scheme a subset of CL? I think not.
This might be relevant to the argument if Scheme were called
"Turbo Common Lisp". But it is not. There is nothing about
the _name_ "Scheme" that suggests or is intended to suggest
that Scheme is a subset of Common Lisp. (In strict point of
fact, there _is_ a Scheme/CL compatibility package that lets
a great many Scheme programs run unchanged in CL. I think it's
in the Lisp F.A.Q. periodic posting.)
What does Scheme have that Common Lisp lacks?
- strict distinction between false (#F) and empty list ()
- the numeric tower is slightly different
- call-with-current-continuation
- hygienic macros
My Scheme code avoids hygienic macros because they weren't there
when I started using Scheme and I still don't fully understand them.
However, free source code for implementations is available and
could readily be added to CL.
Some of the Scheme systems available to me only support call/cc for
escapes. That _can_ be translated easily to CL. This is all I use
call/cc for.
Scheme's numeric tower is very very nice, but the permissions in the
standard and RnRS mean that I cannot *rely* on it being there. What
I _can_ rely on is, for practical purposes, a subset of CL.
The only real _nuisance_ when doing a dialect conversion from Scheme
to CL is the #f/() distinction, and in practice it's a minor problem.
(It is _not_ a minor problem going the other way, because it is easy
to ignore a distinction than to introduce one.)
I expect to *routinely* port R4RS Scheme code that I have written to
other Lisps with only minor effort. In fact, I quite often write
code in Scheme at home and port it to Xlisp-Stat (CLish) and GCL.
To give an example, consider computing the distance between two
vectors.
(define (vector-distance V1 V2)
(let ((N (vector-length V1)))
(do ((I 0 (+ I 1))
(S 0 (+ S (expt (- (vector-ref V1 I) (vector-ref V2 I)) 2)) ))
((= I N) (sqrt S))) ))
In order to run that under Common Lisp, I don't need to change anything.
I just add the following definitions:
(defmacro define (Name &rest Value)
(if (listp Name)
`(defun ,(car Name) ,(cdr Name) ,@Value)
`(setq ,Name ,(car Value))))
(defmacro vector-ref (Vec Inx)
`(aref ,Vec ,Inx))
(defun vector-length (V)
(length (the vector V)))
Of course these definitions don't get rewritten every time. They go in
a Scheme support library.
So, we find that
(1) The *name* Scheme does not make any false claims about compatibility
with other Lisps.
(2) Nevertheless, there *is* a substantial amount of overlap between
Scheme and Common Lisp, to the point where it is possible to write
substantial amounts of code that will run *without change* under
both. (This will mean a support library on each side, but the _same_
support libraries will serve for many programs.)
In contrast,
(1) The *name* "Turbo Prolog" falsely suggests (to people who have
previously learned about "Prolog" but not "Turbo Prolog") just
another C&M Prolog dialect.
(2) *NO* C&M Prolog code can run under "Turbo Prolog" without a
substantial amount of additional program-specific text AND a
number of apparently pointless changes.
Any pundit sitting in an armchair can say "it looks like Prolog to _me_".
But any poor bugger with 50 000 lines of code to port will in all seriousness
find it easier to port C&M Prolog to Scheme than to "Turbo Prolog". (Yes,
I know Scheme is not a logic programming language. That's the _point_.)
>So you say. I say the same thing about VB, but I don't expect anyone
>to take any notice. With Basic, it seems (or has done, in the past) that
>there are as many dialects as implementations. I've been lead to believe
>(by a number of Prolog books, and other sources of information) that
>Prolog implementations are often unique dialects, but most of them
>have a common subset.
Most systems used to claim they were "Clocksin-and-Mellish" compatible,
or "Edinburgh compatible". This meant a Scheme-sized common subset.
Then they started saying "Quintus compatible". Nowadays they are
saying "ISO compatible". I personally was involved in writing a
Prolog dialect converter (shades of TRANSOR!) and can testify that
syntax was *by far* the least important factor in moving code between
Prolog systems.
>The exceptions to have included Prolog dialects
>like Prolog II and Prolog III. Do you seen these languages as Prolog, or
>do you claim that these too are not Prolog?
We do not expect Modula 2 and Modula 3 to be dialects of the same language,
still less do we expect them to be compatible with the original Modula.
PL/1, PL/11, PL/360, and PL/516 have very little in common.
(Of course, APL\1130, APL\370, APL/700, and APL2 _do_ have a lot in common.)
Experience with other languages teaches that
"Foobar M" and "Foobar N"
where M and N are different numbers, not being year-of-standardisation
numbers, are languages that are probably quite different. Prolog II and
Prolog III were "marketed" as _different_ from C&M Prolog.
I have not had a chance to try Prolog III. I *believe* that it would
be straightforward to translate "Clocksin & Mellish" Prolog to Prolog III
mechanically, but not the reverse. If this is true, then Prolog III is a
borderline case: a reasonable argument could be made either way.
Waffling on about purity of essence can last forever.
Consider the engineering question:
- you have a substantial body of code.
- you have the alternative of purchasing an implementation of "language X"
for $PX or an implementation of "language Y" for $PY.
- if you go with language X, you will have to do a certain amount of
conversion. This will cost you $CX.
- if you go with language Y, you will have to do a certain amount of
conversion. This will cost you $CY.
- If $PX + $CX < $PY + $CY,
it is rational to go with language X *whatever* it is called.
- The cost of conversion is affected by the availability of conversion
tools. I am aware of conversion tools between C Prolog, Arity Prolog,
LPA Prolog, and IBM Prolog on the one hand and Quintus Prolog on the
other. (Quintus and SICStus are close enough that the same converter
would do for SICStus Prolog.) Some of these converters preserve
comments, so one maintains the converted code. Such tools dramatically
lower the $CX price.
- If $CX is low (by which I mean dominated by the usual costs of adapting
to a different operating system) it is reasonable to regard language X
as a dialect of the language you are currently using. If $CY is high,
it is reasonable to regard language Y as a different language.
By this criterion, I believe that anyone who has actually _tried_ it
will agree that LPA Prolog and SICStus Prolog are dialects, but LPA
WinProlog and Visual Prolog (although they run on the same machine)
are different languages.
Other people may prefer other criteria, but for people who are considering
_buying_ a compiler, I believe this to be the most useful criterion.
>I wonder what that might have been. If you can explain to me at what
>point a language ceases to be Prolog, then I'd greatly appreciate it.
When it costs too much to convert code that is unarguably Prolog to
the language in question.
>I've been puzzled by this question for years.
Come come. Philosophers have puzzled over the question of identity
for MILLENIA (remember the boat?). Requiring your interlocutor to
solve the problem is a very shabby debating trick.
Let me rephrase what I said above, because it looks as though I think
I've solved it. I don't know when a language ceases to *BE* Prolog,
and what's more I don't CARE. I should have written:
it ceases to be USEFUL to call a language Prolog
when the cost of converting programs everyone agrees
to be Prolog (as described in Clocksin & Mellish, Sterling
& Shapiro, or the ISO standard) becomes too high.
What's "too high"? Well, operationally, the cost is too high when it
is cheaper to buy a rival product. If a programmer is A$50k/year plus
overheads, buying *any* commercial PC product will be cheaper than
converting a non-trivial Prolog program to Turbo Prolog. (For students,
there is a good C&M-compatible *free* Prolog for PCs, so we get the same
answer for students as for commercial software developers.) It's
certainly too high when it is cheaper to develop your own interpreter
than to convert, and I've known of that happening too.
>How did you quantify the language differences? This is the same argument
>that I use to claim that VB is not Basic, nor is it visual, so I have an
>interest in how this may be done, plus how large numbers of people may be
>pursuaded by your argument.
I don't know how fjh quantifies, but
- time &
- money
look pretty good to me. I can convert several hundred lines of Fortran
code to C by hand per day. It takes me much longer to convert Prolog to
Turbo Prolog. One important reason is that the Fortran->C translation
is *local*, while the Prolog->Turbo Prolog translation is NOT.
Another important reason is that all the major features of Fortran have
direct analogues in C, whereas several of the major semantic features of
Prolog have no direct analogue in Turbo Prolog. Of course, while I _can_
convert Fortran to C, I don't. I just call Fortran from C and vice versa,
sharing _unmodified_ data structures. Indeed, I can translate Fortran to
C mechanically using the free "f2c" program.
In fact, Fortran and C could be fantastically different, and the existence
of f2c would still mean that *operationally*, Fortran and C could be
considered syntactic dialects of the same language, because the cost of
converting ($CX) is so low.
In the same way, the cost of converting *my* Scheme code to Common Lisp
is so low that *for my operational purposes* Scheme _is_ a subset of CL.
(I have to work harder to maintain compatibility with different Scheme
systems.)
>> But the differences between Turbo Prolog and Prolog are large enough,
>> IMHO, that Turbo Prolog is a different language, not just a dialect.
>Fair enough, I'll accept that this is your opinion. I remain unconvinced,
HAVE YOU EVER TRIED TO CONVERT A SUBSTANTIAL PROGRAM IN EITHER DIRECTION?
Or supervised someone else making the attempt? I have been paid to write
and maintain "Prolog". I have been paid to maintain "Turbo Prolog". The
only thing that will convince anyone on this subject is the pain of actually
trying to _act_ on the assumption that they are the "same" language.
Now fjh is invovled in building a logic programming language called Mercury,
which has a type system similar to but very much better than Turbo's, and
a "mode" system similar to but very much better than Turbo's. Mercury is
in fact much more compatible with "Prolog" than Turbo Prolog is (if you
erase the declarations from the Mercury compiler, you have a Prolog program,
which is how they bootstrapped). The group he's in are thoroughly aware of
Turbo Prolog. I think he knows what he's talking about.
>This is my point! PD Prolog and the familiy of Prolog dialects share
>enough distingishing features, IMHO, that I'm happy to call PDC Prolog
>a member of that family.
Yes, but the *NAME* of that family is "logic programming languages".
You are like someone saying, well, "so-and-so is black, so it's ok
to call him OJ Simpson."
>It may be an illegitimate child
No. I am sure Fjh would agree that Turbo Prolog is a perfectly
legitimate and honourable member of the family called "logic programming
languages". Just as Trilogy and Geodel are.
>but I don't
>feel that this is important.
Feelings schmeelings. What matters is how names lead people to ACT.
And if you adopt a name which leads people to ACT on the assumption
that Turbo Prolog is usefully similar to the language described in
books like "Programming in Prolog", "The Art of Prolog", "The Craft
of Prolog", &c, then you are deceiving them. *Operationally*, it is
so costly to convert that people who are actually interseted in
*running* programs instead of just talking about them do not obtain
any value by calling "Turbo Prolog" Prolog.
>My question still remains: who will stop PDC from calling their product
>Prolog? Nobody, I suspect.
But this is a question about POWER. That is a very different question
from "is it USEFUL to call the product Prolog."
>IMHO the only
>issue is whether or not a tool can do what is claimed for it or not,
As long as you appreciate that "claims" include expectations deliberately
created by marketing, whether or not those claims are stated baldly, then
we are in complete agreement. I have personally spoken with a number of
people who bought Turbo Prolog _because the advertisements brought about
in them the belief that it was close enough to C&M Prolog for their
purposes_ (even though the advertisements did not explicitly say so in
as many words) and felt angry at having been cheated when they found it
was not so. At the price they paid, they did not feel it worth taking
legal action, but they had considered it.
Nothing in this posting should be construed as stating or implying that
PDC or Borland *intended* to deceive anyone at all or in any way acted
unethically. Clearly, reasonable people _can_ disagree about whether it
is a "Prolog" or not. My point is not what PDC or Borland did, but what
_some_ customers felt.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
With a mighty <············@goanna.cs.rmit.edu.au>,
··@goanna.cs.rmit.edu.au wibbled into the void...
> This might be relevant to the argument if Scheme were called
> "Turbo Common Lisp". But it is not. There is nothing about
> the _name_ "Scheme" that suggests or is intended to suggest
> that Scheme is a subset of Common Lisp. (In strict point of
> fact, there _is_ a Scheme/CL compatibility package that lets
> a great many Scheme programs run unchanged in CL. I think it's
> in the Lisp F.A.Q. periodic posting.)
I didn't suggest that Scheme was a subset of CL. Why are you so
concerned about code compatibility? Not everyone feels this is
so important. Perhaps this is the problem...
> (1) The *name* Scheme does not make any false claims about compatibility
> with other Lisps.
I only mentioned Scheme because I think of it as a dialect of Lisp.
I may be mistaken, of course.
> (2) Nevertheless, there *is* a substantial amount of overlap between
> Scheme and Common Lisp, to the point where it is possible to write
> substantial amounts of code that will run *without change* under
> both. (This will mean a support library on each side, but the _same_
> support libraries will serve for many programs.)
This is irrelevant. Since was exact code compatibility necessary
in order for two languages to be members of the same family? My point
was that if this were so, then Scheme would not be a member of the
Lisp family.
Whatever you or I may feel is reasonable to call "Prolog" or "Lisp",
there's nothing to stop anyone (e.g. MS, PDC, etc) from "abusing" a
name, which may indeed be what they're doing. The real question might
not be "Wat does a name refer to?", or even "Who defines what a name
refers to?", but "Why do so few people care?"
Not that these questions actally matter. You, Fergus, myself, PDC, or
anyone else can call something whatever like, _because we can_. The
only thing that might stop us would be a trademark. Is "Prolog"
trademarked, and if so, why has it failed to stop PDC from abusing the
name? Why have the problems that you've described not stopped PDC
Prolog from being a commercial success? If code compatibility was so
important, then I'd have expected PDC Prolog to die by now.
From what I know of VB, and how it gets used, code compatibility isn't
_begin_ to be an issue. Perhaps it's the same with Visual Prolog. This
appears to be what the "Visual" part of the name implies, as it's a
common characteristic with other development tools with "Visual" as
part of the name. If you don't like what these products stand for,
then I can sympathise.
However, there's nothing that has so far stopped these products from
being sold and used in sufficient numbers for them to succeed. It's
true that Borland gave up on Turbo Prolog, but the product itself has
not yet died. In an ideal world, this would not be possible. However,
this is a far from ideal world...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>I didn't suggest that Scheme was a subset of CL. Why are you so
>concerned about code compatibility?
Have you got any better criteria for determining language and dialect
borders?
If you think Turbo Prolog is Prolog, do you have anything other than
the name including the word "Prolog" to justify this?
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <··········@mulga.cs.mu.OZ.AU>,
···@murlibobo.cs.mu.OZ.AU wibbled into the void...
> If you think Turbo Prolog is Prolog, do you have anything other than
> the name including the word "Prolog" to justify this?
How about the various entries in the comp.lang.prolog FAQ?
Even the FAQ implies that PDC Prolog is a Prolog system.
As I've pointed out to Richard several times, incompatible
is not always a problem.
Here's just one of the comp.lang.prolog FAQ entries:
PDC Prolog runs on IBM PCs (DOS, OS/2, Windows and SCO Unix). Formerly
known as Turbo Prolog from Borland. Includes a native code compiler
but is incompatible with most other prologs. Its variables are
strongly typed, unlike most other prologs. For more information, write
Prolog Development Center, 568 14th Street, Atlanta, GA 30318, call
800-762-2710, (404-873-1366), fax 404-872-5243 or email
···········@pdc.dk (general information), ·····@pdc.dk (sales),
·······@pdc.dk (tech support). European customers may write to Prolog
Development Center, A/S, H.J. Holst Vej 5A, DK-2605 Broendby, Denmark,
call +45 36 72 10 22, or fax +45 36 72 02 69. Reviewed in AI Expert
January 1991. Other email addresses include ·········@compuserve.com.
To subscribe to the ·····@nic.surfnet.nl mailing list, a discussion
list for PDC Prolog users, send mail to ········@nic.surfnet.nl with
SUBSCRIBE PDC-L <your full name>
in the message body.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer wrote:
>
> With a mighty <··········@mulga.cs.mu.OZ.AU>,
> ···@murlibobo.cs.mu.OZ.AU wibbled into the void...
>
> > If you think Turbo Prolog is Prolog, do you have anything other than
> > the name including the word "Prolog" to justify this?
>
> How about the various entries in the comp.lang.prolog FAQ?
I thought the point about Turbo Prolog was that it didn't have
back-tracking, so wasn't logic-programming (although you could say that
it's just less complete than it could be though still sound). OTOH isn't
there an ANSI Prolog now so all bets are off?
yours, Patrick
________________________________________________________
Patrick Herring at work, ········@rlsclare.agw.bt.co.uk
"Occam's razor is so sharp, I bought the whole argument"
With a mighty <·············@rlsclare.agw.bt.co.uk>,
········@rlsclare.agw.bt.co.uk wibbled into the void...
> I thought the point about Turbo Prolog was that it didn't have
> back-tracking, so wasn't logic-programming (although you could say that
> it's just less complete than it could be though still sound). OTOH isn't
> there an ANSI Prolog now so all bets are off?
I wouldn't know about ANSI Prolog, but I recall something about an ISO
Prolog. I'm sure Richard O'Keefe knows more about it, as I also recall
that he used to be on the committee. Unless I'm misremembering
something, he may be able to tell you something about it.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Patrick Herring <········@rlsclare.agw.bt.co.uk> writes:
>I thought the point about Turbo Prolog was that it didn't have
>back-tracking, so wasn't logic-programming
No, Turbo Prolog does have backtracking.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: William Clodius
Subject: Re: Microsoft Common Lisp?
Date:
Message-ID: <3303A218.6488@lanl.gov>
Cyber Surfer
Wake up:
Pay attention to the thread. The recent part of the thread has been,
ineffect, why is the name Turbo/Visual/PDC Prolog unacceptably
misleading.
You wrote:
>
> With a mighty <············@goanna.cs.rmit.edu.au>,
> ··@goanna.cs.rmit.edu.au wibbled into the void...
>
> > This might be relevant to the argument if Scheme were called
> > "Turbo Common Lisp". But it is not. There is nothing about
> > the _name_ "Scheme" that suggests or is intended to suggest
> > that Scheme is a subset of Common Lisp. (In strict point of
> > fact, there _is_ a Scheme/CL compatibility package that lets
> > a great many Scheme programs run unchanged in CL. I think it's
> > in the Lisp F.A.Q. periodic posting.)
>
> I didn't suggest that Scheme was a subset of CL. Why are you so
> concerned about code compatibility? Not everyone feels this is
> so important. Perhaps this is the problem...
>
Richard O'Keefe is simply noting that whether or not Scheme is related
to Lisp (a topic you brought up) is irrelevant to the recent part of the
thread. Scheme (unlike T/V/P Prolog) is not falsely marketing itself. He
then goes on as to why Scheme is not false maketing as opposed to T/V/P
Prolog.
> > (1) The *name* Scheme does not make any false claims about compatibility
> > with other Lisps.
>
> I only mentioned Scheme because I think of it as a dialect of Lisp.
> I may be mistaken, of course.
This response is unnecessary given the next paragraph
>
> > (2) Nevertheless, there *is* a substantial amount of overlap between
> > Scheme and Common Lisp, to the point where it is possible to write
> > substantial amounts of code that will run *without change* under
> > both. (This will mean a support library on each side, but the _same_
> > support libraries will serve for many programs.)
which in effect says that Scheme is a near dialect of Lisp. In this and
other recent messages you seem to be responding to part of the content
of the message without taking into account its context.
>
> This is irrelevant. Since was exact code compatibility necessary
> in order for two languages to be members of the same family? My point
> was that if this were so, then Scheme would not be a member of the
> Lisp family.
Your response is irrelevant. O'Keefe has never argued that exact code
similarity is required to be in the same familly. He has argued only
that the degree of semantic similarity is the primary means by which the
relationship of languages can be judged. He is in fact agreeing with you
that Lisp and Scheme are similar. He is noting that the designers of
Scheme thought that the differences were large enough to deserve giving
it a name other than Lisp, although in comparison to the differences
between T/V/P Prolog and most other Prologs those differences are minor.
As in any categorization scheme there are levels of similarity. In
programming languages the grouping might go
dialects of a language < language familly < language group < language
category < languages as a whole
The borders can be fuzzy but the differences between Scheme and Common
Lisp are sufficiently large that I would not call Scheme and Common Lisp
dialects, but they are similar enough that I would call them members of
the same familly. Dylan is sufficiently different that I would not put
it in the same familly, but would probably put it in the same language
group. SML I would put in the same language category as Scheme, Lisp,
and Dylan, i.e., impure functional languages, but not in the same group.
I suspect that O'Keefe would put T/V/P Prolog in the same language
category (Logic programming languages) as other Prologs, but not in the
same language group, let alone family.
>
> <other irrelevancies snipped>
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
>>"CS" == Cyber Surfer schrieb am Mon, 10 Feb 1997 14:24:30 -0000:
>> - It is essentially imposssible to move between Turbo/Visual/PDC
>> Prolog and any of the above dialects.
CS> This is the assumption that I'm questioning. Not every programmer
CS> will wish to move existing code from one Prolog to another, nor
CS> is the fact that this may be hard proof that a particular
CS> language is not a dialect of a family of languages.
You make the impression as if you have never used either a regular
prolog (that is, one conforming to CS&M) nor Turbo/PDC Prolog. If you
are not convinced by the arguments of the profis, just try it out. It
is very apparent that PDC "Prolog" and -say- SWI/Quintus/Sicstus
Prolog differ much more than Scheme and Common Lisp. And we are _not_
talking about a few minor quirks here and there. There are fundamental
differences. So, I believe that the argument is valid that Turbo/PDC
Prolog should be called anything but not Prolog.
CS> Some programmes will be very happy to choose a single product and
CS> then stick with it. I agree that choosing PD Prolog will then tie
CS> you to that product. However, I know that a large number of
CS> developers don't let such details stop them.
CS> Even if this were not so, would it mean that PDC Prolog is not
CS> "Prolog"? I don't think so.
I do. If I call a pig a horse and some people around me start calling
pigs horses this doesn't make the pig a horse. Calling a pig a horse
maybe doesn't do me any harm but as soon as I would like to talk about
horses and pigs in the public a lot of people would start looking at
me like a weirdo. After all, this is what language is based on: we
agree on words having a special meaning. And calling the PDC product
Prolog is at best miss-leading.
CS> Alas, most of us live in a truely _ugly_ world of software
CS> development. This is the world that Visual Prolog is marketed
CS> at. It would be easy to just blame the marketing folk for such
CS> abuses, but I doubt it's that simple. In any case, few of these
CS> people will even understand your concerns, never mind share
CS> them.
Use a regular prolog and use PDC Prolog and _you_ will share these
concerns.
What is it that convinces you that PDC Prolog should be called Prolog
? The syntax, or what ? Even that is different given that PDC Prolog
requires type declarations.
Holger
--
holger_schauer :-
mail_address(···············@gmd.de"),
project("BGP-MS/AVANTI, GMD Sankt Augustin, FIT.MMK"),
www_home_page("http://www.uni-koblenz.de/~schauer/index.html").
(^:= A donkey came to my office. It had a theory about people anaphora...
Peter da Silva wrote:
[...]
> [The programming language C is] great for writing O/S kernels and
> other things that need low level access to machine objects. It's not
> great for writing big applications. So? Don't use it for that.
[...]
This is the correct answer. Unfortunately people do write big
applications in C--which is what provided the motivation for the
development of C++. And we all know what a mistake that was.
-thant
Robert Sanders <········@mindspring.net> writes:
>The fact that one is not prevented from indexing off the end of a C array
That's a "quality of implementation" issue. Some translators do check
(though there are ways around it using pointer arithmetic). Much of the
argument against C seem to be based on what the commonly used translators
do rather than the language specification and how it is possible to be
implemented. There are some sophisticated C environments/compilers/
interpreters that do provide mechanisms for checking things. Some will
argue that such systems wouldn't be needed if the language spec. handled
such issues in the first place but that doesn't belong in comp.arch (where
I'm reading this thread) or in comp.lang.<whatever> either.
--
Andy Newman <····@research.canon.com.au>
····@research.canon.com.au (Andy Newman) writes:
> Robert Sanders <········@mindspring.net> writes:
> >The fact that one is not prevented from indexing off the end of a C array
>
> That's a "quality of implementation" issue. Some translators do check
...
> Much of the argument against C seem to be based on what the commonly
> used translators do rather than the language specification and how
> it is possible to be implemented. There are some sophisticated C
> environments/compilers/ interpreters that do provide mechanisms for
> checking things. Some will argue that such systems wouldn't be
> needed if the language spec. handled such issues in the first place
That doesn't make sense. Not only doesn't the standard C allow the
programmer to discover the size of an array allocated elsewhere in the
code, standard C doesn't provide any standard mechanism for catching
out-of-bounds access exceptions. I really need one or the other to
program safely. With Common Lisp, I can use (array-dimensions) to
retrieve the array's dimensions, and I can use (handler-case) to catch
out-of-bounds access. With Objective Caml, I can use Array.length for
the former and try/with for the latter. In Scheme, I have
(vector-length), and in Java I have <array>.length and try/catch.
In a high quality implementation of C, how do I find the dimensions of
an array? How do I catch out-of-bounds accesses?
Those features may come as a language extension, but it's not obvious
to me how increasing the quality of implemention of the standard C
language will add those features to the language we love to hate.
> but that doesn't belong in comp.arch (where I'm reading this thread)
> or in comp.lang.<whatever> either.
True. Sorry. He started it.
regards,
-- Robert
Robert Sanders <········@mindspring.net> writes:
>In a high quality implementation of C, how do I find the dimensions of
>an array? How do I catch out-of-bounds accesses?
I think you misunderstood me a little, probably me being unclear.
Not a language extension but as a feature of an implementation. The lcc
compiler will, if you tell it to, insert array bounds checking code (there
is a version of the GNU C compiler that can do the same), there are C
interpreters that perform extensive checking, via memory "cell" tagging,
of data accesses, etc... You're still programming in C but the development
tools are doing more work. This obviously doesn't give you the features
or other languages which provide a higher level data abstraction but C
does let you write such higher level abstract data types and access them.
There's overhead of course as these things aren't native in the language
and other languages may be able to do them more efficiently because they
are primitives but at leat C will let me do it.
As for catching these out of bounds accesses it depends on the method
employed by the "advanced tool". It might raise a signal, it may call
a well-known function, who knows? I've never really needed it but I
just wanted to point out that sophisticated tools do exist that can
make the C programmer's life a little easier.
--
Andy Newman <····@research.canon.com.au>
From: Bruce Hoult
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <2936807255@hoult.actrix.gen.nz>
·····@borealis.cs.uregina.ca (John Bayko) writes:
> >if you design a language small enough, _all_ other languages will have to
> >have all operators that is also in that language.
>
> Did I just happen to miss the bitwise-OR or ++ operators in
> Pascal?
They're called BOR(x,y) and succ(x).
Now I know succ() isn't actually quite the same as ++, but then it's not
as if ++ does anything you can't do without it, unlike the other examples.
And things you do using the C bitwise operators can often be done more
elegantly using Pascal's "set" data types, in which +, - and * can be
implemented directly using OR, BIC and AND instructions. C's bitwise
operators work, but don't express what you're actually trying to do.
> I've certainly haven't found a way to do a bit shift operation
> in Pascal without using a multiply, which certainly works, but doesn't
> express what you're actualy trying to do.
BSL(x,n) and BSR(x,n)
Now, I know this stuff wasn't in Jensen & Wirth, but I've been using them
unchanged since at least Lisa Pascal in 1983 and probably UCSD Pascal in
1980 (I don't actually remember). C wasn't all that common back then.
-- Bruce
--
...in 1996, software marketers wore out a record 31,296 copies of Roget's
Thesaurus searching for synonyms to the word "coffee" ...
In article <··········@sue.cc.uregina.ca>, ·····@borealis.cs.uregina.ca
(John Bayko) wrote:
> As I said, my experience in LISP is limited to some toy programs.
> I don't know what the equivalent of a file descriptor or window handle
> is in LISP, or how you could implement those entirely within LISP (as
> opposed to adding them to the language as basic types).
Well, what would it be? It would be a window object and a pathname
object. In fact, often it is.
> And again, as I said, a LISP expert might be able to show me how
> (and feel free to do so), but it's certainly not obvious to me.
Lisp systems may implement a window class (the example is from
Macintosh Common Lisp 4.0):
(defclass window (view)
((window-cursor :allocation :class :reader window-cursor)
(window-grow-rect :allocation :class :reader window-grow-rect)
(window-drag-rect :allocation :class :reader window-drag-rect)
(color-list :initform nil :reader window-color-list)
(back-color :initform nil)
(object-name :initform nil)
(my-item :initform nil)
(grow-icon-p :initform nil :reader window-grow-icon-p)
(window-do-first-click :initform nil :accessor window-do-first-click
:initarg :window-do-first-click)
(window-active-p :initform nil :accessor window-active-p)
(window-erase-region :initform (#_NewRgn) :accessor window-erase-region)
(window-invalid-region :initform nil :accessor window-invalid-region)
(process :initform nil :initarg :process :accessor window-process)
(queue :initform (make-process-queue "Window") :reader window-process-queue)
(auto-position :initarg :auto-position :initform :noAutoCenter)))
The you write some methods for it. For example a listener
window (there you can type some Lisp and get the results interactively)
may want to modify the window close behaviour with an around
method that asks for confirmation if the listener process
is still running:
(defmethod window-close :around ((w listener))
(let* ((p (window-process w))
(exhausted-p (or (null p) (process-exhausted-p p))))
(when (or exhausted-p
(not (window-close-kills-process-p w p))
(eq *quitting* w)
(process-is-toplevel-listener-p p)
(y-or-n-dialog
(format nil "Close ~s and abort execution in progress?" w)
:cancel-text (if *quitting* "Cancel" nil)))
; Hide errors in closing the window
(window-hide w)
(unless exhausted-p
(setf (symbol-value-in-process '*top-listener* p) nil))
(call-next-method))))
Lisp is not (just) an AI language. It is a general purpose language.
People have written all kinds of programs in Lisp:
image processing stuff, drawing packages, SCSI drivers, window
systems, text editors, 3d renderers, rule systems, TCP/IP
implementations, mail reader, C compiler, ...
Why should it be difficult to write a window system in Lisp?
> > _I'd_ like a _low-level_ language to handle integer overflow,
> >or at least give me access to this absolutely _vital_ information. C
> >doesn't.
>
> That's a problem too, but it's not so bad since it doesn't happen very
> often, and when it does, you can compare to predefined MAXINT type
> constants and filter values before they overflow (instead of after,
> which might be better for reliability in the long run anyway).
But many people do develop C code which doesn't check for
overflow errors. Accounting software in C - Jesus.
I don't trust any C program in this
respect unless I have examined the source code closely
(something I don't often have the time to do).
> I wasn't trying to suggest that C is the best language for
> anything, just why it's popular - in most (generally simple) cases,
> programmers just don't have problems with it. And when they do, they've
> invested enough effort that it's easier to just work around them than
> restart in a better language... (another element of C popularity - the
> simple/complex transition trap!).
Something that forces us to live with crappy software and makes
maintenance very expensive.
Rainer Joswig
In article <·············@netright.com> David Hanley <·····@netright.com> writes:
> When you're writing code that has to make 60 screen updates a second,
>and change 10,000 pixls on each of them, while the user is spell
>checking a document, you don't _need_ integer overflow, rationals, and
>bignums. You don't even _want_ them--they cause too much overhead.
Shouldn't you be writing your program in a language that supports
reliable arithmetic, and *then* choose the parts that *really* need
optimisation, and hand craft them in C?
That's the real problem. C is good for the odd occasion when something
needs to be really fast. But people don't do that. They use C and C
arithmetic as the default, and then try and fix all the resulting bugs
as they are discovered. Better to kill the bugs up front and kill the
performance problems as they are discovered.
In article <··········@dex.trin.cam.ac.uk> Tony Finch <····@lspace.org> writes:
>>Actually, the really correct way to do it, is to specify precicely
>>what range to support. Like int:-2000,75000 or some such to specify
>>exactly what range you will use. Then if there is some hypothetical
>>machine with 20bit words, you don't have to upgrade to 32 bits when
>>porting just for safety's sake. Oh, and a nice implementation would
>>have a checking mode to tell you when you've exceeded your
>>self-imposed limit.
>
>But you have to make sure that your limits are right.
That's the idea. To make sure they're right. Not to hope like hell
they'll be right.
From: Wiker, Raymond
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <hckg1zlzqka.fsf@eto.ericsson.se>
David Shepherd <···@bristol.st.com> writes:
>
> Chris Bitmead <·············@Alcatel.com.au> wrote:
>
> : Actually, the really correct way to do it, is to specify precicely
> : what range to support. Like int:-2000,75000 or some such to specify
> : exactly what range you will use. Then if there is some hypothetical
> : machine with 20bit words, you don't have to upgrade to 32 bits when
> : porting just for safety's sake. Oh, and a nice implementation would
> : have a checking mode to tell you when you've exceeded your
> : self-imposed limit. Better than having a limited exception facility
> : where the only boundaries you can impose are 16, 32 and 64 bits.
>
> I think that sounds rather like the (experimental) language "NewSpeak"
> that was being developed at, I think, RSRE (a UK defence establisment)
> for "verified" applications.
I think that PLANC had this, and also a similar mechanism to
specify the precision of reals. PLANC (Programming Language for Nord
Computers) was the "systems" programming language used on minis from
Norsk Data (remember them?) Wonderfully quirky --- both the language
and the machines it ran on.
BTW: doesn't "NewSpeak" carry some fairly unpleasant
associations, though?
//Raymond.
From: David Bruce
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32EF625F.6662@dra.hmg.gb>
David Shepherd <···@bristol.st.com> wrote:
> Chris Bitmead <·············@Alcatel.com.au> wrote:
> : Actually, the really correct way to do it, is to specify precicely
> : what range to support. Like int:-2000,75000 or some such to specify
> : exactly what range you will use. Then if there is some hypothetical
> : machine with 20bit words, you don't have to upgrade to 32 bits when
> : porting just for safety's sake. Oh, and a nice implementation would
> : have a checking mode to tell you when you've exceeded your
> : self-imposed limit. Better than having a limited exception facility
> : where the only boundaries you can impose are 16, 32 and 64 bits.
>
> I think that sounds rather like the (experimental) language "NewSpeak"
> that was being developed at, I think, RSRE (a UK defence establisment)
> for "verified" applications.
In fact NewSpeak went much further: the ``checking mode'' is the compiler!
(In particular, the expression "x+1" never has the same type as does "x",
so the (seemingly reasonable) expression "x := x+1" is always type incorrect.
Thus there can be no such thing as an overflow (let alone an exception).)
Subsequently, Raymond Wiker <······@eto.ericsson.se> wrote:
> BTW: doesn't "NewSpeak" carry some fairly unpleasant
> associations, though?
You might consider them unpleasant, but NewSpeak's philosophy was that those
associations are in fact necessary. In other words, they're all deliberate!
Quoting from I F Currie, ``Orwellian Programming in Safety Critical Systems'',
IFIP/IFORS Conf. on System Implementation Languages, Experience and Assessment,
Canterbury, Kent, UK, August 1984 (AFAIK the first paper about NewSpeak):
The restriction of language to limit one's capacity for dangerous
thought has already been predicted for this year (1984) in a somewhat
different context [Orwell's book]. In safety-critical programming,
the attractive freedoms of recursion or unrestricted branching and
looping are definitely subversive thoughts. Thus, computer NewSpeak
must be a language in which such thoughts are not only forbidden,
but unthinkable; the job of the ThoughtPolice (in the shape of the
certifying authority [even one as simple and familiar as a compiler!])
then becomes much easier, not to say feasible. ...
and later, on arithmetic:
It must be unthinkable that a NewSpeaker might confuse an element of
a finite integral range with a mathematical integer or a floating point
number with a mathematical real. ... [The possibility of dynamically
produced exceptional values, even if they can be trapped in the language]
is roughly equivalent to a cross between GOTOs and interrupts, both of
which are anathemas to the ThoughtPolice and should be unNewSpeakable.
(Hence the Draconian measures described above.)
Good Thoughts only from now on, then, eh?
David Bruce
----
post: DRA Malvern, St Andrews Road, Malvern, Worcestershire WR14 3PS, ENGLAND
··········@dra.hmg.gb ** phone: +44 1684 895112 ** fax: +44 1684 894389
From: Rob Warnock
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c1ihq$5e3@tokyo.engr.sgi.com>
John Bayko <·····@borealis.cs.uregina.ca> wrote:
+---------------
| Basically, C was the first high level language that was low level
| enough to be useful, getting rid of the conventional abstractions that
| got in the way.
+---------------
Hah! The BLISS language was availabe to non-DEC users long before C was
available to non-AT&T users, had all the usual arithmetic operators, had
no I/O built into the language, a much nicer bit-twiddling structure system,
a *much* nicer macro system, and nicer/cleaner hooks for connecting to
other languages and environments (e.g., you could explicitly declare a
procedure to use "LINKAGE INTERRUPT", neat for writing drivers). And the
code quality of the BLISS-11 compiler [a couple of years after BLISS-10]
was far, *far* better than any C compiler would achieve for more than a
decade to come. But being proprietary to DEC hardware killed it...
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
From: John Bayko
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cglf1$5k4@sue.cc.uregina.ca>
In article <··········@hplb.hpl.hp.com>, <···@hplb.hpl.hp.com> wrote:
>John Bayko (·····@borealis.cs.uregina.ca) wrote:
>| Theory #51 of "Why C became the most popular language": C was the
>|first language where I/O was *not* part of the language.
>
>Algol-60 disproves your theory. (How about Algol-58?)
>
>The rest of your post is similarly perceptive, as well.
Algol-60 was not *a* language - it was at least three. In fact,
each implementation could almost be considered a different language,
as far as syntax details.
Remember I also mentioned a language couldn't be popular if it
gave up very much that programmers took for granted. FORTRAN could be
run almost unchanged on any system. Algol? Good luck...
--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
John Bayko (·····@borealis.cs.uregina.ca) wrote:
|In article <··········@hplb.hpl.hp.com>, <···@hplb.hpl.hp.com> wrote:
|>John Bayko (·····@borealis.cs.uregina.ca) wrote:
|>| Theory #51 of "Why C became the most popular language": C was the
|>|first language where I/O was *not* part of the language.
|>
|>Algol-60 disproves your theory. (How about Algol-58?)
|>
|>The rest of your post is similarly perceptive, as well.
| Algol-60 was not *a* language - it was at least three. In fact,
|each implementation could almost be considered a different language,
|as far as syntax details.
I don't remember that which you are asserting. However, you are now asserting
that 3 languagues without i/o preceeded C !
| Remember I also mentioned a language couldn't be popular if it
|gave up very much that programmers took for granted. FORTRAN could be
|run almost unchanged on any system. Algol? Good luck...
True, but that is orthogonal to your assertion.
--
===============================================================================
The above are my own views, not the views of HP
Tom Gardner Hewlett Packard Laboratories, Filton Rd,
···@hplb.hpl.hp.com Stoke Gifford, Bristol, Avon, BS12 6QZ, ENGLAND.
Fax: +44 117 9228924 Tel: +44 117 9799910 ext. 28192
===============================================================================
> Unfortunately, your assertion is not, IMHO, true.
> C was NOT the first language without I/O. Try ALGOL 68
ALGOL wasn't a language. ALGOL was at least three languages, and
no-one really knew which one to use...
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca (John Bayko) writes:
> Theory #51 of "Why C became the most popular language": C was the
>first language where I/O was *not* part of the language. All I/O was via
>functions, so calling functions to to anything becomes second nature
>from the very first 'hello world' program a user writes. And because
>there's a variety of functions for different needs, it's no stretch at
>all to switch to GUI-oriented functions for I/O.
> For comparison, I've written toy programs in LISP, and it's fun,
>but how would you write a windowing system or database in it? I'm sure
>LISP experts could do that with their eyes closed, but it's not
>obvious in the structure of the language...
Huh??? I/O in Lisp is via functions, exactly the same as in
C. Actually Lisp takes the matter even further. In C I/O is not
built-in, but arithmetic is. In Lisp, almost nothing is built
in. Everything is a function, including arithmetic.
So I don't know what you are talking about.
> Pascal was good because I/O *looked* like procedures at least, but
>had its own limits - how do you extract the middle four bits in a
>byte? When you access a field through a couple of structures and
>pointers, which order to the ^ and . go in?
And C is supposed to be *good* in this regard??? What order do all the
-> and . and * and () go in when declaring structures, pointers and
function pointers??? I've been hacking C for 10 years now and I've
still got to look this up sometimes.
> Basically, C was the first high level language that was low level
>enough to be useful, getting rid of the conventional abstractions that
>got in the way.
I don't know that it was the first. I'd imagine LISP had functions for
extracting bits and so-forth well before C was even thought of.
>Now we just take that for granted - when was the last
>language you've seen designed where I/O was not a
>function/procedure/method, and which didn't have most if not all of C's
>operators?
Huh?? How many languages *do* have all of C's operators? C, C++ and
Java. That's it. That's the lot. You've lived a sheltered life.
> That's another lesson - no new 'new idea' language will survive if
>you have to give up something. That's why Object Pascal died, and C++
>survived. And that's why Java's virtual machine is becoming popular,
>even though it's basically the same as the USCD Pascal's p-Machine -
>it doesn't make you give up C features or C++ features, while you lose
>both switching to Pascal (not to mention the p-Machine was only 16
>bits).
On the contrary. Java makes you give up all the low level C and C++
nasties. So your theory is bunk.
····@rigden.engr.sgi.com (Rob Warnock) writes:
>
> Hah! The BLISS language was availabe to non-DEC users long before C was
> available to non-AT&T users, had all the usual arithmetic operators, had
> no I/O built into the language, a much nicer bit-twiddling structure system,
> a *much* nicer macro system, and nicer/cleaner hooks for connecting to
> other languages and environments (e.g., you could explicitly declare a
> procedure to use "LINKAGE INTERRUPT", neat for writing drivers). And the
> code quality of the BLISS-11 compiler [a couple of years after BLISS-10]
> was far, *far* better than any C compiler would achieve for more than a
> decade to come. But being proprietary to DEC hardware killed it...
>
It also had a language reference manual as thick as a telephone book.
It seems to me that I learned BLISS by reading other peoples code.
That is not unusual. What is unusual is that two years after I had
learned BLISS, other people where able to tell me what programs I had
learned from based on the coding idioms I still used.
BLISS was powerful and occasionally pretty but I learned C in a
fraction of the time, and I can read C code written by experienced
engineers with relative ease. The only thing I really miss is the
macro facilities.
--
Fergus is just a character from a book. I'm Colin Benson. (310)
828-3400 or ·······@retix.com
Fergus Mixolydian <·······@macaw.retix.com> wrote:
>It also had a language reference manual as thick as a telephone book.
>It seems to me that I learned BLISS by reading other peoples code.
>That is not unusual. What is unusual is that two years after I had
>learned BLISS, other people where able to tell me what programs I had
>learned from based on the coding idioms I still used.
Then you used it in the wrong way. The correct way to use BLISS was to study
the microfiches of the parts of VMS generated from BLISS source code (i.e.
the generated assembler) and learn some neat MACRO idiom from that :-)
--
Toon Moene (···········@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: ··············@gnu.ai.mit.edu; NWP: http://www.knmi.nl/hirlam
In article <··········@web.nmti.com> ·····@nmti.com (Peter da Silva) writes:
>In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>> _I'd_ like to have a language that defined the width of integers.
>
>I wouldn't. I've been there, and the biggest pain porting PL/I programs from
>one machine to another is you can't tell whether they really needed a 35
>bit signed integer or they were just optimising for a 36 bit word (w/sign).
>
>I'd like to be able to say "int:16" when I needed a 16 bit integer, but for
>most cases it's been much easier porting programs from 16-32-64 bit over the
>years than porting between 32 and 36 bit PL/Is.
Actually, the really correct way to do it, is to specify precicely
what range to support. Like int:-2000,75000 or some such to specify
exactly what range you will use. Then if there is some hypothetical
machine with 20bit words, you don't have to upgrade to 32 bits when
porting just for safety's sake. Oh, and a nice implementation would
have a checking mode to tell you when you've exceeded your
self-imposed limit. Better than having a limited exception facility
where the only boundaries you can impose are 16, 32 and 64 bits.
From: Tony Finch
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c6bae$og9@dex.trin.cam.ac.uk>
·············@Alcatel.com.au wrote:
>
>Actually, the really correct way to do it, is to specify precicely
>what range to support. Like int:-2000,75000 or some such to specify
>exactly what range you will use. Then if there is some hypothetical
>machine with 20bit words, you don't have to upgrade to 32 bits when
>porting just for safety's sake. Oh, and a nice implementation would
>have a checking mode to tell you when you've exceeded your
>self-imposed limit.
But you have to make sure that your limits are right. There's more to
hardware than just the CPU, as the Arianne 5 people will tell you.
Tony.
--
(S(SKK)(SKK))(S(SKK)(SKK))
From: David Shepherd
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cks80$15g@milkwort.bri.st.com>
Chris Bitmead <·············@Alcatel.com.au> wrote:
: Actually, the really correct way to do it, is to specify precicely
: what range to support. Like int:-2000,75000 or some such to specify
: exactly what range you will use. Then if there is some hypothetical
: machine with 20bit words, you don't have to upgrade to 32 bits when
: porting just for safety's sake. Oh, and a nice implementation would
: have a checking mode to tell you when you've exceeded your
: self-imposed limit. Better than having a limited exception facility
: where the only boundaries you can impose are 16, 32 and 64 bits.
I think that sounds rather like the (experimental) language "NewSpeak"
that was being developed at, I think, RSRE (a UK defence establisment)
for "verified" applications.
--
--------------------------------------------------------------------------
david shepherd
SGS-THOMSON Microelectronics Ltd, 1000 aztec west, bristol bs12 4sq, u.k.
tel/fax: +44 1454 611522/617910 email: ···@bristol.st.com
"whatever you don't want, you don't want negative advertising"
From: Chris Torek
Subject: Re: superior(?) programming languages
Date:
Message-ID: <5c4vgg$hoe@elf.bsdi.com>
(This article is rather a bit off-topic for all these groups, for
which I apologize.)
In article <························@phu989.um.us.sbphrd.com>
John R. Campbell <····@jtan.com> writes:
>C is merely an enhanced macro-assembler originally written for
>the PDP-11 (if you look at the adressing modes in the -11 you'll
>recognize where C's come from).
This claim is popular, but false. As Dennis Ritchie's paper on the
development of the C language notes:
Thompson went a step further by inventing the ++ and --
operators.... They were not in the earliest versions of
B, but appeared along the way. People often guess that
they were created to use the auto-increment and auto-decrement
address modes provided by the DEC PDP-11 on which C and
Unix first became popular. This is historically impossible,
since there was no PDP-11 when B was developed. ...
The full PostScript text of the document appears below.
>BTW, this wasn't really meant as a troll; I've maintained my
>eclectic background by not taking my language preferences
>seriously.
(Just leaving the above in for the record. :-) )
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: ·····@bsdi.com +1 510 234 3167
[The Development of the C Language]
%!PS
%%Version: 3.3.1
%%DocumentFonts: (atend)
%%Pages: (atend)
%%EndComments
%
% Version 3.3.1 prologue for troff files.
%
/#copies 1 store
/aspectratio 1 def
/formsperpage 1 def
/landscape false def
/linewidth .3 def
/magnification 1 def
/margin 0 def
/orientation 0 def
/resolution 720 def
/rotation 1 def
/xoffset 0 def
/yoffset 0 def
/roundpage true def
/useclippath true def
/pagebbox [0 0 612 792] def
/R /Times-Roman def
/I /Times-Italic def
/B /Times-Bold def
/BI /Times-BoldItalic def
/H /Helvetica def
/HI /Helvetica-Oblique def
/HB /Helvetica-Bold def
/HX /Helvetica-BoldOblique def
/CW /Courier def
/CO /Courier def
/CI /Courier-Oblique def
/CB /Courier-Bold def
/CX /Courier-BoldOblique def
/PA /Palatino-Roman def
/PI /Palatino-Italic def
/PB /Palatino-Bold def
/PX /Palatino-BoldItalic def
/Hr /Helvetica-Narrow def
/Hi /Helvetica-Narrow-Oblique def
/Hb /Helvetica-Narrow-Bold def
/Hx /Helvetica-Narrow-BoldOblique def
/KR /Bookman-Light def
/KI /Bookman-LightItalic def
/KB /Bookman-Demi def
/KX /Bookman-DemiItalic def
/AR /AvantGarde-Book def
/AI /AvantGarde-BookOblique def
/AB /AvantGarde-Demi def
/AX /AvantGarde-DemiOblique def
/NR /NewCenturySchlbk-Roman def
/NI /NewCenturySchlbk-Italic def
/NB /NewCenturySchlbk-Bold def
/NX /NewCenturySchlbk-BoldItalic def
/ZD /ZapfDingbats def
/ZI /ZapfChancery-MediumItalic def
/S /S def
/S1 /S1 def
/GR /Symbol def
/inch {72 mul} bind def
/min {2 copy gt {exch} if pop} bind def
/setup {
counttomark 2 idiv {def} repeat pop
landscape {/orientation 90 orientation add def} if
/scaling 72 resolution div def
linewidth setlinewidth
1 setlinecap
pagedimensions
xcenter ycenter translate
orientation rotation mul rotate
width 2 div neg height 2 div translate
xoffset inch yoffset inch neg translate
margin 2 div dup neg translate
magnification dup aspectratio mul scale
scaling scaling scale
addmetrics
0 0 moveto
} def
/pagedimensions {
useclippath userdict /gotpagebbox known not and {
/pagebbox [clippath pathbbox newpath] def
roundpage currentdict /roundpagebbox known and {roundpagebbox} if
} if
pagebbox aload pop
4 -1 roll exch 4 1 roll 4 copy
landscape {4 2 roll} if
sub /width exch def
sub /height exch def
add 2 div /xcenter exch def
add 2 div /ycenter exch def
userdict /gotpagebbox true put
} def
/addmetrics {
/Symbol /S null Sdefs cf
/Times-Roman /S1 StandardEncoding dup length array copy S1defs cf
} def
/pagesetup {
/page exch def
currentdict /pagedict known currentdict page known and {
page load pagedict exch get cvx exec
} if
} def
/decodingdefs [
{counttomark 2 idiv {y moveto show} repeat}
{neg /y exch def counttomark 2 idiv {y moveto show} repeat}
{neg moveto {2 index stringwidth pop sub exch div 0 32 4 -1 roll widthshow} repeat}
{neg moveto {spacewidth sub 0.0 32 4 -1 roll widthshow} repeat}
{counttomark 2 idiv {y moveto show} repeat}
{neg setfunnytext}
] def
/setdecoding {/t decodingdefs 3 -1 roll get bind def} bind def
/w {neg moveto show} bind def
/m {neg dup /y exch def moveto} bind def
/done {/lastpage where {pop lastpage} if} def
/f {
dup /font exch def findfont exch
dup /ptsize exch def scaling div dup /size exch def scalefont setfont
linewidth ptsize mul scaling 10 mul div setlinewidth
/spacewidth ( ) stringwidth pop def
} bind def
/changefont {
/fontheight exch def
/fontslant exch def
currentfont [
1 0
fontheight ptsize div fontslant sin mul fontslant cos div
fontheight ptsize div
0 0
] makefont setfont
} bind def
/sf {f} bind def
/cf {
dup length 2 idiv
/entries exch def
/chtab exch def
/newencoding exch def
/newfont exch def
findfont dup length 1 add dict
/newdict exch def
{1 index /FID ne {newdict 3 1 roll put}{pop pop} ifelse} forall
newencoding type /arraytype eq {newdict /Encoding newencoding put} if
newdict /Metrics entries dict put
newdict /Metrics get
begin
chtab aload pop
1 1 entries {pop def} for
newfont newdict definefont pop
end
} bind def
%
% A few arrays used to adjust reference points and character widths in some
% of the printer resident fonts. If square roots are too high try changing
% the lines describing /radical and /radicalex to,
%
% /radical [0 -75 550 0]
% /radicalex [-50 -75 500 0]
%
% Move braceleftbt a bit - default PostScript character is off a bit.
%
/Sdefs [
/bracketlefttp [201 500]
/bracketleftbt [201 500]
/bracketrighttp [-81 380]
/bracketrightbt [-83 380]
/braceleftbt [203 490]
/bracketrightex [220 -125 500 0]
/radical [0 0 550 0]
/radicalex [-50 0 500 0]
/parenleftex [-20 -170 0 0]
/integral [100 -50 500 0]
/infinity [10 -75 730 0]
] def
/S1defs [
/underscore [0 80 500 0]
/endash [7 90 650 0]
] def
%
% Tries to round clipping path dimensions, as stored in array pagebbox, so they
% match one of the known sizes in the papersizes array. Lower left coordinates
% are always set to 0.
%
/roundpagebbox {
7 dict begin
/papersizes [8.5 inch 11 inch 14 inch 17 inch] def
/mappapersize {
/val exch def
/slop .5 inch def
/diff slop def
/j 0 def
0 1 papersizes length 1 sub {
/i exch def
papersizes i get val sub abs
dup diff le {/diff exch def /j i def} {pop} ifelse
} for
diff slop lt {papersizes j get} {val} ifelse
} def
pagebbox 0 0 put
pagebbox 1 0 put
pagebbox dup 2 get mappapersize 2 exch put
pagebbox dup 3 get mappapersize 3 exch put
end
} bind def
%%EndProlog
%%BeginSetup
mark
/linewidth 0.5 def
/xoffset 0 def
/yoffset 0 def
/#copies 1 store
/magnification 1 def
%%FormsPerPage: 1
/formsperpage 1 def
%%Patch from lp
%%EndPatch
/landscape false def
/resolution 720 def
setup
2 setdecoding
%%EndSetup
%%Page: 1 1
/saveobj save def
mark
1 pagesetup
13 B f
(The Development of the C Language\262)5 2100 1 2190 1230 t
11 I f
(Dennis M. Ritchie)2 797 1 2841 1470 t
(AT&T Bell Laboratories)2 1086 1 2697 1590 t
( USA)1 257(Murray Hill, NJ 07974)3 1016 2 2603 1710 t
11 CW f
(···@research.att.com)2580 1950 w
11 I f
(ABSTRACT)2979 2400 w
11 R f
( the early 1970s as a system)6 1294(The C programming language was devised in)6 2056 2 1690 2670 t
( from)1 253( Derived)1 420( Unix operating system.)3 1088(implementation language for the nascent)4 1839 4 1440 2790 t
(the typeless language BCPL, it evolved a type structure; created on a tiny)12 3600 1 1440 2910 t
( environment, it has become)4 1251(machine as a tool to improve a meager programming)8 2349 2 1440 3030 t
( paper studies its evolution.)4 1209( This)1 252(one of the dominant languages of today.)6 1768 3 1440 3150 t
11 B f
(Introduction)1080 3510 w
11 R f
( it, and the)3 472(This paper is about the development of the C programming language, the influences on)13 3848 2 1080 3666 t
( the sake of brevity, I omit full descriptions of C itself,)11 2413( For)1 210( it was created.)3 661(conditions under which)2 1036 4 1080 3786 t
( BCPL [Richards 79], and instead concentrate on)7 2253(its parent B [Johnson 73] and its grandparent)7 2067 2 1080 3906 t
(characteristic elements of each language and how they evolved.)8 2792 1 1080 4026 t
( in the years 1969-1973, in parallel with the early development of the)12 3224(C came into being)3 846 2 1330 4182 t
( spate of changes)3 761( Another)1 418( system; the most creative period occurred during 1972.)8 2475(Unix operating)1 666 4 1080 4302 t
( In)1 150( demonstrated.)1 650(peaked between 1977 and 1979, when portability of the Unix system was being)12 3520 3 1080 4422 t
( period, the first widely available description of the language appeared:)10 3185(the middle of this second)4 1135 2 1080 4542 t
11 I f
(The C Programming Language,)3 1414 1 1080 4662 t
11 R f
( Finally,)1 400( `white book' or `K&R' [Kernighan 78].)6 1796(often called the)2 680 3 2524 4662 t
( X3J11 committee,)2 865(in the middle 1980s, the language was officially standardized by the ANSI)11 3455 2 1080 4782 t
( early 1980s, although compilers existed for a variety of)9 2559( the)1 172( Until)1 293(which made further changes.)3 1296 4 1080 4902 t
( associated)1 499(machine architectures and operating systems, the language was almost exclusively)9 3821 2 1080 5022 t
( among the lan-)3 720(with Unix; more recently, its use has spread much more widely, and today it is)14 3600 2 1080 5142 t
(guages most commonly used throughout the computer industry.)7 2807 1 1080 5262 t
11 B f
(History: the setting)2 903 1 1080 5502 t
11 R f
( research at Bell Telephone Labo-)5 1513(The late 1960s were a turbulent era for computer systems)9 2557 2 1330 5658 t
( Multics project [Organick)3 1174( company was pulling out of the)6 1437( The)1 229(ratories [Ritchie 78] [Ritchie 84].)4 1480 4 1080 5778 t
( 1969, Bell)2 504(75], which had started as a joint venture of MIT, General Electric, and Bell Labs; by)15 3816 2 1080 5898 t
(Labs management, and even the researchers, came to believe that the promises of Multics could)14 4320 1 1080 6018 t
( before the GE-645 Multics machine was)6 1907( Even)1 298( late and too expensively.)4 1189(be fulfilled only too)3 926 4 1080 6138 t
( Thompson, had begun)3 1072(removed from the premises, an informal group, led primarily by Ken)10 3248 2 1080 6258 t
(investigating alternatives.)1 1130 1 1080 6378 t
( constructed according to)3 1118(Thompson wanted to create a comfortable computing environment)7 2952 2 1330 6534 t
( plans, it is evident in retrospect,)6 1558( His)1 230( whatever means were available.)4 1510(his own design, using)3 1022 4 1080 6654 t
9 S1 f
(________________)1080 6764 w
9 R f
( electronic reprint made available by the)6 1495( This)1 213( Machinery, Inc.)2 611(\262Copyright 1993 Association for Computing)4 1641 4 1080 6874 t
( presented at)2 458( article was)2 415( This)1 208( further publication rights contact ACM or the author.)8 1958( For)1 173(author as a courtesy.)3 748 6 1080 6984 t
(Second History of Programming Languages conference, Cambridge, Mass., April, 1993.)9 3195 1 1080 7094 t
cleartomark
showpage
saveobj restore
%%EndPage: 1 1
%%Page: 2 2
/saveobj save def
mark
2 pagesetup
11 I f
( 2)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( a process)2 444(incorporated many of the innovative aspects of Multics, including an explicit notion of)12 3876 2 1080 840 t
( system, a command interpreter as user-level program,)7 2436(as a locus of control, a tree-structured file)7 1884 2 1080 960 t
( excluded others, such)3 988( They)1 285(simple representation of text files, and generalized access to devices.)9 3047 3 1080 1080 t
( the start, moreover, he and the rest of us deferred)10 2282( At)1 176( memory and to files.)4 979(as unified access to)3 883 4 1080 1200 t
( exclusively in)2 644(another pioneering \(though not original\) element of Multics, namely writing almost)10 3676 2 1080 1320 t
( Multics, was not much to our)6 1428( the implementation language of)4 1499( PL/I,)1 299(a higher-level language.)2 1094 4 1080 1440 t
( BCPL, and we regretted losing the)6 1670(tastes, but we were also using other languages, including)8 2650 2 1080 1560 t
( above the level of assembler, such as ease of writ-)10 2278(advantages of writing programs in a language)6 2042 2 1080 1680 t
( weight on portability; interest)4 1354( the time we did not put much)7 1348( At)1 170(ing and clarity of understanding.)4 1448 4 1080 1800 t
(in this arose later.)3 782 1 1080 1920 t
( even for the time:)4 834(Thompson was faced with a hardware environment cramped and spartan)9 3236 2 1330 2076 t
( in 1968 was a machine with 8K 18-bit words of memory and)12 2719(the DEC PDP-7 on which he started)6 1601 2 1080 2196 t
( wanting to use a higher-level language, he wrote the original)10 2794( While)1 334(no software useful to him.)4 1192 3 1080 2316 t
( not even program on the PDP-7 itself, but)8 1909( the start, he did)4 731( At)1 172(Unix system in PDP-7 assembler.)4 1508 4 1080 2436 t
( postprocessor)1 639( A)1 143( GEMAP assembler on a GE-635 machine.)6 1943(instead used a set of macros for the)7 1595 4 1080 2556 t
(generated a paper tape readable by the PDP-7.)7 2027 1 1080 2676 t
( a primitive)2 536(These tapes were carried from the GE machine to the PDP-7 for testing until)13 3534 2 1330 2832 t
( editor, an assembler, a simple shell \(command interpreter\), and a few utilities)12 3608(Unix kernel, an)2 712 2 1080 2952 t
(\(like the Unix)2 613 1 1080 3072 t
11 I f
(rm, cat, cp)2 473 1 1722 3072 t
11 R f
( this point, the operating system was)6 1619( After)1 288(commands\) were completed.)2 1268 3 2225 3072 t
( tested without resort to paper tape, and develop-)8 2209(self-supporting: programs could be written and)5 2111 2 1080 3192 t
(ment continued on the PDP-7 itself.)5 1579 1 1080 3312 t
( assembler outdid even DEC's in simplicity; it evaluated expressions)9 3182(Thompson's PDP-7)1 888 2 1330 3468 t
( libraries, no loader or link editor: the entire)8 2007( were no)2 399( There)1 321(and emitted the corresponding bits.)4 1593 4 1080 3588 t
( file\320with a fixed name\320that)4 1357(source of a program was presented to the assembler, and the output)11 2963 2 1080 3708 t
( name,)1 302( \(This)1 297(emerged was directly executable.)3 1487 3 1080 3828 t
11 I f
(a.out)3203 3828 w
11 R f
( is the)2 280(, explains a bit of Unix etymology; it)7 1693 2 3427 3828 t
( another)1 360( after the system gained a linker and a means of specifying)11 2610( Even)1 284(output of the assembler.)3 1066 4 1080 3948 t
(name explicitly, it was retained as the default executable result of a compilation.\))12 3570 1 1080 4068 t
( in 1969, Doug McIlroy created the new system's)8 2184(Not long after Unix first ran on the PDP-7,)8 1886 2 1330 4224 t
( is a lan-)3 388( TMG)1 305(first higher-level language: an implementation of McClure's TMG [McClure 65].)9 3627 3 1080 4344 t
(guage for writing compilers \(more generally, TransMoGrifiers\) in a top-down, recursive-descent)10 4320 1 1080 4464 t
( and Bob)2 440( McIlroy)1 436( context-free syntax notation with procedural elements.)6 2550(style that combines)2 894 4 1080 4584 t
(Morris had used TMG to write the early PL/I compiler for Multics.)11 2951 1 1080 4704 t
( feat in reproducing TMG, Thompson decided that Unix\320possibly)8 2964(Challenged by McIlroy's)2 1106 2 1330 4860 t
( a rapidly scut-)3 677( After)1 293( system programming language.)3 1432(it had not even been named yet\320needed a)7 1918 4 1080 4980 t
( can be)2 332( B)1 141( instead a language of his own, which he called B.)10 2315(tled attempt at Fortran, he created)5 1532 4 1080 5100 t
( squeezed into 8K bytes of memory)6 1623(thought of as C without types; more accurately, it is BCPL)10 2697 2 1080 5220 t
( name most probably represents a contraction of)7 2295( Its)1 192( Thompson's brain.)2 911(and filtered through)2 922 4 1080 5340 t
( it derives from Bon [Thompson 69], an unrelated)8 2294(BCPL, though an alternate theory holds that)6 2026 2 1080 5460 t
( named either after his)4 1013( in turn was)3 538( Bon)1 247(language created by Thompson during the Multics days.)7 2522 4 1080 5580 t
( manual\), after a religion whose rit-)6 1570(wife Bonnie, or \(according to an encyclopedia quotation in its)9 2750 2 1080 5700 t
(uals involve the murmuring of magic formulas.)6 2081 1 1080 5820 t
11 B f
(Origins: the languages)2 1060 1 1080 6060 t
11 R f
( visiting MIT, and)3 830(BCPL was designed by Martin Richards in the mid-1960s while he was)11 3240 2 1330 6216 t
( for several interesting projects, among them the OS6 operating)9 2862(was used during the early 1970s)5 1458 2 1080 6336 t
( Oxford [Stoy 72], and parts of the seminal Alto work at Xerox PARC [Thacker 79].)15 3896(system at)1 424 2 1080 6456 t
( because the MIT CTSS system [Corbato 62] on which Richards)10 3035(We became familiar with it)4 1285 2 1080 6576 t
( original BCPL compiler was transported both to)7 2178( The)1 229(worked was used for Multics development.)5 1913 3 1080 6696 t
( Labs [Canaday)2 702(Multics and to the GE-635 GECOS system by Rudd Canaday and others at Bell)13 3618 2 1080 6816 t
( and immediately after, it was the lan-)7 1744(69]; during the final throes of Multics's life at Bell Labs)10 2576 2 1080 6936 t
(guage of choice among the group of people who would later become involved with Unix.)14 3928 1 1080 7056 t
( typified by Fortran and)4 1093(BCPL, B, and C all fit firmly in the traditional procedural family)11 2977 2 1330 7212 t
cleartomark
showpage
saveobj restore
%%EndPage: 2 2
%%Page: 3 3
/saveobj save def
mark
3 pagesetup
11 I f
( 3)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( small and compactly)3 956( are particularly oriented towards system programming, are)7 2652( They)1 288(Algol 60.)1 424 4 1080 840 t
( are `close to the machine')5 1190( They)1 287(described, and are amenable to translation by simple compilers.)8 2843 3 1080 960 t
( the concrete data types and opera-)6 1557(in that the abstractions they introduce are readily grounded in)9 2763 2 1080 1080 t
( by conventional computers, and they rely on library routines for input-output and)12 3697(tions supplied)1 623 2 1080 1200 t
( less success, they also use library procedures to)8 2114( With)1 277(other interactions with an operating system.)5 1929 3 1080 1320 t
( the same)2 453( At)1 185( procedure closures.)2 917(specify interesting control constructs such as coroutines and)7 2765 4 1080 1440 t
( between)1 425(time, their abstractions lie at a sufficiently high level that, with care, portability)12 3895 2 1080 1560 t
(machines can be achieved.)3 1168 1 1080 1680 t
( Programs)1 481( are similar.)2 530(BCPL, B and C differ syntactically in many details, but broadly they)11 3059 3 1330 1836 t
( Procedures)1 557( global declarations and function \(procedure\) declarations.)6 2651(consist of a sequence of)4 1112 3 1080 1956 t
( may not refer to non-static objects defined in containing procedures.)10 3089(can be nested in BCPL, but)5 1231 2 1080 2076 t
( Each)1 279( no nested procedures at all.)5 1251(B and C avoid this restriction by imposing a more severe one:)11 2790 3 1080 2196 t
( earliest versions of B\) recognizes separate compilation, and provides)9 3085(of the languages \(except for)4 1235 2 1080 2316 t
(a means for including text from named files.)7 1954 1 1080 2436 t
( those)1 266(Several syntactic and lexical mechanisms of BCPL are more elegant and regular than)12 3804 2 1330 2592 t
( example, BCPL's procedure and data declarations have a more uniform struc-)11 3560( For)1 219( C.)1 140(of B and)2 401 4 1080 2712 t
( programs are)2 630( BCPL)1 318( Although)1 485(ture, and it supplies a more complete set of looping constructs.)10 2887 4 1080 2832 t
( from an undelimited stream of characters, clever rules allow most semicolons)11 3468(notionally supplied)1 852 2 1080 2952 t
( convenience, and end)3 980( and C omit this)4 711( B)1 131(to be elided after statements that end on a line boundary.)10 2498 4 1080 3072 t
( spite of the differences, most of the statements and opera-)10 2655( In)1 156(most statements with semicolons.)3 1509 3 1080 3192 t
(tors of BCPL map directly into corresponding B and C.)9 2442 1 1080 3312 t
( limitations on inter-)3 913(Some of the structural differences between BCPL and B stemmed from)10 3157 2 1330 3468 t
( example, BCPL declarations may take the form)7 2119( For)1 209(mediate memory.)1 769 3 1080 3588 t
10 CW f
(let P1 be)2 540 1 1368 3758 t
10 I f
(command)1968 3758 w
10 CW f
(and P2 be)2 540 1 1368 3868 t
10 I f
(command)1968 3868 w
10 CW f
(and P3 be)2 540 1 1368 3978 t
10 I f
(command)1968 3978 w
10 CW f
(...)1428 4088 w
11 R f
( subdecla-)1 453( The)1 232( the commands contains whole procedures.)5 1921(where the program text represented by)5 1714 4 1080 4268 t
(rations connected by)2 924 1 1080 4388 t
11 CW f
(and)2040 4388 w
11 R f
(occur simultaneously, so the name)4 1550 1 2274 4388 t
11 CW f
(P3)3860 4388 w
11 R f
(is known inside procedure)3 1177 1 4028 4388 t
11 CW f
(P1)5240 4388 w
11 R f
(.)5372 4388 w
( into an expression that)4 1109(Similarly, BCPL can package a group of declarations and statements)9 3211 2 1080 4508 t
(yields a value, for example)4 1186 1 1080 4628 t
10 CW f
(E1 := valof $\()3 840 1 1368 4798 t
10 I f
(declarations)2268 4798 w
10 CW f
(;)2828 4798 w
10 I f
(commands)2948 4798 w
10 CW f
(; resultis E2 $\) + 1)5 1200 1 3435 4798 t
11 R f
( and analyzing a parsed representa-)5 1546(The BCPL compiler readily handled such constructs by storing)8 2774 2 1080 4978 t
( limitations on the B com-)5 1161( Storage)1 392( in memory before producing output.)5 1630(tion of the entire program)4 1137 4 1080 5098 t
( the)1 169(piler demanded a one-pass technique in which output was generated as soon as possible, and)14 4151 2 1080 5218 t
(syntactic redesign that made this possible was carried forward into C.)10 3055 1 1080 5338 t
( to its own technological problems and were)7 2050(Certain less pleasant aspects of BCPL owed)6 2020 2 1330 5494 t
( BCPL uses a `global vector' mechanism)6 1862( example,)1 438( For)1 220(consciously avoided in the design of B.)6 1800 4 1080 5614 t
( programmer)1 596( this scheme, the)3 812( In)1 173(for communicating between separately compiled programs.)5 2739 4 1080 5734 t
( visible procedure and data object with a numeric)8 2181(explicitly associates the name of each externally)6 2139 2 1080 5854 t
( is accomplished in the compiled code by using these)9 2527(offset in the global vector; the linkage)6 1793 2 1080 5974 t
( by insisting that the entire program be pre-)8 1914( evaded this inconvenience initially)4 1565( B)1 132(numeric offsets.)1 709 4 1080 6094 t
( all those of C, use a conven-)7 1312( implementations of B, and)4 1213( Later)1 290(sented all at once to the compiler.)6 1505 4 1080 6214 t
( placing)1 359(tional linker to resolve external names occurring in files compiled separately, instead of)12 3961 2 1080 6334 t
(the burden of assigning offsets on the programmer.)7 2246 1 1080 6454 t
( of taste, and)3 604(Other fiddles in the transition from BCPL to B were introduced as a matter)13 3466 2 1330 6610 t
( single character)2 727(some remain controversial, for example the decision to use the)9 2806 2 1080 6730 t
11 CW f
(=)4646 6730 w
11 R f
(for assignment)1 655 1 4745 6730 t
(instead of)1 439 1 1080 6850 t
11 CW f
(:=)1556 6850 w
11 R f
( B uses)2 337(. Similarly,)1 532 2 1688 6850 t
11 CW f
(/* */)1 318 1 2594 6850 t
11 R f
(to enclose comments, where BCPL uses)5 1811 1 2949 6850 t
11 CW f
(//)4798 6850 w
11 R f
(, to ignore)2 470 1 4930 6850 t
( has resurrected the BCPL)4 1157( \(C++)1 291( here.)1 244( legacy of PL/I is evident)5 1119( The)1 228(text up to the end of the line.)7 1281 6 1080 6970 t
( influenced the syntax of declarations: B declarations begin with a)10 2945( Fortran)1 383(comment convention.\))1 992 3 1080 7090 t
(specifier like)1 576 1 1080 7210 t
11 CW f
(auto)1691 7210 w
11 R f
(or)1990 7210 w
11 CW f
(static)2116 7210 w
11 R f
( not only followed this style)5 1265(, followed by a list of names, and C)8 1623 2 2512 7210 t
cleartomark
showpage
saveobj restore
%%EndPage: 3 3
%%Page: 4 4
/saveobj save def
mark
4 pagesetup
11 I f
( 4)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
(but ornamented it by placing its type keywords at the start of declarations.)12 3259 1 1080 840 t
( BCPL language documented in Richards's book [Richards)7 2612(Not every difference between the)4 1458 2 1330 996 t
( exam-)1 307( For)1 215( earlier version of BCPL [Richards 67].)6 1773(79] and B was deliberate; we started from an)8 2025 4 1080 1116 t
(ple, the)1 333 1 1080 1236 t
11 CW f
(endcase)1450 1236 w
11 R f
(that escapes from a BCPL)4 1184 1 1949 1236 t
11 CW f
(switchon)3170 1236 w
11 R f
( not present in the lan-)5 1037(statement was)1 628 2 3735 1236 t
( the)1 167(guage when we learned it in the 1960s, and so the overloading of)12 2932 2 1080 1356 t
11 CW f
(break)4212 1356 w
11 R f
(keyword to escape)2 825 1 4575 1356 t
(from the B and C)4 765 1 1080 1476 t
11 CW f
(switch)1873 1476 w
11 R f
(statement owes to divergent evolution rather than conscious change.)8 2999 1 2297 1476 t
( B, the core)3 522(In contrast to the pervasive syntax variation that occurred during the creation of)12 3548 2 1330 1632 t
( expression evaluation rules\320remained intact.)4 2072(semantic content of BCPL\320its type structure and)6 2248 2 1080 1752 t
( or `cell,' a fixed-length)4 1061(Both languages are typeless, or rather have a single data type, the `word,')12 3259 2 1080 1872 t
( consists of a linear array of such cells, and the meaning)11 2536( in these languages)3 857( Memory)1 442(bit pattern.)1 485 4 1080 1992 t
( The)1 234(of the contents of a cell depends on the operation applied.)10 2616 2 1080 2112 t
11 CW f
(+)3967 2112 w
11 R f
(operator, for example, simply)3 1330 1 4070 2112 t
(adds its operands using the machine's integer add instruction, and the other arithmetic operations)13 4320 1 1080 2232 t
( memory is a linear)4 913( Because)1 436( of the actual meaning of their operands.)7 1887(are equally unconscious)2 1084 4 1080 2352 t
( supplies an)2 524(array, it is possible to interpret the value in a cell as an index in this array, and BCPL)18 3796 2 1080 2472 t
( was spelled)2 539( the original language it)4 1045( In)1 147(operator for this purpose.)3 1110 4 1080 2592 t
11 CW f
(rv)3950 2592 w
11 R f
(, and later)2 438 1 4082 2592 t
11 CW f
(!)4549 2592 w
11 R f
(, while B uses the)4 785 1 4615 2592 t
(unary)1080 2712 w
11 CW f
(*)1360 2712 w
11 R f
( if)1 98(. Thus,)1 335 2 1426 2712 t
11 CW f
(p)1890 2712 w
11 R f
( \(or address of, or pointer to\) another cell,)8 1852(is a cell containing the index of)6 1399 2 1987 2712 t
11 CW f
(*p)5268 2712 w
11 R f
( of an)2 254(refers to the contents of the pointed-to cell, either as a value in an expression or as the target)18 4066 2 1080 2832 t
(assignment.)1080 2952 w
( the memory array, arithmetic)4 1320(Because pointers in BCPL and B are merely integer indices in)10 2750 2 1330 3108 t
(on them is meaningful: if)4 1126 1 1080 3228 t
11 CW f
(p)2237 3228 w
11 R f
(is the address of a cell, then)6 1236 1 2334 3228 t
11 CW f
(p+1)3601 3228 w
11 R f
( This)1 254(is the address of the next cell.)6 1316 2 3830 3228 t
( in BCPL one writes)4 901( When)1 317(convention is the basis for the semantics of arrays in both languages.)11 3023 3 1080 3348 t
10 CW f
(let V = vec 10)4 840 1 1368 3518 t
11 R f
(or in B,)2 335 1 1080 3698 t
10 CW f
(auto V[10];)1 660 1 1368 3868 t
11 R f
(the effect is the same: a cell named)7 1546 1 1080 4048 t
11 CW f
(V)2655 4048 w
11 R f
( then another group of 10 contiguous cells is set)9 2124(is allocated,)1 526 2 2750 4048 t
( of the first of these is placed into)8 1569(aside, and the memory index)4 1319 2 1080 4168 t
11 CW f
(V)4008 4168 w
11 R f
( a general rule, in B the)6 1101(. By)1 225 2 4074 4168 t
(expression)1080 4288 w
10 CW f
(*\(V+i\))1368 4458 w
11 R f
(adds)1080 4638 w
11 CW f
(V)1310 4638 w
11 R f
(and)1405 4638 w
11 CW f
(i)1592 4638 w
11 R f
(, and refers to the)4 773 1 1658 4638 t
11 CW f
(i)2461 4638 w
11 R f
(-th location after)2 735 1 2527 4638 t
11 CW f
(V)3292 4638 w
11 R f
( BCPL and B each add special notation)7 1741(. Both)1 301 2 3358 4638 t
(to sweeten such array accesses; in B an equivalent expression is)10 2805 1 1080 4758 t
10 CW f
(V[i])1368 4928 w
11 R f
(and in BCPL)2 577 1 1080 5108 t
10 CW f
(V!i)1368 5278 w
11 R f
( was unusual even at the time; C would later assimilate it in an even less)15 3273(This approach to arrays)3 1047 2 1080 5458 t
(conventional way.)1 805 1 1080 5578 t
(None of BCPL, B, or C supports character data strongly in the language; each treats strings)15 4070 1 1330 5734 t
( both BCPL)2 531( In)1 148( by a few conventions.)4 996(much like vectors of integers and supplements general rules)8 2645 4 1080 5854 t
( the)1 179(and B a string literal denotes the address of a static area initialized with the characters of)16 4141 2 1080 5974 t
( the)1 165( BCPL, the first packed byte contains the number of characters in)11 2919( In)1 151(string, packed into cells.)3 1085 4 1080 6094 t
( there is no count and strings are terminated by a special character, which B spelled)15 3780(string; in B,)2 540 2 1080 6214 t
(`)1080 6334 w
11 CW f
(*e)1116 6334 w
11 R f
( length of a string caused by)6 1270( change was made partially to avoid the limitation on the)10 2560('. This)1 322 3 1248 6334 t
( and partly because maintaining the count seemed, in our)9 2566(holding the count in an 8- or 9-bit slot,)8 1754 2 1080 6454 t
(experience, less convenient than using a terminator.)6 2275 1 1080 6574 t
( spreading the string out)4 1072(Individual characters in a BCPL string were usually manipulated by)9 2998 2 1330 6730 t
(into another array, one character per cell, and then repacking it later; B provided corresponding)14 4320 1 1080 6850 t
( library functions that accessed or replaced individual)7 2413(routines, but people more often used other)6 1907 2 1080 6970 t
(characters in a string.)3 938 1 1080 7090 t
cleartomark
showpage
saveobj restore
%%EndPage: 4 4
%%Page: 5 5
/saveobj save def
mark
5 pagesetup
11 I f
( 5)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 B f
(More History)1 636 1 1080 840 t
11 R f
( B in itself \(a bootstrapping)5 1264(After the TMG version of B was working, Thompson rewrote)9 2806 2 1330 996 t
( continually struggled against memory limitations: each language)7 2931( development, he)2 772(step\). During)1 617 3 1080 1116 t
( fit, but each rewrite taking advantage of the fea-)9 2192(addition inflated the compiler so it could barely)7 2128 2 1080 1236 t
( example, B introduced generalized assignment operators, using)7 2873( For)1 218(ture reduced its size.)3 929 3 1080 1356 t
11 CW f
(x=+y)5136 1356 w
11 R f
(to add)1 272 1 1080 1476 t
11 CW f
(y)1380 1476 w
11 R f
(to)1474 1476 w
11 CW f
(x)1588 1476 w
11 R f
( via McIlroy, who had incorpo-)5 1384( notation came from Algol 68 [Wijngaarden 75])7 2108(. The)1 254 3 1654 1476 t
( C, the operator was spelled)5 1246( B and early)3 552( \(In)1 189(rated it into his version of TMG.)6 1471 4 1080 1596 t
11 CW f
(=+)4571 1596 w
11 R f
(instead of)1 435 1 4736 1596 t
11 CW f
(+=)5204 1596 w
11 R f
(;)5369 1596 w
( handling the first form)4 1049(this mistake, repaired in 1976, was induced by a seductively easy way of)12 3271 2 1080 1716 t
(in B's lexical analyzer.\))3 1048 1 1080 1836 t
(Thompson went a step further by inventing the)7 2139 1 1330 1992 t
11 CW f
(++)3508 1992 w
11 R f
(and)3679 1992 w
11 CW f
(--)3876 1992 w
11 R f
(operators, which increment or)3 1352 1 4048 1992 t
( alteration occurs before or after)5 1412(decrement; their prefix or postfix position determines whether the)8 2908 2 1080 2112 t
( versions of B, but appeared along)6 1547( were not in the earliest)5 1058( They)1 287(noting the value of the operand.)5 1428 4 1080 2232 t
( often guess that they were created to use the auto-increment and auto-decrement)12 3587( People)1 358(the way.)1 375 3 1080 2352 t
( is)1 106( This)1 256( first became popular.)3 969(address modes provided by the DEC PDP-11 on which C and Unix)11 2989 4 1080 2472 t
( PDP-7, however,)2 782( The)1 226(historically impossible, since there was no PDP-11 when B was developed.)10 3312 3 1080 2592 t
( an indirect memory refer-)4 1196(did have a few `auto-increment' memory cells, with the property that)10 3124 2 1080 2712 t
( probably suggested such operators to)5 1787( feature)1 357( This)1 279(ence through them incremented the cell.)5 1897 4 1080 2832 t
( the)1 177( Indeed,)1 396( both prefix and postfix was his own.)7 1738(Thompson; the generalization to make them)5 2009 4 1080 2952 t
( of the operators, and a stronger)6 1483(auto-increment cells were not used directly in implementation)7 2837 2 1080 3072 t
( innovation was probably his observation that the translation of)9 3003(motivation for the)2 843 2 1080 3192 t
11 CW f
(++x)4979 3192 w
11 R f
(was)5230 3192 w
(smaller than that of)3 852 1 1080 3312 t
11 CW f
(x=x+1)1960 3312 w
11 R f
(.)2290 3312 w
( instead `threaded)2 797(The B compiler on the PDP-7 did not generate machine instructions, but)11 3273 2 1330 3468 t
( in which the compiler's output consists of a sequence of)10 2568(code' [Bell 72], an interpretive scheme)5 1752 2 1080 3588 t
( operations typically\320in)2 1094( The)1 226(addresses of code fragments that perform the elementary operations.)8 3000 3 1080 3708 t
(particular for B\320act on a simple stack machine.)7 2129 1 1080 3828 t
( PDP-7 Unix system, only a few things were written in B except B itself, because the)16 3773(On the)1 297 2 1330 3984 t
( do more than experiment; rewriting the operating system)8 2568(machine was too small and too slow to)7 1752 2 1080 4104 t
( some point Thomp-)3 909( At)1 170( B was too expensive a step to seem feasible.)9 2015(and the utilities wholly into)4 1226 4 1080 4224 t
( address-space crunch by offering a `virtual B' compiler that allowed the inter-)12 3599(son relieved the)2 721 2 1080 4344 t
( bytes by paging the code and data within the interpreter,)10 2540(preted program to occupy more than 8K)6 1780 2 1080 4464 t
( some utilities written in B)5 1255( Still,)1 286( too slow to be practical for the common utilities.)9 2316(but it was)2 463 4 1080 4584 t
( of the variable-precision calculator)4 1574(appeared, including an early version)4 1605 2 1080 4704 t
11 I f
(dc)4291 4704 w
11 R f
(familiar to Unix users)3 974 1 4426 4704 t
( cross-compiler that)2 916( most ambitious enterprise I undertook was a genuine)8 2535( The)1 249([McIlroy 79].)1 620 4 1080 4824 t
( was a small)3 565( It)1 131(translated B to GE-635 machine instructions, not threaded code.)8 2885 3 1080 4944 t
11 I f
(tour de force)2 586 1 4698 4944 t
11 R f
(: a)1 116 1 5284 4944 t
( and generating code for a 36-bit mainframe, that ran)9 2358(full B compiler, written in its own language)7 1962 2 1080 5064 t
( project was possible only)4 1231( This)1 274( 18-bit machine with 4K words of user address space.)9 2553(on an)1 262 4 1080 5184 t
(because of the simplicity of the B language and its run-time system.)11 2989 1 1080 5304 t
( implementing one of the major lan-)6 1715(Although we entertained occasional thoughts about)5 2355 2 1330 5460 t
( seemed hopelessly large for our)5 1438(guages of the time like Fortran, PL/I, or Algol 68, such a project)12 2882 2 1080 5580 t
( these languages influenced our)4 1439( All)1 211( called for.)2 500(resources: much simpler and smaller tools were)6 2170 4 1080 5700 t
(work, but it was more fun to do things on our own.)11 2244 1 1080 5820 t
( promise that we were able to acquire the new)9 2050(By 1970, the Unix project had shown enough)7 2020 2 1330 5976 t
( was among the first of its line delivered by DEC, and three months)13 3010( processor)1 451( The)1 230(DEC PDP-11.)1 629 4 1080 6096 t
( the threaded technique)3 1104( B programs run on it using)6 1375( Making)1 425(passed before its disk arrived.)4 1416 4 1080 6216 t
(required only writing the code fragments for the operators, and a simple assembler which I coded)15 4320 1 1080 6336 t
(in B; soon,)2 495 1 1080 6456 t
11 I f
(dc)1609 6456 w
11 R f
(became the first interesting program to be tested, before any operating system, on)12 3654 1 1746 6456 t
( disk, Thompson recoded the Unix kernel and)7 2016( as rapidly, still waiting for the)6 1368( Almost)1 383(our PDP-11.)1 553 4 1080 6576 t
( the 24K bytes of memory on the)7 1620( Of)1 194(some basic commands in PDP-11 assembly language.)6 2506 3 1080 6696 t
( for the operating system, a tiny space)7 1702(machine, the earliest PDP-11 Unix system used 12K bytes)8 2618 2 1080 6816 t
( version was only for testing, not for)7 1658( This)1 259(for user programs, and the remainder as a RAM disk.)9 2403 3 1080 6936 t
( of var-)2 324(real work; the machine marked time by enumerating closed knight's tours on chess boards)13 3996 2 1080 7056 t
( transliterating assembly-)2 1161( its disk appeared, we quickly migrated to it after)9 2372( Once)1 310(ious sizes.)1 477 4 1080 7176 t
(language commands to the PDP-11 dialect, and porting those already in B.)11 3285 1 1080 7296 t
cleartomark
showpage
saveobj restore
%%EndPage: 5 5
%%Page: 6 6
/saveobj save def
mark
6 pagesetup
11 I f
( 6)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( all wanted to cre-)4 796( We)1 208( computer center was beginning to have users.)7 2038(By 1971, our miniature)3 1028 4 1330 840 t
( B, despite its per-)4 829( assembler was dreary enough that)5 1549( Using)1 326(ate interesting software more easily.)4 1616 4 1080 960 t
( by a small library of useful service routines and was)10 2369(formance problems, had been supplemented)4 1951 2 1080 1080 t
( the more notable results of this period was)8 1910( Among)1 389(being used for more and more new programs.)7 2021 3 1080 1200 t
(Steve Johnson's first version of the)5 1549 1 1080 1320 t
11 I f
(yacc)2657 1320 w
11 R f
(parser-generator [Johnson 79a].)2 1389 1 2884 1320 t
11 B f
(The Problems of B)3 878 1 1080 1560 t
11 R f
( lan-)1 199(The machines on which we first used BCPL and then B were word-addressed, and these)14 3871 2 1330 1716 t
( The)1 235(guages' single data type, the `cell,' comfortably equated with the hardware machine word.)12 4085 2 1080 1836 t
( its character-)2 615( First,)1 297( semantic model.)2 769(advent of the PDP-11 exposed several inadequacies of B's)8 2639 4 1080 1956 t
( changes from BCPL, were clumsy: using library proce-)8 2487(handling mechanisms, inherited with few)4 1833 2 1080 2076 t
( and then repack, or to access and replace indi-)9 2079(dures to spread packed strings into individual cells)7 2241 2 1080 2196 t
(vidual characters, began to feel awkward, even silly, on a byte-oriented machine.)11 3556 1 1080 2316 t
( floating-point arithmetic, the)3 1365(Second, although the original PDP-11 did not provide for)8 2705 2 1330 2472 t
( operations had been added)4 1198( Floating-point)1 688( soon be available.)3 821(manufacturer promised that it would)4 1613 4 1080 2592 t
( GCOS compilers by defining special operators, but the mechanism)9 3050(to BCPL in our Multics and)5 1270 2 1080 2712 t
( was large enough to contain a)6 1354(was possible only because on the relevant machines, a single word)10 2966 2 1080 2832 t
(floating-point number; this was not true on the 16-bit PDP-11.)9 2748 1 1080 2952 t
( model implied overhead in dealing with pointers: the language)9 2918(Finally, the B and BCPL)4 1152 2 1330 3108 t
( represented as)2 658(rules, by defining a pointer as an index in an array of words, forced pointers to be)16 3662 2 1080 3228 t
( generated a run-time scale conversion from the pointer to)9 2644( pointer reference)2 790( Each)1 284(word indices.)1 602 4 1080 3348 t
(the byte address expected by the hardware.)6 1884 1 1080 3468 t
( that a typing scheme was necessary to cope with characters)10 2676(For all these reasons, it seemed)5 1394 2 1330 3624 t
( issues, particu-)2 687( Other)1 305( for the coming floating-point hardware.)5 1769(and byte addressing, and to prepare)5 1559 4 1080 3744 t
(larly type safety and interface checking, did not seem as important then as they became later.)15 4083 1 1080 3864 t
( B compiler's threaded-code technique)4 1711(Aside from the problems with the language itself, the)8 2359 2 1330 4020 t
( slower than their assembly-language counterparts that we discounted)8 3127(yielded programs so much)3 1193 2 1080 4140 t
(the possibility of recoding the operating system or its central utilities in B.)12 3272 1 1080 4260 t
( its)1 145(In 1971 I began to extend the B language by adding a character type and also rewrote)16 3925 2 1330 4416 t
( transition)1 451( the)1 170( Thus)1 284(compiler to generate PDP-11 machine instructions instead of threaded code.)9 3415 4 1080 4536 t
( programs)1 444(from B to C was contemporaneous with the creation of a compiler capable of producing)14 3876 2 1080 4656 t
( called the slightly-extended lan-)4 1500( I)1 107( assembly language.)2 918(fast and small enough to compete with)6 1795 4 1080 4776 t
(guage NB, for `new B.')4 1037 1 1080 4896 t
11 B f
(Embryonic C)1 633 1 1080 5136 t
11 R f
( supplied the types)3 853( It)1 133( briefly that no full description of it was written.)9 2212(NB existed so)2 636 4 1330 5292 t
11 CW f
(int)5202 5292 w
11 R f
(and)1080 5412 w
11 CW f
(char)1266 5412 w
11 R f
(, arrays of them, and pointers to them, declared in a style typified by)13 3006 1 1530 5412 t
10 CW f
(int i, j;)2 540 1 1368 5582 t
(char c, d;)2 600 1 1368 5692 t
(int iarray[10];)1 900 1 1368 5802 t
(int ipointer[];)1 900 1 1368 5912 t
(char carray[10];)1 960 1 1368 6022 t
(char cpointer[];)1 960 1 1368 6132 t
11 R f
( remained exactly as in B and BCPL: the declarations of)10 2604(The semantics of arrays)3 1080 2 1080 6312 t
11 CW f
(iarray)4805 6312 w
11 R f
(and)5242 6312 w
11 CW f
(carray)1080 6432 w
11 R f
( 10)1 140(create cells dynamically initialized with a value pointing to the first of a sequence of)14 3753 2 1507 6432 t
( declarations for)2 730( The)1 235(integers and characters respectively.)3 1614 3 1080 6552 t
11 CW f
(ipointer)3697 6552 w
11 R f
(and)4263 6552 w
11 CW f
(cpointer)4459 6552 w
11 R f
(omit the)1 375 1 5025 6552 t
( the)1 200( procedures,)1 574( Within)1 401(size, to assert that no storage should be allocated automatically.)9 3145 4 1080 6672 t
( of the array variables: a pointer dec-)7 1637(language's interpretation of the pointers was identical to that)8 2683 2 1080 6792 t
( in that the programmer was)5 1366(laration created a cell differing from an array declaration only)9 2954 2 1080 6912 t
( the)1 172(expected to assign a referent, instead of letting the compiler allocate the space and initialize)14 4148 2 1080 7032 t
(cell.)1080 7152 w
( and pointer names were the machine addresses,)7 2206(Values stored in the cells bound to array)7 1864 2 1330 7308 t
cleartomark
showpage
saveobj restore
%%EndPage: 6 6
%%Page: 7 7
/saveobj save def
mark
7 pagesetup
11 I f
( 7)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( indirection through a pointer)4 1349( Therefore,)1 528( bytes, of the corresponding storage area.)6 1894(measured in)1 549 4 1080 840 t
( other hand,)2 542( the)1 171( On)1 199(implied no run-time overhead to scale the pointer from word to byte offset.)12 3408 4 1080 960 t
( code for array subscripting and pointer arithmetic now depended on the type of the)14 3778(the machine)1 542 2 1080 1080 t
( the pointer: to compute)4 1068(array or)1 345 2 1080 1200 t
11 CW f
(iarray[i])2525 1200 w
11 R f
(or)3151 1200 w
11 CW f
(ipointer+i)3274 1200 w
11 R f
(implied scaling the addend)3 1194 1 3966 1200 t
11 CW f
(i)5192 1200 w
11 R f
(by)5290 1200 w
(the size of the object referred to.)6 1422 1 1080 1320 t
( I experimented with them for)5 1375(These semantics represented an easy transition from B, and)8 2695 2 1330 1476 t
( became evident when I tried to extend the type notation, especially to)12 3212( Problems)1 483(some months.)1 625 3 1080 1596 t
( an intuitive way onto memory)5 1365( it seemed, should map in)5 1132( Structures,)1 530(add structured \(record\) types.)3 1293 4 1080 1716 t
( a structure containing an array, there was no good place to stash the pointer)14 3354(in the machine, but in)4 966 2 1080 1836 t
( For)1 225( arrange that it be initialized.)5 1344(containing the base of the array, nor any convenient way to)10 2751 3 1080 1956 t
(example, the directory entries of early Unix systems might be described in C as)13 3493 1 1080 2076 t
10 CW f
(struct {)1 480 1 1368 2246 t
(int inumber;)1 960 1 1848 2356 t
(char name[14];)1 1020 1 1848 2466 t
(};)1368 2576 w
11 R f
( to characterize an abstract object but also to describe a collec-)11 2831(I wanted the structure not merely)5 1489 2 1080 2756 t
( the pointer to)3 651( could the compiler hide)4 1121( Where)1 359(tion of bits that might be read from a directory.)9 2189 4 1080 2876 t
11 CW f
(name)1080 2996 w
11 R f
( structures were thought of more abstractly, and the)8 2308( if)1 100( Even)1 286(that the semantics demanded?)3 1329 4 1377 2996 t
( I handle the technical problem of prop-)7 1789(space for pointers could be hidden somehow, how could)8 2531 2 1080 3116 t
( object, perhaps one that specified)5 1559(erly initializing these pointers when allocating a complicated)7 2761 2 1080 3236 t
(structures containing arrays containing structures to arbitrary depth?)7 2996 1 1080 3356 t
(The solution constituted the crucial jump in the evolutionary chain between typeless BCPL)12 4070 1 1330 3512 t
( the)1 173( eliminated the materialization of the pointer in storage, and instead caused)11 3428( It)1 135(and typed C.)2 584 4 1080 3632 t
( rule, which sur-)3 738( The)1 232( the pointer when the array name is mentioned in an expression.)11 2874(creation of)1 476 4 1080 3752 t
( in expressions,)2 702(vives in today's C, is that values of array type are converted, when they appear)14 3618 2 1080 3872 t
(into pointers to the first of the objects making up the array.)11 2592 1 1080 3992 t
( work, despite the underlying)4 1346(This invention enabled most existing B code to continue to)9 2724 2 1330 4148 t
( programs that assigned new values to an array name to)10 2434( few)1 192( The)1 227(shift in the language's semantics.)4 1467 4 1080 4268 t
( impor-)1 328( More)1 294(adjust its origin\320possible in B and BCPL, meaningless in C\320were easily repaired.)11 3698 3 1080 4388 t
( a coherent and workable \(if unusual\) explanation of the semantics)10 2940(tant, the new language retained)4 1380 2 1080 4508 t
(of arrays, while opening the way to a more comprehensive type structure.)11 3229 1 1080 4628 t
( clearly distinguishes C from its predecessors is this fuller)9 2609(The second innovation that most)4 1461 2 1330 4784 t
( offered the basic)3 793( NB)1 221( declarations.)1 597(type structure and especially its expression in the syntax of)9 2709 4 1080 4904 t
(types)1080 5024 w
11 CW f
(int)1345 5024 w
11 R f
(and)1576 5024 w
11 CW f
(char)1767 5024 w
11 R f
( and pointers to them, but no further ways of)9 2016(, together with arrays of them,)5 1353 2 2031 5024 t
( object of any type, it should be possible to)9 1973( was required: given an)4 1064(composition. Generalization)1 1283 3 1080 5144 t
( to)1 116(describe a new object that gathers several into an array, yields it from a function, or is a pointer)18 4204 2 1080 5264 t
(it.)1080 5384 w
( to mention the underlying)4 1173(For each object of such a composed type, there was already a way)12 2897 2 1330 5540 t
( Analogical)1 544( the function, use the indirection operator on the pointer.)9 2546(object: index the array, call)4 1230 3 1080 5660 t
(reasoning led to a declaration syntax for names mirroring that of the expression syntax in which)15 4320 1 1080 5780 t
( Thus,)1 304(the names typically appear.)3 1201 2 1080 5900 t
10 CW f
(int i, *pi, **ppi;)3 1080 1 1368 6070 t
11 R f
( syntax of these)3 693( The)1 228( an integer, a pointer to a pointer to an integer.)10 2060(declare an integer, a pointer to)5 1339 4 1080 6250 t
(declarations reflects the observation that)4 1789 1 1080 6370 t
11 CW f
(i)2901 6370 w
11 R f
(,)2967 6370 w
11 CW f
(*pi)3027 6370 w
11 R f
(, and)1 218 1 3225 6370 t
11 CW f
(**ppi)3475 6370 w
11 R f
(all yield an)2 497 1 3837 6370 t
11 CW f
(int)4365 6370 w
11 R f
(type when used in)3 806 1 4594 6370 t
( Similarly,)1 495(an expression.)1 628 2 1080 6490 t
10 CW f
(int f\(\), *f\(\), \(*f\)\(\);)3 1320 1 1368 6660 t
11 R f
( integer, a pointer to a)5 995(declare a function returning an integer, a function returning a pointer to an)12 3325 2 1080 6840 t
(function returning an integer;)3 1290 1 1080 6960 t
10 CW f
(int *api[10], \(*pai\)[10];)2 1500 1 1368 7130 t
11 R f
( all these cases the)4 819( In)1 149( to an array of integers.)5 1028(declare an array of pointers to integers, and a pointer)9 2324 4 1080 7310 t
cleartomark
showpage
saveobj restore
%%EndPage: 7 7
%%Page: 8 8
/saveobj save def
mark
8 pagesetup
11 I f
( 8)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( whose type is the one named at the)8 1596(declaration of a variable resembles its usage in an expression)9 2724 2 1080 840 t
(head of the declaration.)3 1029 1 1080 960 t
( C owes considerable debt to Algol 68,)7 1936(The scheme of type composition adopted by)6 2134 2 1330 1116 t
( cen-)1 217( The)1 228( not, perhaps, emerge in a form that Algol's adherents would approve of.)12 3225(although it did)2 650 4 1080 1236 t
( on atomic types \(including struc-)5 1557(tral notion I captured from Algol was a type structure based)10 2763 2 1080 1356 t
( 68's con-)2 459( Algol)1 317( functions \(procedures\).)2 1064(tures\), composed into arrays, pointers \(references\), and)6 2480 4 1080 1476 t
(cept of unions and casts also had an influence that appeared later.)11 2871 1 1080 1596 t
( and the compiler for the new lan-)7 1617(After creating the type system, the associated syntax,)7 2453 2 1330 1752 t
( decided to fol-)3 683( I)1 97( new name; NB seemed insufficiently distinctive.)6 2202(guage, I felt that it deserved a)6 1338 4 1080 1872 t
( name represented)2 800(low the single-letter style and called it C, leaving open the question whether the)13 3520 2 1080 1992 t
(a progression through the alphabet or through the letters in BCPL.)10 2913 1 1080 2112 t
11 B f
(Neonatal C)1 528 1 1080 2352 t
11 R f
( language had been named, for example the introduction)8 2545(Rapid changes continued after the)4 1525 2 1330 2508 t
(of the)1 261 1 1080 2628 t
11 CW f
(&&)1377 2628 w
11 R f
(and)1545 2628 w
11 CW f
(||)1739 2628 w
11 R f
( BCPL and B, the evaluation of expressions depends on context:)10 2904(operators. In)1 589 2 1907 2628 t
(within)1080 2748 w
11 CW f
(if)1400 2748 w
11 R f
( expression's value with zero, these)5 1616(and other conditional statements that compare an)6 2214 2 1570 2748 t
(languages place a special interpretation on the)6 2089 1 1080 2868 t
11 CW f
(and)3208 2868 w
11 R f
(\()3445 2868 w
11 CW f
(&)3481 2868 w
11 R f
(\) and)1 233 1 3547 2868 t
11 CW f
(or)3819 2868 w
11 R f
(\()3990 2868 w
11 CW f
(|)4026 2868 w
11 R f
( ordinary con-)2 641( In)1 157(\) operators.)1 510 3 4092 2868 t
(texts, they operate bitwise, but in the B statement)8 2172 1 1080 2988 t
10 CW f
(if \(e1 & e2\) ...)4 960 1 1368 3158 t
11 R f
( must evaluate)2 645(the compiler)1 556 2 1080 3338 t
11 CW f
(e1)2314 3338 w
11 R f
(and if it is non-zero, evaluate)5 1306 1 2479 3338 t
11 CW f
(e2)3818 3338 w
11 R f
(, and if it too is non-zero, elabo-)7 1450 1 3950 3338 t
(rate the statement dependent on the)5 1567 1 1080 3458 t
11 CW f
(if)2678 3458 w
11 R f
( requirement descends recursively on)4 1644(. The)1 257 2 2810 3458 t
11 CW f
(&)4742 3458 w
11 R f
(and)4838 3458 w
11 CW f
(|)5026 3458 w
11 R f
(opera-)5122 3458 w
(tors within)1 476 1 1080 3578 t
11 CW f
(e1)1585 3578 w
11 R f
(and)1747 3578 w
11 CW f
(e2)1935 3578 w
11 R f
( short-circuit semantics of the Boolean operators in such `truth-value')9 3077(. The)1 256 2 2067 3578 t
( overloading of the operators was difficult to explain and use.)10 2811(context seemed desirable, but the)4 1509 2 1080 3698 t
( the)1 168(At the suggestion of Alan Snyder, I introduced)7 2094 2 1080 3818 t
11 CW f
(&&)3376 3818 w
11 R f
(and)3542 3818 w
11 CW f
(||)3734 3818 w
11 R f
(operators to make the mechanism)4 1500 1 3900 3818 t
(more explicit.)1 611 1 1080 3938 t
( B one writes)3 584( In)1 147(Their tardy introduction explains an infelicity of C's precedence rules.)9 3092 3 1330 4094 t
10 CW f
(if \(a==b & c\) ...)4 1020 1 1368 4264 t
11 R f
(to check whether)2 752 1 1080 4444 t
11 CW f
(a)1862 4444 w
11 R f
(equals)1958 4444 w
11 CW f
(b)2268 4444 w
11 R f
(and)2365 4444 w
11 CW f
(c)2554 4444 w
11 R f
(is non-zero; in such a conditional expression it is better that)10 2652 1 2651 4444 t
11 CW f
(&)5334 4444 w
11 R f
(have lower precedence than)3 1223 1 1080 4564 t
11 CW f
(==)2333 4564 w
11 R f
( converting from B to C, one wants to replace)9 2019(. In)1 176 2 2465 4564 t
11 CW f
(&)4689 4564 w
11 R f
(by)4784 4564 w
11 CW f
(&&)4923 4564 w
11 R f
(in such)1 316 1 5084 4564 t
(a statement; to make the conversion less painful, we decided to keep the precedence of the)15 4209 1 1080 4684 t
11 CW f
(&)5334 4684 w
11 R f
(operator the same relative to)4 1253 1 1080 4804 t
11 CW f
(==)2362 4804 w
11 R f
(, and merely split the precedence of)6 1569 1 2494 4804 t
11 CW f
(&&)4091 4804 w
11 R f
(slightly from)1 573 1 4251 4804 t
11 CW f
(&)4852 4804 w
11 R f
( it)1 90(. Today,)1 392 2 4918 4804 t
(seems that it would have been preferable to move the relative precedences of)12 3590 1 1080 4924 t
11 CW f
(&)4717 4924 w
11 R f
(and)4830 4924 w
11 CW f
(==)5035 4924 w
11 R f
(, and)1 233 1 5167 4924 t
(thereby simplify a common C idiom: to test a masked value against another value, one must write)16 4301 1 1080 5044 t
10 CW f
(if \(\(a&mask\) == b\) ...)4 1320 1 1368 5214 t
11 R f
(where the inner parentheses are required but easily forgotten.)8 2682 1 1080 5394 t
( around 1972-3, but the most important was the introduction)9 2745(Many other changes occurred)3 1325 2 1330 5550 t
( also in recognition of the)5 1128(of the preprocessor, partly at the urging of Alan Snyder [Snyder 74], but)12 3192 2 1080 5670 t
( original version was)3 934( Its)1 171( and PL/I.)2 448(utility of the the file-inclusion mechanisms available in BCPL)8 2767 4 1080 5790 t
(exceedingly simple, and provided only included files and simple string replacements:)10 3763 1 1080 5910 t
11 CW f
(#include)4872 5910 w
11 R f
(and)1080 6030 w
11 CW f
(#define)1272 6030 w
11 R f
( thereafter, it was extended, mostly by Mike Lesk)8 2236( Soon)1 290(of parameterless macros.)2 1106 3 1768 6030 t
( The)1 227(and then by John Reiser, to incorporate macros with arguments and conditional compilation.)12 4093 2 1080 6150 t
( for)1 174( Indeed,)1 400( optional adjunct to the language itself.)6 1829(preprocessor was originally considered an)4 1917 4 1080 6270 t
( its)1 142(some years, it was not even invoked unless the source program contained a special signal at)15 4178 2 1080 6390 t
( of the syntax of)4 747( attitude persisted, and explains both the incomplete integration)8 2846(beginning. This)1 727 3 1080 6510 t
( with the rest of the language and the imprecision of its description in early refer-)15 3597(the preprocessor)1 723 2 1080 6630 t
(ence manuals.)1 621 1 1080 6750 t
cleartomark
showpage
saveobj restore
%%EndPage: 8 8
%%Page: 9 9
/saveobj save def
mark
9 pagesetup
11 I f
( 9)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 B f
(Portability)1080 840 w
11 R f
( language and compiler were)4 1278( The)1 229( were complete.)2 703(By early 1973, the essentials of modern C)7 1860 4 1330 996 t
( of)1 123(strong enough to permit us to rewrite the Unix kernel for the PDP-11 in C during the summer)17 4197 2 1080 1116 t
( a system coded in an early version of)8 1700( had made a brief attempt to produce)7 1641( \(Thompson)1 567(that year.)1 412 4 1080 1236 t
( during this period, the compiler was)6 1623( Also)1 265(C\320before structures\320in 1972, but gave up the effort.\))7 2432 3 1080 1356 t
( 360/370; because)2 813(retargeted to other nearby machines, particularly the Honeywell 635 and IBM)10 3507 2 1080 1476 t
( could not live in isolation, the prototypes for the modern libraries were developed.)13 3754(the language)1 566 2 1080 1596 t
( that was later reworked to become)6 1601(In particular, Lesk wrote a `portable I/O package' [Lesk 72])9 2719 2 1080 1716 t
( 1978 Brian Kernighan and I published)6 1812( In)1 163( I/O' routines.)2 652(the C `standard)2 705 4 1080 1836 t
11 I f
(The C Programming)2 944 1 4456 1836 t
(Language)1080 1956 w
11 R f
( not describe some additions that soon became com-)8 2376( it did)2 277( Although)1 481([Kernighan 78].)1 709 4 1557 1956 t
( a formal standard was adopted more than)7 1901(mon, this book served as the language reference until)8 2419 2 1080 2076 t
( on this book, there was a clear division of)9 1927( we worked closely together)4 1261( Although)1 478(ten years later.)2 654 4 1080 2196 t
( the)1 191(labor: Kernighan wrote almost all the expository material, while I was responsible for)12 4129 2 1080 2316 t
(appendix containing the reference manual and the chapter on interfacing with the Unix system.)13 4171 1 1080 2436 t
( a bit: the type structure gained unsigned, long, union,)9 2392(During 1973-1980, the language grew)4 1678 2 1330 2592 t
( objects \(lacking only a notation)5 1465(and enumeration types, and structures became nearly first-class)7 2855 2 1080 2712 t
( important developments appeared in its environment and the accompanying)9 3396( Equally)1 402(for literals\).)1 522 3 1080 2832 t
( in C had given us enough confidence in the language's use-)11 2679( the Unix kernel)3 723(technology. Writing)1 918 3 1080 2952 t
( recode the system's utilities and tools as well, and then to)11 2596(fulness and efficiency that we began to)6 1724 2 1080 3072 t
( we)1 156( described in [Johnson 78a],)4 1244( As)1 180(move the most interesting among them to the other platforms.)9 2740 4 1080 3192 t
( the C)2 274(discovered that the hardest problems in propagating Unix tools lay not in the interaction of)14 4046 2 1080 3312 t
( software of other operating systems.)5 1643(language with new hardware, but in adapting to the existing)9 2677 2 1080 3432 t
(Thus Steve Johnson began to work on)6 1729 1 1080 3552 t
11 I f
(pcc)2846 3552 w
11 R f
( intended to be easy to retarget to new)8 1752(, a C compiler)3 651 2 2997 3552 t
( move the Unix system itself to the)7 1568(machines [Johnson 78b], while he, Thompson, and I began to)9 2752 2 1080 3672 t
(Interdata 8/32 computer.)2 1082 1 1080 3792 t
( changes during this period, especially around 1977, were largely focused on)11 3469(The language)1 601 2 1330 3948 t
( the problems we foresaw)4 1163(considerations of portability and type safety, in an effort to cope with)11 3157 2 1080 4068 t
( at that time)3 527( C)1 131( body of code to the new Interdata platform.)8 1945(and observed in moving a considerable)5 1717 4 1080 4188 t
( for example, were barely distin-)5 1512( Pointers,)1 461( typeless origins.)2 776(still manifested strong signs of its)5 1571 4 1080 4308 t
( in early language manuals or extant code; the similarity of)10 2629(guished from integral memory indices)4 1691 2 1080 4428 t
( to resist the)3 581(the arithmetic properties of character pointers and unsigned integers made it hard)11 3739 2 1080 4548 t
( The)1 246(temptation to identify them.)3 1291 2 1080 4668 t
11 CW f
(unsigned)2665 4668 w
11 R f
( unsigned arithmetic)2 940(types were added to make)4 1219 2 3241 4668 t
( the early language condoned)4 1293( Similarly,)1 498(available without confusing it with pointer manipulation.)6 2529 3 1080 4788 t
( and pointers, but this practice began to be discouraged; a notation)11 3001(assignments between integers)2 1319 2 1080 4908 t
( specify type)2 577(for type conversions \(called `casts' from the example of Algol 68\) was invented to)13 3743 2 1080 5028 t
( early C did not tie structure point-)7 1540( by the example of PL/I,)5 1075( Beguiled)1 454(conversions more explicitly.)2 1251 4 1080 5148 t
( to the structures they pointed to, and permitted programmers to write)11 3820(ers firmly)1 500 2 1080 5268 t
11 CW f
(pointer->member)1080 5388 w
11 R f
(almost without regard to the type of)6 1649 1 2110 5388 t
11 CW f
(pointer)3800 5388 w
11 R f
(; such an expression was)4 1138 1 4262 5388 t
( to a region of memory designated by the pointer, while the mem-)12 2917(taken uncritically as a reference)4 1403 2 1080 5508 t
(ber name specified only an offset and a type.)8 1966 1 1080 5628 t
( of K&R described most of the rules that brought C's type struc-)12 2932(Although the first edition)3 1138 2 1330 5784 t
( many programs written in the older, more relaxed style persisted, and so)12 3266(ture to its present form,)4 1054 2 1080 5904 t
( encourage people to pay more attention to the official language)10 2815( To)1 179( tolerated it.)2 531(did compilers that)2 795 4 1080 6024 t
(rules, to detect legal but suspicious constructions, and to help find interface mismatches unde-)13 4320 1 1080 6144 t
( his)1 168(tectable with simple mechanisms for separate compilation, Steve Johnson adapted)9 3698 2 1080 6264 t
11 I f
(pcc)4985 6264 w
11 R f
(com-)5175 6264 w
(piler to produce)2 717 1 1080 6384 t
11 I f
(lint)1836 6384 w
11 R f
( scanned a set of files and remarked on dubious con-)10 2405([Johnson 79b], which)2 972 2 2023 6384 t
(structions.)1080 6504 w
11 B f
(Growth in Usage)2 795 1 1080 6744 t
11 R f
( Tom)1 241(The success of our portability experiment on the Interdata 8/32 soon led to another by)14 3829 2 1330 6900 t
( machine became much more popular)5 1708( This)1 264( DEC VAX 11/780.)3 911(London and John Reiser on the)5 1437 4 1080 7020 t
( began to spread rapidly, both within AT&T and)8 2178(than the Interdata, and Unix and the C language)8 2142 2 1080 7140 t
( by the middle 1970s Unix was in use by a variety of projects within the Bell)16 3495(outside. Although)1 825 2 1080 7260 t
cleartomark
showpage
saveobj restore
%%EndPage: 9 9
%%Page: 10 10
/saveobj save def
mark
10 pagesetup
11 I f
( 10)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( group of research-oriented industrial, academic, and government orga-)8 3172(System as well as a small)5 1148 2 1080 840 t
( Of)1 172( began only after portability had been achieved.)7 2098(nizations outside our company, its real growth)6 2050 3 1080 960 t
( were the System III and System V versions of the system from the emerging Com-)15 3684(particular note)1 636 2 1080 1080 t
( and research)2 604(puter Systems division of AT&T, based on work by the company's development)11 3716 2 1080 1200 t
( California at Berkeley that derived)5 1612(groups, and the BSD series of releases by the University of)10 2708 2 1080 1320 t
(from research organizations in Bell Laboratories.)5 2157 1 1080 1440 t
( the C language spread widely, and compilers became available)9 2831(During the 1980s the use of)5 1239 2 1330 1596 t
( particular it became popular as a)6 1510(on nearly every machine architecture and operating system; in)8 2810 2 1080 1716 t
( software for)2 597(programming tool for personal computers, both for manufacturers of commercial)9 3723 2 1080 1836 t
( the start of the decade, nearly)6 1355( At)1 173(these machines, and for end-users interesting in programming.)7 2792 3 1080 1956 t
(every compiler was based on Johnson's)5 1796 1 1080 2076 t
11 I f
(pcc)2915 2076 w
11 R f
( independently-produced)1 1105(; by 1985 there were many)5 1229 2 3066 2076 t
(compiler products.)1 824 1 1080 2196 t
11 B f
(Standardization)1080 2436 w
11 R f
( to a)2 220( best approximation)2 902( The)1 240(By 1982 it was clear that C needed formal standardization.)9 2708 4 1330 2592 t
( language in actual use; in particular, it)7 1724(standard, the first edition of K&R, no longer described the)9 2596 2 1080 2712 t
( the)1 165(mentioned neither)1 798 2 1080 2832 t
11 CW f
(void)2074 2832 w
11 R f
(or)2369 2832 w
11 CW f
(enum)2491 2832 w
11 R f
( it foreshadowed the newer approach to struc-)7 2027(types. While)1 587 2 2786 2832 t
( passing them to and)4 942(tures, only after it was published did the language support assigning them,)11 3378 2 1080 2952 t
( members firmly with the structure or union contain-)8 2339(from functions, and associating the names of)6 1981 2 1080 3072 t
( compilers distributed by AT&T incorporated these changes, and most of the)11 3421( Although)1 477(ing them.)1 422 3 1080 3192 t
(purveyors of compilers not based on)5 1612 1 1080 3312 t
11 I f
(pcc)2722 3312 w
11 R f
( no complete,)2 602(quickly picked up them up, there remained)6 1895 2 2903 3312 t
(authoritative description of the language.)4 1803 1 1080 3432 t
( was also insufficiently precise on many details of the language,)10 2931(The first edition of K&R)4 1139 2 1330 3588 t
(and it became increasingly impractical to regard)6 2132 1 1080 3708 t
11 I f
(pcc)3242 3708 w
11 R f
(as a `reference compiler;' it did not perfectly)7 1977 1 3423 3708 t
( the)1 185( Finally,)1 420( alone subsequent extensions.)3 1370(embody even the language described by K&R, let)7 2345 4 1080 3828 t
( projects subject to commercial and government contract meant that the)10 3342(incipient use of C in)4 978 2 1080 3948 t
( urging of M. D. McIlroy\), ANSI)6 1506( \(at the)2 319( Thus)1 283(imprimatur of an official standard was important.)6 2212 4 1080 4068 t
( with the)2 388(established the X3J11 committee under the direction of CBEMA in the summer of 1983,)13 3932 2 1080 4188 t
( produced its report [ANSI 89] at the end of 1989, and)11 2519( X3J11)1 355(goal of producing a C standard.)5 1446 3 1080 4308 t
(subsequently this standard was accepted by ISO as ISO/IEC 9899-1990.)9 3175 1 1080 4428 t
( the X3J11 committee took a cautious, conservative view of language)10 3155(From the beginning,)2 915 2 1330 4584 t
( to my satisfaction, they took seriously their goal: `to develop a clear, consis-)13 3506(extensions. Much)1 814 2 1080 4704 t
( which codifies the common,)4 1330(tent, and unambiguous Standard for the C programming language)8 2990 2 1080 4824 t
( and which promotes the portability of user programs across C language)11 3264(existing definition of C)3 1056 2 1080 4944 t
( committee realized that mere promulgation of a standard does not)10 2957(environments.' [ANSI 89] The)3 1363 2 1080 5064 t
(make the world change.)3 1048 1 1080 5184 t
( only one genuinely important change to the language itself: it incorpo-)11 3274(X3J11 introduced)1 796 2 1330 5340 t
( type signature of a function, using syntax borrowed)8 2389(rated the types of formal arguments in the)7 1931 2 1080 5460 t
( the old style, external functions were declared like this:)9 2460( In)1 147(from C++ [Stroustrup 86].)3 1164 3 1080 5580 t
10 CW f
(double sin\(\);)1 780 1 1368 5750 t
11 R f
(which says only that)3 935 1 1080 5930 t
11 CW f
(sin)2054 5930 w
11 R f
( a)1 88(is a function returning)3 1007 2 2291 5930 t
11 CW f
(double)3426 5930 w
11 R f
(\(that is, double-precision floating-)3 1538 1 3862 5930 t
( the new style, this better rendered)6 1510( In)1 147(point\) value.)1 556 3 1080 6050 t
10 CW f
(double sin\(double\);)1 1140 1 1368 6220 t
11 R f
( and thus encourage better type checking and appropriate con-)9 2770(to make the argument type explicit)5 1550 2 1080 6400 t
( a noticeably better language, caused difficulties.)6 2182( this addition, though it produced)5 1499(version. Even)1 639 3 1080 6520 t
(The committee justifiably felt that simply outlawing `old-style' function definitions and declara-)11 4320 1 1080 6640 t
( inevitable compromise)2 1032( The)1 226( that the new forms were better.)6 1393(tions was not feasible, yet also agreed)6 1669 4 1080 6760 t
( definition is complicated by permitting)5 1797(was as good as it could have been, though the language)10 2523 2 1080 6880 t
( with compilers not yet brought up to)7 1694(both forms, and writers of portable software must contend)8 2626 2 1080 7000 t
(standard.)1080 7120 w
( and adjustments, for example, the type)6 1807(X3J11 also introduced a host of smaller additions)7 2263 2 1330 7276 t
cleartomark
showpage
saveobj restore
%%EndPage: 10 10
%%Page: 11 11
/saveobj save def
mark
11 pagesetup
11 I f
( 11)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
(qualifiers)1080 840 w
11 CW f
(const)1526 840 w
11 R f
(and)1888 840 w
11 CW f
(volatile)2078 840 w
11 R f
( the)1 166( Nevertheless,)1 653(, and slightly different type promotion rules.)6 1975 3 2606 840 t
( particular, the C standard)4 1142( In)1 148(standardization process did not change the character of the language.)9 3030 3 1080 960 t
(did not attempt to specify formally the language semantics, and so there can be dispute over fine)16 4320 1 1080 1080 t
( in usage since the original description,)6 1744(points; nevertheless, it successfully accounted for changes)6 2576 2 1080 1200 t
(and is sufficiently precise to base implementations on it.)8 2479 1 1080 1320 t
( from the standardization process, and)5 1731(Thus the core C language escaped nearly unscathed)7 2339 2 1330 1476 t
( important)1 456( More)1 293( better, careful codification than a new invention.)7 2162(the Standard emerged more as a)5 1409 4 1080 1596 t
( prepro-)1 354( The)1 231( the library.)2 520(changes took place in the language's surroundings: the preprocessor and)9 3215 4 1080 1716 t
( Its)1 172( the rest of the language.)5 1110(cessor performs macro substitution, using conventions distinct from)7 3038 3 1080 1836 t
( compiler had never been well-described, and X3J11 attempted to remedy the)11 3457(interaction with the)2 863 2 1080 1956 t
( noticeably better than the explanation in the first edition of K&R; besides)12 3300( result is)2 382(situation. The)1 638 3 1080 2076 t
( available)1 429(being more comprehensive, it provides operations, like token concatenation, previously)9 3891 2 1080 2196 t
(only by accidents of implementation.)4 1635 1 1080 2316 t
( library was as)3 670(X3J11 correctly believed that a full and careful description of a standard C)12 3400 2 1330 2472 t
( C language itself does not provide for input-)8 2068( The)1 237( itself.)1 287(important as its work on the language)6 1728 4 1080 2592 t
( outside world, and thus depends on a set of standard pro-)11 2579(output or any other interaction with the)6 1741 2 1080 2712 t
( C was thought of mainly as the system program-)9 2267( the time of publication of K&R,)6 1514(cedures. At)1 539 3 1080 2832 t
( Unix; although we provided examples of library routines intended to be readily)12 3547(ming language of)2 773 2 1080 2952 t
( support from Unix was implicitly under-)6 1930(transportable to other operating systems, underlying)5 2390 2 1080 3072 t
( a set of)3 384( the X3J11 committee spent much of its time designing and documenting)11 3353(stood. Thus,)1 583 3 1080 3192 t
(library routines required to be available in all conforming implementations.)9 3316 1 1080 3312 t
( the standards process, the current activity of the X3J11 committee is con-)12 3389(By the rules of)3 681 2 1330 3468 t
( an informal group originally)4 1313( However,)1 493( existing standard.)2 822(fined to issuing interpretations on the)5 1692 4 1080 3588 t
( has been officially)3 934(convened by Rex Jaeschke as NCEG \(Numerical C Extensions Group\))9 3386 2 1080 3708 t
( the name)2 469( As)1 199(accepted as subgroup X3J11.1, and they continue to consider extensions to C.)11 3652 3 1080 3828 t
( intended to make the language more suitable for)8 2228(implies, many of these possible extensions are)6 2092 2 1080 3948 t
( for example, multi-dimensional arrays whose bounds are dynamically determined,)9 3673(numerical use:)1 647 2 1080 4068 t
( arithmetic, and making the language more effec-)7 2191(incorporation of facilities for dealing with IEEE)6 2129 2 1080 4188 t
( all the possible exten-)4 1002( Not)1 225(tive on machines with vector or other advanced architectural features.)9 3093 3 1080 4308 t
(sions are specifically numerical; they include a notation for structure literals.)10 3371 1 1080 4428 t
11 B f
(Successors)1080 4668 w
11 R f
( have several direct descendants, though they do not rival Pascal in generating)12 3468(C and even B)3 602 2 1330 4824 t
( University of Water-)3 941( Steve Johnson visited the)4 1149( When)1 318( side branch developed early.)4 1286(progeny. One)1 626 5 1080 4944 t
( became popular on the Honeywell machines)6 1987( It)1 125(loo on sabbatical in 1972, he brought B with him.)9 2208 3 1080 5064 t
( John-)1 279( When)1 324( answers to `what follows B?'\).)5 1414(there, and later spawned Eh and Zed \(the Canadian)8 2303 4 1080 5184 t
( the language whose seeds he)5 1324(son returned to Bell Labs in 1973, he was disconcerted to find that)12 2996 2 1080 5304 t
(brought to Canada had evolved back home; even his own)9 2572 1 1080 5424 t
11 I f
(yacc)3685 5424 w
11 R f
(program had been rewritten in C,)5 1483 1 3917 5424 t
(by Alan Snyder.)2 718 1 1080 5544 t
( C proper include Concurrent C [Gehani 89], Objective C [Cox)10 2845(More recent descendants of)3 1225 2 1330 5700 t
( is also widely used as)5 1007( language)1 429( The)1 232(86], C* [Thinking 90], and especially C++ [Stroustrup 86].)8 2652 4 1080 5820 t
( as a portable assembly language\) for a wide variety of)10 2431(an intermediate representation \(essentially,)3 1889 2 1080 5940 t
( for direct descendents like C++, and independent languages like Modula 3 [Nel-)12 3628(compilers, both)1 692 2 1080 6060 t
(son 91] and Eiffel [Meyer 88].)5 1341 1 1080 6180 t
11 B f
(Critique)1080 6420 w
11 R f
( of its class: the relationship)5 1373(Two ideas are most characteristic of C among languages)8 2697 2 1330 6576 t
( expression syntax.)2 850(between arrays and pointers, and the way in which declaration syntax mimics)11 3470 2 1080 6696 t
(They are also among its most frequently criticized features, and often serve as stumbling blocks)14 4320 1 1080 6816 t
( historical accidents or mistakes have exacerbated their difficulty.)8 2936( both cases,)2 526( In)1 155(to the beginner.)2 703 4 1080 6936 t
( should be)2 455( As)1 179( been the tolerance of C compilers to errors in type.)10 2271(The most important of these has)5 1415 4 1080 7056 t
( did not suddenly appear to its)6 1328( It)1 124(clear from the history above, C evolved from typeless languages.)9 2868 3 1080 7176 t
( we)1 190(earliest users and developers as an entirely new language with its own rules; instead)13 4130 2 1080 7296 t
cleartomark
showpage
saveobj restore
%%EndPage: 11 11
%%Page: 12 12
/saveobj save def
mark
12 pagesetup
11 I f
( 12)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( and make allowance for an)5 1213(continually had to adapt existing programs as the language developed,)9 3107 2 1080 840 t
( X3J11 committee standardizing C would face the same)8 2510( the ANSI)2 458( \(Later,)1 356(existing body of code.)3 996 4 1080 960 t
(problem.\))1080 1080 w
( as assigning)2 589(Compilers in 1977, and even well after, did not complain about usages such)12 3481 2 1330 1236 t
( or using objects of the wrong type to refer to structure members.)12 2980(between integers and pointers)3 1340 2 1080 1356 t
( reasonably \(though)2 896(Although the language definition presented in the first edition of K&R was)11 3424 2 1080 1476 t
( in its treatment of type rules, that book admitted that existing compilers)12 3215(not completely\) coherent)2 1105 2 1080 1596 t
( to later)2 348( some rules designed to ease early transitions contributed)8 2549( Moreover,)1 520(didn't enforce them.)2 903 4 1080 1716 t
( example, the empty square brackets in the function declaration)9 2781(confusion. For)1 670 2 1080 1836 t
10 CW f
(int f\(a\) int a[]; { ... })6 1500 1 1368 2006 t
11 R f
(are a living fossil, a remnant of NB's way of declaring a pointer;)12 2937 1 1080 2186 t
11 CW f
(a)4053 2186 w
11 R f
( case only,)2 485(is, in this special)3 760 2 4155 2186 t
( notation survived in part for the sake of compatibility, in part)11 2798( The)1 233( as a pointer.)3 583(interpreted in C)2 706 4 1080 2306 t
( programmers to communicate to their readers an)7 2287(under the rationalization that it would allow)6 2033 2 1080 2426 t
(intent to pass)2 616 1 1080 2546 t
11 CW f
(f)1741 2546 w
11 R f
( an array, rather than a reference to a single integer.)10 2417(a pointer generated from)3 1131 2 1852 2546 t
(Unfortunately, it serves as much to confuse the learner as to alert the reader.)13 3343 1 1080 2666 t
( function call was the responsibility)5 1593(In K&R C, supplying arguments of the proper type to a)10 2477 2 1330 2822 t
( failure of the)3 600( The)1 228( type agreement.)2 732(of the programmer, and the extant compilers did not check for)10 2760 4 1080 2942 t
( a function was a significant)5 1276(original language to include argument types in the type signature of)10 3044 2 1080 3062 t
( required the X3J11 committee's boldest and most painful innova-)9 2980(weakness, indeed the one that)4 1340 2 1080 3182 t
( by my avoidance of technological)5 1566( early design is explained \(if not justified\))7 1905( The)1 235(tion to repair.)2 614 4 1080 3302 t
( between separately-compiled source files, and my incom-)7 2693(problems, especially cross-checking)2 1627 2 1080 3422 t
( The)1 238( of moving between an untyped to a typed language.)9 2410(plete assimilation of the implications)4 1672 3 1080 3542 t
11 I f
(lint)1080 3662 w
11 R f
( the problem: among its other functions,)6 1879(program, mentioned above, tried to alleviate)5 2050 2 1276 3662 t
11 I f
(lint)5252 3662 w
11 R f
( program by scanning a set of source files, com-)9 2147(checks the consistency and coherency of a whole)7 2173 2 1080 3782 t
(paring the types of function arguments used in calls with those in their definitions.)13 3626 1 1080 3902 t
( indirec-)1 369( The)1 227( of the language.)3 735(An accident of syntax contributed to the perceived complexity)8 2739 4 1330 4058 t
(tion operator, spelled)2 933 1 1080 4178 t
11 CW f
(*)2042 4178 w
11 R f
( This)1 252( operator, just as in BCPL and B.)7 1462(in C, is syntactically a unary prefix)6 1549 3 2137 4178 t
( but in more complex cases, parentheses are required to direct)10 2799(works well in simple expressions,)4 1521 2 1080 4298 t
( example, to distinguish indirection through the value returned by a function from)12 3596( For)1 210(the parsing.)1 514 3 1080 4418 t
(calling a function designated by a pointer, one writes)8 2417 1 1080 4538 t
11 CW f
(*fp\(\))3536 4538 w
11 R f
(and)3905 4538 w
11 CW f
(\(*pf\)\(\))4103 4538 w
11 R f
(respectively. The)1 795 1 4605 4538 t
(style used in expressions carries through to declarations, so the names might be declared)13 3888 1 1080 4658 t
10 CW f
(int *fp\(\);)1 600 1 1368 4828 t
(int \(*pf\)\(\);)1 720 1 1368 4938 t
11 R f
(In more ornate but still realistic cases, things become worse:)9 2656 1 1080 5118 t
10 CW f
(int *\(*pfp\)\(\);)1 840 1 1368 5288 t
11 R f
( Most)1 287( are two effects occurring.)4 1162( There)1 314( integer.)1 364(is a pointer to a function returning a pointer to an)10 2193 5 1080 5468 t
(important, C has a relatively rich set of ways of describing types \(compared, say, with Pascal\).)15 4320 1 1080 5588 t
( objects equally)2 712(Declarations in languages as expressive as C\320Algol 68, for example\320describe)9 3608 2 1080 5708 t
( effect owes to)3 651( second)1 336( A)1 139(hard to understand, simply because the objects themselves are complex.)9 3194 4 1080 5828 t
( in C must be read in an `inside-out' style that many find diffi-)13 2788( Declarations)1 612(details of the syntax.)3 920 3 1080 5948 t
( the nested declarations and)4 1241( [Sethi 81] observed that many of)6 1520( Sethi)1 291(cult to grasp [Anderson 80].)4 1268 4 1080 6068 t
( been taken as a postfix operator)6 1432(expressions would become simpler if the indirection operator had)8 2888 2 1080 6188 t
(instead of prefix, but by then it was too late to change.)11 2393 1 1080 6308 t
( to declarations remains plausible,)4 1527(In spite of its difficulties, I believe that the C's approach)10 2543 2 1330 6464 t
(and am comfortable with it; it is a useful unifying principle.)10 2633 1 1080 6584 t
( feature of C, its treatment of arrays, is more suspect on practical)12 3011(The other characteristic)2 1059 2 1330 6740 t
( pointers and arrays is)4 976( the relationship between)3 1113( Although)1 476(grounds, though it also has real virtues.)6 1755 4 1080 6860 t
( to describe impor-)3 848( the language shows considerable power)5 1790( Moreover,)1 519(unusual, it can be learned.)4 1163 4 1080 6980 t
( whose length varies at run time, with only a few basic rules)12 2750(tant concepts, for example, vectors)4 1570 2 1080 7100 t
( handled by the same mechanisms as any)7 1937( particular, character strings are)4 1455( In)1 165(and conventions.)1 763 4 1080 7220 t
cleartomark
showpage
saveobj restore
%%EndPage: 12 12
%%Page: 13 13
/saveobj save def
mark
13 pagesetup
11 I f
( 13)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( com-)1 257( is interesting to)3 723( It)1 128(other array, plus the convention that a null character terminates a string.)11 3212 4 1080 840 t
(pare C's approach with that of two nearly contemporaneous languages, Algol 68 and Pascal [Jen-)14 4320 1 1080 960 t
( considerable mechanism)2 1121( in Algol 68 either have fixed bounds, or are `flexible:')10 2484( Arrays)1 360(sen 74].)1 355 4 1080 1080 t
( \(and)1 225(is required both in the language definition, and in compilers, to accommodate flexible arrays)13 4095 2 1080 1200 t
( arrays and strings,)3 839( Pascal had only fixed-sized)4 1248( Original)1 426(not all compilers fully implement them.\))5 1807 4 1080 1320 t
( this was partially fixed, though the resulting)7 2068( Later,)1 328( proved confining [Kernighan 81].)4 1565(and this)1 359 4 1080 1440 t
(language is not yet universally available.)5 1795 1 1080 1560 t
( from)1 249( Aside)1 320( conventionally terminated by a marker.)5 1797(C treats strings as arrays of characters)6 1704 4 1330 1716 t
( string literals, the semantics of strings are fully subsumed)9 2607(one special rule about initialization by)5 1713 2 1080 1836 t
( as a result the language is simpler to describe and)10 2234(by more general rules governing all arrays, and)7 2086 2 1080 1956 t
( costs accrue from its)4 969( Some)1 316(to translate than one incorporating the string as a unique data type.)11 3035 3 1080 2076 t
( than in other designs because application)6 1879(approach: certain string operations are more expensive)6 2441 2 1080 2196 t
( occasionally search for the end of a string, because few built-in)11 2947(code or a library routine must)5 1373 2 1080 2316 t
( storage management for strings falls more)6 1975(operations are available, and because the burden of)7 2345 2 1080 2436 t
( C's approach to strings works well.)6 1586( Nevertheless,)1 649(heavily on the user.)3 861 3 1080 2556 t
( unfortunate)1 555(On the other hand, C's treatment of arrays in general \(not just strings\) has)13 3515 2 1330 2712 t
( prevalence of pointers in C pro-)6 1427( The)1 227(implications both for optimization and for future extensions.)7 2666 3 1080 2832 t
( declared explicitly or arising from arrays, means that optimizers must be)11 3360(grams, whether those)2 960 2 1080 2952 t
( compil-)1 370( Sophisticated)1 649(cautious, and must use careful dataflow techniques to achieve good results.)10 3301 3 1080 3072 t
( change, but some important usages remain)6 1980(ers can understand what most pointers can possibly)7 2340 2 1080 3192 t
( functions with pointer arguments derived from arrays are hard)9 2803( example,)1 433( For)1 215(difficult to analyze.)2 869 4 1080 3312 t
( into efficient code on vector machines, because it is seldom possible to determine that)14 3850(to compile)1 470 2 1080 3432 t
( data also referred to by another argument, or accessible)9 2562(one argument pointer does not overlap)5 1758 2 1080 3552 t
( describes the semantics of)4 1245( fundamentally, the definition of C so specifically)7 2300(externally. More)1 775 3 1080 3672 t
( permitting opera-)2 801(arrays that changes or extensions treating arrays as more primitive objects, and)11 3519 2 1080 3792 t
( extensions to permit)3 924( Even)1 282( hard to fit into the existing language.)7 1659(tions on them as wholes, become)5 1455 4 1080 3912 t
( arrays whose size is determined dynamically are not)8 2363(the declaration and use of multidimensional)5 1957 2 1080 4032 t
( would make it much easier)5 1257(entirely straightforward [MacDonald 89] [Ritchie 90], although they)7 3063 2 1080 4152 t
( C covers the most important uses of strings and arrays)10 2514( Thus,)1 315(to write numerical libraries in C.)5 1491 3 1080 4272 t
( by a uniform and simple mechanism, but leaves problems for highly efficient)12 3520(arising in practice)2 800 2 1080 4392 t
(implementations and for extensions.)3 1595 1 1080 4512 t
( in the language and its description besides those discussed)9 2702(Many smaller infelicities exist)3 1368 2 1330 4668 t
( that transcend detailed points.)4 1389( are also general criticisms to be lodged)7 1833( There)1 323(above, of course.)2 775 4 1080 4788 t
( generally-expected environment provide little help)5 2273(Chief among these is that the language and its)8 2047 2 1080 4908 t
( naming structure provides only two main levels, `external')8 2692( The)1 237( very large systems.)3 906(for writing)1 485 4 1080 5028 t
( intermediate level of visibility)4 1362( An)1 191( a single procedure\).)3 898(\(visible everywhere\) and `internal' \(within)4 1869 4 1080 5148 t
( there)1 247( Thus,)1 306(\(within a single file of data and procedures\) is weakly tied to the language definition.)14 3767 3 1080 5268 t
( project designers are forced to create their own con-)9 2318(is little direct support for modularization, and)6 2002 2 1080 5388 t
(ventions.)1080 5508 w
( provides two durations of storage: `automatic' objects that exist while)10 3253(Similarly, C itself)2 817 2 1330 5664 t
(control resides in or below a procedure, and `static,' existing throughout execution of a program.)14 4320 1 1080 5784 t
( of)1 129(Off-stack, dynamically-allocated storage is provided only by a library routine and the burden)12 4191 2 1080 5904 t
(managing it is placed on the programmer: C is hostile to automatic garbage collection.)13 3801 1 1080 6024 t
11 B f
(Whence Success?)1 815 1 1080 6264 t
11 R f
( qualities)1 406( What)1 298(C has become successful to an extent far surpassing any early expectations.)11 3366 3 1330 6420 t
(contributed to its widespread use?)4 1495 1 1080 6540 t
( made the language)3 892(Doubtless the success of Unix itself was the most important factor; it)11 3178 2 1330 6696 t
( of course, Unix's use of C and its con-)9 1732( Conversely,)1 585( of people.)2 469(available to hundreds of thousands)4 1534 4 1080 6816 t
( the)1 167( But)1 221( machines was important in the system's success.)7 2204(sequent portability to a wide variety of)6 1728 4 1080 6936 t
(language's invasion of other environments suggests more fundamental merits.)8 3434 1 1080 7056 t
( occasionally even to the adept, C)6 1607(Despite some aspects mysterious to the beginner and)7 2463 2 1330 7212 t
cleartomark
showpage
saveobj restore
%%EndPage: 13 13
%%Page: 14 14
/saveobj save def
mark
14 pagesetup
11 I f
( 14)1 1764( of C)2 216(Ritchie Development)1 2340 3 1080 490 t
11 R f
( types and)2 450( Its)1 168( compilers.)1 491(remains a simple and small language, translatable with simple and small)10 3211 4 1080 840 t
(operations are well-grounded in those provided by real machines, and for people used to how)14 4320 1 1080 960 t
( generating time- and space-efficient programs is not dif-)8 2529(computers work, learning the idioms for)5 1791 2 1080 1080 t
( is sufficiently abstracted from machine details that program)8 2664( the same time the language)5 1229(ficult. At)1 427 3 1080 1200 t
(portability can be achieved.)3 1213 1 1080 1320 t
( support always remained in touch with a real)8 2106(Equally important, C and its central library)6 1964 2 1330 1476 t
( to prove a point, or to serve as an example, but as a)13 2295( was not designed in isolation)5 1317(environment. It)1 708 3 1080 1596 t
( did useful things; it was always meant to interact with a larger operat-)13 3138(tool to write programs that)4 1182 2 1080 1716 t
( approach)1 429( parsimonious, pragmatic)2 1119( A)1 137(ing system, and was regarded as a tool to build larger tools.)11 2635 4 1080 1836 t
( many programmers, but)3 1120(influenced the things that went into C: it covers the essential needs of)12 3200 2 1080 1956 t
(does not try to supply too much.)6 1425 1 1080 2076 t
( which)1 298(Finally, despite the changes that it has undergone since its first published description,)12 3772 2 1330 2232 t
(was admittedly informal and incomplete, the actual C language as seen by millions of users using)15 4320 1 1080 2352 t
( stable and unified compared to those of simi-)8 2056(many different compilers has remained remarkably)5 2264 2 1080 2472 t
( of C\320)2 353( are differing dialects)3 970( There)1 322(larly widespread currency, for example Pascal and Fortran.)7 2675 4 1080 2592 t
( described by the older K&R and the newer Standard C\320but on the whole,)13 3330(most noticeably, those)2 990 2 1080 2712 t
( the most significant)3 900( Perhaps)1 404( of proprietary extensions than other languages.)6 2095(C has remained freer)3 921 4 1080 2832 t
( to deal with peculiarities of)5 1326(extensions are the `far' and `near' pointer qualifications intended)8 2994 2 1080 2952 t
( C was not originally designed with portability as a prime goal, it)12 2868( Although)1 472( processors.)1 518(some Intel)1 462 4 1080 3072 t
( systems, on machines ranging from)5 1629(succeeded in expressing programs, even including operating)6 2691 2 1080 3192 t
(the smallest personal computers through the mightiest supercomputers.)7 3128 1 1080 3312 t
( accidents of history surely helped, it)6 1664( While)1 330(C is quirky, flawed, and an enormous success.)7 2076 3 1330 3468 t
( a system implementation language efficient enough to displace)8 2964(evidently satisfied a need for)4 1356 2 1080 3588 t
( sufficiently abstract and fluent to describe algorithms and interactions in a)11 3298(assembly language, yet)2 1022 2 1080 3708 t
(wide variety of environments.)3 1318 1 1080 3828 t
11 B f
(Acknowledgments)1080 4068 w
11 R f
( the direct contributors to today's C lan-)7 1889(It is worth summarizing compactly the roles of)7 2181 2 1330 4224 t
( directly from Martin)3 961( Thompson created the B language in 1969-70; it was derived)10 2821(guage. Ken)1 538 3 1080 4344 t
( turned B into C during 1971-73, keeping most of B's syntax)11 2781( Ritchie)1 354( Dennis)1 375(Richards's BCPL.)1 810 4 1080 4464 t
( Alan Snyder,)2 610( Ritchie,)1 403( types and many other changes, and writing the first compiler.)10 2734(while adding)1 573 4 1080 4584 t
( contributed language ideas during 1972-1977,)5 2091(Steven C. Johnson, Michael Lesk, and Thompson)6 2229 2 1080 4704 t
( the collection of)3 814( this period,)2 574( During)1 392(and Johnson's portable compiler remains widely used.)6 2540 4 1080 4824 t
( to these people and many others at Bell Laboratories.)9 2441(library routines grew considerably, thanks)4 1879 2 1080 4944 t
( definition for sev-)3 821(In 1978, Brian Kernighan and Ritchie wrote the book that became the language)12 3499 2 1080 5064 t
( Especially)1 514( X3J11 committee standardized the language.)5 2006( in 1983, the ANSI)4 836( Beginning)1 515(eral years.)1 449 5 1080 5184 t
( J. Plauger,)2 496( P.)1 149( efforts on track were its officers Jim Brodie, Tom Plum, and)11 2718(notable in keeping its)3 957 4 1080 5304 t
(and the successive draft redactors, Larry Rosler and Dave Prosser.)9 2908 1 1080 5424 t
( Prosser, Peter Nelson, Rob Pike, Ken)6 1853(I thank Brian Kernighan, Doug McIlroy, Dave)6 2217 2 1330 5580 t
(Thompson, and HOPL's referees for advice in the preparation of this paper.)11 3325 1 1080 5700 t
11 B f
(References)2986 5940 w
10 R f
( National Standards Institute,)3 1166( American)1 833([ANSI 89])1 424 3 1080 6122 t
10 I f
(American National Standard for Information)4 1801 1 3528 6122 t
(Systems\320Programming Language C,)2 1508 1 1944 6232 t
10 R f
(X3.159-1989.)3477 6232 w
( Anderson, `Type syntax in the language C: an object lesson in syntactic innova-)13 3218( B.)1 377([Anderson 80])1 579 3 1080 6378 t
(tion,' SIGPLAN Notices)2 991 1 1944 6488 t
10 B f
(15)2960 6488 w
10 R f
(\(3\), March, 1980, pp. 21-27.)4 1134 1 3085 6488 t
( R. Bell, `Threaded Code,' C. ACM)6 1432( J.)1 570([Bell 72])1 358 3 1080 6634 t
10 B f
(16)3465 6634 w
10 R f
(\(6\), pp. 370-372.)2 674 1 3590 6634 t
( H. Canaday and D. M. Ritchie, `Bell Laboratories BCPL,' AT&T Bell Laborato-)12 3260( R.)1 416([Canaday 69])1 540 3 1080 6780 t
(ries internal memorandum, May, 1969.)4 1562 1 1944 6890 t
( J. Corbato, M. Merwin-Dagget, R. C. Daley, `An Experimental Time-sharing Sys-)11 3318( F.)1 432([Corbato 62])1 513 3 1080 7036 t
(tem,' AFIPS Conf. Proc. SJCC, 1962, pp. 335-344.)7 2051 1 1944 7146 t
( J. Cox and A. J. Novobilski,)6 1156( B.)1 598([Cox 86])1 358 3 1080 7292 t
10 I f
(Object-Oriented Programming: An Evolutionary)3 1956 1 3217 7292 t
cleartomark
showpage
saveobj restore
%%EndPage: 14 14
%%Page: 15 15
/saveobj save def
mark
15 pagesetup
10 I f
( 15)1 1800( of C)2 195(Ritchie Development)1 2325 3 1080 480 t
(Approach,)1944 830 w
10 R f
(Addison-Wesley: Reading, Mass., 1986. Second edition, 1991.)6 2515 1 2388 830 t
( H. Gehani and W. D. Roome,)6 1209( N.)1 482([Gehani 89])1 479 3 1080 976 t
10 I f
(Concurrent C,)1 578 1 3275 976 t
10 R f
(Silicon Press: Summit, NJ, 1989.)4 1327 1 3878 976 t
( Jensen and N. Wirth,)4 865( K.)1 504([Jensen 74])1 457 3 1080 1122 t
10 I f
(Pascal User Manual and Report,)4 1324 1 2931 1122 t
10 R f
(Springer-Verlag: New)1 889 1 4280 1122 t
( Edition, 1974.)2 595( Second)1 344(York, Heidelberg, Berlin.)2 1023 3 1944 1232 t
( C. Johnson and B. W. Kernighan, `The Programming Language B,' Comp. Sci.)12 3200( S.)1 426([Johnson 73])1 519 3 1080 1378 t
(Tech. Report #8, AT&T Bell Laboratories \(January 1973\).)7 2340 1 1944 1488 t
( C. Johnson and D. M. Ritchie, `Portability of C Programs and the UNIX System,')14 3296( S.)1 382([Johnson 78a])1 563 3 1080 1634 t
(Bell Sys. Tech. J.)3 700 1 1944 1744 t
10 B f
(57)2694 1744 w
10 R f
(\(6\) \(part 2\), July-Aug, 1978.)4 1134 1 2819 1744 t
( C. Johnson, `A Portable Compiler: Theory and Practice,' Proc. 5th ACM POPL)12 3209( S.)1 376([Johnson 78b])1 569 3 1080 1890 t
(Symposium \(January 1978\).)2 1130 1 1944 2000 t
( C. Johnson, `Yet another compiler-compiler,' in)6 1950( S.)1 382([Johnson 79a])1 563 3 1080 2146 t
10 I f
(Unix Programmer's Manual,)2 1168 1 4000 2146 t
10 R f
(Sev-)5193 2146 w
( Bell Labora-)2 532( AT&T)1 322(enth Edition, Vol. 2A, M. D. McIlroy and B. W. Kernighan, eds.)11 2586 3 1944 2256 t
(tories: Murray Hill, NJ, 1979.)4 1191 1 1944 2366 t
( C. Johnson, `Lint, a Program Checker,' in)7 1701( S.)1 376([Johnson 79b])1 569 3 1080 2512 t
10 I f
(Unix Programmer's Manual,)2 1168 1 3751 2512 t
10 R f
(Seventh)4944 2512 w
( Bell Laboratories:)2 749( AT&T)1 322(Edition, Vol. 2B, M. D. McIlroy and B. W. Kernighan, eds.)10 2384 3 1944 2622 t
(Murray Hill, NJ, 1979.)3 916 1 1944 2732 t
( W. Kernighan and D. M. Ritchie,)6 1359( B.)1 344([Kernighan 78])1 612 3 1080 2878 t
10 I f
(The C Programming Language,)3 1278 1 3420 2878 t
10 R f
(Prentice-Hall:)4723 2878 w
( edition, 1988.)2 578( Second)1 344(Englewood Cliffs, NJ, 1978.)3 1144 3 1944 2988 t
( W. Kernighan, `Why Pascal is not my favorite programming language,' Comp.)11 3187( B.)1 344([Kernighan 81])1 612 3 1080 3134 t
(Sci. Tech. Rep. #100, AT&T Bell Laboratories, 1981.)7 2156 1 1944 3244 t
( E. Lesk, `A Portable I/O Package,' AT&T Bell Laboratories internal memoran-)11 3199( M.)1 593([Lesk 73])1 385 3 1080 3390 t
(dum ca. 1973.)2 566 1 1944 3500 t
( MacDonald, `Arrays of variable length,' J. C Lang. Trans)9 2325( T.)1 288([MacDonald 89])1 662 3 1080 3646 t
10 B f
(1)4380 3646 w
10 R f
(\(3\), Dec. 1989, pp.)3 751 1 4455 3646 t
(215-233.)1944 3756 w
( M. McClure, `TMG\320A Syntax Directed Compiler,' Proc. 20th ACM National)10 3186( R.)1 410([McClure 65])1 546 3 1080 3902 t
(Conf. \(1965\), pp. 262-274.)3 1074 1 1944 4012 t
( D. McIlroy, `Macro Instruction Extensions of Compiler Languages,' C. ACM)10 3135( M.)1 460([McIlroy 60])1 518 3 1080 4158 t
10 B f
(3)5218 4158 w
10 R f
(\(4\), pp. 214-220.)2 674 1 1944 4268 t
( D. McIlroy and B. W. Kernighan, eds,)7 1558( M.)1 460([McIlroy 79])1 518 3 1080 4414 t
10 I f
(Unix Programmer's Manual,)2 1168 1 3641 4414 t
10 R f
(Seventh Edi-)1 519 1 4834 4414 t
(tion, Vol. I, AT&T Bell Laboratories: Murray Hill, NJ, 1979.)9 2451 1 1944 4524 t
( Meyer,)1 310( B.)1 505([Meyer 88])1 451 3 1080 4670 t
10 I f
(Object-oriented Software Construction,)2 1586 1 2371 4670 t
10 R f
(Prentice-Hall: Englewood Cliffs,)2 1318 1 3982 4670 t
(NJ, 1988.)1 386 1 1944 4780 t
( Nelson,)1 333( G.)1 487([Nelson 91])1 474 3 1080 4926 t
10 I f
(Systems Programming with Modula-3,)3 1544 1 2424 4926 t
10 R f
(Prentice-Hall: Englewood Cliffs,)2 1318 1 3993 4926 t
(NJ, 1991.)1 386 1 1944 5036 t
( I. Organick,)2 504( E.)1 388([Organick 75])1 562 3 1080 5182 t
10 I f
(The Multics System: An Examination of its Structure,)7 2127 1 2559 5182 t
10 R f
(MIT Press:)1 447 1 4711 5182 t
(Cambridge, Mass., 1975.)2 1005 1 1944 5292 t
( Richards, `The BCPL Reference Manual,' MIT Project MAC Memorandum M-)10 3217( M.)1 432([Richards 67])1 546 3 1080 5438 t
(352, July 1967.)2 617 1 1944 5548 t
( Richards and C. Whitbey-Strevens,)4 1437( M.)1 432([Richards 79])1 546 3 1080 5694 t
10 I f
(BCPL: The Language and its Compiler,)5 1601 1 3520 5694 t
10 R f
(Cam-)5146 5694 w
(bridge Univ. Press: Cambridge, 1979.)4 1513 1 1944 5804 t
( M. Ritchie, `UNIX: A Retrospective,' Bell Sys. Tech. J.)9 2267( D.)1 481([Ritchie 78])1 480 3 1080 5950 t
10 B f
(57)4358 5950 w
10 R f
(\(6\) \(part 2\), July-Aug,)3 884 1 4483 5950 t
(1978.)1944 6060 w
( M. Ritchie, `The Evolution of the UNIX Time-sharing System,' AT&T Bell Labs.)12 3314( D.)1 481([Ritchie 84])1 480 3 1080 6206 t
(Tech. J.)1 313 1 1944 6316 t
10 B f
(63)2307 6316 w
10 R f
(\(8\) \(part 2\), Oct. 1984.)4 906 1 2432 6316 t
( M. Ritchie, `Variable-size arrays in C,' J. C Lang. Trans.)10 2301( D.)1 481([Ritchie 90])1 480 3 1080 6462 t
10 B f
(2)4392 6462 w
10 R f
(\(2\), Sept. 1990, pp.)3 769 1 4467 6462 t
(81-86.)1944 6572 w
( Sethi, `Uniform syntax for type expressions and declarators,' Softw. Prac. and Exp.)12 3358( R.)1 559([Sethi 81])1 397 3 1080 6718 t
10 B f
(11)1944 6828 w
10 R f
(\(6\), June 1981, pp. 623-628.)4 1132 1 2069 6828 t
( Snyder,)1 333( A.)1 487([Snyder 74])1 474 3 1080 6974 t
10 I f
(A Portable Compiler for the Language C,)6 1670 1 2399 6974 t
10 R f
(MIT: Cambridge, Mass., 1974.)3 1241 1 4094 6974 t
( E. Stoy and C. Strachey, `OS6\320An experimental operating system for a small)12 3166( J.)1 553([Stoy 72])1 375 3 1080 7120 t
(computer. Part I: General principles and structure,' Comp J.)8 2393 1 1944 7230 t
10 B f
(15)4387 7230 w
10 R f
(, \(Aug. 1972\), pp.)3 713 1 4487 7230 t
cleartomark
showpage
saveobj restore
%%EndPage: 15 15
%%Page: 16 16
/saveobj save def
mark
16 pagesetup
10 I f
( 16)1 1800( of C)2 195(Ritchie Development)1 2325 3 1080 480 t
10 R f
(117-124.)1944 830 w
( Stroustrup,)1 467( B.)1 348([Stroustrup 86])1 608 3 1080 976 t
10 I f
(The C++ Programming Language,)3 1414 1 2528 976 t
10 R f
(Addison-Wesley: Reading, Mass.,)2 1368 1 3967 976 t
( edition, 1991.)2 578(1986. Second)1 569 2 1944 1086 t
( P. Thacker, E. M. McCreight, B. W. Lampson, R. F. Sproull, D. R. Boggs, `Alto:)15 3275( C.)1 439([Thacker 79])1 517 3 1080 1232 t
(A Personal Computer,' in)3 1027 1 1944 1342 t
10 I f
(Computer Structures: Principles and Examples,)4 1918 1 2996 1342 t
10 R f
(D.)4939 1342 w
(Sieworek, C. G. Bell, A. Newell, McGraw-Hill: New York, 1982.)9 2632 1 1944 1452 t
([Thinking 90])1 558 1 1080 1598 t
10 I f
(C* Programming Guide,)2 997 1 1944 1598 t
10 R f
(Thinking Machines Corp.: Cambridge Mass., 1990.)5 2063 1 2966 1598 t
( Thompson, `Bon\320an Interactive Language,' undated AT&T Bell Laboratories)8 3183( K.)1 342([Thompson 69])1 619 3 1080 1744 t
(internal memorandum \(ca. 1969\).)3 1339 1 1944 1854 t
( van Wijngaarden, B. J. Mailloux, J. E. Peck, C. H. Koster, M. Sintzoff, C. Lindsey,)15 3356( A.)1 255([Wijngaarden 75])1 706 3 1080 2000 t
(L. G. Meertens, R. G. Fisker, `Revised report on the algorithmic language Algol 68,')13 3390 1 1944 2110 t
(Acta Informatica)1 678 1 1944 2220 t
10 B f
(5)2647 2220 w
10 R f
(, pp. 1-236.)2 458 1 2697 2220 t
cleartomark
showpage
saveobj restore
%%EndPage: 16 16
%%Trailer
done
%%Pages: 16
%%DocumentFonts: Courier Times-Bold Times-Italic Times-Roman Times-Roman
From: Steve Casselman
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F05EF2.17DD@vcc.com>
Ketil Z Malde wrote:
>
> Steve Casselman <··@vcc.com> writes:
>
> > If you take the picojava as an example it runs java 15 times faster
> > than a Pentium. (EE-Times jan 13 97 p56) so if a picojava runs at
> > 33MHz it will take a 500MHz Pentium to keep up. This artical also
> > stated that the picojava ran 5 1/2 times faster than just in time
> > compilers.
>
> And the picojava architecture will run other languages at a decent speed
> as well? And its development keep up with JIT compiler technology?
By using reconfigurable technology you could design a picolisp,
picosmalltalk, picohaskell, picoC++ and have them all run on the same
silicon but swapp them in and out in microseconds. I know it is hard
to accept a new way of doing things but the above pico jive is just
to point out with reconfigurable technology you are the master
over hardware.
You want to know what is really going to rock the world is evolvable
hardware see http://www.cogs.susx.ac.uk/users/adrianth/index.html
for a far out look at the furture.
Steve Casselman
In article <·············@vcc.com> ··@vcc.com "Steve Casselman" writes:
> By using reconfigurable technology you could design a picolisp,
> picosmalltalk, picohaskell, picoC++ and have them all run on the same
> silicon but swapp them in and out in microseconds. I know it is hard
> to accept a new way of doing things but the above pico jive is just
> to point out with reconfigurable technology you are the master
> over hardware.
Wasn't something like this possible with the Xerox Dorado?
I seem to recall reading that it could switch microcode in
one microsecond.
> You want to know what is really going to rock the world is evolvable
> hardware see http://www.cogs.susx.ac.uk/users/adrianth/index.html
> for a far out look at the furture.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: Ketil Z Malde
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <KETIL-ytqu3nzmx4w.fsf@imr.no>
Steve Casselman <··@vcc.com> writes:
> If you take the picojava as an example it runs java 15 times faster
> than a Pentium. (EE-Times jan 13 97 p56) so if a picojava runs at
> 33MHz it will take a 500MHz Pentium to keep up. This artical also
> stated that the picojava ran 5 1/2 times faster than just in time
> compilers.
And the picojava architecture will run other languages at a decent speed
as well? And its development keep up with JIT compiler technology?
BTW, I know just about nothing about Java internals, but my impression was
that the stack-based execution of the byte code were somewhat suboptimal
for modern chips. Somebody wish to comment?
I'm not saying it's not a good, useful technology, but my impression was
that what killed the lisp machines of yore, was that more general
purpose (language wise!) computers would run lisp about as fast, as well
as run other languages a lot faster.
~kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From: Jon Leech
Subject: 3 Mbit Ethernet (was Re: Theory #51 (superior(?) programming languages))
Date:
Message-ID: <5crn5i$8fc@watt.cs.unc.edu>
In article <··········@world.std.com>, Jeff DelPapa <··@world.std.com> wrote:
>It doesn't help your adoption battle that the system was very complex
>for its day, and the product of the same community that gave us ITS
>(<alt><alt>U anyone), and the original emacs. They had a window
>system, pointing device, and LAN well before they were in normal
>use. (for example the lan used in the first machines predated the
>10mhz ethernet standard, it was modeled after the expiremental, you
>can't buy any 3mhz system that Xerox was trying at PARC). [snipped]
We ran 3 Mbit Ethernet in the Caltech Computer Science Department for a
while, though I don't remember the provenance of the hardware.
Jon
··@/
From: Jon Leech
Subject: Re: 3 Mbit Ethernet (was Re: Theory #51 (superior(?) programming languages))
Date:
Message-ID: <5ctccl$b6p@watt.cs.unc.edu>
In article <··········@world.std.com>, Jeff DelPapa <··@world.std.com> wrote:
>In article <··········@watt.cs.unc.edu>, Jon Leech <·····@cs.unc.edu> wrote:
>> We ran 3 Mbit Ethernet in the Caltech Computer Science Department for a
>>while, though I don't remember the provenance of the hardware.
>
>Xerox did seed some Alto's to universities, MIT had some.
We had it on a VAX 11/780 running BSD.
Jon
··@/
From: Simon Brooke
Subject: Re: 3 Mbit Ethernet (was Re: Theory #51 (superior(?) programming languages))
Date:
Message-ID: <5d7085$qb@caleddon.intelligent.co.uk>
In article <··········@world.std.com>,
··@world.std.com (Jeff DelPapa) writes:
>
> Xerox did seed some Alto's to universities, MIT had some. Much later,
> they actually started to sell their lisp hardware. If you ordered a
> dandelion, it came with 10Mbit modern ether. If you were crazed, and
> insisted repeatedly, they woud build a dorado for you. (ecl cpu, made
> a great space heater). Dorado's supposedly were stuck with 3Mbit
> ether, as they wern't going to touch the design.
Well, while I confess to being *extremely* jealous of your Dorado, the
Dandelions weren't that bad as space-heaters either. The nice
government bought me three of them[1], and I used to have them in a
little south-facing lab with plate glass non-opening windows and no
air-conditioning. It could get quite warm in there, on a summer's
day... They actually had a cut-out in them which switched them off
when the got too hot. It was a good reminder that it was time to go
out and have an ice-cream.
[1] In theory other people were supposed to use them as well, but as
no-one else could be bothered to learn how I had them all to myself.
--
·····@intelligent.co.uk (Simon Brooke) http://www.intelligent.co.uk/~simon
-- mens vacua in medio vacuo --
Ketil Z Malde wrote:
> BTW, I know just about nothing about Java internals, but my impression was
> that the stack-based execution of the byte code were somewhat suboptimal
> for modern chips. Somebody wish to comment?
Stack-based execution in principle isn't really bad. Single-stack is.
JavaVM is single-stack. Since typical Java code doesn't do much around
the top of stack, a T9000-like implementation could handle the stack
frame as "registers" and try to schedule all the stack ops as data flow
instructions (almost). This could give good performance, at a high
price. For today, certainly it's suboptimal. We don't know when the
wheel of reincarnation turns back again to the 60th, where this sort of
CISC was good.
> I'm not saying it's not a good, useful technology, but my impression was
> that what killed the lisp machines of yore, was that more general
> purpose (language wise!) computers would run lisp about as fast, as well
> as run other languages a lot faster.
Agreed. And unlike Lisp, Java is a lot of hot air and marketing bubble.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca
(John Bayko) writes:
> Algol-60 was not *a* language - it was at least three. In fact,
> each implementation could almost be considered a different language,
> as far as syntax details.
<Blink> Algol-60 syntax was Algol-60 syntax. Period. I think you're
getting confused with Algol-W and Algol-68 which were different
languages with somewhat different syntaxes.
--
This message is Mime compatible - it can coexist with lying dwarves
who sing in German.
In article <··········@sue.cc.uregina.ca> ·····@borealis.cs.uregina.ca
(John Bayko) wrote:
> Algol-60 was not *a* language - it was at least three.
·············@Smallworld.co.uk (Arthur Chance) replied:
:<Blink> Algol-60 syntax was Algol-60 syntax. Period. I think you're
:getting confused with Algol-W and Algol-68 which were different
:languages with somewhat different syntaxes.
More probably Bayko was confused by the fact that while Algol 60 had
one and only one *syntax*, it allowed for several different *lexical*
formats. There was one format that was allowed to substitute
<subscript>xxx<normal> for [xxx] (subscripts) and
<superscript>xxx<normal> for <power> (xxx), but that faded away.
There was the publication format used in e.g. CACM Algorithms, with
keywords in boldface. And different machines had different "hardware"
formats, such as IBM's apostrophes-around-keywords format. These days
that sounds like anarchy, but since there was no "practically universal"
character code (heck, at one time I had a table giving four different
_punched card_ codings for the _same_ character set) the only alternative
to recognising the variation that actually existed would have been to
standardise on some very small character set. (Hmm. A-Z, 0-9, decimal
point, comma, +, -, *, /, parentheses. Fortran, anyone?)
Algol 68 continued the tradition of allowing multiple lexical forms.
If I recall correctly, there were four official ways of indicating keywords.
Algol 68 compilers could be told which lexical form to process at run time.
In this decade, it was possible for the Ada 95 standardisers to nominate
a single universal character set to be used for their language, a character
set that currently contains 38 885 characters. Things have come a _long_
way from the old "every manufacturer a different 6-bit code" days.
I'm actually reading this in comp.arch. The odd thing is that this _is_
a hardware issue, not a language issue. _Hardware_ changes (large memories,
very fast machines, cheap raster graphic displays, laser printers, &c) have
permitted a change in language design. You couldn't, for example, have had
visual programming languages (languages that is where programming is done
by connecting pictures) without cheap displays. I find myself wondering
what languages that use 3D multimedia _to express the language_ will be like.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Rob Warnock
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5ehkek$60q@fido.asd.sgi.com>
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote:
+---------------
| I'm actually reading this in comp.arch. The odd thing is that this _is_
| a hardware issue, not a language issue. _Hardware_ changes (large memories,
| very fast machines, cheap raster graphic displays, laser printers, &c) have
| permitted a change in language design. You couldn't, for example, have had
| visual programming languages (languages that is where programming is done
| by connecting pictures) without cheap displays.
+---------------
Actually, that's not *quite* true... ;-} ;-}
The list programming language "AMBIT/L", that I played with briefly
[and most enjoyably!] in the early 1970's, used textual Algol-like
block-structured control constructs, but predicates and data mutations
(assignments) were expressed as *pictures* which showed the interconnections
of both the "old" data and the "new" data. These pictures were printed
in character graphics in the listing file output by the compiler (sort
of the ultimate in "pretty-printing!).
You coded your program by first drawing your before & after pictures on
a pad of *paper* marked with coordinates -- basically the good old box &
pointer pictures well-loved by Lisp fans, using (well, the way I did it)
two colors of pencil for the "before" pointers/data and the "after" --
and then entered the program in a plain-text "pic"-like language that
said where the boxes were to be on the printed listing page and where
the pointer links needed to be (though *not* the routing, the compiler
would do that for you!), plus any control flow statements, etc.
A data mutation was a kind of pattern match & replace. When the control
flow reach a given pattern/block/item/(?), if the data in the global heap
matched the "before" picture, then the mutation "succeeded" and the
matching data was mutated to look like the "after" picture. If not,
the mutation "failed". As in SNOBOL (which it reminded me of a lot),
you could branch on success/failure.
Arithmetic predicates could cause success/fail, but I forget whether
it was done inside the box containing a variable or as an annotation.
(I show the latter below.) I also forget how I/O was done. Local
variable names for values could be introduced, so that data in the
"after" part could be computed from data in the "before" part.
Here's a really simple example. If you wanted to do something like:
(while (< cnt 10)
(set! cnt (+ 1 cnt))
(set! foo (car foo)))
you'd input it [I almost said "keypunch", but we had Teletypes in the
PDP-10 I ran AMBIT/L on] something like this (please pardon me for
faint memory):
while
block
var,1,30,13,count
box,2,30,15,number,tmp && tmp < 10
box,3,33,15,new_number,tmp + 1
var,4,32,18,pointer,foo
box,5,32,20,pointer
box,6,35,20 ; (I don't recall it allowing comment, but...)
ptr,1,2 ; if "count" points to an o.k. value,
new,1,3 ; make it point to a new value.
ptr,4,5 ; if "foo" points to a list
ptr,5,6 ; or at least to a pointer cell,
new,4,6 ; move it to the pointed-to cell.
endblock
and the compiler would list it like this (really!):
while
block
count =========+
| #
| #
V V
+--------+ +---------+
| tmp | | tmp + 1 |
+--------+ +---------+
tmp < 10
foo ===========+
| #
| #
V V
+--------+ +---------+
| |---->| |
+--------+ +---------+
endblock
[We don't need to know anything about the data that "foo" points to
except that the first item is a pointer to another item. No local
names are needed in this case.]
My example is really too trivial to do it justice. It had the ability
to do rich pattern-matching on list structures, and you could use it
to do powerful searches of the the heap. For example, the pattern:
result =========+
#
#
V
+---+---+ +---+---+ +------+
| | |---->| | |---->| |
+-+-+---+ +-+-+---+ +------+
| |
v v
+-------+ +-------+
| 1234 | | 5678 |
+-------+ +-------+
will find *any* data in the heap of the form "(1234 5678 . rest-of-list)"
and set "result" to "rest-of-list". (Hmmm... Or did searches have to be
"anchored" with at least one global variable pointing into the pattern?
I forget. But you get the idea...)
Anyway, O'Keefe is partly right in that it certainly was clumsy. As legions
of "troff" and "pic" users know, it's far more work (and one spends far
more time) to make such things pretty than to make them merely correct. ;-}
(E.g., above I deliberately made "count" and "foo" not line up -- something
one would have spent lots of time tweaking during debugging.) "Drag & drop"
would have certainly helped...
-Rob
p.s. References (see a FOLDOC web server near you):
1. AMBIT -- Algebraic Manipulation by Identity Translation (also claimed:
"Acronym May Be Ignored Totally").
An early pattern-matching language, developed by C. Christensen of
Massachusetts Computer Assocs in 1964, aimed at algebraic manipulation.
2. AMBIT/L -- "An Introduction to AMBIT/L, A Diagrammatic Language for
List Processing", Carlos Christensen, Proc 2nd ACM Symp Symb and Alg
Manip (Mar 1971)].
A variant of AMBIT supporting list handling and pattern matching rules
based on two-dimensional diagrams.
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
From: Steve Miklos
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F8B74F.17CD@citicorp.com>
Bernd Paysan wrote:
> Agreed. And unlike Lisp, Java is a lot of hot air and marketing bubble.
I would sooner put it that unlike Lisp, Java *has* a lot of hot air and
marketing hype behind it, and therefore will probably succeed at what
Lisp has failed to do in spite of its many fine qualities: become a
broadly-used programming system, highly regarded by non-technical
managers.
Regards,
Steve
--
··············@citicorp.com, ··········@aol.com Steve Miklos @ home
Not speaking for the Big Bank:Any comments or statements made are not
necessarily those of Citicorp, its subsidiaries or affiliates.
http://members.aol.com/pialamodem
With a mighty <·············@citicorp.com>,
··············@citicorp.com wibbled into the void...
> Bernd Paysan wrote:
> > Agreed. And unlike Lisp, Java is a lot of hot air and marketing bubble.
>
> I would sooner put it that unlike Lisp, Java *has* a lot of hot air and
> marketing hype behind it, and therefore will probably succeed at what
> Lisp has failed to do in spite of its many fine qualities: become a
> broadly-used programming system, highly regarded by non-technical
> managers.
Ooh, a contraversial viewpoint! ;-) Alas, I'm inclined to agree with you.
History is written by the winning side, but marketing people prefer to
write their "history" _before_ the events have occured!
This suggests that the answer is not to produce higher quality tools, but
to put more effort into marketing whatever you have already, however poor
it may be. My impression, from reading newsgroups like comp.lang.lisp, is
that Lisp people are far too honest for their own good. Quoting CS
papers, refering to Lisp implementations and apps, etc - none of these
tactics appear to have anything close to the effect of the marketing
behind a single (commercial) C++ compiler.
I wonder what $40,000,000 spent on marketing might do for Lisp? Could we
live with the myths that these people might create? Well, if we ensured
that the people marketing Lisp were more honest that the people marketing
C++, Java, etc, then we'd actually have what I'd call "anti-myths", i.e.
truths.
Not that I'd expect any marketing people to know the difference...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: Dave Hansen
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32f9f215.906890@192.168.2.34>
We're drifting a bit from topic, but oh well...
On Thu, 6 Feb 1997 08:41:23 -0000, ············@wildcard.demon.co.uk
(Cyber Surfer) wrote:
>This suggests that the answer is not to produce higher quality tools, but
>to put more effort into marketing whatever you have already, however poor
>it may be.
At the risk of being controversial :) I suggest you need look no
further than Microsoft for evidence of your theory.
>I wonder what $40,000,000 spent on marketing might do for Lisp?
Lisp has been around too long and has built up too much of a
"mystique" to win the hearts and minds (and dollars) of non-techincal
managers. The base of good, experienced Lisp programmers is too
small. And all those parentheses! :)
Look at the successful "romantic" languages of today: C++ and Java.
C++ succeeded because it was based on C (which had an established base
of practitioners from which to draw, and was viewed as a "mainstream"
programming language) and was backed by AT&T (which was seen as a less
risky bet than a company like Stepstone with their Obective C). And
Java succeeds (at least in part) because it looks so much like C++.
Lisp looks like nothing else, and has a reputation as "that esoteric
AI language."
>Could we
>live with the myths that these people might create? Well, if we ensured
>that the people marketing Lisp were more honest that the people marketing
>C++, Java, etc, then we'd actually have what I'd call "anti-myths", i.e.
>truths.
>
I suspect that people are people, whether they are Lispers or not. If
someone thinks they have something to gain by bending or stretching
the truth, they'll do it (or at least a certain percentage of them
will).
All IMHO. Regards,
-=Dave
I can barely speak for myself, so I certainly can't speak for B-Tree.
From: Ozan S. Yigit
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <x6g1z8fi9l.fsf@ds9.border.com>
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> I wonder what $40,000,000 spent on marketing might do for Lisp?
a brief perusal of computing history from would convince you that much
more than this was directly or indirectly spent on lisp, through academic
and commercial research and development funding on AI and through years
of government grants. lisp has had as much or more funding and hype
as any other deserving or undeserving part of computing.
oz
--
related reading:
Daniel Crevier, AI: the Tumultuous History of the
Search for Artificial Intelligence by Daniel Crevier
BasicBooks, 1993
--
simplicity is only skin deep. | electric: ··@border.com
- peter roosen-runge | or [416] 368 0074 x 294
From: ozan s. yigit
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <x6d8ucfgqd.fsf@ds9.border.com>
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> I wonder what $40,000,000 spent on marketing might do for Lisp?
a brief perusal of computing history would convince you that much more
than this was directly or indirectly spent on lisp, through academic
and commercial research and development funding on AI and years of
government grants. lisp has had as much or more funding and hype
as any other deserving or undeserving part of computing.
oz
--
related reading:
Daniel Crevier
AI: the Tumultuous History of the
Search for Artificial Intelligence
BasicBooks, 1993
--
simplicity is only skin deep. | electric: ··@border.com
- peter roosen-runge | or phone:[416] 813 2091
With a mighty <··············@ds9.border.com>,
··@border.com wibbled into the void...
> > I wonder what $40,000,000 spent on marketing might do for Lisp?
>
> a brief perusal of computing history would convince you that much more
> than this was directly or indirectly spent on lisp, through academic
> and commercial research and development funding on AI and years of
> government grants. lisp has had as much or more funding and hype
> as any other deserving or undeserving part of computing.
How much of that money was spent on marketing? If Lisp has been hyped
more than C++, then I must've been reading the wrong magazines. I've yet
to see a full page commercial for a Lisp system, and yet I see many pages
devoted to C++ every month.
Perhaps the magazines I read are too specialised, tho Byte used to review
a Lisp system once every two years. If you know of a general magazine for
software developers that has ever had a regular full page ad for a Lisp
system, please let me know. I'd also be interested to know if such ads
may be found in recent issues.
Y'see, I'd like to subscribe to such a magazine!
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·························@news.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>With a mighty <··············@ds9.border.com>,
>··@border.com wibbled into the void...
>
>> > I wonder what $40,000,000 spent on marketing might do for Lisp?
>>
>> a brief perusal of computing history would convince you that much more
>> than this was directly or indirectly spent on lisp, through academic
>> and commercial research and development funding on AI and years of
>> government grants. lisp has had as much or more funding and hype
>> as any other deserving or undeserving part of computing.
>
>How much of that money was spent on marketing? If Lisp has been hyped
>more than C++, then I must've been reading the wrong magazines. I've yet
>to see a full page commercial for a Lisp system, and yet I see many pages
>devoted to C++ every month.
I think that the average programmer thinks procedurally. No amount of money
is going to convince him or her to spend the intellectual effort to figure
out how to express their problems recursively, or using higher order functions;
especially if their "problem" is handling mouse clicks and sending messages
to windowing "objects" or databases. You can use Lisp as if it weren't a
language designed to implement the lambda calculus, but is it really
competitive as a Better Basic than Basic? Not if you are learning from a
traditional Lisp text.
So my call is no: Microsoft could not make Lisp fly through sheer force of
will and cash, unless they turned it into Basic, or worse, "Visual Basic".
Paul Prescod
With a mighty <··········@undergrad.math.uwaterloo.ca>,
········@csclub.uwaterloo.ca wibbled into the void...
> I think that the average programmer thinks procedurally. No amount of money
> is going to convince him or her to spend the intellectual effort to figure
> out how to express their problems recursively, or using higher order functions;
> especially if their "problem" is handling mouse clicks and sending messages
> to windowing "objects" or databases. You can use Lisp as if it weren't a
> language designed to implement the lambda calculus, but is it really
> competitive as a Better Basic than Basic? Not if you are learning from a
> traditional Lisp text.
You've helped make my point: some of the money could be
spent on writing _new_ Lisp books, that target the problems
that Basic programmers are more likely to deal with. Forget
the AI stuff, and instead concentrate on database, user
interface design, file processing, and perhaps even platform
specific things like OLE.
Pick up a few books about VB, and copy their style. Apply
it to Lisp. It isn't as hopeless as you suggest. If the
$40,000,000 spent on marketing produced only copies of
existing books, magazine articles, adverts etc, then you
could be right. I'm thinking of someone with that kind of
money who was determined to market Lisp in the same way
that C++ and VB have been marketed, i.e. successfully, where
"success" is defined by the huge market that exists for
these tools.
This is why I think that MS failed to push Lisp, in the
past, and that it was probably because they had no idea what
it was. I could be wrong, of course. Perhaps it was an
internal political thing, or that somebody high up decided
that Lisp wasn't "right", i.e. it wasn't Basic. That's also
a kind of political thing, I guess, but it's about the
language itself, rather than the people within MS.
It's unfair to say that "the average programmer thinks
procedurally", when so little effort has been made to
educate the "average programmer".
> So my call is no: Microsoft could not make Lisp fly through sheer force of
> will and cash, unless they turned it into Basic, or worse, "Visual Basic".
A "Visual Lisp" might help promote Lisp in general, which
could have beneffits for _all_ Lisp programmers. In the
corporate world, MS support for a language is significant,
while the technical issues...
Once again, it's a question doing something _because you
can_. A "Visual Lisp" would make it possible to use Lisp
where currently only VC++ or VB will be accepted. We can use
Lisp for anyone we like, but we won't necessarily get _paid_
to do it. That will depend on a variety of factors. Some of
us may be fortunate enough to have arranged things so that
it's always possible to use Lisp. Many more will find it
very hard, due to resistance from people who know nothing
about Lisp.
In my case, it's people who know that C++ can do something,
but have doubts about Lisp. If a Visual Lisp were available,
it might suck compared to many "true" Lisps (ACL, CMU, etc),
but if it supports the features that I need in order to use
Lisp instead of C++, then that'll have to do.
Perhaps the biggest problem that Lisp has not even a
technical one. It's the price. A Lisp that costs 8 times as
much as a C++ for the same platform, and supports a subset
of features (no multi-threading, say), then it doesn't help.
There are C++ people who will slag off VB and Delphi for far
less! What chance does Lisp have?
$40,000,000 spent on marketing Lisp might just help even the
balance. It's unlikely to happen, but perhaps someday...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·························@news.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>With a mighty <··········@undergrad.math.uwaterloo.ca>,
>········@csclub.uwaterloo.ca wibbled into the void...
>
>> I think that the average programmer thinks procedurally. No amount of money
>> is going to convince him or her to spend the intellectual effort to figure
>> out how to express their problems recursively, or using higher order functions;
>> especially if their "problem" is handling mouse clicks and sending messages
>> to windowing "objects" or databases. You can use Lisp as if it weren't a
>> language designed to implement the lambda calculus, but is it really
>> competitive as a Better Basic than Basic? Not if you are learning from a
>> traditional Lisp text.
>
>You've helped make my point: some of the money could be
>spent on writing _new_ Lisp books, that target the problems
>that Basic programmers are more likely to deal with. Forget
>the AI stuff, and instead concentrate on database, user
>interface design, file processing, and perhaps even platform
>specific things like OLE.
But why would a Basic programmer to change to Lisp if they are going
to program Basic-in-Lisp? And just how deep are we willing to "hide"
Lisp? Are we going to encourage globals, and assignments and iteration?
Is popularity worth that? How would we explain all that "funny stuff"
in the language that has no equivalent in Basic or C++?
Lisps have features that Joe Average is never going to appreciate or
want to use no matter how much money we spend on marketing. There are
fourth year students in the programming language course here who
don't "get" functional programming.
I'm not saying that Lisps couldn't be more popular than they are, just
that they will never be mainstream, because they appeal to a particular
kind of programmer. Perhaps with enough marketing, we could convince
the top teir of programmers, but the rest would spend weeks trying to
understand what "map" does, and how it relates to WM_LOSTFOCUS events.
In niches, however, Scheme and other Lisps can do well. DSSSL is a nice
introduction to scheme because you can do powerful things without using
advanced functions and because the primary "objects" being manipulated
(SGML elements) are naturally represented as a lists and lists of lists.
But even though I love DSSSL, and have the option (thanks to Kawa) of
writing GUIs in scheme, I'll probably would not do so, because Java is a
language that is nicely "wrapped" around the objects I want to manipulate.
Then again, maybe I just feel that way because I know Scheme and not CL.
If I was comfortable with the full object system, I might think that
manipulating object state in Lisp was as natural as in Java. But what makes
functional languages so elegant (and reliable) is the *lack* of manipulation
of object state, isn't it? Is that a misconception on my part?
Paul Prescod
With a mighty <··········@undergrad.math.uwaterloo.ca>,
········@csclub.uwaterloo.ca wibbled into the void...
> But why would a Basic programmer to change to Lisp if they are going
> to program Basic-in-Lisp? And just how deep are we willing to "hide"
> Lisp? Are we going to encourage globals, and assignments and iteration?
> Is popularity worth that? How would we explain all that "funny stuff"
> in the language that has no equivalent in Basic or C++?
I was refering to the the style of tutorial, not the language details.
The same language should be taught, but with the emphasis on rather
different problems, like database access. This might seem like a
strange way to use Lisp, but it would be a great way to communicate
the idea that Lisp can be used in the "real world", and isn't just for
AI apps. Not that I'm suggesting AI can't be applied to database apps!
> Lisps have features that Joe Average is never going to appreciate or
> want to use no matter how much money we spend on marketing. There are
> fourth year students in the programming language course here who
> don't "get" functional programming.
"Let them eat cake." Yeah, right.
> I'm not saying that Lisps couldn't be more popular than they are, just
> that they will never be mainstream, because they appeal to a particular
> kind of programmer. Perhaps with enough marketing, we could convince
> the top teir of programmers, but the rest would spend weeks trying to
> understand what "map" does, and how it relates to WM_LOSTFOCUS events.
I don't expect Lisp to ever be mainstream. I just think that we can do
better when we try to explain what Lisp is. I agree that there are a
lot of programmers who won't understand Lisp. Many of them won't even
understand the difference between WHILE and REPEAT/UNTIL, in Basic
(I like to summary it thus: 0 and 1+).
How many programmers are able to understand Lisp, but either don't
know it exists, or believe the C++ propaganda, and so never give Lisp
a chance? As has often been pointed out, you can write apps like web
servers in Lisp! With all the hype for the Web, a book about using a
Lisp-based web server could do a hell of a lot to counter the myths
that persist even today, dispite the many "real world" apps written in
Lisp. My guess is that this is because most people won't know of these
achievements, while they'll have actually _used_ apps written in C++.
I work with people who regularly use an app written in Lisp, but they
wouldn't know it if I didn't tell them (I expect I'll need to remind
them, as it's not something that means anything to them).
> In niches, however, Scheme and other Lisps can do well. DSSSL is a nice
> introduction to scheme because you can do powerful things without using
> advanced functions and because the primary "objects" being manipulated
> (SGML elements) are naturally represented as a lists and lists of lists.
How many people _know_ that Lisp can, and _does_, actually do this?
> But even though I love DSSSL, and have the option (thanks to Kawa) of
> writing GUIs in scheme, I'll probably would not do so, because Java is a
> language that is nicely "wrapped" around the objects I want to manipulate.
I'd rather just use Scheme and ignore Java. I'm sure that you don't
need Kawa to write GUI software in Scheme. Scheme/Tk springs to mind.
> Then again, maybe I just feel that way because I know Scheme and not CL.
> If I was comfortable with the full object system, I might think that
> manipulating object state in Lisp was as natural as in Java. But what makes
> functional languages so elegant (and reliable) is the *lack* of manipulation
> of object state, isn't it? Is that a misconception on my part?
Have you seen Haskell and frameworks like Fudgets and Haggis? I can't
comment on Lisp-based frameworks, as I'm only vaguely familiar with
one of them. I'd prefer any of 'em to the framworks I've seen and used
in C++. I'd prefer the MVC classes in Smalltalk-80 to anything in
Java. I don't know CLIM, unfortunately.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
I think we agree that Lisp will not be mainstream anytime soon, and
perhaps never. I think that we agree that the top teir of programmers
could be better marketed to, although more money is only part of the
problem.
Note that Java has something like closures, so we are at least making
progress. Lisp-ish ideas are becoming mainstream. Guy Steele might
have something to do with that. Perhaps Algol style programming
languages will progress towards Lisp semantics just as the Windows
kernel migrates towards Unix, and functional programming language syntax
will migrate towards that of algol-style languages, just as Unix gets
more and more GUI (slowly!).
>Have you seen Haskell and frameworks like Fudgets and Haggis? I can't
>comment on Lisp-based frameworks, as I'm only vaguely familiar with
>one of them. I'd prefer any of 'em to the framworks I've seen and used
>in C++. I'd prefer the MVC classes in Smalltalk-80 to anything in
>Java. I don't know CLIM, unfortunately.
I don't doubt that the Smalltalk-80 frameworks are more mature, but I think
that Java is as capable a language of wrapping the GUI objects in
language constructs as Smalltalk is. I don't think that doing the same
things in functional languages is as "intutive" (loaded word!), but there
may be benefit to doing it that way anyhow. Please describe what you
see the benefits of functional GUI programming to be. In my mind, once
you are mostly manipulating state (screen objects, database connections,
TCP/IP connections), you might as well move to a language that is designed
to model object states, rather than one that is designed to model functions.
On the other hand, if you are going to argue that you should use Lisp or
Haskell imperatively, then I'll ask: then what benefit do they offer over
Algol style languages? Why not use a language that was designed to be
imperative? I've only preused a Haskell introduction, but my reading
suggested that they jumped through some major hoops to surpress imperative
programming. I have seen it described as "purely functional", monadic I/O
notwithstanding.
I'm looking at the Fugets info, and it sounds like the *added* an object
construct to the language: "Fudget programming is like Object Oriented
Programming in that state information is encapsulated and hidden from
arbitrary use/misuse. The components that corresponds to objects are
called fudgets. State information can be accessed/changed only by sending
messages to the fudget maintaining it."
I also note that many of the benefits ascribed to functional programming
languages in that document also hold for Java: "Higher order functions
and parametric polymorphism." (and a Java 2.0 with generics would be
even more competitive here) "Automatic memory management", "Type safety".
The two it fails on are "Brief notation" and "Lazy evaluation". Fair
enough, but not really earthshaking stuff for GUI programming. In ML, the
brief notation seems to be "bought" through a very complex type system
that must be restricted so that the type inferencer can cope. Lazy
evaluation can be simulated in any language, especially any language with
closures.
Functional programmers may want to look at the proposed "Inner Class"
documentation to see how it compares to closures.
http://www.javasoft.com/products/JDK/1.1/docs/guide/innerclasses/html/innerclasses.doc.html
Paul Prescod
With a mighty <··········@undergrad.math.uwaterloo.ca>,
········@csclub.uwaterloo.ca wibbled into the void...
> I think we agree that Lisp will not be mainstream anytime soon, and
> perhaps never. I think that we agree that the top teir of programmers
> could be better marketed to, although more money is only part of the
> problem.
Strong pro-Lisp marketing might at the very least help counter the
strong pro-C++ marketing. While pro-C++ propaganda bombards the
majority of programmers, we can hardly blame them for making poor
choices of tools.
> Note that Java has something like closures, so we are at least making
> progress. Lisp-ish ideas are becoming mainstream. Guy Steele might
> have something to do with that. Perhaps Algol style programming
> languages will progress towards Lisp semantics just as the Windows
> kernel migrates towards Unix, and functional programming language syntax
> will migrate towards that of algol-style languages, just as Unix gets
> more and more GUI (slowly!).
Progress is slow but steady? I don't feel complacent, but I'm inclined
to agree. Perhaps that's because I like to be optimistic. I've no idea
how realistic this may be.
> I don't doubt that the Smalltalk-80 frameworks are more mature, but I think
> that Java is as capable a language of wrapping the GUI objects in
> language constructs as Smalltalk is. I don't think that doing the same
> things in functional languages is as "intutive" (loaded word!), but there
> may be benefit to doing it that way anyhow. Please describe what you
> see the benefits of functional GUI programming to be. In my mind, once
> you are mostly manipulating state (screen objects, database connections,
> TCP/IP connections), you might as well move to a language that is designed
> to model object states, rather than one that is designed to model functions.
FP should allow you to isolate the state manitpulations from the data
crunching part of your code. For a GUI app, this is what I thought the
goal of the MVC approach was. The model stores and crunches the data,
while the views display data in the model to the user, and the
controls accept commands from the user and relay them to the model.
Now imagine that instead of message sends, it's IO monads that connect
the model with the views and controllers, and you've got the FP style
of contructing a GUI app.
If you want to understand monads in greater detail, I'm not going to
explain them myself, partly because this isn't the right place, but
mainly because others have written much better explanations that I
ever will.
What can I do is refer you to my monads page:
<URL:http://www.wildcard.demon.co.uk/haskell/monads.html>
> On the other hand, if you are going to argue that you should use Lisp or
> Haskell imperatively, then I'll ask: then what benefit do they offer over
> Algol style languages? Why not use a language that was designed to be
> imperative? I've only preused a Haskell introduction, but my reading
> suggested that they jumped through some major hoops to surpress imperative
> programming. I have seen it described as "purely functional", monadic I/O
> notwithstanding.
I wouldn't argue that you should use Haskell imperatively! I tend to
use an FP style in Lisp, but in Haskell the imperative parts of an app
will be isolated from the rest of the code.
> I'm looking at the Fugets info, and it sounds like the *added* an object
> construct to the language: "Fudget programming is like Object Oriented
> Programming in that state information is encapsulated and hidden from
> arbitrary use/misuse. The components that corresponds to objects are
> called fudgets. State information can be accessed/changed only by sending
> messages to the fudget maintaining it."
Perhaps, but I'm not familiar enough with Fudgets to comment. Certain
features of Haskell resemble the OO features of other languages, and
it's possible to create an OO system in a great many languages that
don't provide one as standard.
This is not a failing, IMHO. In fact, the same is true of CL and
Scheme, and is seen by many as a strength of these languages.
> I also note that many of the benefits ascribed to functional programming
> languages in that document also hold for Java: "Higher order functions
> and parametric polymorphism." (and a Java 2.0 with generics would be
> even more competitive here) "Automatic memory management", "Type safety".
I'm not familiar enough with Java 2.0 to comment, but I'm aware that
pro-Java programmers have made claims like this. Does Java 2.0 add
first class functions?
> The two it fails on are "Brief notation" and "Lazy evaluation". Fair
> enough, but not really earthshaking stuff for GUI programming. In ML, the
> brief notation seems to be "bought" through a very complex type system
> that must be restricted so that the type inferencer can cope. Lazy
> evaluation can be simulated in any language, especially any language with
> closures.
This is not an argument against languages that support lazy evaluation
as standard. You can add anything to Lisp, if you want to, and yet
most programmers still choose something else. Go figure.
> Functional programmers may want to look at the proposed "Inner Class"
> documentation to see how it compares to closures.
>
> http://www.javasoft.com/products/JDK/1.1/docs/guide/innerclasses/html/innerclasses.doc.html
You might also want to read a little more about FP. Try lurking in the
comp.lang.functional newsgroup for a few months, and you might find a
few reasons for using an FP language. YMMV.
Of course, I should add the most important reason for using an FP:
because you can. I know it's a glib statement, but it's also true.
It seems to me to be as good an explanation as any for why so many
different tools get used for the same kinds of tasks. Some of us
prefer functional to imperative languages, and this may also be true
of many Lisp programmers, as Lisp gives you both functional _and_
imperative styles. You don't have to accept or understand our reasons,
but the explanations are there if you want to find them.
There's also a newsgroup in which you can ask questions about the
things that you don't yet understand, and people I expect will be
happy to help give you answers. I hope to see you there someday.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·························@news.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>FP should allow you to isolate the state manitpulations from the data
>crunching part of your code. For a GUI app, this is what I thought the
>goal of the MVC approach was. The model stores and crunches the data,
>while the views display data in the model to the user, and the
>controls accept commands from the user and relay them to the model.
I would have to investigate this more.
>> I also note that many of the benefits ascribed to functional programming
>> languages in that document also hold for Java: "Higher order functions
>> and parametric polymorphism." (and a Java 2.0 with generics would be
>> even more competitive here) "Automatic memory management", "Type safety".
>
>I'm not familiar enough with Java 2.0 to comment, but I'm aware that
>pro-Java programmers have made claims like this. Does Java 2.0 add
>first class functions?
I was just proposing that Java 2.0 would probably have generics. Java
is only up to 1.1 beta right now. They decided explicitly not to create
first class functions, because everything else in Java is an object or
a class. What they have is "inner classes" which does the same thing.
You construct an inner class with a single method in the same way that
an FP programmer would create a function, and the inner class remembers
its construction environment just as a functional closure does. It was
clearly modelled after closures, and I'm sure Guy Steele had something
to do with that.
>> The two it fails on are "Brief notation" and "Lazy evaluation". Fair
>> enough, but not really earthshaking stuff for GUI programming. In ML, the
>> brief notation seems to be "bought" through a very complex type system
>> that must be restricted so that the type inferencer can cope. Lazy
>> evaluation can be simulated in any language, especially any language with
>> closures.
>
>This is not an argument against languages that support lazy evaluation
>as standard. You can add anything to Lisp, if you want to, and yet
>most programmers still choose something else. Go figure.
I didn't mean to argue against the language, but to demonstrate why it
would be hard to sell to typical programmers.
I'll take a look at comp.lang.functional .
Paul Prescod
In article <··········@undergrad.math.uwaterloo.ca>,
········@csclub.uwaterloo.ca (Paul Prescod) wrote:
> Lisps have features that Joe Average is never going to appreciate or
> want to use no matter how much money we spend on marketing. There are
> fourth year students in the programming language course here who
> don't "get" functional programming.
>
You mean like AutoLisp. I've seen magazines with regular
sections on AutoLisp. For Joe User. Still AutoLisp
is enormously popular.
--
http://www.lavielle.com/~joswig/
From: Alex Williams
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5e4p40$jdd@netnews.alf.dec.com>
In article <··········@undergrad.math.uwaterloo.ca>,
Paul Prescod <········@csclub.uwaterloo.ca> wrote:
>If I was comfortable with the full object system, I might think that
>manipulating object state in Lisp was as natural as in Java. But what makes
>functional languages so elegant (and reliable) is the *lack* of manipulation
>of object state, isn't it? Is that a misconception on my part?
One word: closures.
Closures can (and do, in most advanced Lisp code) encapsulate internal
state, manipulate it, and reveal it just as Objects do in other OOP
languages. YASOS, the Object system that comes with SLIB for Scheme,
uses closures to create and manipulate Objects, in fact, every Object
/is/ a closure, with a standard protocol for manipulating and dealing
with the abstraction.
In a sense, high-level Lisp programming (and functional programming in
general) can be seen as abstract manipulations of state information
by expressly passing state around /between/ objects rather than
depending on globals, etc, to carry that information. Closures have
been used for some time to represent entities that really need to have
their own state attached.
--
Alexander ················@··················@photobooks.com}
The Mekton is a powerful tool, both physically and emotionally.
There is something that happens to an enemy when he sees his home
and family stepped on by a hundred ton metal man. -- Arkon Verian
From: William Paul Vrotney
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <vrotneyE5IrLt.2HM@netcom.com>
In article <·························@news.demon.co.uk> ············@wildcard.demon.co.uk (Cyber Surfer) writes:
> ...
>
> Perhaps the biggest problem that Lisp has not even a
> technical one. It's the price. A Lisp that costs 8 times as
> much as a C++ for the same platform, and supports a subset
> of features (no multi-threading, say), then it doesn't help.
> There are C++ people who will slag off VB and Delphi for far
> less! What chance does Lisp have?
>
Sorry to have to repeat this again. But this simply is not true. C++ is
not a library but Common Lisp contains quite a robust library. Show us a
C++ library that has what Common Lisp has for the same price. Furthermore
CL vendors like Franz give you quite a bit more than just CL with their
product like light weight processes, tree shakers etc. Besides that,
nothing like *full* Common Lisp for C++ (by itself) currently even exists.
I can tell you as a Lisp library for C++ designer that it never will because
of inherent limitations of C++.
It just takes the world some time to see the light. No amount of money can
help Lisp right now because the world has not. If you want to see Lisp
thrive again then take care of yourself.
--
William P. Vrotney - ·······@netcom.com
With a mighty <·················@netcom.com>,
·······@netcom.com wibbled into the void...
> Sorry to have to repeat this again. But this simply is not true. C++ is
> not a library but Common Lisp contains quite a robust library. Show us a
> C++ library that has what Common Lisp has for the same price. Furthermore
> CL vendors like Franz give you quite a bit more than just CL with their
> product like light weight processes, tree shakers etc. Besides that,
> nothing like *full* Common Lisp for C++ (by itself) currently even exists.
> I can tell you as a Lisp library for C++ designer that it never will because
> of inherent limitations of C++.
Please note that I'm comparing ACL/PC with VC++, not ACL for Unix with
some othr C++ compiler. Many Windows developers will _expect_ certain
features, and ACL does fail to provide them. This doesn't make ACL/PC
a poor Lisp system, but it might appear to be a poor Windows
development system.
I guess it depends on your perspective. There's a big myth that multi-
threading is vital. Actually, it merely helps with certain kinds of
code, like writing servers (Win32 doesn't use fork). There's still a
strong belief that you need this feature. I like it just for making an
app more responsive, but not everyone considers this so desirable.
Please also note that I'm not suggesting that C++ is in _any_ way
superior to Lisp. There are simply a lot of people who are misguided
enough to think that this is so, and will use a lack of a certain
feature or two to bash a tool, e.g. VB, Dephi, etc.
Can you deny that the cost of ACL/PC is 8 times as high as VC++?
> It just takes the world some time to see the light. No amount of money can
> help Lisp right now because the world has not. If you want to see Lisp
> thrive again then take care of yourself.
Thanks, I'm doing so, and will continue to do so.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: David H. Thornley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5dvmhp$5hf@epx.cis.umn.edu>
In article <·················@netcom.com>,
William Paul Vrotney <·······@netcom.com> wrote:
>In article <·························@news.demon.co.uk> ············@wildcard.demon.co.uk (Cyber Surfer) writes:
>> ...
>>
>> Perhaps the biggest problem that Lisp has not even a
>> technical one. It's the price. A Lisp that costs 8 times as
>> much as a C++ for the same platform, and supports a subset
>> of features (no multi-threading, say), then it doesn't help.
>> There are C++ people who will slag off VB and Delphi for far
>> less! What chance does Lisp have?
>>
>
>Sorry to have to repeat this again. But this simply is not true.
Maybe not eight times, but the CL implementations I am familiar
with are more expensive than C++.
On my favorite platform, the Macintosh, the obvious choices are
Metrowerks Codewarrior and Macintosh Common Lisp. CW costs about
$400 max, $150 for students who aren't going to use it commercially.
MCL costs about the same minimum, but the lowest cost for any
use that involves distribution of object code is, I think, about
$800. The minimum price for a commercial implementation that can
distribute anything besides source is $1000.
Now, this isn't going to stop a professional who thinks Lisp is
better than C++. For that person, the difference between $400
and $1000 is trivial. If Lisp allows him or her to work 10%
faster, the difference in price is paid off within weeks.
It is going to stop the casual browser who might want to try Lisp.
The entry cost for me, as a student, to do something for somebody
else is $150 in C++, $800 or so in Lisp. As a student user of
Metrowerks, the only restriction is that I can't sell my compiled
code commercially. As a student user of MCL, I can't give anybody
my compiled code, as the only way I have to save it, in effect,
is as a lisp image, and Digitool would take great offense if I
distributed that.
Granted there are quality differences. Codewarrior is a good, but
not superb, implementation of C++ (and C and Pascal and Java), while
MCL is a superb Lisp system. However, Codewarrior is simply more
versatile, out of the box, than MCL. With Codewarrior, I can compile
Windows programs. Codewarrior includes an applications framework,
so getting a good GUI program running isn't that much mroe difficult
than in Lisp.
Until I can write little programs in Lisp and give them to my friends
to show them what I can do in Lisp, I'm going to have no luck in
convincing them to try Lisp. (Most of them are also anti-Lisp because
of their earlier exposure to it, but that's another topic.) I can't
use public-domain Lisps for this, since I can't easily do a Mac-like
program in them.
> C++ is
>not a library but Common Lisp contains quite a robust library. Show us a
>C++ library that has what Common Lisp has for the same price. Furthermore
>CL vendors like Franz give you quite a bit more than just CL with their
>product like light weight processes, tree shakers etc. Besides that,
>nothing like *full* Common Lisp for C++ (by itself) currently even exists.
>I can tell you as a Lisp library for C++ designer that it never will because
>of inherent limitations of C++.
>
Granted. There was debate about adding hash tables to the C++ library;
as a Lisp hacker, of course, I just use them as a matter of course.
On the other hand, C++ will get the job done, C++ libraries tend to
be good (if not as convenient as CL), and it doesn't require quite
as much new learning to write good C++ as it does to write good Lisp.
(Even without CLOS, a good Lisp program uses much of the same
concepts as a good C++ program.)
The big differences are price and redistributability.
David H. Thornley, known to the Wise as ········@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
--
David H. Thornley, known to the Wise as ········@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
From: William Paul Vrotney
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <vrotneyE5K9F6.Mnv@netcom.com>
In article <··········@epx.cis.umn.edu> ········@cs.umn.edu (David
H. Thornley) writes:
>
> In article <·················@netcom.com>,
> William Paul Vrotney <·······@netcom.com> wrote:
> >In article <·························@news.demon.co.uk> ············@wildcard.demon.co.uk (Cyber Surfer) writes:
> >> ...
> >>
> >> Perhaps the biggest problem that Lisp has not even a
> >> technical one. It's the price. A Lisp that costs 8 times as
> >> much as a C++ for the same platform, and supports a subset
> >> of features (no multi-threading, say), then it doesn't help.
> >> There are C++ people who will slag off VB and Delphi for far
> >> less! What chance does Lisp have?
> >>
> >
> >Sorry to have to repeat this again. But this simply is not true.
>
> Maybe not eight times, but the CL implementations I am familiar
> with are more expensive than C++.
>
> On my favorite platform, the Macintosh, the obvious choices are
> Metrowerks Codewarrior and Macintosh Common Lisp. CW costs about
> $400 max, $150 for students who aren't going to use it commercially.
> MCL costs about the same minimum, but the lowest cost for any
> use that involves distribution of object code is, I think, about
> $800. The minimum price for a commercial implementation that can
> distribute anything besides source is $1000.
>
> Now, this isn't going to stop a professional who thinks Lisp is
> better than C++. For that person, the difference between $400
> and $1000 is trivial. If Lisp allows him or her to work 10%
> faster, the difference in price is paid off within weeks.
>
Exactly! Is that not why we use high level languages to begin with?
Sounds like you are agreeing with me in the final analysis.
> It is going to stop the casual browser who might want to try Lisp.
> The entry cost for me, as a student, to do something for somebody
> else is $150 in C++, $800 or so in Lisp. As a student user of
> Metrowerks, the only restriction is that I can't sell my compiled
> code commercially. As a student user of MCL, I can't give anybody
> my compiled code, as the only way I have to save it, in effect,
> is as a lisp image, and Digitool would take great offense if I
> distributed that.
>
Then use GCL for the distribution. GCL is free.
> Granted there are quality differences. Codewarrior is a good, but
> not superb, implementation of C++ (and C and Pascal and Java), while
> MCL is a superb Lisp system. However, Codewarrior is simply more
> versatile, out of the box, than MCL. With Codewarrior, I can compile
> Windows programs. Codewarrior includes an applications framework,
> so getting a good GUI program running isn't that much mroe difficult
> than in Lisp.
>
> Until I can write little programs in Lisp and give them to my friends
> to show them what I can do in Lisp, I'm going to have no luck in
> convincing them to try Lisp. (Most of them are also anti-Lisp because
> of their earlier exposure to it, but that's another topic.) I can't
> use public-domain Lisps for this, since I can't easily do a Mac-like
> program in them.
>
Until your friends get enlightened and actually use Lisp you will not
convince them. Please believe me when I tell you that I have a lot of
experience at this. I have demonstrated to many people that Lisp
executables can be small, fast and cheap and this did not convince them.
It sure seems to me like the problem is dogmatism, pure and simple.
> > C++ is
> >not a library but Common Lisp contains quite a robust library. Show us a
> >C++ library that has what Common Lisp has for the same price. Furthermore
> >CL vendors like Franz give you quite a bit more than just CL with their
> >product like light weight processes, tree shakers etc. Besides that,
> >nothing like *full* Common Lisp for C++ (by itself) currently even exists.
> >I can tell you as a Lisp library for C++ designer that it never will because
> >of inherent limitations of C++.
> >
> Granted.
Thanks.
> There was debate about adding hash tables to the C++ library;
> as a Lisp hacker, of course, I just use them as a matter of course.
> On the other hand, C++ will get the job done,
Not always true, depends on what you are doing.
> C++ libraries tend to
> be good (if not as convenient as CL),
Not true, depends on what you are doing. Is there a good convenient C++
library for doing AI programming?
> and it doesn't require quite
> as much new learning to write good C++ as it does to write good Lisp.
You pay for learning to use Lisp just once, you pay for long development
cycles with C++ over and over and over again.
There are so many quirks in C++ it is more a matter of discovering C++ than
it is a matter of learning it. It is even as bad as discovering the quirks
in a particular implementation of C++, not to mention the quirks in
C++ libraries, like STL for example.
> (Even without CLOS, a good Lisp program uses much of the same
> concepts as a good C++ program.)
Not true, a good Lisp program usually uses CONSes and dynamic typing.
>
> The big differences are price and redistributability.
>
You can get many full Common Lisp systems for free nowadays and it is a
simple as FTPing them.
--
William P. Vrotney - ·······@netcom.com
With a mighty <··········@epx.cis.umn.edu>,
········@cs.umn.edu wibbled into the void...
> Maybe not eight times, but the CL implementations I am familiar
> with are more expensive than C++.
I agree that it might not be true of all implementations, but I was
refering to a specific example. I think some confusion resulted
because I failed to give the details (ACL/PC, VC++). The details
may actually be unimportant, as one thing that becomes very clear
after reading attacks from C++ programmers on UseNet, or hearing the
myths about Lisp elsewhere, is that _any_ differences in cost or
support of "critical" features will be seen a gross failure by certain
people. I do mean _any_ differences. Even the featurs that we Lisp
folk consider to be advantages can be seen as weaknesses by some
people. They may be fools, but if these people are vocal enough, and
either respected or in a position of power (i.e. able to choose which
development tools other developers will use), then Lisp may lose to
cheaper and less productive tools.
> On my favorite platform, the Macintosh, the obvious choices are
> Metrowerks Codewarrior and Macintosh Common Lisp. CW costs about
> $400 max, $150 for students who aren't going to use it commercially.
> MCL costs about the same minimum, but the lowest cost for any
> use that involves distribution of object code is, I think, about
> $800. The minimum price for a commercial implementation that can
> distribute anything besides source is $1000.
Yep, I can believe that. The extra value that you get for that money,
and the work that goes into creating that tool, may justify the cost
to a programmer. Of course, programmers don't always get to make these
choices, which is where the trouble begins.
> Now, this isn't going to stop a professional who thinks Lisp is
> better than C++. For that person, the difference between $400
> and $1000 is trivial. If Lisp allows him or her to work 10%
> faster, the difference in price is paid off within weeks.
Assuming that the Lisp actually supports the programming tasks that
the programmer is asked to do. If not, then that programmer may need
to spend some time adding support for those features, assuming that
this is possible. (Try turning somebody else's .EXE into a .DLL).
I can think of a few kludges that should work around such problems,
but it takes time to write that code. It's also less than ideal,
giving the pro-C++ argument a lot of ammo. Not that C++ is what I'd
call ideal, but try fighting all that pro-C++ propaganda in an
environment that's very pro-C++.
> It is going to stop the casual browser who might want to try Lisp.
> The entry cost for me, as a student, to do something for somebody
> else is $150 in C++, $800 or so in Lisp. As a student user of
> Metrowerks, the only restriction is that I can't sell my compiled
> code commercially. As a student user of MCL, I can't give anybody
> my compiled code, as the only way I have to save it, in effect,
> is as a lisp image, and Digitool would take great offense if I
> distributed that.
I have the same problem, so I can sympathise. I'm currently using
"Lite" version of ACL/PC, and hoping to purchase the Standard version
sometime this year (hopefully in a month or two). As I've just spent a
great deal of my savings on hardware upgrades, and may well spent some
more on hardware very soon, I can't yet afford the Professional
version of ACL/PC. So, I won't be able to deliver code except in the
development environment, which has certain disadvantes, like not being
to run the code in the office (where disk space is _very_ tight).
I hope that we're not typical Lisp developers. We may, however, be
typical of developers in general.
> Granted there are quality differences. Codewarrior is a good, but
> not superb, implementation of C++ (and C and Pascal and Java), while
> MCL is a superb Lisp system. However, Codewarrior is simply more
> versatile, out of the box, than MCL. With Codewarrior, I can compile
> Windows programs. Codewarrior includes an applications framework,
> so getting a good GUI program running isn't that much mroe difficult
> than in Lisp.
This seems to be a common characteristic of C++ tools, perhaps because
of the large amounts of money spent on them, justified by the size of
the market for them. I'd like to think that the same is true for Lisp,
but it appears not to be the case. Cross platform GUI support exists
in the form of CLIM, and if it's included as a standard feature of
Lisp systems (like GUI frameworks tend to be, for C++ systems) and
priced competitively, then this should help Lisp.
> Until I can write little programs in Lisp and give them to my friends
> to show them what I can do in Lisp, I'm going to have no luck in
> convincing them to try Lisp. (Most of them are also anti-Lisp because
> of their earlier exposure to it, but that's another topic.) I can't
> use public-domain Lisps for this, since I can't easily do a Mac-like
> program in them.
I have the same problem, but for Windows. I can use Gambit C for non-
commercial work, but I know that if I ask for $1000 for the commercial
license, then I'll be told to use something else. The extra value that
_I_ get from using Lisp means nothing, except to me.
However, these are personal circumstances, and I shouldn't generalise
to much. I'd hope that most other Lisp programmers are more fortunate.
Still, my circumstances may be very typeical for anyone working in
Windows development. If you can do this and use Lisp, then you're
atypical.
> Granted. There was debate about adding hash tables to the C++ library;
> as a Lisp hacker, of course, I just use them as a matter of course.
> On the other hand, C++ will get the job done, C++ libraries tend to
> be good (if not as convenient as CL), and it doesn't require quite
> as much new learning to write good C++ as it does to write good Lisp.
> (Even without CLOS, a good Lisp program uses much of the same
> concepts as a good C++ program.)
I'm not concerned about hash tables - that's easy. I've been using
them in _C_ for years, never mind C++. That's the basic stuff. What
concerns me now is support for the not so trivial things, like the
platform specific features (e.g. ActiveX). Some factors are not purely
language related.
> The big differences are price and redistributability.
Agreed, tho I'd add that a few other factors can be significant, too.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Paul Prescod wrote:
>
> In article <·························@news.demon.co.uk>,
> Cyber Surfer <············@wildcard.demon.co.uk> wrote:
> >With a mighty <··············@ds9.border.com>,
> >··@border.com wibbled into the void...
> >
> >> > I wonder what $40,000,000 spent on marketing might do for Lisp?
> >>
> >> a brief perusal of computing history would convince you that much more
> >> than this was directly or indirectly spent on lisp, through academic
> >> and commercial research and development funding on AI and years of
> >> government grants. lisp has had as much or more funding and hype
> >> as any other deserving or undeserving part of computing.
> >
> >How much of that money was spent on marketing? If Lisp has been hyped
> >more than C++, then I must've been reading the wrong magazines. I've yet
> >to see a full page commercial for a Lisp system, and yet I see many pages
> >devoted to C++ every month.
I agree with Cyber Surfer. Lisp has had less funding and hype than
C++. I'm interested in hearing a rebuttal to this.
>
> I think that the average programmer thinks procedurally. No amount of money
> is going to convince him or her to spend the intellectual effort to figure
> out how to express their problems recursively, or using higher order functions;
> especially if their "problem" is handling mouse clicks and sending messages
> to windowing "objects" or databases. You can use Lisp as if it weren't a
> language designed to implement the lambda calculus, but is it really
> competitive as a Better Basic than Basic? Not if you are learning from a
> traditional Lisp text.
>
> So my call is no: Microsoft could not make Lisp fly through sheer force of
> will and cash, unless they turned it into Basic, or worse, "Visual Basic".
>
> Paul Prescod
This doesn't support or refute Cyber Surfers claim.
Earl Harris Jr.
In article <···············@192.168.2.34> ·······@btree.com (Dave Hansen) writes:
>Lisp has been around too long and has built up too much of a
>"mystique" to win the hearts and minds (and dollars) of non-techincal
>managers. The base of good, experienced Lisp programmers is too
>small. And all those parentheses! :)
Oh I don't know. Smalltalk has been around too long too, but seems to
have had a renaissance of late. It's syntax is a little strange as
well.
In article <··········@undergrad.math.uwaterloo.ca> ········@csclub.uwaterloo.ca (Paul Prescod) writes:
>I think that the average programmer thinks procedurally. No amount of
>money is going to convince him or her to spend the intellectual effort
>to figure out how to express their problems recursively, or using
>higher order functions;
True, but that is only because of what they have been
taught. Paradigms do change though. Sometimes quickly, sometimes
slowly.
········@cs.umn.edu (David H. Thornley) writes:
>
> On my favorite platform, the Macintosh, the obvious choices are
> Metrowerks Codewarrior and Macintosh Common Lisp. CW costs about
> $400 max, $150 for students who aren't going to use it commercially.
> MCL costs about the same minimum, but the lowest cost for any
> use that involves distribution of object code is, I think, about
> $800. The minimum price for a commercial implementation that can
> distribute anything besides source is $1000.
from http://www.digitool.com/MCL-price-list.html:
MCL Newsstand Issue
This is a license for the current MCL release only. It does not include updates
or subsequent MCL releases. The current release includes both MCL 4.0 for the
PowerPC and MCL 3.1 for the 68K platform. Product package includes:
MCL CD with:
MCL 4.0 and MCL 3.1 software
Complete on-line documentation: Getting Started with Macintosh
Common Lisp and Macintosh Common Lisp Reference .
120+ mb of user contributed code
Twelve user contributed standalone applications
Software License Agreement
Registration Card
N.B. A hardcopy of the MCL documentation is available separately.
MCL-NS MCL 4.0/3.1 single issue $345.00
MCL-NS/E with educational discount $275.00
MCL-NS/S with student discount $85.00
Redistribution kit with student discount is $400.
From: Cyber Surfer
Subject: superior (?) macros for C (was Re: superior(?) programming languages)
Date:
Message-ID: <851184485snz@wildcard.demon.co.uk>
Sorry to reply to one of my own posts, but I have some info to add:
In article <············@wildcard.demon.co.uk>
············@wildcard.demon.co.uk "Cyber Surfer" writes:
> Possibly some people (e.g MS) have biased things to make C++
> look more attractive to developers. Possibly this may someday
> change - see the MS Research website for details. I seem to
> recall Henry Baker refering to an MS paper about "Lisp style"
> macro processing for C++, and I suspect that he was thinking
> of the MSR work, with some CS people at a certain Texas
> university, called "Intentional Programming". This could
> eventually introduce a lot of C++ programmers to some of the
> ideas supposedly unique to languages like Lisp, e.g meta
> linguistic tools.
I may have found "Intentional Programming" whilst looking for
that paper on macros, but that probably wasn't the paper that
Henry Baker was refering to. Here's a more likely candidate:
<URL:ftp://ftp.research.microsoft.com/pub/analysts/macro.ps.Z>
Here's the abstract:
Programmable Syntax Macros
Daniel Weise and Roger Crew
PLDI '93
Abstract:
Lisp has shown that a programmable syntax macro system acts as an
adjunct to the compiler that gives the programmer important and
powerful abstraction facilities not provided by the language. Unlike
simple token substitution macros, such as are provided by CPP (the C
preprocessor), syntax macros operate on Abstract Syntax Trees (ASTs).
Programmable syntax macro systems have not yet been developed for
syntactically rich languages such as C because rich concrete syntax
requires the manual construction of syntactically valid program
fragments, which is a tedious, difficult, and error prone process.
Also, using two languages, one for writing the program, and one for
writing macros, is another source of complexity. This research solves
these problems by having the macro language be a minimal extension of
the programming language, by introducing explicit code template
operators into the macro language, and by using a type system to
guarantee, at macro definition time, that all macros and macro
functions only produce syntactically valid program fragments. The
code template operators make the language context sensitive, which
requires changes to the parser. The parser must perform type analysis
in order to parse macro definitions, or to parse user code that
invokes macros.
Anyone who thinks that MS are the "Evil Empire" and are doing
"no good at all" should look at the MS Research site. Papers
like this one might even make C more appealing to those who
like to knock it - but I don't expect miracles. ;-)
Followup-To: comp.lang.lisp (this is getting _really_ offtopic!)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Miroslav Silovic
Subject: Re: superior (?) macros for C (was Re: superior(?) programming languages)
Date:
Message-ID: <kd0916qqtts.fsf@jagor.srce.hr>
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> Programmable Syntax Macros
> Daniel Weise and Roger Crew
> PLDI '93
>
> Abstract:
> Lisp has shown that a programmable syntax macro system acts as an
> adjunct to the compiler that gives the programmer important and
> powerful abstraction facilities not provided by the language. Unlike
> simple token substitution macros, such as are provided by CPP (the C
> preprocessor), syntax macros operate on Abstract Syntax Trees (ASTs).
> Programmable syntax macro systems have not yet been developed for
> syntactically rich languages such as C because rich concrete syntax
> requires the manual construction of syntactically valid program
> fragments, which is a tedious, difficult, and error prone process.
> Also, using two languages, one for writing the program, and one for
> writing macros, is another source of complexity. This research solves
> these problems by having the macro language be a minimal extension of
> the programming language, by introducing explicit code template
> operators into the macro language, and by using a type system to
> guarantee, at macro definition time, that all macros and macro
> functions only produce syntactically valid program fragments. The
> code template operators make the language context sensitive, which
> requires changes to the parser. The parser must perform type analysis
> in order to parse macro definitions, or to parse user code that
> invokes macros.
>
> Anyone who thinks that MS are the "Evil Empire" and are doing
> "no good at all" should look at the MS Research site. Papers
> like this one might even make C more appealing to those who
> like to knock it - but I don't expect miracles. ;-)
>
I don't share this sentiment. The problem is that, if LISP-like macros
were natural to C/C++, someone would've thought of it already. But to
implement even a subset of LISP power, namely, ability to look /into/
the macro body and transform it beyond simply mingling the outer
forms, requires 'language-within-language' approach. In fact, this
abstract shows that this is exactly what Microsoft people had in mind.
In other words, making it bigger won't make it better.
Miro
Someone once said, and I misquote, "Genius is 99% persperation and 1%
intelligence." or someting like that. I've been working on something for
two years. When I started, I looked at the parts and languages available
and chose what worked for me. I'm going to *CREATE* my customers(I hope),
so they don't have anything to do with it. **I** saw the problem, did the
market research, and will solve the problem with what works.
This is an another example of how solutions, tools, and problems meet for
the sake of excitement and making the world a better place.
Erik Naggum, who wrote about his may years of struggle and belief in his
choice of solutions and tools he chose to meet his **CUSTOMER'S** problems
is another example.
To cyber-surfer, if you are solving problems for people and making the
world a better and more rewarding place to hang out, (That --*IS*--
the definition of an engineer or programmer), then arguing about what
everybody should use probably takes you away from the excitement of
helping the world and solving problems. Use what you like and do some good
things. Find some problems and solve them, if the problems don't come to
you.
I hope all of us like what we're doing and that we would all share
information that will help us especially talented and creative types do
our thing.
*********************
## ##
## R.S., ##
## ##
## Dennis Kegley. ##
## ##
*********************
In article <········································@internet.oit.edu>
·······@OIT.EDU "Dennis Kegley" writes:
> Someone once said, and I misquote, "Genius is 99% persperation and 1%
> intelligence." or someting like that. I've been working on something for
> two years. When I started, I looked at the parts and languages available
> and chose what worked for me. I'm going to *CREATE* my customers(I hope),
> so they don't have anything to do with it. **I** saw the problem, did the
> market research, and will solve the problem with what works.
If I were working alone, I might have that kind of freedom.
Many developers I know are in a similar position. It's those
who can choose their tools that interest me most. It was my
interest in _creating_ tools that lead me to Lisp.
For a Windows developer, you can be dazzled by the quality of
"off the shelf" tools that are available. This is an area of
programming where Lisp has less to offer, as a language. Too
much of Windows development is little more than "gluing" other
people's tools together, to form an app that does what a client
asks for. The "creativity" is in seeing how two or more tools
can be combined to form an app.
> This is an another example of how solutions, tools, and problems meet for
> the sake of excitement and making the world a better place.
Yep. And if you can find a combinatotion of tools that nobody
else has thought of, or if you manage to glue them together in
a way that few others can do, then perhaps you have an edge.
It might not be exciting to hardcore hackers, coz it'll be too
"easy", but I can promise you that if you get it right, then
you'll knock the socks of your clients.
> Erik Naggum, who wrote about his may years of struggle and belief in his
> choice of solutions and tools he chose to meet his **CUSTOMER'S** problems
> is another example.
I have a lot of respect for Erik, dispite our disagreements on
one or two issues. I think we're just writing different kinds of
software, almost certainly for different kinds of clients.
> To cyber-surfer, if you are solving problems for people and making the
> world a better and more rewarding place to hang out, (That --*IS*--
> the definition of an engineer or programmer), then arguing about what
> everybody should use probably takes you away from the excitement of
> helping the world and solving problems. Use what you like and do some good
> things. Find some problems and solve them, if the problems don't come to
> you.
Hopfully, I've been making some constructive comments. If they
only look like arguments, then I've possibly not made my points
clear enough. Possibly the fault lies elsewhere, but I can't say.
However, please don't assume that the strength of Erik's opposition
to my point of view implies any hostility between us.
> I hope all of us like what we're doing and that we would all share
> information that will help us especially talented and creative types do
> our thing.
Indeed. I'm getting a massive kick out of what I'm doing! I'm
expecting it to get even better, in the New Year. I hope that
everyone reading this has as much, if not more, good fortune!
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
* Erik Naggum wrote:
* Adam Alpern
> | I've written many hundreds of thousands of lines of Common Lisp without
> | ever calling eval once - and this was in dynamic, end-user programmable
> | environments (class & prototype based visual programming systems, highly
> | parallel blackboard systems with integrated rule engines), defining new
> | classes and methods on the fly, etc...
> then it should be entirely safe for you to evaluate (fmakunbound 'eval) and
> report how well your system works, or how well you work. right? if not,
> please explain what you mean by "without ever calling eval once". just
> because somebody else does it for you, doesn't mean you don't use it.
> otherwise, you could just have a "designated eval caller" (a.k.a "the fall
> guy") in any Lisp community, and he could write a wrapper with another name
> which you could call. washing your hands of all eval, you can now use this
> function, instead.
This is silly. I'm sure that practically no one who is an experienced
Lisp person uses EVAL (or wrappers around it), unless you count
running programs as implicitly using EVAL, or typing at the top-level
of an interactive lisp system while developing. Apart from anything
else it's an appalling `security' hole: the form it gets to evaluate
could do anything, including redefining half your system. I mean,
imagine if something like the CL-HTTP server let its users call EVAL!
If you need an evaluator for some bit of lisp, or some embedded
language, you just write one and use that.
I'm quite confident that I could cause EVAL not to work in my programs
and they'd still work. I'd like to be confident that I could cause
COMPILE not to work, but many CLOS systems seem to use it.
If you mean by `calling eval' `having an interactive top-level' then
of course that's a huge win, but that isn't what it sounds like to me.
--tim
* Tim Bradshaw
| I mean, imagine if something like the CL-HTTP server let its users call
| EVAL! If you need an evaluator for some bit of lisp, or some embedded
| language, you just write one and use that.
sigh. I think the point is getting lost in ever more silliness.
fact 1: we can't do without `eval' in Lisp.
fact 2: just because `eval' can have negative consequences or has negative
aspects to it, doesn't mean it's _evil_.
fact 3: reinventing wheels like `eval' is needlessly hard.
the greatest problem with applications that have their own mini-languages
is that they invariably cripple the programmer. one of the reasons Emacs
is successful is that it uses a real Lisp language inside. it may lack
some features we now consider essential, but it's not some "4GL" invented
by someone who doesn't even understands syntax enough to make it fit a
reasonable language model, like LL(1) or LALR, much less provide any real
set of language constructs.
an easy way to deal with mini-languages, and still save time using EVAL and
have all the interesting language features available, is to check that all
symbols in forms read are in a particular package, then _use_ only safe
symbols from some other packages in that package.
also, this is obviously not in defense of using EVAL wantonly, just because
those who argue against EVAL use such silly arguments to debunk it. this
is not an argument in defense of letting CL-HTTP evaluate random input
code, which should be equally obvious. I'm frankly amazed by the sheer
lack of depth and insight that those arguments portray.
there are many reasons to _want_ EVAL. there are many reasons to want to
_limit_ the power of EVAL. however, the people who seem to argue against
EVAL all do it under the clearly invalid presumption that EVAL has only bad
uses, that only stupid programmers use it, that only people who would want
to open a security hole in CL-HTTP, etc, would use it. if those are the
only uses for EVAL, why would it ever be in the language? clearly, there
was a constructive purpose to include the feature, and it is unfortunate if
the only aspects of it that people can think of are destructive.
you know where I actually _use_ EVAL? in the read-eval reader macro! I
need #.(complex-form) to yield the return value of the form at read time.
I also rely on eval in some software I write, which is always called from
the Lisp listener. just like I don't foolish believe that I can dispense
with the Unix shells once I have all my applications loaded, I don't think
I can get my work done without a Lisp listener. now, if the argument is
that people shouldn't get listeners in shipped applications, but instead
use some other user interface that for all practical purposes duplicate a
listener and evaluator, any meaning in the objections evaporates. and
that's just what the anti-EVAL arguments do: evaporate upon inspection.
now, you guys can go on with your silly arguments against EVAL based on the
need not to open up huge security holes in CL-HTTP, but I would have
expected people to notice that there is no disagreement over such blatantly
obvious cases, and thus no need to repeat the their arguments. unless, of
course, the point with discussing them is only to prove that you're a
card-carrying member of the eval-haters-union. that doesn't seem very
fruitful to me.
#\Erik
--
users should be computer-friendly.
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> fact 1: we can't do without `eval' in Lisp.
Is it needed at runtime? I think not. You may insist that EVAL
is needed at development time, but I don't think that's what Tim
is talking about. I know that _I'm_ concerned about runtime.
> fact 2: just because `eval' can have negative consequences or has negative
> aspects to it, doesn't mean it's _evil_.
At runtime, it may be. Obviously, Your Mileage May Vary.
I find that I can do without it _at runtime_, and that the
overhead _at runtime_ is very unwelcome.
> fact 3: reinventing wheels like `eval' is needlessly hard.
Who needs to reinvent it?
> you know where I actually _use_ EVAL? in the read-eval reader macro! I
> need #.(complex-form) to yield the return value of the form at read time.
> I also rely on eval in some software I write, which is always called from
> the Lisp listener. just like I don't foolish believe that I can dispense
> with the Unix shells once I have all my applications loaded, I don't think
> I can get my work done without a Lisp listener. now, if the argument is
> that people shouldn't get listeners in shipped applications, but instead
> use some other user interface that for all practical purposes duplicate a
> listener and evaluator, any meaning in the objections evaporates. and
> that's just what the anti-EVAL arguments do: evaporate upon inspection.
Great, but not all of us need to read symbolic expressions _at runtime_.
> now, you guys can go on with your silly arguments against EVAL based on the
> need not to open up huge security holes in CL-HTTP, but I would have
> expected people to notice that there is no disagreement over such blatantly
> obvious cases, and thus no need to repeat the their arguments. unless, of
> course, the point with discussing them is only to prove that you're a
> card-carrying member of the eval-haters-union. that doesn't seem very
> fruitful to me.
Can you understand the distinction between development and runtime?
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
* Cyber Surfer
| Is it needed at runtime? I think not. You may insist that EVAL
| is needed at development time, but I don't think that's what Tim
| is talking about. I know that _I'm_ concerned about runtime.
loading code or reading data into an application may require facilities not
normally associated with "runtime", such as the #. reader macro. such
forms may even be generated by `print' (unless you bind *read-eval* to nil,
in which case some data cannot be printed at all if you also have
*print-readable* bound to t).
| Great, but not all of us need to read symbolic expressions _at runtime_.
now, what does this argument mean? is your real argument that Common Lisp
should not have EVAL because "not all of us" need it? why don't you also
mention hundred other functions in Common Lisp that "not all of us" need?
can you imagine that "not all of us" actually need _computers_ in the first
place and that this argument can be used for _anything_, and thus has no
defined range of validity, i.e., should be discarded as a priori invalid.
I can think of nothing that addresses what "all of us" need or want if it
is taken literally, and if we limit "us" to programmers in only _some_
domains, we must be very explicit about who the "us" are before the
argument can become valid. since this is not normally done, it is much
easier to name the "us" of whom "all of us" _can_ or _do_ need something,
and that's the point in having a programming language _community_ instead
of each of us sitting down to write our own languages and compilers for
them from scratch. (incidentally, my first inclination was also to write
my own Lisp tools. fortunately, I got over this delusion -- I have time to
write _either_ tools or something useful, just like Larry Wall had the time
to write Perl, while all the system administrators around the world only
had time to do their job. I quickly realized that building a Lisp system
is not something I could do on my own. once you start to use a commercial
Lisp system, you also quickly realize how much more there is to a Lisp
system than just a compiler.)
| Can you understand the distinction between development and runtime?
the real question is whether you can understand the difference between what
you can think of and what others can think of. your asking such idiotic
questions only goes to show that you are unable to understand how others
think, and isntead relate everything to your own deficient understanding.
moreover, that distinction is not as hard and fast a distinction as you
seem to believe it is, or indeed necessarily _where_ you think it is. in
static languages, such as C and C++, development and runtime are of
necessity hard distinctions, and they can be in only one place. in Lisp,
development and runtime form endpoints of a wide range, and the distinction
can be in a wide subrange of places within that range. e.g., if you
dynamically load patches into a running system, are you "developing" or
"maintaining a runtime system"? if you make it possible for patches to
dynamically deinstall themselves if they contain programming errors, so as
to keep a running system running even if your patches are broken, are you
developing, or just maintaining a 100%-duty cycle system that cannot ever
go down or stop working? the latter is possible if and only if you aren't
anal about the distinction between development and runtime.
some real-life examples of where this distinction is intentionally blurred:
on an oil rig, "development" and "deployment" overlap with at least 5
years. an airplane has so much maintenance work done on it during its
lifetime that after about 10 years, no single part of the delivered machine
can be expected still to be in place. Lisp systems don't always need to be
grounded to undergo maintainance. C systems do. what does this do to your
"distinction"?
I conclude that you do not even _want_ to understand how others are using
Lisp, but insist upon your own world view as the only valid one. this is
like how many Europeans view Americans. somehow, the popularized version
of "American" in Europe is that of a member of a largely homogenic group of
people, at least in important aspects. but once you actually live there
for a while, you start to appreciate the much _wider_ range of people in
the U.S. than you find in Europe. thinking in stereotypes may be useful in
saving time and effort, but one also needs to know when to stop doing it.
this EVAL discussion is one of arguments against stereotypical uses of EVAL
without EVAL-bashers wanting or even trying to understand non-stereotypical
uses of EVAL. it is as if a European tourist would walk up to an American
that didn't fit his prejudices and say "according to my tourist guide and
my baggage of cultural stereotypes, you don't exist", except, of course,
that everything up to the comma is usually omitted for brevity and effect.
I'm still hoping that you would take a more interested view of a community
and a language that you are trying to communicate with than you do. and,
no, I'm not a long-time resident or anything, I'm just new enough in this
neighborhood that I haven't tired of defending it from prejudices, yet. I
defended Unix and C and SGML for a number of years, too, if that is any
comfort to you. that I'm defending something does not mean that I can't
make mistakes in doing so, it only means that the mistakes you make are
much bigger than the ones I may be making.
#\Erik
--
"He didn't care."
"They never do."
Erik Naggum <····@naggum.no> writes:
> * Adam Alpern
> | I've written many hundreds of thousands of lines of Common Lisp without
> | ever calling eval once - and this was in dynamic, end-user programmable
> | environments (class & prototype based visual programming systems, highly
> | parallel blackboard systems with integrated rule engines), defining new
> | classes and methods on the fly, etc...
>
> then it should be entirely safe for you to evaluate (fmakunbound 'eval) and
> report how well your system works, or how well you work. right? if not,
> please explain what you mean by "without ever calling eval once". just
> because somebody else does it for you, doesn't mean you don't use it.
> otherwise, you could just have a "designated eval caller" (a.k.a "the fall
> guy") in any Lisp community, and he could write a wrapper with another name
> which you could call. washing your hands of all eval, you can now use this
> function, instead.
I would be surprised if much of value aside from the top-level
interactive loop would be unavailable in a Lisp without some sort of
eval, even one that compiles expressions on the fly.
I've looked over the sources of Ilog Talk and I've found exactly the
following uses of eval:
* Evaluate forms in the debugger.
* Evaluate forms in the top-level interactive loop.
* Evaluate forms when using the built-in test file system.
* Evaluate forms coming from Emacs.
All of these are related to the development environment, which in Ilog
Talk is a separate library which is not automatically linked with user
programs. The interpreter itself is in another separate library, only
linked with user programs when eval is called explicitly.
I don't know how many tens or hundreds of thousands of lines of Lisp
I've written over the last 12 years of doing professional Lisp
programming, but I do recall using eval only once in a real-life
program. It was a Web browser which had a special communication
channel with a special-purpose proxy server. The Web server received
back-channel information from the proxy server in terms of evaluated
Lisp expressions. This was done purely out of laziness; the actual
set of requests fielded by the browser formed a fairly small set which
would have been more efficiently implemented as a special-purpose
protocol which could have been tackled in a day or so of work.
Other than implementing development environments and avoiding writing
special-purpose protocol interpreters, I have to say that eval strikes
me as one of the more useless features of Lisp, despite the press it's
gotten in the Lisp community. I think its popularity may have more to
do with the deficiencies of certain Lisp implementations rather than
its inherent value. More modern Lisps like Scheme (can it really be
considered modern any more?), EuLisp, and Ilog Talk get along fine
with a much smaller role for eval as an auxiliary library function at
best.
-- Harley
-------------------------------------------------------------------
Harley Davis net: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
* Harley Davis
| I've looked over the sources of Ilog Talk and I've found exactly the
| following uses of eval:
|
| * Evaluate forms in the debugger.
| * Evaluate forms in the top-level interactive loop.
| * Evaluate forms when using the built-in test file system.
| * Evaluate forms coming from Emacs.
does that mean that Ilog Talk does not support read-time evaluation as in
the sharp-dot reader macro?
#\Erik
--
"He didn't care."
"They never do."
Erik Naggum <····@naggum.no> writes:
> just for fun, let's see how irrelevant this can get.
ok. :-)
> Lotus, Inc, has estimated that there is an order of magnitude
> difference in coding speed between their _good_ programmers.
Ahh, an interesting factoid I have observed myself.
> a hacker may well type like a maniac (10 keystrokes per second is
> not _that_ unusual), but still end up with less effective speed than
> a secretary who types only 30 words per minute but never makes
> mistakes. (for purposes of comparison, 1 keystroke per second is 10
> words per minute.)
I once had the pleasure of watching a secretarial interviewee type at
160 wpm sustained, no errors. Frighting to watch. Words appeared as
if by magic. The sound was fairly impressive as well (IBM keyboard
into some word processor (WordPerfect?)).
> example: a student [...] wrote about 12 000 lines. I [...] worked a
> bit with it to get it into production state. it had been reduced to
> 1500 lines when we were all done, and ran 70 times faster.
While grading student labs, I've observed that the fewer lines of code
written, the fewer bugs there are and the sooner it was done (and
faster it ran)! There's an obvious correlation between the good and
the bad here, but I never figured out how to use it to en-clue the
clueless.
> I saw a TV production about the Bill Gates imperium some time ago. at some
> point, IBM wanted everything measured in "KLOCs", and somebody (Paul Allen,
> I think) said "if we work smarter and write fewer lines, we don't want to
> be punished for that".
I think perhaps the quote you are looking for is (paraphrased slightly
because I can't remember the exact wording):
"Measuring a programming project by KLOCs is like
measuring airplane construction by weight. -- Bill Gates"
Cliff
--
Cliff Click, Ph.D. Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
······@risc.sps.mot.com (512) 891-7240
http://members.aol.com/mjclick1
From: John Hascall
Subject: Re: Triva! Was: Re: superior(?) programming languages
Date:
Message-ID: <59jqht$8hd@news.iastate.edu>
Cliff Click <······@ami.sps.mot.com> wrote:
}I think perhaps the quote you are looking for is (paraphrased slightly
}because I can't remember the exact wording):
} "Measuring a programming project by KLOCs is like
} measuring airplane construction by weight. -- Bill Gates"
Thank goodness MS does not build planes.
New! MS 737 version 4.0 (requires 64 Million HP engines, not included)
John
--
John Hascall, Software Engr. Shut up, be happy. The conveniences you
ISU Computation Center demanded are now mandatory. -Jello Biafra
···········@iastate.edu
http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud
In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
this is like some orthodox Jews who are forbidden to do work that involves
machinery of any kind during the Sabbath, and thus can't turn on electric
lights. to solve this problem, they have devised a stick that they can use
to turn the switch for them. it's not machinery, and they do get light.
It is irrelevant to the point being discussed, but in the name of accuracy
I want to interject that as an Orthodox Jew I have never heard of such
a stick. I suspect I know what Erik has misunderstood, but this is not
the place to go into that discussion.
From: Tim Bradshaw
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <ey3zpze75gq.fsf@staffa.aiai.ed.ac.uk>
* Steve Barnard wrote:
> 3. Pointer arithmetic is the single greatest language feature I've ever
> seen for a performance-oriented programmer (Java and Fortran90
> notwithstanding).
Hmmm. But isn't pointer arithmetic just what makes languages like C a
real pain to write optimising compilers for (compared to fortran &c)?
> 5. It doesn't take the stance that I'm an idiot and have to be protected
> from my own mistakes. It lets me shoot myself in the foot if I want to.
Everyone is an idiot and needs to be protected from their own
mistakes.
--tim
From: STB
Subject: Re: Why do I like C? (was Parallelism (superior(?) programming languages)
Date:
Message-ID: <32B73588.31DF@nas.nasa.gov>
Tim Bradshaw wrote:
>
> * Steve Barnard wrote:
>
> > 3. Pointer arithmetic is the single greatest language feature I've ever
> > seen for a performance-oriented programmer (Java and Fortran90
> > notwithstanding).
>
> Hmmm. But isn't pointer arithmetic just what makes languages like C a
> real pain to write optimising compilers for (compared to fortran &c)?
That may well be true, but there are often times when an optimizing compiler
can't do a good job. A lot of stuff I develop involves very unstructured,
sparse-matrix operations, usually on distributed-memory parallel computers.
There is so much indirection that I've found that compiler-generated
optimizations are often not as good as what I can do by hand with pointer
arithmetic. Sometimes I'll even precompute and store absolute addresses to
avoid doing indexing arithmetic over and over (assuming I have space).
You may argue that if I were using a language without pointer arithmetic (say,
Fortran) then the compiler would optimize well enough, but Fortran77 doesn't
have other features that I need, like dynamic storage allocation. I'm just
starting to look at Fortran90 and it looks pretty good, but it's still not as
universally available as C and so Fortran90 code isn't as portable. I don't
have it on my SGI Indy workstation, for example.
>
> > 5. It doesn't take the stance that I'm an idiot and have to be protected
> > from my own mistakes. It lets me shoot myself in the foot if I want to.
>
> Everyone is an idiot and needs to be protected from their own
> mistakes.
>
You must be either a liberal Democrat or a product-liability attorney. :-)
Steve Barnard