On 7/18/2022 2:16 PM, Simon Clubley wrote:
> On 2022-07-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> VMS Fortran and VMS C++ does not support newer standards - but those
>> newer standards are used on other platforms.
>
> Devil's Advocate time: Does adding new standards to a language sometimes
> make it so complex that it's better to start over with a new language
> that covers the same usage cases ?

I think so.

But probably not in the case of Fortran 95 -> 2003 and
C++ 98 -> 11.

(Fortran 77 -> 90 could have been a case)

>> VMS Pascal and VMS Basic are very much VMS specific languages, but
>> no dramatic changes the last 25 years.
>>
>> VMS C is the only "hot topic" due to the C99 features phase in,
>> the 32 bit vs 64 bit pointers issue etc..
>
> 32-bit versus 64-bit pointers on VMS are not just a C issue. :-)

No.

But there are not that many languages that support both.

And I do not remember ever seeing a question about the
different pointer sizes in Fortran.

:-)

Arne

On Monday, July 18, 2022 at 7:20:00 PM UTC-4, Arne Vajhøj wrote:
> On 7/18/2022 2:16 PM, Simon Clubley wrote:
> > On 2022-07-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> VMS Fortran and VMS C++ does not support newer standards - but those
> >> newer standards are used on other platforms.
> >
> > Devil's Advocate time: Does adding new standards to a language sometimes
> > make it so complex that it's better to start over with a new language
> > that covers the same usage cases ?
> I think so.
>
> But probably not in the case of Fortran 95 -> 2003 and
> C++ 98 -> 11.
>
> (Fortran 77 -> 90 could have been a case)
> >> VMS Pascal and VMS Basic are very much VMS specific languages, but
> >> no dramatic changes the last 25 years.
> >>
> >> VMS C is the only "hot topic" due to the C99 features phase in,
> >> the 32 bit vs 64 bit pointers issue etc..
> >
> > 32-bit versus 64-bit pointers on VMS are not just a C issue. :-)
> No.
>
> But there are not that many languages that support both.
>
> And I do not remember ever seeing a question about the
> different pointer sizes in Fortran.
>
> :-)
>
> Arne
Fortran does have support for 64-bit pointers are variables but it doesn't have 64-bit pointers as fields in a structure. That can get in the way. I don't think %DESCR or %STDESCR know anything. I'm not sure about %LOC with P2 space common blocks.

Pascal has good support for 64-bit pointers with the [QUAD] attribute but it doesn't know how to create 64-bit descriptors in cases where it should when 64-bit pointers are used. It has IADDRESS and IADDRESS64.

COBOL does have a POINTER64 datatype so you can move them around. Can't really deference them.

And nothing in BASIC. "by descr" only needs to make 32-bit descriptors

On Saturday, July 16, 2022 at 7:46:10 PM UTC-4, Arne Vajhøj wrote:
> On 7/15/2022 7:02 PM, Jan-Erik Söderholm wrote:
> > Den 2022-07-15 kl. 22:56, skrev Arne Vajhøj:
> >> On 7/15/2022 4:12 PM, Bill Gunshannon wrote:
> >>> On 7/15/22 15:05, Arne Vajhøj wrote:
> >>>> On 7/15/2022 10:35 AM, Bill Gunshannon wrote:
> >>>>> Wonder where all of these VMS COBOL users are.
> >>>>
> >>>> You do see COBOL questions here occasionally.
> >>>
> >>> Can't remember the last time I saw one.
> >>
> >> Google finds 3 question the last 12 months:
> >>
> >> Brian June 10th
> >> Jan-Erik September 20th
> >> Jan-Erik August 14th
> >>
> >
> > Well, Cobol, as a language, is fairly stable and well documented,
> > so there is usually very few reasons to ask questions about Cobol
> > as such.
> I don't think that makes Cobol unique in the VMS world.
>
> VMS Cobol does not support newer standards - and supposedly nobody
> use the newer standards anyway.
>
> VMS Fortran and VMS C++ does not support newer standards - but those
> newer standards are used on other platforms.
>
> VMS Pascal and VMS Basic are very much VMS specific languages, but
> no dramatic changes the last 25 years.
>
> VMS C is the only "hot topic" due to the C99 features phase in,
> the 32 bit vs 64 bit pointers issue etc..
>
> Arne
I was curious for Pascal. The last major addition that I added was the SELECT/SELECTONE statement (patterned strongly after the BLISS statements with the same name) in 2006. Only a few minor tweaks since then.

