superior(?) programming languages
Alex Williams
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 {tha...@alf.dec.com / zan...@photobooks.com}
Prefect of the 8,000,000th Terran Overlord Government Experimental
Strike Legion, Primary Transport TOG "Bellatores Inquieti"
======================================================================
Cyber Surfer
In article <59m9is$c...@netnews.alf.dec.com>
tha...@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
Robert Swindells
>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
r...@genrad.co.uk - Work
r...@fdy2.demon.co.uk - Home
Scott Schwartz
cyber_...@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. :-)
Cyber Surfer
In article <8g4tha9...@galapagos.cse.psu.edu>
schw...@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.
Alex Williams
In article <851369...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@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.
Scott Schwartz
tha...@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!)
Richard Coleman
> tha...@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
col...@math.gatech.edu
Marc Feeley
> >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
Cyber Surfer
In article <8g681m9...@galapagos.cse.psu.edu>
schw...@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?
Cyber Surfer
In article <5a3sam$r...@netnews.alf.dec.com>
tha...@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.
Alex Williams
In article <8g681m9...@galapagos.cse.psu.edu>,
Scott Schwartz <schw...@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.
Cyber Surfer
In article <q6ohfds...@raptor.IRO.UMontreal.CA>
fee...@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
Bill Gribble
for...@ils.nwu.edu (Kenneth D. Forbus) writes:
> 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 don't know squat about Win32, but we're using RScheme here at the
University of Texas as the backbone of a fairly serious real-time
robot control framework under Linux. RScheme doesn't (yet) have a Tk
interface, but it does have a simple and robust object system,
preemptive threads (even on systems that don't support preemptive
multitasking) with thread-blocking-not-process-blocking IO and a full
UNIX system interface including sockets and lots of other stuff.
Bill Gribble
Kenneth D. Forbus
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 <rcvi9m1...@cypress.skiles.gatech.edu>,
Richard Coleman <col...@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.
>
Scott Schwartz
tha...@uxtlaser.alf.dec.com (Alex Williams) writes:
| Scott Schwartz <schw...@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.)
Alex Williams
In article <851888...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@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.
William A. Barnett-Lewis
In article <5aen47$3...@netnews.alf.dec.com>,
tha...@uxtlaser.alf.dec.com says...
>
(snip)
>The final conclusion is easy to draw.
>
>--
> Alexander Williams {tha...@alf.dec.com / zan...@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
wle...@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."
------------------------------------------------------------------------
-
Alex Williams
In article <8geng56...@galapagos.cse.psu.edu>,
Scott Schwartz <schw...@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.
Cyber Surfer
In article <5aen47$3...@netnews.alf.dec.com>
tha...@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.
Scott Schwartz
tha...@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.
Don Smith
Damnit! Why don't all you Scheme people agree on one standard set
of extensions so you can cooperate? There are too many good but
incompatible Scheme systems around.
Don (dsm...@cs.waikato.ac.nz)
Cyber Surfer
In article <5akcph$l...@ogre.cs.waikato.ac.nz>
dsm...@cs.waikato.ac.nz "Don Smith" writes:
> Damnit! Why don't all you Scheme people agree on one standard set
> of extensions so you can cooperate? There are too many good but
> incompatible Scheme systems around.
Because there's no single "right" way of doing things (that everyone
can agree on)? Hmm. I doubt that everyone (or, being pessimistic,
anyone) will agree with that!
This is what can sometimes make designing things so "interesting",
in the sense of the Chinese curse, "May you live in interesting
times". A programming version might go, "May you program in an
interesting language". Most of us do...
"Truth is never pure, and rarely simple." -- Oscar Wilde
"I would gladly die for a man who was looking for the
truth, but would just as gladly kill a man who thought
he had actually found it." -- Voltaire
Hmm.
Alex Williams
In article <8gpvznbn...@galapagos.cse.psu.edu>,
Scott Schwartz <schw...@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.
Cyber Surfer
In article <5b36g2$f...@netnews.alf.dec.com>
tha...@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>
Christopher B. Browne
On Fri, 10 Jan 97 20:00:29 GMT, Cyber Surfer <cyber_...@nospam.wildcard.demon.co.uk> posted:
>In article <5b36g2$f...@netnews.alf.dec.com>
> tha...@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.
Arguable in both directions.
There's an "infamous" document on LISP that proposes the "Worse is Better"
view that represents "good enough" rather well.
If memory serves, the author suggests that Microsoft is perhaps the best
example of this as a vendor that does "Just-in-Time Debugging."
They do just enough debugging that their products don't *completely* turn
off their customers, and have the competitive advantage of quickly-released
functionality as a result.
Windows '95 seems to be a counterexample to this characterization due to the
many delays, although consider that MS's alternative was to "fix" NT to run
in less memory and on shoddier hardware, which would have been "The Right
Way" to do it.
Something that's "good enough" and:
a) available today (rather than the better technology, available next month),
b) easier for marketers to understand and thus sell,
then it may happen to sell better.
"Ivory tower" stuff often loses out simply because the "good enough"
programmers are better able to communicate the critical fact that "This
system now works." They don't care to mention the unbeautiful flaws in the
design; the people paying the bills didn't want to know about that anyways.
--
Christopher B. Browne, cbbr...@unicomp.net, chris_...@sdt.com
"When you say 'I wrote a program that crashed Windows', people just stare at
you blankly and say 'Hey, I got those with the system, *for free*"
- Linus Torvalds
Alex Williams
In article <852926...@wildcard.demon.co.uk>,
So you either write them yourself, pay someone to write them or don't
whine because you're not willing to do either. Isn't this where we
came in?
>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!
Actually, from what I hear, some of them realize it and they're not
happy about it. C++ programmers who never really fully grasped OOP
under C++ (and there are /more/ than a few) aren't too keen in my
neighborhood about Java removing some of the hooks they've grown used
to using as crutches.
>What comes after Java, I wonder? Hopefully something that
>brings the Java converts another step closer to Lisp.
What /should/ come after Java is a realization that you don't need a
full language to do applets, all you need is a good VM. VM design
really ought to come back into its own. I think Sun has got the cloo:
They've produced a SafeTcl plug-in for Netscrape that allows you to
use `ticklets,' Tcl applets, in HTML, instead of Java. The
recognition that you can /do/ that might drive us to get our choice of
languages for inter-applet communication.
Me, of course, I'm pushing for Scheme.
>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".
That's not what I see; what I see from where I sit is people choosing
NT for their mail-servers and their user-hubs and thinking that `Hey,
its Windows, I can hire some young punk for $25k/yr and he won't even
have to really administrate it, its plug and play!' And then they
discover NT combines the speed of VMS with the stability of Unix and
that their young punk couldn't administrate a network if his cojones
were on fire with Ethernet packets.
Netware people, at the scale you deal with them at, should stick with
Netware save for their big servers which should be Unix; most of the
Netware folk just need a distributed networking environment that runs
the aps they want. NT looks pretty, but it doesn't have the
horsepower to be a corporate server stabily. No one wants to pay for
VMS. :)
>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?
You miss the point; the strength they sell Windows-based tools on is
the GUI-nature. In terms of simple resources needed to support and
continue using the GUI-frontended tasks that csh allows you to do, the
Windows version will /inevitably/ be bigger. Ragging on how much
overhead that a Scheme-compiled ap has really pales compared to the
resources of non-Scheme aps that you intend to run next to it. If I
have five major Windows aps written in Scheme which use a 1.4meg
shared library, that's a trivial amount compared to the amount of
window-state, graphics front-ending, graphics and GUI libraries,
pull-down-menu handling, etc, all the things that the aps have to hook
to run in a Windows API. Scheme turns out looking like a rather
smallish and sparse library of development tools set alongside that
nightmare bag, so critiquing the size of Scheme applications,
especially in the Windows environment, is shown to be a silly thing to
do.
That doesn't even begin to address the coding safety improvements when
you no longer manually manage memory and have dynamic types.
Michael David WINIKOFF
cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>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.
Pizza.
<a href="http://www.math.luc.edu/pizza/">Pizza</a>
It takes some ideas from Haskell and adds them to Java.
--
Michael Winikoff wini...@acm.org http://www.cs.mu.oz.au/~winikoff
Computer science postgrad. University of Melbourne, Australia.
"Computer Science is no more about computers than astronomy is about
telescopes." -- E. W. Dijkstra
Michael Davidson
In article <852926...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>
>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".
While I know that Novell does still care about UnixWare, and
probably still isn't too keen on NT, I wonder if you realise
that Novell sold both Unix (in general) and the UnixWare
product itself, to SCO over a year ago ...
Bengt Kleberg
In article <5bct7r$t...@hobbes.sco.com>, m...@sco.COM (Michael Davidson) writes:
>Novell sold both Unix (in general) and the UnixWare
>product itself, to SCO over a year ago ...
UNIX is a ``brand name'' or ``trade mark'' that anybody may use,
provided that they comply with the test suite.
--
Best Wishes, Bengt
--------------------------------------------------------------------
Email: Bengt....@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.'' fle...@netreach.net
Cyber Surfer
In article <5bcb13$4...@mulga.cs.mu.OZ.AU>
wini...@mundook.cs.mu.OZ.AU "Michael David WINIKOFF" writes:
> Pizza.
> <a href="http://www.math.luc.edu/pizza/">Pizza</a>
>
> It takes some ideas from Haskell and adds them to Java.
Yes, I've been aware of it for a while, and it looks good.
For some reason, the link to it in my Java page was for one
of the mirrors, but I'll fix that.
Lots of neat things are being done with Java. Some are not
so neat, exactly, but may help make Java more popular. For
example, compilers for older languages that produce JVM code.
Cyber Surfer
In article <slrn5deaeq....@wolfe.brownes.org>
cbbr...@unicomp.net "Christopher B. Browne" writes:
> They do just enough debugging that their products don't *completely* turn
> off their customers, and have the competitive advantage of quickly-released
> functionality as a result.
I see a lot of this, too. It could be called a willingness to
compromise. It's an ugly idea, but if that's what it is that MS
and others are doing, then it works. At least, it works well
enough for them to stay in business.
> Windows '95 seems to be a counterexample to this characterization due to the
> many delays, although consider that MS's alternative was to "fix" NT to run
> in less memory and on shoddier hardware, which would have been "The Right
> Way" to do it.
I see Win95 as a marketing answer to Warp. As I understand it,
MS plan to phase it out after Win97. NT is the platform they're
pushing, for the long term. Some customers are going straight
for NT, bypassing Win95 completely.
Yes, Win95 is full of problems. It's one of those ugly compromises.
However, people were rushing to buy it. Go figure. Perhaps it's
just "Good enough" to succeed? Could be!
> Something that's "good enough" and:
> a) available today (rather than the better technology, available next month),
> b) easier for marketers to understand and thus sell,
> then it may happen to sell better.
Yep, and Warp was "ahead" of Windows, so MS had to do something.
They did it. Judge for yourself how successful they were, but
don't look merely at the technical side, as that doesn't always
count. If it did, then MS would today be selling _Unix_.
> "Ivory tower" stuff often loses out simply because the "good enough"
> programmers are better able to communicate the critical fact that "This
> system now works." They don't care to mention the unbeautiful flaws in the
> design; the people paying the bills didn't want to know about that anyways.
There's a lot of "Ivory Tower" stuff (I love that term!) that's
good enough for me to use, but I'm not a typical developer. As
long as I can afford to use a tool, for myself, then there's no
problem. Right now, I'm writing CGI code in Haskell. What language
do most people use for CGI? Perl, VB, C++?
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. Perl memes are very powerful, coz of
the techniques used by Larry Wall to spread the word. Ivory Tower
people tend not to be so "aggressive", so the memes they spread
don't reach as many people. Nobody should doubt how aggressively
MS spread _their_ memes.
On the other hand, Lisp memes are also being spread, via Emacs,
Guile, AutoCad, etc. Not exactly Ivory Tower stuff, but perhaps
close enough? It's only relative. I'd say that Perl and VB memes
are simply pushed harder, and with a higher profile, so they
appear to reach more people than, say, AutoLisp. Not every AutoCad
user knows AutoLisp, so the memes have less power? Hmm. Maybe.
Judge for yourself. Don't let the marketing people do the thinking
for you - and be sure to spread _this_ meme!
Cyber Surfer
In article <5bb56f$b...@netnews.alf.dec.com>
tha...@uxtlaser.alf.dec.com "Alex Williams" writes:
> So you either write them yourself, pay someone to write them or don't
> whine because you're not willing to do either. Isn't this where we
> came in?
Huh? I'm talking about what _other_ programmers look for in a
development tool. What I, as an individual, do has no measurable
impact on the market. That's simply because of the nature of the
software that I currently write.
What's more interesting is the software that rather more typical
programmers write. Hence the interest in components.
> Actually, from what I hear, some of them realize it and they're not
> happy about it. C++ programmers who never really fully grasped OOP
> under C++ (and there are /more/ than a few) aren't too keen in my
> neighborhood about Java removing some of the hooks they've grown used
> to using as crutches.
I can easily believe that. Not all programmers will choose
what we would consider to be a "superior" tool. It's too early
to say how significant these people may be. I don't see why
every C/C++ programmer should want to switch to Java - or Lisp,
or anything else. The "C++ or death" people will always use
C++, because that's what they do.
> What /should/ come after Java is a realization that you don't need a
> full language to do applets, all you need is a good VM. VM design
> really ought to come back into its own. I think Sun has got the cloo:
> They've produced a SafeTcl plug-in for Netscrape that allows you to
> use `ticklets,' Tcl applets, in HTML, instead of Java. The
> recognition that you can /do/ that might drive us to get our choice of
> languages for inter-applet communication.
Yup. And then there's Guile. I'd love to use Guile as an Active
script engine, and I know at least one person who's turning SCM
into such a beast. That's platform specific, of course, but at
least it's a language that I'm more than comfortable with, and
it'll work with a large number of other tools (which are also yet
to become available).
> Me, of course, I'm pushing for Scheme.
Me too. See above. The only difference is perhaps the platform.
Don't expect MS to adopt SafeTcl - that's not their way. Luckily,
the MS way is no longer Basic only, as predicted by Bill Gates
in the 80s. Today it's a little more open than that. Phew.
> >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".
>
> That's not what I see; what I see from where I sit is people choosing
> NT for their mail-servers and their user-hubs and thinking that `Hey,
> its Windows, I can hire some young punk for $25k/yr and he won't even
> have to really administrate it, its plug and play!' And then they
> discover NT combines the speed of VMS with the stability of Unix and
> that their young punk couldn't administrate a network if his cojones
> were on fire with Ethernet packets.
Ah, yes. Slag off "young punks". These people are the next gen.
Crying "Help!" won't stop it from happening. There's too much
intertia. What I hope wil happen is that some companies will
realise this either before, or just after, it happens, and then
correct the error. It's been happening for _years_. Why is now
so special?
> Netware people, at the scale you deal with them at, should stick with
> Netware save for their big servers which should be Unix; most of the
> Netware folk just need a distributed networking environment that runs
> the aps they want. NT looks pretty, but it doesn't have the
> horsepower to be a corporate server stabily. No one wants to pay for
> VMS. :)
As I said, Novell are offering Unixware. ;)
> >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?
>
> You miss the point; the strength they sell Windows-based tools on is
> the GUI-nature. In terms of simple resources needed to support and
> continue using the GUI-frontended tasks that csh allows you to do, the
> Windows version will /inevitably/ be bigger. Ragging on how much
> overhead that a Scheme-compiled ap has really pales compared to the
> resources of non-Scheme aps that you intend to run next to it. If I
> have five major Windows aps written in Scheme which use a 1.4meg
> shared library, that's a trivial amount compared to the amount of
> window-state, graphics front-ending, graphics and GUI libraries,
> pull-down-menu handling, etc, all the things that the aps have to hook
> to run in a Windows API. Scheme turns out looking like a rather
> smallish and sparse library of development tools set alongside that
> nightmare bag, so critiquing the size of Scheme applications,
> especially in the Windows environment, is shown to be a silly thing to
> do.
You're assuming that everyone wants (and needs) the power of csh.
I agree about the value of Scheme, but some people will only see
the cost - the cost of a commercial license, for example, or the
imagined cost of things that don't even count.
A lot of developers don't even know that Scheme exists, but that's
another kind of memetic problem. The C++ meme is very powerful,
in inverse proportion to the value and power of the language.
The same can be said for the Scheme meme, if you look in the same
places. So, who spreads these memes? I'm more than happy to write
pro-Scheme articles for magazines, but nobody has published _my_
words yet. Perhaps it's a mistake to target what could be called
pro-C++ mags (pro-Windows development, in fact), but that seems
to me like a good place to counter the pro-C++ meme.
Still, I have a homepage in which to "publish" these things.
That'll do nicely, even if very few people ever browse it. ;)
> That doesn't even begin to address the coding safety improvements when
> you no longer manually manage memory and have dynamic types.
Indeed. I don't mind being called a "quiche eater", as I like
quiche. It would be a compliment! "Real programmers" suck.
At least, that's the impression that software written in C++
gives me. I've seen some horrible code written in C++, full
of potential crashes causes by accesses via NULL pointers, etc.
A certain infamous bug in fingerd could've been prevented simply
by using the right function, instead of the unsafe version that
somehow survives in the standard C library. So, you can not only
get software that is more reliable, by avoiding these pitfalls,
but also get a more secure system. Not everybody may make your
machine crash by sending a line that overflows a buffer. Some
people have more malicious intentions. If your server falls over,
that's merely a denial of service attack. If your security is
compromised, it's a very different issue!
My attitude has always been: get it working before you worry
about how fast it works. If it crashes, speed won't help you.
Cyber Surfer
In article <5bct7r$t...@hobbes.sco.com> m...@sco.COM "Michael Davidson" writes:
> While I know that Novell does still care about UnixWare, and
> probably still isn't too keen on NT, I wonder if you realise
> that Novell sold both Unix (in general) and the UnixWare
> product itself, to SCO over a year ago ...
No, I wasn't aware of that. I don't follow Netware events too
closely, nor do I keep up with everything in the Unix world.
As it may be clear by now, I'm not familiar with either world.
I don't think this dramatically changes my point, tho. Novell
will still wish to sell you _something_, just like everyone else.
Netware isn't going away - not yet, anyway, and certainly not
soon. The same is true for a lot of the alternatives.
Hiroshi Murakami
Some language is superior or inferior cannot be said so easily.
Do you think some language that you think inferior should be
sent to the gas chamber to protect the superior ones?
Alex Williams
In article <853242...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>I can easily believe that. Not all programmers will choose
>what we would consider to be a "superior" tool. It's too early
>to say how significant these people may be. I don't see why
>every C/C++ programmer should want to switch to Java - or Lisp,
>or anything else. The "C++ or death" people will always use
>C++, because that's what they do.
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.
>Yup. And then there's Guile. I'd love to use Guile as an Active
>script engine, and I know at least one person who's turning SCM
>into such a beast. That's platform specific, of course, but at
>least it's a language that I'm more than comfortable with, and
>it'll work with a large number of other tools (which are also yet
>to become available).
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.
>Ah, yes. Slag off "young punks". These people are the next gen.
>Crying "Help!" won't stop it from happening. There's too much
>intertia. What I hope wil happen is that some companies will
>realise this either before, or just after, it happens, and then
>correct the error. It's been happening for _years_. Why is now
>so special?
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.
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.
>You're assuming that everyone wants (and needs) the power of csh.
>I agree about the value of Scheme, but some people will only see
>the cost - the cost of a commercial license, for example, or the
>imagined cost of things that don't even count.
Not all people need or want the power of scsh, but most programmers
/do/ want at least the power and expressability of basic Scheme.
>A lot of developers don't even know that Scheme exists, but that's
>another kind of memetic problem. The C++ meme is very powerful,
>in inverse proportion to the value and power of the language.
>The same can be said for the Scheme meme, if you look in the same
>places. So, who spreads these memes? I'm more than happy to write
>pro-Scheme articles for magazines, but nobody has published _my_
>words yet. Perhaps it's a mistake to target what could be called
>pro-C++ mags (pro-Windows development, in fact), but that seems
>to me like a good place to counter the pro-C++ meme.
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.
>Indeed. I don't mind being called a "quiche eater", as I like
>quiche. It would be a compliment! "Real programmers" suck.
>At least, that's the impression that software written in C++
>gives me. I've seen some horrible code written in C++, full
>of potential crashes causes by accesses via NULL pointers, etc.
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.
>A certain infamous bug in fingerd could've been prevented simply
>by using the right function, instead of the unsafe version that
>somehow survives in the standard C library. So, you can not only
>get software that is more reliable, by avoiding these pitfalls,
>but also get a more secure system. Not everybody may make your
>machine crash by sending a line that overflows a buffer. Some
>people have more malicious intentions. If your server falls over,
>that's merely a denial of service attack. If your security is
>compromised, it's a very different issue!
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.
>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./
(Sidreal issue: I still wish I had Common LISP-like variable
declarations in Scheme. SoftScheme doesn't count. :)
John Bayko
In article <5bidna$d...@newsgate.so-net.or.jp>,
The language debate is over - the first reference to Hitler has
been made.
--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
Peter da Silva
In article <5bb56f$b...@netnews.alf.dec.com>,
Alex Williams <tha...@uxtlaser.alf.dec.com> wrote:
> have to really administrate it, its plug and play!' And then they
> discover NT combines the speed of VMS with the stability of Unix and
That's unfair to both VMS (it's not that slow) and UNIX (it's *definitely*
not that unstable).
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
John R. Campbell
On 15 Jan 1997 11:06:18 GMT, Hiroshi Murakami <nws...@ca2.so-net.or.jp> wrote:
>Some language is superior or inferior cannot be said so easily.
>Do you think some language that you think inferior should be
>sent to the gas chamber to protect the superior ones?
Agreed; Most computer languages I know of accumulate a fair
amount of cachet based upon "coolness" rather than technical
excellence or elegance.
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.
Ada has a following trying to act as a high priesthood. Nobody
takes them seriously, even when the language has advantages for
a particular job.
C++ is the most current attempt at a snob language. Need I say
more?
FORTH is not a computer language; It is a religion. I worked
in a FORTH shop for 5 years and I managed to maintain my agnostic
views towards languages; I've managed to maintain my eclectic
background. FORTH is the Zen of computer languages; Every one
of it's strengths is a weakness, and every one of it's weaknesses
is a strength.
So no language is really the BEST for everything and (often)
language choice is best matched for particular problems. I
wouldn't use COBOL for a message switch any more than I'd use
FORTH for a sort/merge application.
Has that muddied the water enough?
BTW, this wasn't really meant as a troll; I've maintained my
eclectic background by not taking my language preferences
seriously.
Romanchek's 6th Rule: Laugh at yourself; Why should everybody
else have all the fun?
--
John R. Campbell, Speaker to Machines, Resident Heckler so...@jtan.com
"As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me
Disclaimer: I'm just a consultant at the bottom of the food chain, so,
if you're thinking I speak for anyone but myself, you must
have more lawyers than sense.
Richard Karpinski
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.
Cyber Surfer
In article <5bjud8$d...@netnews.alf.dec.com>
tha...@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
John Bayko
In article <slrn45dvq86....@phu989.um.us.sbphrd.com>,
John R. Campbell <so...@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).
Erik Naggum
* 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.
Alex Williams
In article <5bom2n$k...@web.nmti.com>, Peter da Silva <pe...@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/!'
Rob Warnock
John Bayko <ba...@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 rp...@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
John Bayko
> 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...
D. J. Bernstein
In article <30627577...@naggum.no>, Erik Naggum <er...@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
Chris Bitmead
> 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.
Erik Naggum
* 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.
|
| 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".
Peter da Silva
[among some real nice things that C doesn't have]
In article <30627577...@naggum.no>, Erik Naggum <er...@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.
Peter da Silva
In article <5c04gd$4...@netnews.alf.dec.com>,
Alex Williams <tha...@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/!
Erik Naggum
* 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.
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...
>
>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!).
--
Fergus Mixolydian
rp...@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 cbe...@retix.com
D. J. Bernstein
In article <30628502...@naggum.no>, Erik Naggum <er...@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?
Bruce Hoult
ba...@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" ...
Larry Kilgallen
In article <5c3aum$9...@web.nmti.com>, pe...@nmti.com (Peter da Silva) writes:
> [among some real nice things that C doesn't have]
>
>> _I'd_ like to have a language that defined the width of integers.
>
> 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
Erik Naggum
* Robert Harley
| In the ring "modulo 2^n, where n is the number of bits in the type",
| according to Mssrs Kernighan and Ritchie. If you assumed a different
| ring (such as Z) that's tough. You should read the language spec
| before pontificating in error.
you gotta love this kind of response. it's the language specification that
is in error. just as it is in error in many other ways. division between
two signed integers can yield either floor or ceiling depending on what the
CPU architecture supports. chars are signed or unsigned according to what
the "hardware" thinks is faster. etc. the _language_ C is underspecified.
no matter how well they write their specification, C remains underspecified.
C is _designed_ to be "fast but unreliable". _that_ is the problem.
Peter da Silva
In article <30628733...@naggum.no>, Erik Naggum <er...@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.
Robert Sanders
pe...@nmti.com (Peter da Silva) writes:
> In article <30628733...@naggum.no>, Erik Naggum <er...@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
Larry Kilgallen
In article <5c5c65$9...@news-rocq.inria.fr>, har...@pauillac.inria.fr (Robert Harley) writes:
> Erik Naggum <er...@naggum.no> writes:
>>[...]
>>thank you. you prove my point most eloquently: C does not give programmers
>>access to arithmetic condition known as "overflow".
>
> overflow flag, hardware may not have one for you to access.
Hardware is irrelevant. If the hardware does not support such a check,
it should be generated by the compiler. Of course if a language has no
way to report such an error, whether the compiled code detected such an
overflow or not is a secret.
>>as I said, A+1 is either A+1, 0 or -(A+1) in C.
>
> A+1 is A+1.
>
> In the ring "modulo 2^n, where n is the number of bits in the type",
> according to Mssrs Kernighan and Ritchie. If you assumed a different
> ring (such as Z) that's tough. You should read the language spec
> before pontificating in error.
If a language provides modular arithmetic by default, it does not
meet the expectations of most programmers. Most programmers do not
read language specifications. Restricting one's interest to the
subset known as "good programmers" is not acceptable, since most
software is not written by "good programmers" (the other sort being
in much more plentiful supply and much cheaper).
Larry Kilgallen
Robert Sanders
pe...@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.
Peter da Silva
In article <1997Jan22.121634.1@eisner>,
Larry Kilgallen <kilg...@eisner.decus.org> wrote:
> If a language provides modular arithmetic by default, it does not
> meet the expectations of most programmers.
Programmers who don't learn how C arithmetic (or Forth arithmetic, which is
also modular, or PL/M arithmetic, or the arithmetic of any other low level
language I've ever used) works shouldn't be programming in C.
That's like programming in Pascal without understanding the nuances of "get",
or in Ada, without understanding operator overloading.
Larry Kilgallen
In article <5c602r$k...@web.nmti.com>, pe...@nmti.com (Peter da Silva) writes:
> In article <1997Jan22.121634.1@eisner>,
> Larry Kilgallen <kilg...@eisner.decus.org> wrote:
>> If a language provides modular arithmetic by default, it does not
>> meet the expectations of most programmers.
>
> Programmers who don't learn how C arithmetic (or Forth arithmetic, which is
> also modular, or PL/M arithmetic, or the arithmetic of any other low level
> language I've ever used) works shouldn't be programming in C.
"Shouldn't" has no place in the real world. They do, regardless of
whether that is because it is the only language they learned in school
or because their boss learned from Computerworld that all programs
should be written in C.
Larry Kilgallen
Chris Bitmead
>In article <30627577...@naggum.no>, Erik Naggum <er...@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.
Rainer Joswig
In article <5c398r$2...@sue.cc.uregina.ca>, ba...@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
Robert Harley
Erik Naggum <er...@naggum.no> writes:
>[...]
>thank you. you prove my point most eloquently: C does not give programmers
>access to arithmetic condition known as "overflow".
What exactly is an "arithmetic condition"? If you mean a carry or
overflow flag, hardware may not have one for you to access.
>as I said, A+1 is either A+1, 0 or -(A+1) in C.
A+1 is A+1.
In the ring "modulo 2^n, where n is the number of bits in the type",
according to Mssrs Kernighan and Ritchie. If you assumed a different
ring (such as Z) that's tough. You should read the language spec
before pontificating in error.
Bye,
Rob.
.-. Robert...@inria.fr .-.
/ \ .-. "Dances with bits" .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' Hit me with those laser beams. `-'
Oleg Moroz
On 22 Jan 1997 16:00:07 +0000, Erik Naggum <er...@naggum.no> wrote:
>* Robert Harley
>| In the ring "modulo 2^n, where n is the number of bits in the type",
>| according to Mssrs Kernighan and Ritchie. If you assumed a different
>| ring (such as Z) that's tough. You should read the language spec
>| before pontificating in error.
>
>you gotta love this kind of response. it's the language specification that
>is in error. just as it is in error in many other ways. division between
>two signed integers can yield either floor or ceiling depending on what the
>CPU architecture supports. chars are signed or unsigned according to what
>the "hardware" thinks is faster. etc. the _language_ C is underspecified.
>no matter how well they write their specification, C remains underspecified.
>
>C is _designed_ to be "fast but unreliable". _that_ is the problem.
The fact is that for most everyday programming needs many (if not all)
programmers need just that - fast and unreliable integer arithmetic, not an
overspecified Common Lisp or Ada numerics or Scheme's number tower. And when
they do need the precisely defined number-crunching operations, they can surely
code them explicitly.
I think that one of the faults of CL and like was to first overspecify some
features of the language and then depend on "sufficiently smart compilers" to
achieve good performance, instead of using more straightforwardly implementable
things as the language basis and then building on it with more (standard)
libraries and such.
Oleg
David Hanley
Tim Pierce wrote:
>
> >A+1 is A+1.
> >
> >In the ring "modulo 2^n, where n is the number of bits in the type",
> >according to Mssrs Kernighan and Ritchie. If you assumed a different
> >ring (such as Z) that's tough. You should read the language spec
> >before pontificating in error.
>
> actually be related to the ring Z.
It might seems silly, but I seem to remember it as part of the required
computer science classes at my university, and pretty much everyone got
it. If someone can't be bothered to learn basic language 'stuff' I
don't know how much I trust them as programmers.
--
------------------------------------------------------------------------------
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
Peter da Silva
In article <kn915l7...@xena.mindspring.com>,
> > > 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.
Peter da Silva
In article <1997Jan22.072945.1@eisner>,
Larry Kilgallen <kilg...@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...
Peter da Silva
In article <kn20bd7...@xena.mindspring.com>,
Robert Sanders <rsan...@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.
Chris Torek
(This article is rather a bit off-topic for all these groups, for
which I apologize.)
In article <slrn45dvq86....@phu989.um.us.sbphrd.com>
John R. Campbell <so...@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: to...@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
(d...@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
Tony Finch
Chris....@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))
Andy Newman
Robert Sanders <rsan...@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 <an...@research.canon.com.au>
Erik Naggum
* 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.
Mike Haertel
In article <30629692...@naggum.no>, Erik Naggum <er...@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 <hae...@ichips.intel.com>
Not speaking for Intel.
Robert Sanders
pe...@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
Robert Sanders
an...@research.canon.com.au (Andy Newman) writes:
> Robert Sanders <rsan...@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
David Hanley
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?
Erik Naggum
* David Hanley
| [modulo 2^n definition of integer types] might seems silly, but I seem to
| remember it as part of the required computer science classes at my
| university, and pretty much everyone got it. If someone can't be
| bothered to learn basic language 'stuff' I don't know how much I trust
| them as programmers.
obviously, the problems don't happen when programmers are aware of them and
actually code to detect overflow. the problems happen because programmers
are not aware of the _possibility_ of an overflow in a given operation, and
so calculate and return the wrong answers without any notification or error.
with extreme care and precaution, a C programmer may write explicit code
that detects when the modulo 2^n arithmetic does not agree with expected
mathematical values, but overflow is an _error_ condition. if a programmer
writes checks after the fact, the _error_ still went unnoticed by C. you
can add as much explicit code as you want -- C _still_ doesn't give you
access to the overflow condition.
and yes, I _do_ know that what I'm asking for is not C. please get the
point: C _does_ _not_ _provide_ a necessary mechanism for safe programming.
Erik Naggum
* 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 Naggum
* 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.
Robert Harley
>you aren't bright enough to understand the issues I raised and you
1. This is uncalled for.
2. Dan knows a thing or two about arithmetic and most certainly does
understand the issues.
3. We'll continue merrily using C and putting in checks for overflow
when they are needed. If you're lazy, use some other language that
always checks even when you know for a fact that overflow cannot
occur, thereby increasing your code size drastically and
needlessly slowing down most arithmetic operations.
There are times when ultra-safe, high-level prototyping is productive
and there are times when non-portable hackery in machine code is
essential. But most of the time, most programmers strike a balance
between these two extremes and find that C is a happy medium.
Horses for courses and all that.
Bye,
Rob.
Robert Bernecky
This followup may be a mistake, but let's see what we can do...
The included text below has the flavor of Socratic dialogue to me.
Perhaps a concrete example will help.
Consider the bankers of the field, how they grow; they toil not, neither do
they spin. They do, however, make bazillions by using giant brain
machines to look at the market and decide where to place their bets.
Often, they don't like floating point for currency, because roundoff
error can be evil. So, let's consider scaled integers.
Oops, careful -- runaway currency
inflation can do you in there, producing [Gasp!] integer overflow
when you least expect it. Now, they're going to be doing stuff
like very very big matrix multiplies to pick the best subset of
market instruments to meet some criteria.
Hanley suggests that the programmers will carefully write
unsigned integer code and check everywhere for overflow so they
can take appropriate action. I don't think so. Particularly
when they inherit code from the dark ages and have never
taken a computer science course in their life. They got sent on
one (count 'em, 1) C programming course offered by the
Matchbook Institute Of Computering and are now playing
the Leeson version of computer roulette.
As for me, I'd be happy if I could merely detect SIGNED integer
overflow (as any self-respecting bit of hardware does as a matter
of course) and take "appropriate" action within a C program generated
by my compiler.
Use of unsigned math is not the greatest thing to here it -- clutter
reigns.
I think of C as a generic assembler code -- evil, unsafe, and ugly,
and preferably not to be hand-generated. BUT, one of its [many] shortcomings
is this inability to do something that the most humble pocket calculator
is able to do.
Bob
Erik Naggum
* Robert Harley
| If you're lazy, use some other language that always checks even when you
| know for a fact that overflow cannot occur, thereby increasing your code
| size drastically and needlessly slowing down most arithmetic operations.
this is interesting. do you have a suggestion for how I can have the
software that fails for me (or that I can't trust) automatically rewritten
into a language that does check for overflow, to take but one example?
it is also interesting that you think it's either all or nothing and that
overflow is extremely expensive. no wonder programmers like you don't want
overflow detection! but I can only guess that your job security is better
than your users' safety.
as for speed, I'm using Allegro Common Lisp in two projects right now. the
compiler has a switch `declared-fixnums-remains-fixnum' that gets true if
speed > 2 and safety < 1 in the optimization settings. (those are the
defaults; I can change the conditions under which it is true.) I can wrap
a piece of code in (locally (declare (optimize (speed 3) (safety 0))) ...)
and then I won't have overflow detection. I love _having_ that option, but
it has yet to be used in real code. in any case, the code produced at
these settings is as fast as C, or even faster, considering that a lot of
other optimizations kick in that C can't do. (e.g., tail call merging.)
Thant Tessman
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
David H. Thornley
In article <30628502...@naggum.no>, Erik Naggum <er...@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.
>
>| 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".
>
>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 thor...@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.
Robert Harley
Erik Naggum <er...@naggum.no> writes:
>as for speed, I'm using Allegro Common Lisp in two projects right now. the
>compiler has a switch `declared-fixnums-remains-fixnum' that gets true if
So you complain about how obscure this check is in C:
v += u;
if (v < u) overflow();
but you're happy with this mess to not check in Lisp:
(locally (declare (optimize (speed 3) (safety 0))) (set v (plus v u)))
!!!?!??! Ha ha ha!
>in any case, the code produced at these settings is as fast as C,
>or even faster [...]
So you found an example where it occasionally approaches the speed of C,
until suddenly the garbage collector stops everything to reclaim
unused memory that should never have been allocated in the first
place, but is so conservative that it only frees a fraction of it?
Am I right or am I right?
This thread has turned into a farce.
Let's allow it die before someone starts ad hominem flames.
Oh yeah, you already did to Dan...
Peter da Silva
In article <1997Jan22.181709.1@eisner>,
Larry Kilgallen <kilg...@eisner.decus.org> wrote:
> "Shouldn't" has no place in the real world.
Trying to convince people not to code in C is just as futile in the real
world. In any world where there's any point at all to this entire discussion
then the word "shouldn't" is an entirely appropriate response.
Now if you want to rag on lusers let's talk about the ten minutes I just
spent trying to understand why someone was complaining that they couldn't
telnet into an NT server when it worked just yesterday. And, no, there's
never been a telnetd installed on that particular box.
Peter da Silva
In article <kn915lu...@xena.mindspring.com>,
Robert Sanders <rsan...@mindspring.net> wrote:
> pe...@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.
David Hanley
Erik Naggum wrote:
>
> * David Hanley
> | [modulo 2^n definition of integer types] might seems silly, but I seem to
> | remember it as part of the required computer science classes at my
> | university, and pretty much everyone got it. If someone can't be
> | bothered to learn basic language 'stuff' I don't know how much I trust
> | them as programmers.
>
> obviously, the problems don't happen when programmers are aware of them and
> actually code to detect overflow. the problems happen because programmers
> are not aware of the _possibility_ of an overflow in a given operation, and
> so calculate and return the wrong answers without any notification or error.
Then why did't they flunk out of the SE class?
>
> with extreme care and precaution, a C programmer may write explicit code
> that detects when the modulo 2^n arithmetic does not agree with expected
> mathematical values, but overflow is an _error_ condition. if a programmer
> writes checks after the fact, the _error_ still went unnoticed by C. you
> can add as much explicit code as you want -- C _still_ doesn't give you
> access to the overflow condition.
Integer overflow is not an error condition in C. The result that is
produced is perfectly valid as the result of the expression. Defining
overflow as an error condition is a value judgement, whick in turn
causes several eingineering tradeoffs.
If I know integer overflow will not happen in a number crunching loop,
I don't want to pay because you happen to like defaulting to bignums!
>
> and yes, I _do_ know that what I'm asking for is not C. please get the
> point: C _does_ _not_ _provide_ a necessary mechanism for safe programming.
It depends on how you happen to define 'safe programming'. Are you
claiming there are languages in which error scannot happen? What are
these exactly? I'm guesing you like scheme or lisp. What hapens in
these when the dynamic type is not what you expect?
David Hanley
Robert Bernecky wrote:
>
> Hanley suggests that the programmers will carefully write
> unsigned integer code and check everywhere for overflow so they
> can take appropriate action. I don't think so.
I don't think so. I never suggested any such thing. What I did state
is that there are times when machine integers with no overflow catch are
a very good thing<tm>.
Nowehere did I state that it was the correct approach for all
applications, and nowhere did I state that you should check for overflow
in all situations manually. In fact, I'm really curious how you got the
latter part from my post.
There are situations where each approach is useful. Criticizing a
language for taking one of these equally valid approaches is very silly;
it doesn't expand anyone's knowledge by one iota.
> Particularly
> when they inherit code from the dark ages and have never
> taken a computer science course in their life. They got sent on
> one (count 'em, 1) C programming course offered by the
> Matchbook Institute Of Computering and are now playing
> the Leeson version of computer roulette.
I doubt such a person should be writing in C. However, I think BCD
numbers a in the STL( are they? ) and they behave much like regular
integers.
> I think of C as a generic assembler code -- evil, unsafe, and ugly,
> and preferably not to be hand-generated. BUT, one of its [many] shortcomings
> is this inability to do something that the most humble pocket calculator
> is able to do.
Like scale bitmps in realtime?
Chris Bitmead
> 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.
Chris Bitmead
>>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.
Chris Bitmead
In article <32e6a3d8...@news-win.rinet.ru> mo...@inist.ru (Oleg Moroz) writes:
>I think that one of the faults of CL and like was to first overspecify some
>features of the language and then depend on "sufficiently smart compilers" to
>achieve good performance, instead of using more straightforwardly implementable
>things as the language basis and then building on it with more (standard)
>libraries and such.
It's easier to write a lisp compiler, and then spend some time getting
the optimisations right, than to write even a plain 'ol C++ compiler
that accepts the full syntax, and generates correct code.
Chris Brown
In article <E4FC0...@midway.uchicago.edu>,
Tim Pierce <twpierc...@mail.bsd.uchicago.edu> wrote:
>
>How silly to imagine that a variable type entitled `int' might
>actually be related to the ring Z.
I think people are just going to have to accept that this is going to
remain a point of difference between Computer Scientists (of the
practical kind), and mathematicians and Computer Scientists (of the
theoretical kind). I don't think either (if we're talking about Lisp
and C here) language is 'superior', because I don't think a comparison
between them is sensible - they're aimed at different
targets. Criticisms of C on the basis of it using machine integer
types, rather than 'true' integer types are somewhat silly - it's like
criticising a giraffe for not having wheels.
Of course, if you want to carry on having a pointless flamewar, please
don't let me stop you. :-)
--
/* _ */main(int k,char**n){char*i=k&1?"+L*;99,RU[,RUo+BeKAA+BECACJ+CAACA"
/* / ` */"CD+LBCACJ*":1[n],j,l=!k,m;do for(m=*i-48,j=l?m/k:m%k;m>>7?k=1<<m+
/* | */8,!l&&puts(&l)**&l:j--;printf(" \0_/"+l));while((l^=3)||l[++i]);}
/* \_,hris Brown -- All opinions expressed are probably wrong. */
David B. Lamkins
On Thu, Jan 23, 1997 4:09 AM, Erik Naggum <mailto:er...@naggum.no> wrote:
>and yes, I _do_ know that what I'm asking for is not C. please get
>the
>point: C _does_ _not_ _provide_ a necessary mechanism for safe
>programming.
>
Yup. And even when the language does provide a mechanism,
many programmers will disable it in the name of "efficiency."
I worked on one project where the default was to disable
all compiler-generated runtime checks. We found quite a
few new bugs once I convinced others on the team that we
should enable all checks by default, and explicitly disable
checks only in small, local sections of code where we were
(reasonably) sure that we had all the boundary conditions
covered by design...
---------------------------------------------------------
David B. Lamkins --- http://www.teleport.com/~dlamkins/
CPU Cycles: Use them now, or lose them forever...
---------------------------------------------------------
Erik Naggum
* Robert Harley
| So you complain about how obscure this check is in C:
|
| v += u;
| if (v < u) overflow();
|
| but you're happy with this mess to not check in Lisp:
|
| (locally (declare (optimize (speed 3) (safety 0))) (set v (plus v u)))
|
| !!!?!??! Ha ha ha!
thank you. I needed that.
Common Lisp programmers write macros that do these things for them. this
is another important point you missed about the lack of abilities in C.
| So you found an example where it occasionally approaches the speed of C,
| until suddenly the garbage collector stops everything to reclaim unused
| memory that should never have been allocated in the first place, but is
| so conservative that it only frees a fraction of it? Am I right or am I
| right?
you're wrong, and you're being silly, now, instead of witty, like above.
| This thread has turned into a farce.
yeah, funny how it just did, isn't it?
Erik Naggum
* 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?