On Mon, 18 Jul 2022 21:26:23 -0400, "25B.Z959" <25B.Z959@nada.net>
wrote:

>On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>> [Cross-posted to alt.folklore.computers]
>>
>> On 2022-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>>
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>
>>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>
>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>
>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>>
>>>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>>>>> little space, easier calx.
>>>>>>
>>>>>> There you go, true to form. Now people use 2 digit dates because
>>>>>> they are cheap.
>>>>>
>>>>> You are neglecting Computers Past ..... low speed, low
>>>>> capacity. You simplified calx, you squeezed-down the data anywhere
>>>>> you could. I know, I had to do it.
>>>>
>>>> Me too. My first job was in an all-card shop. To squeeze things onto
>>>> an 80-column card, we stored dates in 5 columns as ddmmy. That's
>>>> right, we only kept the last digit of the year. I started there in
>>>> 1970, and one of my first assignments was to go through all report
>>>> programs and change the '6' they inserted in front of the year to '7'.
>>>
>>> In an all card shop having more than 1 card for a logical record is a
>>> problem. Not insurmountable but difficult. I've heard the one digit
>>> year story in that context but never had to deal with it.
>>
>> We used two cards for customer name data, but they didn't have dates
>> in them, just long names. You're right, having more than one card
>> for a logical record is a pain in the ass. I use the present tense
>> because I'm still faced with such files today.
>
>
> Yep - the past IS present ... old records never die, they
> just become more inconvenient. :-)
>
> Amazing how many institutions STILL run COBOL apps writ
> during the 60s by the guys with skinny ties. They work
> very well, they're too expensive to re-do, so ....
>
> There's probably a COBOL->C++ or JAVA translator out
> there somewhere ... but money's so tight these days
> and so many of those legacy apps are so super-critical
> that they just can't/won't.

And now some poor schmuck in India has to deal with it all.

On Tue, 19 Jul 2022 10:48:20 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

>25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>>> [Cross-posted to alt.folklore.computers]
>>>
>>> On 2022-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>>>
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>
>>>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>>
>>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>>
>>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>>>
>>>>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>>>>>> little space, easier calx.
>>>>>>>
>>>>>>> There you go, true to form. Now people use 2 digit dates because
>>>>>>> they are cheap.
>>>>>>
>>>>>> You are neglecting Computers Past ..... low speed, low
>>>>>> capacity. You simplified calx, you squeezed-down the data anywhere
>>>>>> you could. I know, I had to do it.
>>>>>
>>>>> Me too. My first job was in an all-card shop. To squeeze things onto
>>>>> an 80-column card, we stored dates in 5 columns as ddmmy. That's
>>>>> right, we only kept the last digit of the year. I started there in
>>>>> 1970, and one of my first assignments was to go through all report
>>>>> programs and change the '6' they inserted in front of the year to '7'.
>>>>
>>>> In an all card shop having more than 1 card for a logical record is a
>>>> problem. Not insurmountable but difficult. I've heard the one digit
>>>> year story in that context but never had to deal with it.
>>>
>>> We used two cards for customer name data, but they didn't have dates
>>> in them, just long names. You're right, having more than one card
>>> for a logical record is a pain in the ass. I use the present tense
>>> because I'm still faced with such files today.
>>
>>
>> Yep - the past IS present ... old records never die, they
>> just become more inconvenient. :-)
>>
>> Amazing how many institutions STILL run COBOL apps writ
>> during the 60s by the guys with skinny ties. They work
>> very well, they're too expensive to re-do, so ....
>>
>> There's probably a COBOL->C++ or JAVA translator out
>> there somewhere ... but money's so tight these days
>> and so many of those legacy apps are so super-critical
>> that they just can't/won't.
>>
>
>Maybe these are better than translators I have seen, but old ones produced
>unreadable code, and they might well miss some litte tricks that the old
>guys put in, and so leave time-bombs in the translated program. Much more
>expensive, but a lot better, is to extract the specs from the existing
>code, and there are re-engineering programs that can probably do a lot of
>that work, and then rewrite in the new language using programmers skilled
>in that language.

Good luck with that. Figuring out the spec from the code can be an
immense undertaking.

On 2022-07-20, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

> On Wed, 20 Jul 2022 20:09:34 +0100, Kerr-Mudd, John wrote:
>
>> On Wed, 20 Jul 2022 17:16:37 GMT
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> On 2022-07-20, Kerr-Mudd, John <admin@127.0.0.1> wrote:
>>>
>>>> On Wed, 20 Jul 2022 02:50:57 -0000 (UTC)
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>> []
>>>>
>>>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>>>> template program handy, just so we didn't have to fill in all that
>>>>> language /just/ to get a program started.
>>>>
>>>> Ah that old chestnut: "I'll start coding, you go and find out what the user
>>>> wants".
>>>
>>> Been there, done that - although I was on the receiving end of:
>>> "You start coding, I'll find out what the user wants."
>>
>> I may have mis-remembered; your phrasing sounds better.
>
> Shops differ. We had a very involved user community, and no lack
> of requirements and specifications. Our task, as architects,
> designers, and developers, was to keep up with our users. It didn't
> hurt that we had both regulatory and fiduciary requirements and
> deadlines to satisfy as well. Such is life in a big bank.

