Re: Fun: Object Pascal on VMS

In article <vbmp56$2dbee$2@dont-email.me>,
Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2024-09-06, Dave Froble <davef@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@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.