I think it was most of all availability of libraries/bits of program others
had already written: an early case of first-to-market wins.
I too have a fondness for Algol 60: the first program I ever wrote, doing
self-teaching on the University (of York, if anyone's interested) timesharing
machine was in Algol-60, a few days after I'd got my account and got
fatally bitten by the computing addiction while nominally doing a biochem
degree (swapped to CompSci after a year). A little automated Q&A system
recommended which language you should learn, and though it had been put
together by Simula fanatics - so Simula was always somewhere on the top 3
of its recommendations - Algol was wot floated to the top, so I hied me off
to the university library, got out a book, and started on the slippery slope.
Deepening the addiction, the 6-line program compiled & ran first time...
Ah, TOPS-10: now *there* was an OS. And a 36-bit machine with ability to
address bytes of arbitrary size (from 1 to 36 bits) and step within and
across words as you incremented along... and perform arbitrary levels of
address redirection (briefly opening up the possibility of an uninterruptible
instruction, JRST @. - causing the machine to fetch the address of the
address of the address of the address of [repeat ad inf] the place to jump to.
Stefek 'has this drifted off topic far enough yet'?
On 16 Jan 2004 20:50:44 GMT, firstname.lastname@example.org wrote:
Another factor was that a lot of UK universities bought Elliott 803s,
mainly in the 60's IIRC, and then followed by buying 4130s.
University of Wales had one of those, and I believe York and
Manchester did as well.
Algol-60 was the preferred compiler on both of those. On the 803 you
had to load the compiler from paper tape (about 4k of it) and then
your own stuff. On the 4130 you would type up cards on a punch and
give a stack to an operator. At some time later, you would get a
stack of cards back and some listing.
Mentioning York, reminded me, since we were discussing mail the other
day, that there used to be a device invented at York called a 'York
box". IIRC, it was some kind of mail gateway or perhaps protocol
translator. They sold units to most of UK academia. I can't find
any references to it now though...... I think it was early 80s?
You obviously don't know about C. The problem with C is that if the
programmer is not educated to write structured code it is awful and
spaghetti like. Pascal is the best language to learn from as it forces the
user into a reasonably structured way. Write all languages like in Pascal
and you can't go wrong.
C is a programers language. It is for getting your hands dirty.
Checked by AVG anti-virus system (http://www.grisoft.com ).
Version: 6.0.561 / Virus Database: 353 - Release Date: 14/01/2004
| You obviously don't know about C. The problem with C is that
| if the programmer is not educated to write structured code it
| is awful and spaghetti like. Pascal is the best language to
| learn from as it forces the user into a reasonably structured
Well it did until this user found GOTO in the book and whooped with joy. I
also found the sentence that said "always re-use code wherever possible" so
I re-used the code of the chap sitting next to me.
Until you have scratched your head over how to get out of 16 level deep
nested subroutines and abort a whole process in Pasacal, an drealised
that - shit, yes, setjmp()and Longjmp() are in fact exactly what you
need to get back to a fresh start when you have detected deep in the
mire that the other end has dropped the line on you...
Pascal is fine for teaching, and that every subroutine has an entrance
as well as an exit, but sometimes you just want to crash through it all
and start over. Pascal means you have to write an explicit error handler
at EVERY level.
You can't write a real time task scheduler in it either. Mind you its
pretty impossible in 'C' as well. You need to do nasty theings like
manipulationg stack pointers - a complete nono in C - for good reasons!
Hmm, first "C beats em all", and then apparently it doesn't :-)
They all are, to a greater or lesser extent.
I would guess that 90+% of all security holes have been a result of crappy C
coding, or maybe C++, its bastard offspring. If the language (or perhaps
its "standard library") was as good as you claim, such mistakes wouldn't be
so easy to make. You can't simultaneously applaud a language and deride its
users for not being smart enough to avoid writing bad code in it.
This is NOT Burger King. You do not get it YOUR way.
I'm not sure your guess is accurate. C is about as close to machine
code as it is possible to get. With Pascal et al the compiler
typically adds error checking to catch situations such as when a
divide by zero occurs - C compilers don't usually add that overhead.
I have programmed in C, C++, Pascal, Fortran, Visual Basic and a
couple of other languages. Of them all, C was the one that was
inherently "unstable" from a programmers point of view. It was far
easier to program a routine to crash the host computer with C than for
But at the same time, C was also inherently quite forgiving in terms
of casting and similar situations. I quite liked C because you could
perform desired operations without having to jump thru hoops to either
become compliant with the compilers needs, or deliberately instruct
the compiler to ignore the error caused by the programming need.
Sending email to my published email address isn't
guaranteed to reach me.
Err, no. Machine code is as close to machine code as it is possible to
'C' combines all the power of assembler with all the security and ease
of use of ... assembler.
.asciz "Hello World!\n"
save %sp, -112, %sp
sethi %hi(.LLC0), %o0
or %o0, %lo(.LLC0), %o0
call printf, 0
mov %o0, %i0
.ident "GCC: (GNU) 3.2.2"
"The road to Paradise is through Intercourse."
[email me at huge [at] huge [dot] org [dot] uk]
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.