All too often, users don't know what they want - although when
you give them something, they know immediately that it's _not_
what they want. Insert a sales rep between you and the user
and it gets much worse.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

scott@slp53.sl.home (Scott Lurndal) writes:

> Peter Flass <peter_flass@yahoo.com> writes:
>>Anne & Lynn Wheeler <lynn@garlic.com> wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>> around turn of the century was brought into look at performance of 450K
>>> Cobol statement application that ran on 40+ max configured IBM
>>> mainframes (@$30M, >$1B, number needed to finish batch settlement in
>>> overnight window). They had large group responsible for the performance
>>> care & feeding, but got somewhat myopically focused.
>>>
>>> I used some other analysis tools from the IBM science center in the
>>> early 70s and found 14% improvement.
>>>
>>> There was another performance consultant that was brought in and found a
>>> different 7% improvement.
>>
>>I’m not a performance guru, but it seems like only 15-20% improvement in
>>old code that’s probably been beat up for years would indicate the code was
>>fairly decent to begin with.
>
> Or it would indicate that the code was so poorly written that it would
> take a complete rewrite to make it perform better.

The IBM COBOL compilers had an option that could slow binary arithmetic
to a crawl. So, you could change a compiler option and see an 80% change.

--
Dan Espen

On Wed, 20 Jul 2022 18:43:30 -0400
J. Clarke <jclarke.873638@gmail.com> wrote:

> Good luck with that. Figuring out the spec from the code can be an
> immense undertaking.

One which will inevitably lead to asking whether something is a bug
or a feature with no guidelines to help.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On Wed, 20 Jul 2022 23:09:16 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> All too often, users don't know what they want - although when
> you give them something, they know immediately that it's _not_
> what they want.

This is the main reason incremental development is such a good
idea. I'm just not sure how we got from feature driven incremental
development to "Scaled Agile" with it's nested iteration cycles and
constant "ceremonies" with user stories that must fit in a sprint and epics
that must fit in an iteration and an implicit theory that any developer can
take any task.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> On Wed, 20 Jul 2022 23:09:16 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> All too often, users don't know what they want - although when
>> you give them something, they know immediately that it's _not_
>> what they want.
>
> This is the main reason incremental development is such a good
> idea. I'm just not sure how we got from feature driven incremental
> development to "Scaled Agile" with it's nested iteration cycles and
> constant "ceremonies" with user stories that must fit in a sprint and
> epics that must fit in an iteration and an implicit theory that any
> developer can take any task.

Sounds like a lot of pomp and ceremony. People love that.
Death marches are so romantic - if you're not the one doing it.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> On Wed, 20 Jul 2022 18:43:30 -0400
> J. Clarke <jclarke.873638@gmail.com> wrote:
>
>> Good luck with that. Figuring out the spec from the code can be an
>> immense undertaking.
>
> One which will inevitably lead to asking whether something is a bug
> or a feature with no guidelines to help.

At this point it's time to talk to the users, find out what they
actually need, and make an executive decision. This is time-consuming
and politically hazardous, but it's the only clean solution.
Beware of cargo-cult programming!

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On Thu, 21 Jul 2022 17:42:28 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
> > On Wed, 20 Jul 2022 23:09:16 GMT
> > Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> >
> >> All too often, users don't know what they want - although when
> >> you give them something, they know immediately that it's _not_
> >> what they want.
> >
> > This is the main reason incremental development is such a good
> > idea. I'm just not sure how we got from feature driven incremental
> > development to "Scaled Agile" with it's nested iteration cycles and
> > constant "ceremonies" with user stories that must fit in a sprint and
> > epics that must fit in an iteration and an implicit theory that any
> > developer can take any task.
>
> Sounds like a lot of pomp and ceremony. People love that.
> Death marches are so romantic - if you're not the one doing it.

It is a lot of pomp and ceremony. The iteration planning meeting
that happens every eight weeks and involves *everyone* in all the teams on
the project in *one* room and is supposed to resolve all the inter-team
dependencies has to be the most unproductive waste of two days I have ever
seen. It creates jobs for quite a few "agile practitioners" too.

Oh yes one of the four two week sprints in the iteration is supposed
to be for tech debt, tool sharpening and overflow from the other three.
Guess which of the three fill it up *every* time.

