Recent

Author Topic: Contemporary Pascal Discussion  (Read 12642 times)

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Contemporary Pascal Discussion
« Reply #75 on: April 19, 2021, 04:39:30 pm »
I'm definitely not against adding new features into Pascal.  We are in agreement that Pascal should be allowed to evolve, but into what is where we should be concerned about.  The point that should be emphasized is this evolution be done in a careful and thoughtful manner that fits the design and purpose of Pascal.  We should honor and reflect upon what was Niklaus Wirth's original intention and design philosophy.
Absolutely not, Niklaus Wirth was finished with Pascal and made two new languages, Modula and Oberon. If I wanted a language that sticked closer to Niklaus Wirths design philosophy, I would choose one of these languages, the latest version of Oberon, Oberon 07 came out just last year and was completely designed by Wirth himself. So why isn't everyone here in this forum using Oberon instead, which is arguably much closer to Wirths original intention and design philosophy of Pascal then current day Pascal is. One of the reasons for this is pretty simple, while Wirth layed a solid foundation, the derivations from his original design is what made the language flurish in the first place. One example is that Wirth believes that a high level language should not have bit operations, thats why the original pascal didn't have any and Oberon-07 from 2020 still doesn't have them. The problem is if you develop software that interfaces with real apis, does DMA with hardware or does low level network communications, you simply need them, and having a 5 line workaround for 1 bitwise or command is simply not a great choice, especially with respect to readability and maintainability.
Oberon does also not support OOP, there was Oberon2 which supported limited OOP, but was ditched by Wirth in favor of working on Oberon-07. It is continued in a separate project called Component Pascal, which sees moderate success (that is in the small niche that is oberon development), but it is fair to say that OOP is also not part of Wirths design philosophy and it can be argued that the success of Component Pascal is partly due to them derivating from Wirths intend.

So long story short, a lot of the things that are highly useful and make pascal what it is, are explicitly against Wirths original intend and design philosophy, and this is a good thing. Wirth gave a solid foundation and had a lot of good ideas, but also a some bad/impractical ideas for real world development. We should keep what is good, but not discard other good things, like OOP, just because they don't align with what Wirth intended. If it fits into the language and is something the pascal community as a whole benefits from, why care what Wirth would have thought of it?
« Last Edit: April 19, 2021, 04:42:56 pm by Warfley »

Blade

  • Full Member
  • ***
  • Posts: 177
Re: Contemporary Pascal Discussion
« Reply #76 on: April 19, 2021, 06:05:46 pm »
Absolutely not...

...One example is that Wirth believes that a high level language should not have bit operations, thats why the original pascal didn't have any and Oberon-07 from 2020 still doesn't have them. The problem is if you develop software that interfaces with real apis, does DMA with hardware or does low level network communications, you simply need them, and having a 5 line workaround for 1 bitwise or command is simply not a great choice, especially with respect to readability and maintainability.

Oberon does also not support OOP, there was Oberon2 which supported limited OOP, but was ditched by Wirth in favor of working on Oberon-07. It is continued in a separate project called Component Pascal, which sees moderate success (that is in the small niche that is oberon development), but it is fair to say that OOP is also not part of Wirths design philosophy...

We should be careful to not misrepresent Niklaus Wirth, out of at least respect and factual correctness.  In all that I read about the matter and the quotes that I could find on him talking about OOP, he didn't disparage it.  He simply points out that OOP is not the "be all, end all" (if I may boldly sum it up).  That it has its place, along with other paradigms.  OOP and procedural programming are tools that can complement and are to be used together.  Let's not also forget that classic Pascal already had the powerful record data type, so that OOP becomes more of a "cherry on top" as oppose to base necessity.

“Was the development of Object Pascal a positive thing? Is the result still, recognizably ‘Pascal’?”  -- Richard Morris (7/2009)

“During my sabbatical at Xerox Research in Palo Alto in 1985, Larry Tesler approached me with his proposal for an object-oriented version of Pascal. He was a member of the team around Alan Kay implementing Smalltalk. I believe it was a valuable contribution to provide the object-oriented paradigm in a language with static typing. It contained several additions, but essentially retained the character and appearance of Pascal.” -- Wirth

“How do you see the future for procedural programming languages? “ -- Richard Morris

