Forum > Other

Pascal origin, where does it come from

<< < (4/13) > >>

MarkMLl:

--- Quote from: Blade on August 11, 2020, 04:17:41 am ---As we are going down memory lane and doing origins.  The Lisa Pascal Reference Manual, for which Clascal (later Object Pascal) is based on, is itself based on and references the Pascal User Manual and Report (the basis of the ISO standard), created by Kathleen Jensen and Niklaus Wirth.  Presented as viewable PDF.

Pascal User Manual and Report

--- End quote ---

There's several iterations of that, starting off with Wirth's original conference etc. papers. The quality improves substantially once Jensen is involved, I think I'd argue that she made a substantial contribution to the viability of the language.

Interestingly, a student on an MSc course I was once supporting did a spectacularly competent job "refactoring" some of the Multics documentation for her thesis. She singlemindedly adopted a uniform format: what a command did, its parameters, and- above all- if it was interactive how you backed out of it without breaking anything. It was a good illustration of how a bit of discipline can make an enormous difference, and I've tried to learn from it whenever I've been doing technical writing.

MarkMLl

avra:

--- Quote from: MarkMLl on August 08, 2020, 09:49:28 am ---It's interesting that later on he appeared to be very hostile to OO, arguing that everything could be done adequately using records.
--- End quote ---
https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig.pdf
Are you referring to ending of chapter 6.3 in this paper?


--- Quote ---the careful observer may wonder, where the core of the new paradigm would hide, what was the essential difference to the traditional view of programming. After all, the old cornerstones of procedural programming reappear, albeit embedded in a new terminology: Objects are records, classes are types, methods are procedures, and sending a method is equivalent to calling a procedure. True, records now consist of data fields and, in addition, methods; and true, the feature called inheritance allows the construction of heterogeneous data structures, useful also without object-orientation. Was this change of terminology expressing an essential paradigm shift, or was it a vehicle for gaining attention, a “sales trick”?
--- End quote ---
I find chapter 6.3 sounding more as a critique to OOP terminology then being hostile to OOP in general. If you were referring to some other paper then I would appreciate a pointer as I would really like to read it. Thanks!

MarkMLl:
No, it was much older... something like 1986 and I saw in it the mid/late-90s. It came across as reactionary in the extreme: OO didn't (in his opinion) have anything to offer since everything could be done with records and so on.

I'll see if I can track it down but I don't hold out very much hope. Certainly won't be immediate, I'm trying to do some power electronics faultfinding for somebody.

MarkMLl

440bx:

--- Quote from: avra on August 11, 2020, 09:59:03 am ---https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig.pdf
Are you referring to ending of chapter 6.3 in this paper?

--- End quote ---
Like most everything N. Wirth has done/written, I thoroughly enjoyed reading that paper.  Thank you for posting it.


--- Quote from: avra on August 11, 2020, 09:59:03 am ---I find chapter 6.3 sounding more as a critique to OOP terminology then being hostile to OOP in general. If you were referring to some other paper then I would appreciate a pointer as I would really like to read it. Thanks!

--- End quote ---
I agree.  Actually, I am surprised he didn't mention any of the rather significant downsides of OOP.

MarkMLl:
It's certainly a wide-ranging paper, but once one starts considering the details one has to have conclude that he's being selective with his recollections.

For example, he criticises ALGOL's dangling-else, without mentioning that it was fixed in ALGOL-68 but still present in his (slightly later) Pascal. He talks about := being ALGOL's assignment, which is wrong (it used a left arrow). He states that memory protection is unnecessary since compilers should be trusted, which has been proven false multiple times both before and after his date of writing. Finally, he talks about "loopholes" in programs, rather than the industry-standard "cast" or his own term "type transfer".

I agree with his point about excessive research into parsers such that absolutely any kind of syntax could be processed efficiently. I think I'm a bit more positive about extensible languages than he is, and I'm disappointed that he ignored Modula-3's  capability for declaring that a module has a questionable implementation: there's a whole lot of things that are essential but should only be in specially "blessed" modules implemented by a skilled programmer and these could usefully include type transfers and extensible syntax. And so on.

MarkMLl

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version