[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Low-level vs. High-level programming (was My First Computer)



In article <Mt3Ua.17039$Qe5.5814@nwrddc03.gnilink.net>,
M. Pender <mpender@hotmail.com> wrote:
> Michael J. Mahon <mjmahon@aol.com> wrote in message
> 20030724183549.28226.00000581@mb-m24.aol.com">news:20030724183549.28226.00000581@mb-m24.aol.com...
>> Michael Pender wrote:
>>>
>>>Apple Pascal was a half-baked implementation of the language that offered
>>>very limited system access.  It was a compiled Fortran program that
>>>inherited all of the limitations of the Fortran language, as well as
>>> those of Pascal.
>>
>> No.
>>
>> UCSD Pascal was a microcomputer adaptation of Wirth's ETH Zurich
>> portable Pascal implementation (based on P-code).  In the process
>> of adapting it to microcomputers, the biggest problem was memory
>> space, so it is painfully optimized toward saving space at the clear
>> expense of a regular P-code.
>>
>> Later, a FORTRAN implementation was done (in Pascal) which
>> used the same P-code interpreter as Pascal.
>>
>>>For example, a program could not have more than 3 files open at once,
>>>system-wide.
>>
>> Pascal certainly has many limitations as a system programming
>> language (many of which were conscious tradeoffs made to enhance
>> its educational value, in the eyes of its creator).  Limitations like the
>> number of simultaneously open files are not language limitations,
>> but implementation limitations--another consequence of optimizing
>> for very small memory (64KB) systems.
> 
> As I said, Apple Pascal was a half-baked implementation that only allowed
> three files open at the same time.  In general, Pascal was a relatively
> powerful programming language 10 years ago.  However, Apple's limited
> implementation left a *lot* to be desired, even for its day.
> 
> For example, I mentioned that AP only allowed three "files" to be open at
> the same time.
> - one "file" was needed to gather keyboard input (stdin)
> - a second "file" was needed to write to the monitor or printer (stdout)
> - the third "file" was really the only I/O channel available to a program
> without sacrificing the ability to accept user input from the keyboard or to
> send output to the display (or printer)
> 
> Thus, a program that actually interacts with the user could not have more
> than one file open for reading/writing at a time without dynamically
> sacrificing one of the I/O streams.  And if a program crashed without
> reconnecting either of the stdin/stdout streasm you had to reboot to regain
> control of the machine.
 
It wasn't quite THAT bad!  I remember having written some program in
UCSD Pascal which opened one file for input, another for output, then
reading from the input file and writing to the output file, without
losing the keyboard or the console.
 
> That is the standard I/O implementation of ForTran 77
 
...and in Pascal, C, Ada, PL/I and numerous other languages.  Yes, it
is practical to have some predefined input and predefined output.
 
> -- which leads me to believe (but does not prove) that Apple Pascal
> was written in Fortran,
 
Why Fortran?  Why not e.g. C, Ada, PL/I or Pascal instead?  They all
used a similar I/O model....
 
> whether or not Apple had a commercial ForTran product in the box at that
> point in time.
> 
> I stand by my previous statement that Apple Pascal was a half-baked
> implementation.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/