My PPOE was adopting this just before I bailed and found someone
saner to work for.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On Thu, 21 Jul 2022 17:42:29 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> On 2022-07-21, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
> > On Wed, 20 Jul 2022 18:43:30 -0400
> > J. Clarke <jclarke.873638@gmail.com> wrote:
> >
> >> Good luck with that. Figuring out the spec from the code can be an
> >> immense undertaking.
> >
> > One which will inevitably lead to asking whether something is a
> > bug or a feature with no guidelines to help.
>
> At this point it's time to talk to the users, find out what they
> actually need, and make an executive decision. This is time-consuming

Discover that 70% have no idea, 20% find it an irritating bug that
they've been working round for decades and 10% depend on it and couldn't
get their work done without it.

> and politically hazardous, but it's the only clean solution.
> Beware of cargo-cult programming!

Ho yus!

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On 7/19/22 7:20 PM, D.J. wrote:
> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> [snip]
>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>
>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>> there somewhere ... but money's so tight these days
>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>> that they just can't/won't.
>>>>>>>
>>>>>>
>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>> in that language.
>>>>>>
>>>>>>
>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>> well'
>>>>>
>>>>
>>>> How much would you like to bet? Yes, the language encourages
>>>> straightforward programming, but I’ve seen things…
>>>
>>> A long time ago, I worked on many COBOL applications, including a
>>> client (PC) / server (MVS) communications application. I've seen
>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>>
>>
>> I think I remember reading that someone once coded a compiler in COBOL.
>
> My senior year at university I had two classes; one a compiler i VAX
> PASCAL and an assembler in VAX PASCAL.
>
> Oh the sounds of joy from the computer room. Well, there were yells.

Pascal is a GOOD language - and with modern extensions
can do anything 'C' can do ... but more readably. I use
Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
compiler and write stuff in it for fun (and potential
function) sometimes.

Now olde-tyme by-the-book Wirth Pascal ... that'd be a
bit harder to write a compiler with ...

On 22.7.2022 08:54 AM, 25B.Z959 wrote:
> On 7/19/22 7:20 PM, D.J. wrote:
>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
>> <peter_flass@yahoo.com> wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> [snip]
>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>
>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>> that they just can't/won't.
>>>>>>>>
>>>>>>>
>>>>>>> Maybe these are better than translators I have seen, but old ones
>>>>>>> produced
>>>>>>> unreadable code, and they might well miss some litte tricks that
>>>>>>> the old
>>>>>>> guys put in, and so leave time-bombs in the translated program.
>>>>>>> Much more
>>>>>>> expensive, but a lot better, is to extract the specs from the
>>>>>>> existing
>>>>>>> code, and there are re-engineering programs that can probably do
>>>>>>> a lot of
>>>>>>> that work, and then rewrite in the new language using programmers
>>>>>>> skilled
>>>>>>> in that language.
>>>>>>>
>>>>>>>
>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the
>>>>>> bloody
>>>>>> language is 'do it by the book, and write the book as
>>>>>> documentation, as
>>>>>> well'
>>>>>>
>>>>>
>>>>> How much would you like to bet? Yes, the language encourages
>>>>> straightforward programming, but I’ve seen things…
>>>>
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>
>>>>
>>>
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> My senior year at university I had two classes; one a compiler i VAX
>> PASCAL and an assembler in VAX PASCAL.
>>
>> Oh the sounds of joy from the computer room. Well, there were yells.
>
>
>   Pascal is a GOOD language - and with modern extensions
>   can do anything 'C' can do ... but more readably. I use
>   Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
>   compiler and write stuff in it for fun (and potential
>   function) sometimes.
>
>   Now olde-tyme by-the-book Wirth Pascal ... that'd be a
>   bit harder to write a compiler with ...

Urs Ammann, Kesav Nori and Christian Jacobi did exactly that.

They coded the original ETH Pascal compiler in Pascal and
bootstrapped it to compile itself.

I think that I may still have the listings somewhere.

--

-TV

"25B.Z959" <25B.Z959@nada.net> writes:
>On 7/19/22 7:20 PM, D.J. wrote:
>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass

>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> My senior year at university I had two classes; one a compiler i VAX
>> PASCAL and an assembler in VAX PASCAL.
>>
>> Oh the sounds of joy from the computer room. Well, there were yells.
>
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...

Yet our college undergraduate compiler coure built a Pascal
compiler using pretty-close-to-by-the-book Wirth Pascal
(although the more advanced students realized that since
we were using VAX Pascal, one could use those features
to make things a bit simpler).

On 7/22/22 00:54, 25B.Z959 wrote:
>
>   Pascal is a GOOD language - and with modern extensions
>   can do anything 'C' can do ... but more readably. I use
>   Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
>   compiler and write stuff in it for fun (and potential
>   function) sometimes.
>
>   Now olde-tyme by-the-book Wirth Pascal ... that'd be a
>   bit harder to write a compiler with ...

With freepascal it is now possible to compile EFI / PE executables so
you can write bootable applications.