On 7/18/2022 8:44 PM, John Reagan wrote:
> On Monday, July 18, 2022 at 7:20:00 PM UTC-4, Arne Vajhøj wrote:
>> On 7/18/2022 2:16 PM, Simon Clubley wrote:
>>> On 2022-07-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> VMS Fortran and VMS C++ does not support newer standards - but those
>>>> newer standards are used on other platforms.
>>>
>>> Devil's Advocate time: Does adding new standards to a language sometimes
>>> make it so complex that it's better to start over with a new language
>>> that covers the same usage cases ?
>> I think so.
>>
>> But probably not in the case of Fortran 95 -> 2003 and
>> C++ 98 -> 11.
>>
>> (Fortran 77 -> 90 could have been a case)
>>>> VMS Pascal and VMS Basic are very much VMS specific languages, but
>>>> no dramatic changes the last 25 years.
>>>>
>>>> VMS C is the only "hot topic" due to the C99 features phase in,
>>>> the 32 bit vs 64 bit pointers issue etc..
>>>
>>> 32-bit versus 64-bit pointers on VMS are not just a C issue. :-)
>> No.
>>
>> But there are not that many languages that support both.
>>
>> And I do not remember ever seeing a question about the
>> different pointer sizes in Fortran.
>>
>> :-)

> Fortran does have support for 64-bit pointers are variables but it
> doesn't have 64-bit pointers as fields in a structure. That can get
> in the way. I don't think %DESCR or %STDESCR know anything. I'm not
> sure about %LOC with P2 space common blocks. >
> Pascal has good support for 64-bit pointers with the [QUAD] attribute
> but it doesn't know how to create 64-bit descriptors in cases where
> it should when 64-bit pointers are used. It has IADDRESS and
> IADDRESS64. >
> COBOL does have a POINTER64 datatype so you can move them around.
> Can't really deference them. >
> And nothing in BASIC. "by descr" only needs to make 32-bit descriptors

So some support.

But I do still not remember ever seeing a question for
those languages.

While we have seen several C questions.

Either pure C or C being called via JNI where pointer
changed from 32 to 64 bit in later Java versions.

Arne

Le 14/07/2022 à 19:57, Phillip Helbig (undress to reply) a écrit :
> In article <tapiqb$2p2h4$1@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> On 2022-07-14, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>>
>>> Now if there could only be non-expiring licenses!
>>
>> That's clearly not going to happen for the general case Phillip, even
>> though there is clearly heavy discussion about this going on behind
>> the scenes.
>
> If there are still discussions, there is still hope. :-)
Have a look to the frenchies (Lafayette avec nous) :
https://www.vmsgenerations.fr/wp-content/uploads/2022/06/Questions-from-VMSgenerations-Answers-from-VSI.pdf

>
>> I just hope this decision doesn't tip VSI from being a viable business
>> into a non-viable one.
>
> Indeed.
>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

On 2022-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/18/2022 2:16 PM, Simon Clubley wrote:
>> On 2022-07-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> VMS Fortran and VMS C++ does not support newer standards - but those
>>> newer standards are used on other platforms.
>>
>> Devil's Advocate time: Does adding new standards to a language sometimes
>> make it so complex that it's better to start over with a new language
>> that covers the same usage cases ?
>
> I think so.
>
> But probably not in the case of Fortran 95 -> 2003 and
> C++ 98 -> 11.
>
> (Fortran 77 -> 90 could have been a case)
>