“Procedural programming is still the most common paradigm, and it will remain so, because the semantic gap between procedural languages and computers is smaller than for any other paradigm. Instruction sequences are represented by statements, and the state space by variables.

I consider object-oriented languages also as procedural. They emphasize the grouping of related data into objects, and the attachment of methods to objects. The close relationship between object-oriented and procedural views becomes apparent if we relate the respective terminologies: Basically the terms class, object, and method stand for the classical type, variable, and procedure. Instead of calling a procedure, we now send a message.” -- Wirth

On Oberon and OOP.

“...and in Oberon it was object-orientation in disguise, combined with a rigorous desire to reduce the number of features and facilities, to get rid of bells and whistles.” -- Wirth

https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/niklaus-wirth-geek-of-the-week/
(Niklaus Wirth: Geek of the Week)

Nowhere have I've read that Wirth was against bit operations, but rather his languages provide ways to simplify and organize processes when possible.

So long story short, a lot of the things that are highly useful and make pascal what it is, are explicitly against Wirths original intend and design philosophy...

This looks to be a mischaracterization and misrepresentation of what Wirth is about.  I got the impression that he's about well-structured and organized programming, readable and maintainable code, and then simplifying processes when possible.  What fits into that is likely something he would agree with. 
« Last Edit: April 19, 2021, 06:25:51 pm by Blade »

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Contemporary Pascal Discussion
« Reply #77 on: April 19, 2021, 07:53:22 pm »
I did not make any claims about what wirth personally thinks about concepts in general, but if or if not they are part of the original intend of pascal. Let's first start about bit operations, because this is simple. Bit operations where part of Algol, a language Wirth had a lot of influence on. In Pascal later, he did not include bit operations, so assuming that he not suddenly forgot that this concept exists, it is fair to assume that it is a conscious design decision to not include them, therefore they are definitely not a part of Wirths original intend for the language.

About OOP it should be noted that Wirth had a pretty narrow view on OOP
Quote
“Procedural programming is still the most common paradigm, and it will remain so, because the semantic gap between procedural languages and computers is smaller than for any other paradigm. Instruction sequences are represented by statements, and the state space by variables.

I consider object-oriented languages also as procedural. They emphasize the grouping of related data into objects, and the attachment of methods to objects. The close relationship between object-oriented and procedural views becomes apparent if we relate the respective terminologies: Basically the terms class, object, and method stand for the classical type, variable, and procedure. Instead of calling a procedure, we now send a message.” -- Wirth
The kind of OOP he is talking about is only a fraction of the OOP paradigm as it is employed today. It is much more than "grouping related data into object and the attachment of methods to objects". Key aspects of OOP include generally, but are not limited to:
  • Grouping of data and functionality into objects defined by classes or  prototypes
  • Classes and prototypes are objects themselves
  • Method calls can considered messages that are dispatched according to the object
  • Interfaces describe the messages that can be send to the object without specifying any related functionality
  • Access rights to allow/deny messages in different context
  • Inheritance as a way of extending and specializing objects forming a hierarchical subset relation between classes/prototypes
  • Polymorphism through interfaces and inheritance
  • Objects can reference semselves
So his comment: "I consider object-oriented languages also as procedural." does not really work when you apply it to the whole picture of OOP, at least as it is implemented in modern day ObjectPascal. Also you can clearly see that his comment “...and in Oberon it was object-orientation in disguise [...]" only works in this very narrow context of OOP, where OOP basically is only the first point on the list.

Thats not to say that there is one version of OOP, different languages embrace different features to varying degrees. Javascript for example is prototype based, while Pascal is Class based, where prototypes are so to say the "base" version of the instanciated object, while classes are a meta object that are linked to the instance.
Some languages also only implement only small parts of OOP, for example in Go there is no inheritance but only interfaces, which is why the Go company, developing the Go language does not consider itself to be an OOP language, but a lightweight OOP language.
Both Modula and Oberon only implement a fraction of the OOP paradigm, and similar to Go do not embrace all the aspects of OOP. So can these languages be called OOP? Sure why not, I don't want to play the arbiter on the meaning of words, but this form of OOP if you want to call it that is undeniable worlds apart from the OOP of modern day Object Pascal.