Does anyone know of any FPC tools for easing the creations of both BIOS
and EFI bootloaders? I wouldn't know the first thing about FPC syntax
for handing boot and ring 0 to a kernel program.

--

G.K.

On Fri, 22 Jul 2022 01:54:08 -0400, "25B.Z959" <25B.Z959@nada.net>
wrote:
>On 7/19/22 7:20 PM, D.J. wrote:
>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
>> <peter_flass@yahoo.com> wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> [snip]
>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>
>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>> that they just can't/won't.
>>>>>>>>
>>>>>>>
>>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>>> in that language.
>>>>>>>
>>>>>>>
>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>>> well'
>>>>>>
>>>>>
>>>>> How much would you like to bet? Yes, the language encourages
>>>>> straightforward programming, but I’ve seen things…
>>>>
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>
>>>>
>>>
>>> I think I remember reading that someone once coded a compiler in COBOL.
>>
>> My senior year at university I had two classes; one a compiler i VAX
>> PASCAL and an assembler in VAX PASCAL.
>>
>> Oh the sounds of joy from the computer room. Well, there were yells.
>
>
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...

We didn't deal with real numbers, just integers and text. This was
about 1988/89. And for the assembler, a limited list. It still took us
the entire time to write it. Not much, just a few thousand lines of
code, and a big chunk of comments as the professor wanted to see if we
understood what we had done. :-)

--
Jim

"25B.Z959" <25B.Z959@nada.net> writes:
> Pascal is a GOOD language - and with modern extensions
> can do anything 'C' can do ... but more readably. I use
> Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
> compiler and write stuff in it for fun (and potential
> function) sometimes.
>
> Now olde-tyme by-the-book Wirth Pascal ... that'd be a
> bit harder to write a compiler with ...

(IBM) Los Gatos VLSI lab was doing a lot of language stuff with
Metaware's TWS ... and then used it for mainframe pascal compiler for
VLSI tool development ... eventually released as VS/PASCAL, was also
used to the original mainframe TCP/IP support.

Releasing mainframe TCP/IP support was big battle with the (SNA)
communication group ... they eventually decided it had to be released
through them which got 44kbyte/sec aggregate throughput using nearly
whole 3090 CPU. I then did the support for RFC1044 and in some turning
tests at Cray Research, between 4341 and Cray, got sustained 4341
channel throughput using only modest amount of 4341 cpu (something like
500 times improvement in bytes moved per instruction executed). I've
often commented the VS/pascal implementation had none of the
buffer/length problems that were epidemic in c language implementations.

After leaving IBM in the early 90s ... during IBM downturn, a lot of
stuff was being offloading ... including lots of chip tool applications
to industry tool vendors ... however industry standard platform was SUN
.... so all these apps had to be ported to SUN platform.

LSG hires me to port a 50,000 VS/PASCAL statement app to SUN. Enormous
amount of problems 1) I don't think SUN pascal had ever been used for
anything other than educational/instructional and 2) SUN had outsourced
pascal support to organization 12 times zones away on the opposite of
the world (easy drive to drop into SUN hdqtrs ... but didn't do much
good since had to wait until the following day for response, I did get a
billcap from "space city"). In retrospect, it would have been much
easier to have rewritten it in C.

--
virtualization experience starting Jan1968, online at home since Mar1970

On 7/22/22 5:48 AM, Tauno Voipio wrote:
> On 22.7.2022 08:54 AM, 25B.Z959 wrote:
>> On 7/19/22 7:20 PM, D.J. wrote:
>>> On Tue, 19 Jul 2022 12:53:19 -0700, Peter Flass
>>> <peter_flass@yahoo.com> wrote:
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>>
>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>> [snip]
>>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>>
>>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>>> that they just can't/won't.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe these are better than translators I have seen, but old
>>>>>>>> ones produced
>>>>>>>> unreadable code, and they might well miss some litte tricks that
>>>>>>>> the old
>>>>>>>> guys put in, and so leave time-bombs in the translated program.
>>>>>>>> Much more
>>>>>>>> expensive, but a lot better, is to extract the specs from the
>>>>>>>> existing
>>>>>>>> code, and there are re-engineering programs that can probably do
>>>>>>>> a lot of
>>>>>>>> that work, and then rewrite in the new language using
>>>>>>>> programmers skilled
>>>>>>>> in that language.
>>>>>>>>
>>>>>>>>
>>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the
>>>>>>> bloody
>>>>>>> language is 'do it by the book, and write the book as
>>>>>>> documentation, as
>>>>>>> well'
>>>>>>>
>>>>>>
>>>>>> How much would you like to bet? Yes, the language encourages
>>>>>> straightforward programming, but I’ve seen things…
>>>>>
>>>>> A long time ago, I worked on many COBOL applications, including a
>>>>> client (PC) / server (MVS) communications application. I've seen
>>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>>
>>>>>
>>>>
>>>> I think I remember reading that someone once coded a compiler in COBOL.
>>>
>>> My senior year at university I had two classes; one a compiler i VAX
>>> PASCAL and an assembler in VAX PASCAL.
>>>
>>> Oh the sounds of joy from the computer room. Well, there were yells.
>>
>>
>>    Pascal is a GOOD language - and with modern extensions
>>    can do anything 'C' can do ... but more readably. I use
>>    Laz/FPC often. I even have a DOS VM with IBM/MS-PASCAL
>>    compiler and write stuff in it for fun (and potential
>>    function) sometimes.
>>
>>    Now olde-tyme by-the-book Wirth Pascal ... that'd be a
>>    bit harder to write a compiler with ...
>
> Urs Ammann, Kesav Nori and Christian Jacobi did exactly that.
>
> They coded the original ETH Pascal compiler in Pascal and
> bootstrapped it to compile itself.
>
> I think that I may still have the listings somewhere.

