[Info-vax] Fun: Object Pascal on VMS

[Dan Cross]

In article <vbmp56$2dbee$2 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-09-06, Dave Froble <davef at tsoft-inc.com> wrote:
>> On 9/4/2024 3:29 PM, Arne Vajhøj wrote:
>>> On 9/3/2024 10:48 PM, Dave Froble wrote:
>>>> On 9/3/2024 2:02 PM, Simon Clubley wrote:
>>>>> On 2024-09-03, Dave Froble <davef at tsoft-inc.com> wrote:
>>>>>> As for VMS and Pascal, there is a very decent implementation of that
>>>>>> language on
>>>>>> VMS, so what's the problem when a product aimed at a different environment will
>>>>>> not run on every environment.
>>>>>
>>>>> So how capable are the OO features in VMS Pascal these days ?
>>>>
>>>> You state that similar to my comment above, as if it is a given that OO is
>>>> necessary.  Perhaps not.  Cheap way to avoid my question.
>>>
>>> If you write OS kernel or an embedded application for a device counting
>>> memory in KB (or maybe a few MB): it is not necessary.
>>
>> Ok, your word, "necessary".
>>
>> Explain to me why OO is necessary ...
>>
>> Not that it may be useful, or desired.  You wrote "necessary".
>
>Because the sheer size of the projects involved require the additional
>abstraction and encapsulation that OO brings to the table.

This is a bit of a false dichotomy.  I believe that it _is_ true
that software nowadays has become sufficiently complex that some
sort of first-class abstraction facility beyond what we get with
a procedural langauge is necessary.  However, it does not follow
that OO is the only such abstraction facility.

Moreover, what is considered "OO" varies, so if we want to
describe it as a requirement, who's definition are we going
with?  Kay-style Smalltalk OO?  Stroupstrup-style "C with
classes" 1998 and earlier C++?  Or C++'11 and later?  Wirth
Oberon-style super minimal OO?  Is a language "OO" if you can
simply define a method on a type, or restrict the visibility
of a composite type's members in some meaningful way?  What
about languages that claim to be OO but don't really let you
restrict the visibility of most anything?

>There is a reason why Ada, a language designed for building extremely
>large safety-critical systems, added OO features to its second iteration
>and the only debate has been on the syntax, not whether those OO features
>were required.

I don't find this argument convincing.  Ada added OO facilities
because OO was hot at the time and they wanted to attract more
users.  How many safety-critical systems built with Ada make
heavy use of the OO features?  For that matter, COBOL added OO
facilities to try and make itself more attractive, but how many
large COBOL code bases really use them aggressively?

>It's the exact same reason why no-one builds a OS in assembly language
>these days. Technically you "could" do it, but to build something viable
>and robust and in a reasonable amount of time, it is "necessary" to use
>a higher-level language such as C.

See above.  Just because you could use C doesn't mean that you
should, particularly these days when there are better choices.
Similarly, just because you _can_ make heavy use of OO (again,
what does that even mean?) doesn't mean that you should.

Certainly, there are known anti-patterns in OO that we have
learned to avoid, like deeply nested inheritence hierarchies or
multiple inheritence (most of the time, anyway).

	- Dan C.