Oberon is his newest brainchild and, under the assumption that he knows about all the implementations of OOP, he clearly rejected a lot of concepts that are employed in the fully OOP embracing languages like it is ObjectPascal or Java or C++. So while my wording previously might have been a little bit misleading (that it goes explicitly against the original intend), as this only applies to bit operations, it can be said, that Wirth is at least not so fond of these concepts that he left a lot of them out of his newer creations.
That said it is of course impossible to find out if OOP would have been part of his original intend, as back then OOP did not exist, and even if you would ask him today, people change their opinions over time, so this question can never be answered, and it was bad by me to bring it up.

But I stick to what I wrote, I not care what was his original intend, because times change, people change and technology changes. Some concepts simply did not exist back when Pascal was first concieved, and some things might have been around but technically not possible at that time and other concepts can have been refined over time to better suite different situations. A feature must stand and fall on it's own merits only with respect to it's direct influence on the matter. Calling to the "original intend" is basically delegating the explanation to an external authority, if someone tells me a feature is good or bad, I want reasons for this that are about the feature itself, what someone else from 50 years ago thinks about the feature should not have any bearing on the feature itself. If you invoke this to judge a feature, this is just a cop out. The judgement should be done on good reasoning, not on invoking an authority.
« Last Edit: April 19, 2021, 07:57:48 pm by Warfley »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #78 on: April 19, 2021, 09:26:17 pm »
I submit that when Wirth designed Pascal he was in a towering rage over his attempted contribution to ALGOL-68 having been rejected, he was intentionally trying to break ALGOL syntax and start over, and he was using table-driven recursive ascent with manually-constructed tables which are notoriously laborious and error prone.

I will go out on a limb and suggest that McCarthy intentionally nobbled ALGOL (by sending vW off on various wild goose chases) because his interest was now in Lisp and he saw ALGOL as a competitor. I will continue by pointing out that until very recently Wirth had been one of his junior colleagues at Stanford, and would suggest that he was unwilling to accuse him of improper behaviour hence (as is well known) resigned from the ALGOL-68 committee.

By and large, the things Wirth put in Pascal were things he could do fast and fairly reliably using material he had to hand: changes to declaration order relative to ALGOL etc. He didn't attempt to fix the dangling else problem- despite knowing about it- because it would have been dangerous and risky, and that is also why he didn't introduce novel concepts like bitwise operations.

In the UK, .Exe in the 1990s reprinted an interview with (or paper by) Wirth in which he was scathingly dismissive of OO programming, insisting that there was nothing in it that couldn't be done using records. I'm afraid I don't have a reference or a pointer to the original paper, and don't know whether at the time of the original he was in his "Modula Phase" or had progressed to his "Oberon Phase".

Pascal's broken. We're stuck with it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Blade

  • Full Member
  • ***
  • Posts: 177
Re: Contemporary Pascal Discussion
« Reply #79 on: April 19, 2021, 09:44:45 pm »
I did not make any claims about what wirth personally thinks about concepts in general, but if or if not they are part of the original intend of pascal. Let's first start about bit operations, because this is simple. Bit operations where part of Algol, a language Wirth had a lot of influence on. In Pascal later, he did not include bit operations, so assuming that he not suddenly forgot that this concept exists, it is fair to assume that it is a conscious design decision to not include them, therefore they are definitely not a part of Wirths original intend for the language.

Bit operations in early Pascal does get a bit sticky (:-), so not saying you don't kind of have a point on that, but they appear to be part of various Pascal flavors of the time when the 1983 ISO standard came out and definitely by 1990 ISO.  When you start going back into the early 1970s and 1960s, there is other terminology used instead such as partial-word operations, which can obscure specifics and purpose.  It looks like Wirth tried to simplify with the set type, but that wasn't enough for the liking of various parties. 

Do keep in mind there were important early variants of Pascal, like UCSD Pascal (1977) and Apple Pascal (1979).  Clearly and significantly early in its history, Pascal was doing bit manipulation/partial-word operations.  From interviews, Wirth was supportive of these variants/extensions, where they made sense and in the commercial space.  Let's not pretend that Wirth was opposed to extending the language.

About OOP it should be noted that Wirth had a pretty narrow view on OOP...