I love languages/systems written in themselves - it's
such a neat concept :-)

However modern object Pascal - it WOULD be a lot easier.

I liked IBM/MS-Pascal - the old multi-pass compiler/linker
in the pink manuals with the 5-1/4 floppies inside. Something
about the overall philosophy/structure was SO much more
appealing than FORTRAN or PL/I and such (but K&R-ish 'C' -
that's a special class unto itself and I write it often -
still have the actual K&R book on the shelf).

Then came Philippe Kahn and the world changed. Gen-2
RAD/IDE environments vastly sped up development. Gen-3
IMHO is kinda the pinnacle - drag and drop yer GUI and
then customize function. Lazarus/Delphi (ok, Del kinda
priced itself out of the market).

In any case, if you want a nice GUI for an app like
TODAY - use Lazarus. 99% portable to Winders too (it's
usually the damned fonts that don't quite fit).

But once in awhile, I still write a little utility
in FORTRAN or BASIC or COBOL ... just for fun.
Let my successors suffer a bit :-)

Oh yea ... a Linux-ish question ... has anyone found
a decent Modula-3 compiler that'll actually install
and run properly in Deb ??? I've had zero success.
They'll SAY it'll work - and then there's a zillion
confounding error messages. A native compiler is
more to my liking than 'translators' like the 'G__'
family.

(and any language where the word 'lambda' shows up
often and/or has lots and LOTS of nested brackets ...
no,no,no :-)

On 7/19/22 10:50 PM, Lew Pitcher wrote:
> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>
>> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> [snip]
>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>
>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>> there somewhere ... but money's so tight these days
>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>> that they just can't/won't.
>>>>>>>
>>>>>>
>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>> in that language.
>>>>>>
>>>>>>
>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>> well'
>>>>>
>>>>
>>>> How much would you like to bet? Yes, the language encourages
>>>> straightforward programming, but I’ve seen things…
>>>
>>> A long time ago, I worked on many COBOL applications, including a
>>> client (PC) / server (MVS) communications application. I've seen
>>> things that I cannot unsee, coded things that I cannot uncode.
>>
>>
>> Got any of it on a floppy or print-out anywhere ? I'd
>> love to see how to do client/server only using COBOL.
>
> Both client and server used the same COBOL codebase, but with
> different compilers and operating environments.
>
> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
> (terminal communications) connection.
>
> The server was coded in IBM COBOL and ran under IMS DC on an MVS
> system, using an SNA terminal LU as it's communications endpoint.
>
> As this was an in-house "inner platform" project (3 tier client/server
> architecture, circa 1990), I did not keep personal copies of any
> of the code. Suffice it to say that my first question to the architect,
> my first day on that project, was "Why COBOL?" The answer was "Because
> that's what the coders know."

Sometimes that IS a factor ... you have to have people who
can write it. But 1990 ... IMHO it should have been 'C'.

>> Yea, you could do it in BASIC too ... with lots of
>> DATA statements. I remember converting a Fortran
>> pgm to IBMPC BASIC, but had to work that newfangled
>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>
>> COBOL was deliberately made to do "business stuff" in a
>> super-wordy fashion that was SUPPOSED to be "self documenting".
>
> Agreed. That was the defining component of COBOL, and perhaps it's
> saving grace.

Ummmmm ....

Mostly I like "terse" languages - less typing and lots
of room left over for comments at the ends of the lines.
'C' fits the bill pretty well. But you DO need the
comments because the syntax doesn't lend itself to a
quick read. 2/3rds of every 'C' program I do is comments,
from brief to expositions. That way I can come back to
it a few years later and sort-of figure out what I
was doing.

>> Maybe the only language requiring more text than Java :-)
>
> Those of us who coded COBOL for a living kept a boilerplate^W
> template program handy, just so we didn't have to fill in all that
> language /just/ to get a program started.