As can what's going on with C++ at the moment.

In the same way as the police have no motivation to reduce the overall
number of criminals in society (after all, if you reduce the number of
criminals, you reduce the number of police required), standards bodies
have no motivation to declare a language "complete", because if they do,
they will be out of a job.

I wonder if we've reached the point where some standards bodies keep
adding features for their own benefit (ie: to keep them in a job),
instead of for the benefit of the software developers they claim to
be working on behalf of ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 7/19/22 08:37, Simon Clubley wrote:
> On 2022-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/18/2022 2:16 PM, Simon Clubley wrote:
>>> On 2022-07-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> VMS Fortran and VMS C++ does not support newer standards - but those
>>>> newer standards are used on other platforms.
>>>
>>> Devil's Advocate time: Does adding new standards to a language sometimes
>>> make it so complex that it's better to start over with a new language
>>> that covers the same usage cases ?
>>
>> I think so.
>>
>> But probably not in the case of Fortran 95 -> 2003 and
>> C++ 98 -> 11.
>>
>> (Fortran 77 -> 90 could have been a case)
>>
>
> As can what's going on with C++ at the moment.
>
> In the same way as the police have no motivation to reduce the overall
> number of criminals in society (after all, if you reduce the number of
> criminals, you reduce the number of police required), standards bodies
> have no motivation to declare a language "complete", because if they do,
> they will be out of a job.

