8 Nov
2006
8 Nov
'06
12:04 p.m.
On 11/8/06, Brad Parker <brad at heeltoe.com> wrote:
Marvin Johnston wrote:
We shipped production systems using Pascal (Oregon) on an 11/23 with
TSX. It worked fine. Multiuser database (of sorts) and all.
Funny you should mention that environment - the example I had in mind
was on an 11/73 under TSX...
Ethan
Dicks wrote:
At that company, I learned several times over why Pascal is not my
favorite language.
-ethan
Okay, not ever having learned or used Pascal, what are (were?) some of the
limitations of Pascal for production environments? We could go on and on about Pascal but there's
little point (IMHO). It
didn't lend itself to system programming as much as other languages.
I can entirely agree with that.
The specific situation I had in mind, to answer Marvin, was working on
an ultrasonic component inspection system written by someone else in
Pascal. My task was to go in and permit single or double resolution
scans compared to the original arrangement. The system worked as
designed, including a display task under TSX to read scan data. The
sticking point was not double-density data collection; that was easy.
It was the display task.
Fundamentally, it came down to architecture limitations crossed with
language limitations. The original task opened a file of 768 nybbles
per record (one scan line). The new task needed to open *either* a
file of 768 nybbles or 1536 nybbles per line. Because I/O on Pascal
is a) built-in and b) record oriented, the compiler tried to allocate
a record buffer for each type of file. If I'd been writing in C or
assembler, I could have allocated one 1536 nybble buffer and either
used half of it or all of it. There was no way to tell Pascal that I
knew I'd never open both types of files at once and to only worry
about buffering I/O for one type of file or the other. If I'd been
able to throw out Pascal's I/O and roll my own in assembler, I would
have. I was trapped. (the solution, if you are curious, was to
create two display tasks, one single-density only, the other
double-density. The dispatch task chose which one to send a message
to depending on the request from the user and the contents of the scan
file).
But I'm not sure I'd elevate C much higher,
except to say the BSD C
changed my life and made it easy to crank out production code on cheaper
machines which ran almost as well, though not quite as reliable.
I, on the other hand, _would_ elevate C much higher than Pascal, if
only because you can, among other things, adapt or even entirely
replace the standard library (unlike Pascal which has reserved
keywords for way too many things).
C has been called a "glorified PDP-11 assember" - given that I learned
assembler on the PDP-11 (and the 6502 and 1802 and the Z-80...) before
I tried C, it all made sense very rapidly. I don't see that slam as a
limitation.
-ethan