Now we just cut and paste from the internet :-)

The fine detail and complexity of what we do with
computers now has long since reached the point where
nobody can know it all. We have to go to 'the library'
and find various templates - and build upon them.

On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:

> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>
>>> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> [snip]
>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>
>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>> that they just can't/won't.
>>>>>>>>
>>>>>>>
>>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>>> in that language.
>>>>>>>
>>>>>>>
>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>>> well'
>>>>>>
>>>>>
>>>>> How much would you like to bet? Yes, the language encourages
>>>>> straightforward programming, but I’ve seen things…
>>>>
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>>
>>> Got any of it on a floppy or print-out anywhere ? I'd
>>> love to see how to do client/server only using COBOL.
>>
>> Both client and server used the same COBOL codebase, but with
>> different compilers and operating environments.
>>
>> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>> (terminal communications) connection.
>>
>> The server was coded in IBM COBOL and ran under IMS DC on an MVS
>> system, using an SNA terminal LU as it's communications endpoint.
>>
>> As this was an in-house "inner platform" project (3 tier client/server
>> architecture, circa 1990), I did not keep personal copies of any
>> of the code. Suffice it to say that my first question to the architect,
>> my first day on that project, was "Why COBOL?" The answer was "Because
>> that's what the coders know."
>
>
> Sometimes that IS a factor ... you have to have people who
> can write it. But 1990 ... IMHO it should have been 'C'.

As was mine, at the time. But, in that corporate environment,
C was almost unknown.

>>> Yea, you could do it in BASIC too ... with lots of
>>> DATA statements. I remember converting a Fortran
>>> pgm to IBMPC BASIC, but had to work that newfangled
>>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>>
>>> COBOL was deliberately made to do "business stuff" in a
>>> super-wordy fashion that was SUPPOSED to be "self documenting".
>>
>> Agreed. That was the defining component of COBOL, and perhaps it's
>> saving grace.
>
> Ummmmm ....
>
> Mostly I like "terse" languages - less typing and lots
> of room left over for comments at the ends of the lines.
> 'C' fits the bill pretty well. But you DO need the
> comments because the syntax doesn't lend itself to a
> quick read. 2/3rds of every 'C' program I do is comments,
> from brief to expositions. That way I can come back to
> it a few years later and sort-of figure out what I
> was doing.

This development occurred in a large (1000+ branch) banking environment.
When we got specs from the users, they were along the lines of
you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
giving the INTEREST ADJUSTMENT.
you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
giving the ADJUSTED ACCOUNT BALANCE.
which a programmer might convert into
MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.

The convenience was that the user's description /was/ the program code.

>>> Maybe the only language requiring more text than Java :-)
>>
>> Those of us who coded COBOL for a living kept a boilerplate^W
>> template program handy, just so we didn't have to fill in all that
>> language /just/ to get a program started.
>
> Now we just cut and paste from the internet :-)

Yah. Sad, that.

> The fine detail and complexity of what we do with
> computers now has long since reached the point where
> nobody can know it all. We have to go to 'the library'
> and find various templates - and build upon them.

--
Lew Pitcher
"In Skills, We Trust"

On 2022-07-23, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>
>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>> template program handy, just so we didn't have to fill in all that
>>> language /just/ to get a program started.
>>
>> Now we just cut and paste from the internet :-)
>
> Yah. Sad, that.

https://en.wikipedia.org/wiki/Cargo_cult_programming

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>
>>> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> [snip]
>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>
>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>> that they just can't/won't.
>>>>>>>>
>>>>>>>
>>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>>> in that language.
>>>>>>>
>>>>>>>
>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>>> well'
>>>>>>
>>>>>
>>>>> How much would you like to bet? Yes, the language encourages
>>>>> straightforward programming, but I’ve seen things…
>>>>
>>>> A long time ago, I worked on many COBOL applications, including a
>>>> client (PC) / server (MVS) communications application. I've seen
>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>
>>>
>>> Got any of it on a floppy or print-out anywhere ? I'd
>>> love to see how to do client/server only using COBOL.
>>
>> Both client and server used the same COBOL codebase, but with
>> different compilers and operating environments.
>>
>> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>> (terminal communications) connection.
>>
>> The server was coded in IBM COBOL and ran under IMS DC on an MVS
>> system, using an SNA terminal LU as it's communications endpoint.
>>
>> As this was an in-house "inner platform" project (3 tier client/server
>> architecture, circa 1990), I did not keep personal copies of any
>> of the code. Suffice it to say that my first question to the architect,
>> my first day on that project, was "Why COBOL?" The answer was "Because
>> that's what the coders know."
>
>
> Sometimes that IS a factor ... you have to have people who
> can write it. But 1990 ... IMHO it should have been 'C'.
>