Or like Doctors have no reason to cure illnesses. They make too
much money treating repeat customers. :-(

>
> I wonder if we've reached the point where some standards bodies keep
> adding features for their own benefit (ie: to keep them in a job),
> instead of for the benefit of the software developers they claim to
> be working on behalf of ?

A recent discussion over in the COBOL group had me thinking of this
again. His point was that something that should have been clearly
spelled out in the standard doesn't appear to be. I think it is but
not where he was looking. I would have confirmed this but I am
unwilling to pay ISO hundreds of dollars just to read a standard.

So this brings us to just what the purpose of standards are. One would
think that the desire would be to make them as widespread as possible so
that people would actually use them, but no, we hide them and charge
ridiculous amounts of money just to read them (and ISO is not the only
one who does that!!)

And what should be in a standard? Wouldn't you think the standards
bodies would talk to the practitioners before creating a standard to
get an idea what they need and want in a language? But, no, they
write their standards in vacuums putting in things the practitioners
didn't ask for and certainly don't want. And then get upset when the
practitioners refuse to use the crap they never wanted. So then, why
do they put it in the standard?

And then you have all the stuff the practitioners wanted that the
standards bodies refused to consider. The result is vendor extensions
with each vendor doing the same task differently instead of all of them
doing the same way.

I really think it is time to drop the concept of academia generating
standards and create a standards body concept made up of and run by
the practitioners of the IT world. I think it would get corporate
support because they stand to profit from it in the long run.

bill

On 7/19/2022 8:37 AM, Simon Clubley wrote:
> On 2022-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/18/2022 2:16 PM, Simon Clubley wrote:
>>> Devil's Advocate time: Does adding new standards to a language sometimes
>>> make it so complex that it's better to start over with a new language
>>> that covers the same usage cases ?
>>
>> I think so.
>>
>> But probably not in the case of Fortran 95 -> 2003 and
>> C++ 98 -> 11.
>>
>> (Fortran 77 -> 90 could have been a case)
>>
>
> As can what's going on with C++ at the moment.

> I wonder if we've reached the point where some standards bodies keep
> adding features for their own benefit (ie: to keep them in a job),
> instead of for the benefit of the software developers they claim to
> be working on behalf of ?

I believe most of the standard working groups members actually
have a day job besides their standards work.

Arne

On 7/19/2022 3:03 PM, Bill Gunshannon wrote:
> On 7/19/22 08:37, Simon Clubley wrote:
>> I wonder if we've reached the point where some standards bodies keep
>> adding features for their own benefit (ie: to keep them in a job),
>> instead of for the benefit of the software developers they claim to
>> be working on behalf of ?
>
> A recent discussion over in the COBOL group had me thinking of this
> again.  His point was that something that should have been clearly
> spelled out in the standard doesn't appear to be.  I think it is but
> not where he was looking.  I would have confirmed this but I am
> unwilling to pay ISO hundreds of dollars just to read a standard.
>
> So this brings us to just what the purpose of standards are. One would
> think that the desire would be to make them as widespread as possible so
> that people would actually use them, but no, we hide them and charge
> ridiculous amounts of money just to read them (and ISO is not the only
> one who does that!!)

I believe the programming language standards are really mostly
targeted for the compiler writers.

Not for the usenet language lawyers.

But I agree it would be nice if they were available.

I believe that ECMA, W3C, OASIS, JCP etc. allows free downloads.

> And what should be in a standard?  Wouldn't you think the standards
> bodies would talk to the practitioners before creating a standard to
> get an idea what they need and want in a language?  But, no, they
> write their standards in vacuums putting in things the practitioners
> didn't ask for and certainly don't want.  And then get upset when the
> practitioners refuse to use the crap they never wanted.  So then, why
> do they put it in the standard?
>
> And then you have all the stuff the practitioners wanted that the
> standards bodies refused to consider.  The result is vendor extensions
> with each vendor doing the same task differently instead of all of them
> doing the same way.
>
> I really think it is time to drop the concept of academia generating
> standards and create a standards body concept made up of and run by
> the practitioners of the IT world.  I think it would get corporate
> support because they stand to profit from it in the long run.

That is not how reality is.

It is not academia that are creating the standards.

The standards workgroups are filled with compiler vendor
people and some people from big companies using the compilers.
Very few people from universities.

Arne

On 7/19/22 17:54, Arne Vajhøj wrote:
> On 7/19/2022 3:03 PM, Bill Gunshannon wrote:
>> On 7/19/22 08:37, Simon Clubley wrote:
>>> I wonder if we've reached the point where some standards bodies keep
>>> adding features for their own benefit (ie: to keep them in a job),
>>> instead of for the benefit of the software developers they claim to
>>> be working on behalf of ?
>>
>> A recent discussion over in the COBOL group had me thinking of this
>> again.  His point was that something that should have been clearly
>> spelled out in the standard doesn't appear to be.  I think it is but
>> not where he was looking.  I would have confirmed this but I am
>> unwilling to pay ISO hundreds of dollars just to read a standard.
>>
> > So this brings us to just what the purpose of standards are.  One would
> > think that the desire would be to make them as widespread as possible so
> > that people would actually use them, but no, we hide them and charge
> > ridiculous amounts of money just to read them (and ISO is not the only
> > one who does that!!)
>
> I believe the programming language standards are really mostly
> targeted for the compiler writers.
>
> Not for the usenet language lawyers.
>
> But I agree it would be nice if they were available.
>
> I believe that ECMA, W3C, OASIS, JCP etc. allows free downloads.
>
>> And what should be in a standard?  Wouldn't you think the standards
>> bodies would talk to the practitioners before creating a standard to
>> get an idea what they need and want in a language?  But, no, they
>> write their standards in vacuums putting in things the practitioners
>> didn't ask for and certainly don't want.  And then get upset when the
>> practitioners refuse to use the crap they never wanted.  So then, why
>> do they put it in the standard?
>>
>> And then you have all the stuff the practitioners wanted that the
>> standards bodies refused to consider.  The result is vendor extensions
>> with each vendor doing the same task differently instead of all of them
>> doing the same way.
>>
>> I really think it is time to drop the concept of academia generating
>> standards and create a standards body concept made up of and run by
>> the practitioners of the IT world.  I think it would get corporate
>> support because they stand to profit from it in the long run.
>
> That is not how reality is.
>
> It is not academia that are creating the standards.
>
> The standards workgroups are filled with compiler vendor
> people and some people from big companies using the compilers.
> Very few people from universities.

If not academia, then who's bright idea was it to put OO in COBOL
when no one using it wanted it and the user community soundly rejected
it.

bill

On 7/19/2022 3:03 PM, Bill Gunshannon wrote:
> On 7/19/22 08:37, Simon Clubley wrote:
>> On 2022-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 7/18/2022 2:16 PM, Simon Clubley wrote:
>>>> On 2022-07-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> VMS Fortran and VMS C++ does not support newer standards - but those
>>>>> newer standards are used on other platforms.
>>>>
>>>> Devil's Advocate time: Does adding new standards to a language sometimes
>>>> make it so complex that it's better to start over with a new language
>>>> that covers the same usage cases ?
>>>
>>> I think so.
>>>
>>> But probably not in the case of Fortran 95 -> 2003 and
>>> C++ 98 -> 11.
>>>
>>> (Fortran 77 -> 90 could have been a case)
>>>
>>
>> As can what's going on with C++ at the moment.
>>
>> In the same way as the police have no motivation to reduce the overall
>> number of criminals in society (after all, if you reduce the number of
>> criminals, you reduce the number of police required), standards bodies
>> have no motivation to declare a language "complete", because if they do,
>> they will be out of a job.
>
> Or like Doctors have no reason to cure illnesses. They make too
> much money treating repeat customers. :-(
>
>>
>> I wonder if we've reached the point where some standards bodies keep
>> adding features for their own benefit (ie: to keep them in a job),
>> instead of for the benefit of the software developers they claim to
>> be working on behalf of ?
>
> A recent discussion over in the COBOL group had me thinking of this
> again. His point was that something that should have been clearly
> spelled out in the standard doesn't appear to be. I think it is but
> not where he was looking. I would have confirmed this but I am
> unwilling to pay ISO hundreds of dollars just to read a standard.
>
> So this brings us to just what the purpose of standards are. One would
> think that the desire would be to make them as widespread as possible so
> that people would actually use them, but no, we hide them and charge
> ridiculous amounts of money just to read them (and ISO is not the only
> one who does that!!)
>
> And what should be in a standard? Wouldn't you think the standards
> bodies would talk to the practitioners before creating a standard to
> get an idea what they need and want in a language? But, no, they
> write their standards in vacuums putting in things the practitioners
> didn't ask for and certainly don't want. And then get upset when the
> practitioners refuse to use the crap they never wanted. So then, why
> do they put it in the standard?
>
> And then you have all the stuff the practitioners wanted that the
> standards bodies refused to consider. The result is vendor extensions
> with each vendor doing the same task differently instead of all of them
> doing the same way.
>
> I really think it is time to drop the concept of academia generating
> standards and create a standards body concept made up of and run by
> the practitioners of the IT world. I think it would get corporate
> support because they stand to profit from it in the long run.
>
>
> bill
>
>

No, no, no, can't do that. Too much common sense. Can't have that ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/19/2022 7:05 PM, Bill Gunshannon wrote:
> On 7/19/22 17:54, Arne Vajhøj wrote:
>> On 7/19/2022 3:03 PM, Bill Gunshannon wrote:
>>> I really think it is time to drop the concept of academia generating
>>> standards and create a standards body concept made up of and run by
>>> the practitioners of the IT world.  I think it would get corporate
>>> support because they stand to profit from it in the long run.
>>
>> That is not how reality is.
>>
>> It is not academia that are creating the standards.
>>
>> The standards workgroups are filled with compiler vendor
>> people and some people from big companies using the compilers.
>> Very few people from universities.
>
> If not academia, then who's bright idea was it to put OO in COBOL
> when no one using it wanted it and the user community soundly rejected
> it.

ISO X3J4 & JTC1/SC22/WG4 did that.

I cannot find a current member list.

But in 1997 (and that must have been around the time when they started
discussing OO) the member list was:

Tom Rizzo - Computer Associates
Jeff Friedman - Computer Associates
Jerome Garfunkel - COBOL Research Group
Lee Unterreiner - COBOL Research Group
Raymond W. Fisher - Electronic Data Systems
Artur Reimann - Fujitsu Software
Michael Acks - Hewlett-Packard
Ann Wallace - IBM
Barry Tauber - Interleaf
Don A. Schricker - (Chair) Microfocus
Donald F. Nelson - Tandem
John R. Brieschke - Unisys
Stephan Spiro - Wizard Systems

Very much business and probably a majority of Cobol vendors.

Arne

Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
>If not academia, then who's bright idea was it to put OO in COBOL
>when no one using it wanted it and the user community soundly rejected
>it.

IBM and to a lesser extent Fujitsu.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <tb68hj$132fp$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> In the same way as the police have no motivation to reduce the
> overall number of criminals in society (after all, if you reduce
> the number of criminals, you reduce the number of police required),
> standards bodies have no motivation to declare a language
> "complete", because if they do, they will be out of a job.
>
> I wonder if we've reached the point where some standards bodies keep
> adding features for their own benefit (ie: to keep them in a job),
> instead of for the benefit of the software developers they claim to
> be working on behalf of ?

For the C++ standards, the committee members are mostly from industry:
<https://isocpp.org/wiki/faq/wg21>

John

On 2022-07-15 17:56:42 +0000, Simon Clubley said:

> I am also aware that the LLVM team keeps moving to the latest "shiny"
> on a regular basis instead of developing LLVM against a C++ standard
> that has been available for a long time. I see they are currently at
> C++14.
> I wonder when they will be moving again. :-)
>
> Update: I had a look. It seems they are already talking about moving to
> C++17 as the new base. :-(

I fail to see C++17, C++20, or the upcoming C++23 feature usage within
LLVM as an issue for the folks using the compiler directly and natively.

For folks porting an LLVM compiler, the port will be bootstrapping with
a cross-compiler from a supported platform, and then moving native.

Get the target code generator and the cross-linker going, then get the
native versions going.

Trying to bootstrap any compiler entirely locally is front-loading a
massive amount of project work. Arguably unnecessarily.

Using recent or current features also requires the added features work.

Whether the features are "shiny" or are valuable depends on the code context.

And as you well know, a number of embedded platforms involve cross development.

OpenVMS V9.2 is quite close to being an embedded platform, with the
compilers, and the guest-only support, and the rest.

As drivers increasingly either use paravirtualization or bypass
virtualization entirely, and as native boot support and compilers all
become available, OpenVMS will become faster and more flexible.

Yes, we're on a treadmill of upgrades, and that's not going to slow
down. OpenVMS is and will remain on that same treadmill too,
particularly around SSL/TLS and ssh, and yes, LLVM.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-07-20, John Dallman <jgd@cix.co.uk> wrote:
> In article <tb68hj$132fp$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> In the same way as the police have no motivation to reduce the
>> overall number of criminals in society (after all, if you reduce
>> the number of criminals, you reduce the number of police required),
>> standards bodies have no motivation to declare a language
>> "complete", because if they do, they will be out of a job.
>>
>> I wonder if we've reached the point where some standards bodies keep
>> adding features for their own benefit (ie: to keep them in a job),
>> instead of for the benefit of the software developers they claim to
>> be working on behalf of ?
>
> For the C++ standards, the committee members are mostly from industry:
><https://isocpp.org/wiki/faq/wg21>
>

That's an interesting list. Thank you John.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-07-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/19/2022 8:37 AM, Simon Clubley wrote:
>> I wonder if we've reached the point where some standards bodies keep
>> adding features for their own benefit (ie: to keep them in a job),
>> instead of for the benefit of the software developers they claim to
>> be working on behalf of ?
>
> I believe most of the standard working groups members actually
> have a day job besides their standards work.
>

Being on a mainstream working group is a highly valued thing to be
able to place on your CV, provided you can continue making changes
to the language so you appear to still be important to your future
possible employers. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-07-20 19:43, Simon Clubley wrote:
> On 2022-07-20, John Dallman <jgd@cix.co.uk> wrote:
>> In article <tb68hj$132fp$1@dont-email.me>,
>> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>>
>>> In the same way as the police have no motivation to reduce the
>>> overall number of criminals in society (after all, if you reduce
>>> the number of criminals, you reduce the number of police required),
>>> standards bodies have no motivation to declare a language
>>> "complete", because if they do, they will be out of a job.
>>>
>>> I wonder if we've reached the point where some standards bodies keep
>>> adding features for their own benefit (ie: to keep them in a job),
>>> instead of for the benefit of the software developers they claim to
>>> be working on behalf of ?
>>
>> For the C++ standards, the committee members are mostly from industry:
>> <https://isocpp.org/wiki/faq/wg21>
>>
>
> That's an interesting list. Thank you John.

So we have people here who blame academia for language standards. We
have people who blame academia for the lack of interest in Cobol. I'm
sortof amazed by the ignorance. Cobol was ridiculed by almost everyone
long before OO had even been invented. The fact there are still a lot of
software around written in Cobol don't make it a good language, or a
language that makes sense to have in any curriculum.

There are certainly some things you can blame academia for, but so far,
complaints about academia in this newsgroup seems to most be out of
ignorance. And people even seem to take pride in their ignorance. Oh well...

Johnny

Johnny Billquist <bqt@softjar.se> wrote:
>So we have people here who blame academia for language standards. We
>have people who blame academia for the lack of interest in Cobol. I'm
>sortof amazed by the ignorance. Cobol was ridiculed by almost everyone
>long before OO had even been invented. The fact there are still a lot of
>software around written in Cobol don't make it a good language, or a
>language that makes sense to have in any curriculum.

The thing about COBOL is that it's a data description language and a
programming language all wrapped up together. There aren't very many
other systems like that. Datapoint tried one, DEC sort of tried one,
but there weren't many attempts to replace it and none of them really
caught on. RPGII kind of caught on for a little while.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 7/20/2022 8:14 PM, Scott Dorsey wrote:
> Johnny Billquist <bqt@softjar.se> wrote:
>> So we have people here who blame academia for language standards. We
>> have people who blame academia for the lack of interest in Cobol. I'm
>> sortof amazed by the ignorance. Cobol was ridiculed by almost everyone
>> long before OO had even been invented. The fact there are still a lot of
>> software around written in Cobol don't make it a good language, or a
>> language that makes sense to have in any curriculum.
>
> The thing about COBOL is that it's a data description language and a
> programming language all wrapped up together. There aren't very many
> other systems like that. Datapoint tried one, DEC sort of tried one,
> but there weren't many attempts to replace it and none of them really
> caught on. RPGII kind of caught on for a little while.

I am not a Cobol person, but is Cobol more data description than
any other language supporting records?

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 7/20/2022 8:14 PM, Scott Dorsey wrote:
>> The thing about COBOL is that it's a data description language and a
>> programming language all wrapped up together. There aren't very many
>> other systems like that. Datapoint tried one, DEC sort of tried one,
>> but there weren't many attempts to replace it and none of them really
>> caught on. RPGII kind of caught on for a little while.
>
>I am not a Cobol person, but is Cobol more data description than
>any other language supporting records?

Yes, that is what is cool about it. You wind up with enormous programs
where only a tiny bit is the procedure division.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."