What is OOP is clearly a matter of interpretation.  But Wirth had a front row seat given to him by Larry Tesler (who worked on Smalltalk and under Alan Kay) and Apple.  Interviews show that Larry Tesler and Wirth had plenty of talks about OOP.  Clearly Wirth, a man of high intelligence, knows what OOP is about.  So he should be given the benefit of the doubt about accepting (pretty much said so) and contributing to the creation of Object Pascal.

As a matter of language design, Wirth seems to prefer to keep things streamline, make more efficient, or simplify.  His ideas about OOP appear to be often about reflecting on its core elements and what's necessary.  He is entitled to his opinions on OOP, and has a greater understanding of the subject than likely 99% of programmers.

Lastly, I'm not saying that what Wirth thinks is the final arbitrator of what Object Pascal can or can't put into it.  Clearly, people and companies have long took divergent paths very early in Pascal's history.  Rather, it would be good to have an understanding of what his intent and design principles are, and then be thoughtful about what does get added in.  The path that Object Pascal goes down, should arguably be what fits the language best, not incorporate any fad or gimmick.

Quote from: MarkMLl
Pascal's broken. We're stuck with it.

If Pascal is "broken", then all programming languages are.  Don't know of a language that has remained unchanged since its introduction.  All languages have to evolve, and Pascal is.
« Last Edit: April 19, 2021, 09:59:55 pm by Blade »

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Contemporary Pascal Discussion
« Reply #80 on: April 19, 2021, 10:01:54 pm »
and that is also why he didn't introduce novel concepts like bitwise operations.
Bitwise operators were not a novel concept, sets, the thing that replaced them in pascal were. Wirth orginally proposed the Set datatype in pascal to replace bit operations, an idea he originally attributes to C.A.R Hoare. Basically to use high level mathematical concepts instead of low level bits.
I can't find the original source on that one, i.e. the quote where he said that he did not include bit operations because of sets, but in 2007 he wrote a piece about Sets (anbd why they are great on ARM processors) where he at least states that he introduced sets in pascal for handling bit sets on a mathematical level: https://people.inf.ethz.ch/wirth/Oberon/SETs.pdf

Seenkao

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: Contemporary Pascal Discussion
« Reply #81 on: April 19, 2021, 11:24:39 pm »
In the UK, .Exe in the 1990s reprinted an interview with (or paper by) Wirth in which he was scathingly dismissive of OO programming, insisting that there was nothing in it that couldn't be done using records. I'm afraid I don't have a reference or a pointer to the original paper, and don't know whether at the time of the original he was in his "Modula Phase" or had progressed to his "Oberon Phase".
Вероятно я бы его поддержал в этом. Я ещё не видел ни одной программы, которая использует ООП и которую нельзя было бы перевести в процедурный вид. Но, зачастую я встречался в этом же ООП, где код был практически идентичен и ни кто даже не собирался это исправлять в ООП. В процедурном программировании я встречался с этим меньше! (вероятно из-за того, что людей программирующих процедурно сейчас на порядок меньше).

Google translate: I would probably support him in this. I have not yet seen a single program that uses OOP that cannot be translated into a procedural form. But, often I met in the same OOP, where the code was almost identical. and no one was even going to fix it in OOP. I've seen less of this in procedural programming! (probably due to the fact that there are an order of magnitude less people who program procedurally now).
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

Blade

  • Full Member
  • ***
  • Posts: 177
Re: Contemporary Pascal Discussion
« Reply #82 on: April 20, 2021, 04:14:59 am »
Bitwise operators were not a novel concept, sets, the thing that replaced them in pascal were. Wirth orginally proposed the Set datatype in pascal to replace bit operations, an idea he originally attributes to C.A.R Hoare. Basically to use high level mathematical concepts instead of low level bits...

It also appears that ISO 1983, might have messed up Wirth's original implementation of the set type.  Originally the cardinality of the set type was limited by the length of a machine word.  This is sometimes referred to as a "narrow" set.  The ISO standard relaxed the constraints on the set type, which can be referred to as a "wide" set.  The confusion about the ISO standard, implementation, and usage might be one of the reasons why a lot of Pascal variants went with the more "standard use" bitwise operators.  By the 1985 time frame, those kind of operators are in the documentation for various different flavors of Pascal.  Definitely, Turbo Pascal's 4 owner manual (1987) references bitwise operators.