IMNSHO, COBOL. C is a terrible language for those types of language. Things
that are so dimple in COBOL, like moving a character string with blank
fill, or formatting numeric output, requires calling subroutines in C, and
lack of length checking on string moves is a recipe for disaster.

I have used both languages quite a bit, perhaps COBOL more, years ago, but
neither is my preferred language, so I have no dog in this fight.
…

>
> Mostly I like "terse" languages - less typing and lots
> of room left over for comments at the ends of the lines.

Sounds like assembler ;-)

It’s too easy to write tricky code with side-effects in C. COBOL might not
be as self-documenting as advertised, but the operation of each statement
is pretty obvious and easily understood.

--
Pete

Peter Flass <peter_flass@yahoo.com> wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>>
>>>> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>>
>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>> [snip]
>>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>>
>>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>>> that they just can't/won't.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>>>> in that language.
>>>>>>>>
>>>>>>>>
>>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>>>> well'
>>>>>>>
>>>>>>
>>>>>> How much would you like to bet? Yes, the language encourages
>>>>>> straightforward programming, but I’ve seen things…
>>>>>
>>>>> A long time ago, I worked on many COBOL applications, including a
>>>>> client (PC) / server (MVS) communications application. I've seen
>>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>
>>>>
>>>> Got any of it on a floppy or print-out anywhere ? I'd
>>>> love to see how to do client/server only using COBOL.
>>>
>>> Both client and server used the same COBOL codebase, but with
>>> different compilers and operating environments.
>>>
>>> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>>> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>>> (terminal communications) connection.
>>>
>>> The server was coded in IBM COBOL and ran under IMS DC on an MVS
>>> system, using an SNA terminal LU as it's communications endpoint.
>>>
>>> As this was an in-house "inner platform" project (3 tier client/server
>>> architecture, circa 1990), I did not keep personal copies of any
>>> of the code. Suffice it to say that my first question to the architect,
>>> my first day on that project, was "Why COBOL?" The answer was "Because
>>> that's what the coders know."
>>
>>
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>>
>
> IMNSHO, COBOL. C is a terrible language for those types of language. Things
> that are so dimple in COBOL, like moving a character string with blank
> fill, or formatting numeric output, requires calling subroutines in C, and
> lack of length checking on string moves is a recipe for disaster.
>
> I have used both languages quite a bit, perhaps COBOL more, years ago, but
> neither is my preferred language, so I have no dog in this fight.
> …
>
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>
> Sounds like assembler ;-)
>
> It’s too easy to write tricky code with side-effects in C. COBOL might not
> be as self-documenting as advertised, but the operation of each statement
> is pretty obvious and easily understood.
>

“ types of language” should have been “ types of application.”
“dimple”->”simple”, etc. typing balancing my ipad unsteadily on my lap.

--
Pete

On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>
> This development occurred in a large (1000+ branch) banking environment.
> When we got specs from the users, they were along the lines of
> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> giving the INTEREST ADJUSTMENT.
> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> giving the ADJUSTED ACCOUNT BALANCE.
> which a programmer might convert into
> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>
> The convenience was that the user's description /was/ the program code.

Good luck finding white collar droids
now-a-days that can write that clearly!

Ya, a couple hundred years ago I was a programmer in a corporate-captive
service company that did the data processing for 25 or so branch banks.
Did PL/1 and assembler -- mostly on the systems side versus applications.
The specs that came down for projects was always well defined and detailed.

I don't think that's the case these days.

Jonesy

On 7/23/22 3:32 PM, Lew Pitcher wrote:
> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>
>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>>
>>>> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>>
>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>> [snip]
>>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>>
>>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>>> that they just can't/won't.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>>>> in that language.
>>>>>>>>
>>>>>>>>
>>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>>>> well'
>>>>>>>
>>>>>>
>>>>>> How much would you like to bet? Yes, the language encourages
>>>>>> straightforward programming, but I’ve seen things…
>>>>>
>>>>> A long time ago, I worked on many COBOL applications, including a
>>>>> client (PC) / server (MVS) communications application. I've seen
>>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>
>>>>
>>>> Got any of it on a floppy or print-out anywhere ? I'd
>>>> love to see how to do client/server only using COBOL.
>>>
>>> Both client and server used the same COBOL codebase, but with
>>> different compilers and operating environments.
>>>
>>> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>>> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>>> (terminal communications) connection.
>>>
>>> The server was coded in IBM COBOL and ran under IMS DC on an MVS
>>> system, using an SNA terminal LU as it's communications endpoint.
>>>
>>> As this was an in-house "inner platform" project (3 tier client/server
>>> architecture, circa 1990), I did not keep personal copies of any
>>> of the code. Suffice it to say that my first question to the architect,
>>> my first day on that project, was "Why COBOL?" The answer was "Because
>>> that's what the coders know."
>>
>>
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>
> As was mine, at the time. But, in that corporate environment,
> C was almost unknown.

The K&R bible on the language came out in 1978, 2nd
ed about a decade later. Still have the 2nd ed on my
shelf and DO look up stuff in it from time to time.
Most of my code still has a very K&R look and feel.

I was writing 'C' on the original IBM-PCs in the mid
80s, and with Aztec 'C' for CP/M-80 around the same
timeframe (that's when IBM-PCs came with a DOS *and*
a CP/M-86 floppy :-) So, the language and its strengths
surely weren't UNKNOWN.

Admittedly 'C' was originally kind of part of the
Unix & PDP-11 sphere, more 'academia', so if yer bosses
didn't use or pay attention to anything like that then
it really might have escaped their notice. Pointy-haired
know-nothing bosses aren't anything new alas.

>>>> Yea, you could do it in BASIC too ... with lots of
>>>> DATA statements. I remember converting a Fortran
>>>> pgm to IBMPC BASIC, but had to work that newfangled
>>>> 8087 the hard way using DATA. 8087s are weird. Yuk !
>>>>
>>>> COBOL was deliberately made to do "business stuff" in a
>>>> super-wordy fashion that was SUPPOSED to be "self documenting".
>>>
>>> Agreed. That was the defining component of COBOL, and perhaps it's
>>> saving grace.
>>
>> Ummmmm ....
>>
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>> 'C' fits the bill pretty well. But you DO need the
>> comments because the syntax doesn't lend itself to a
>> quick read. 2/3rds of every 'C' program I do is comments,
>> from brief to expositions. That way I can come back to
>> it a few years later and sort-of figure out what I
>> was doing.
>
> This development occurred in a large (1000+ branch) banking environment.

I can understand the conservatism ... and having lots
of COBOL programmers around.

> When we got specs from the users, they were along the lines of
> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
> giving the INTEREST ADJUSTMENT.
> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
> giving the ADJUSTED ACCOUNT BALANCE.
> which a programmer might convert into
> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>
> The convenience was that the user's description /was/ the program code.

For straightforward lines ... but, kinda like with FORTRAN, when
you start to get into formatting the output PICs can get pretty
cryptic and un-intuitive and the sheer wordiness makes typos
more likely. "X++" is less wordy than "ADD 1 TO X" and you
can "x++" or "++x" instead of structuring it in in a COBOL pgm

I do notice that COBOL-related forums and help pages and
such are still kinda busy, so it's not remotely a dead
language. People are still writing/updating COBOL code.
FORTRAN is still pretty widely used also, esp in academic
and engineering environments, mostly due to the huge volume
of proven hard-core math routines which nobody wants to
re-write. Now BASIC ... does ANYBODY use BASIC anymore ?
USED to be THE introductory language ......

Anyway, I basically dropped COBOL and FORTRAN in favor of 'C'
(and Pascal) a long time ago. I think the 2nd version of Turbo
Pascal had straight-up math-coprocessor support and at the time
I was translating a lot of old FORTRAN statistics routines over
to the IBM-PCs for scientifics and stat-mongers. IBM-PC 'C' also
had 8087 libraries, but the TP environment made development a
LOT faster. Time a Fourier Transform with, and without, a math
coprocessor sometime :-)

After that, various micro-controller projects - 8051s/PICS, later
Arduino's and such ... mix of assembler and compiler-generated
code (esp for the very annoying serial-comm stuff).

>>>> Maybe the only language requiring more text than Java :-)
>>>
>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>> template program handy, just so we didn't have to fill in all that
>>> language /just/ to get a program started.
>>
>> Now we just cut and paste from the internet :-)
>
> Yah. Sad, that.

I still sometimes buy actual BOOKS ... hard to hold three
different pages open at the same time on the net and flip
back and forth. Just ain't the same. I think the tangibility
of paper enhances memory too, multi-sensory association.
A lot easier to scribble notes circles and arrows on it too.

On 7/23/22 5:48 PM, Charlie Gibbs wrote:
> On 2022-07-23, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
>> On Sat, 23 Jul 2022 15:18:41 -0400, 25B.Z959 wrote:
>>
>>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>>
>>>> Those of us who coded COBOL for a living kept a boilerplate^W
>>>> template program handy, just so we didn't have to fill in all that
>>>> language /just/ to get a program started.
>>>
>>> Now we just cut and paste from the internet :-)
>>
>> Yah. Sad, that.
>
> https://en.wikipedia.org/wiki/Cargo_cult_programming

Been there :-)

Though I usually figure out pretty quick what's
necessary and what's not because I like terse
programs.

I do have my own little library of handy functions
in several languages - and tend to just paste it
all into new programs whether all of the bits are
used or not. However I see this as "preservation
through replication" ... I'll always be able to
find them by looking in an old program. Recently
rendered some of them in FORTRAN and ADA too, just
in case.(no, I do NOT like ADA - WAY too anal, Lady
Lovelace was probably much more fun)