It might be better to not characterize the issue as any kind of intentional oversight by Wirth, but more of a miscalculation or misjudgment that it would be more widely used for bit manipulation and how effective the set type would be considered for such a purpose. 

Introduction of the set type, could be considered a moderate success (when used for other purposes) as they offered additional functionality not found in other languages.  Furthermore, users of modern dialects of Pascal (and for quite some time) are given the bitwise operators and other tools for bit manipulation.  It clearly wasn't a hindrance to Apple Pascal (1979) and that line of variants that lead to Object Pascal (1986), as Apple created various OSes with it. 

This includes that this was the situation prior to Brian Kernighan's famous critique of Pascal (1981), demonstrating he wasn't aware of various flavors of Pascal or was attempting to pigeonhole it to bolster his argument.  By 1987 (Turbo Pascal version 4 hits the streets), various popular flavors of Pascal have nullified many arguments, despite his paper and many similar to his being continually used as weapons to shape public opinion for years to come.
« Last Edit: April 20, 2021, 05:52:19 am by Blade »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #83 on: April 20, 2021, 08:57:14 am »
It also appears that ISO 1983, might have messed up Wirth's original implementation of the set type.

In any event, Modula (-2?) introduced the concept of a bitset, which was explicitly defined as being the size of a machine word and with explicit bit ordering. Considering Hoare's input, records were considered to be ordered but sets weren't and their implementation was undefined (i.e. a large set could potentially be implemented as a hash table etc.).

"Oversight" is not a word I'd use in this particular case. Wirth felt that he had time constraints, and even though he was one of the most effective compiler writers of the time the technique he was using- table-driven recursive ascent- was arduous and not conducive to quick fixes.

So when I say "broken but we're stuck with it", I mean that I believe that Wirth was very much aware that what he was doing was far from perfect... and he might already have had the germ of ideas for fixing things in a successor language. But assuming that we're talking about the few weeks after his resignation from the ALGOL committee (and possibly prior to the "Minority Report" to which he at least put his signature), then his major focus was trying to get something working to preempt what he considered to be McCarthy's bad-faith manoeuvre.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: Contemporary Pascal Discussion
« Reply #84 on: April 20, 2021, 09:47:09 am »
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #85 on: April 20, 2021, 10:19:25 am »
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.

I think the /explicit/ definition that it was represented by a machine word (even if that omitted the size of the word and the numeric representation of the bit ordering) was important. Before that implementations could have claimed that their sets complied with the rather loose standard even if they'd been implemented by linked lists or unpacked arrays... as would have been done by abominations like Lisp and APL which still had noticeable market share.

(I'm not saying there that Lisp and APL were invariably abominable, merely that "higher level" languages such as those and of course Smalltalk were inclined to pretend that they had efficient low-level data structures when the truth was very different.)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: Contemporary Pascal Discussion
« Reply #86 on: April 20, 2021, 10:40:12 am »
Strictly speaking, bitset was just a predefined type. IIRC most compilers simply declared it packed set of 0..31 and characters set of #0..#255, just like Pascal, and manually made the difference.

I think the /explicit/ definition that it was represented by a machine word (even if that omitted the size of the word and the numeric representation of the bit ordering) was important. Before that implementations could have claimed that their sets complied with the rather loose standard even if they'd been implemented by linked lists or unpacked arrays... as would have been done by abominations like Lisp and APL which still had noticeable market share.

Yes. I think that matters too for languages that don't standardize pragma's.  But the TP-FPC-Delphi block somewhat standardizes those too. (though the set packing ones are not among them, but I think some attempt at standardization would).



MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Contemporary Pascal Discussion
« Reply #87 on: April 20, 2021, 11:23:35 am »
Yes. I think that matters too for languages that don't standardize pragma's.  But the TP-FPC-Delphi block somewhat standardizes those too. (though the set packing ones are not among them, but I think some attempt at standardization would).

I agree, although I think that when pragmata were adopted it was anticipated that they would be compiler-specific. It would obviously be desirable if "obvious" pragmata like overflow checks could be universally uniform, but back in those days there were still systems which made little if any distinction between integers and reals which would possibly have needed a different form (i.e. "variables must not exceed" rather than "turn range checking on").

Whatever, even if Pascal pragmata are a bit messy we have- as you say- got a modicum of standardisation and just have to put up with it... just as we have to put up with the messy bits of the language itself.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018