From Newsgroup: comp.lang.cobol

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files
Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

This is just food for thought
Cobol Greg
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 14/10/2018 7:49 PM, Greg Wallace wrote:

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

And they are not REALLY important (as terms) if you are using OO on a
daily basis.

None of these terms is particularly obscure or confusing once you do
some OO programming. I was tempted to say that some are more important
than others but, actually, they are all important (as functions, NOT as jargon) in order to get the full benefits of the OO approach.

ALL programming paradigms and languages have their own jargon.

COBOL: 02 flt-ctr REDEFINES zt-tab
OCCURS 10 times
INDEXED BY Ndx.

It isn't exactly immediately obvious unless you know the jargon (i.e.
have learned the language...)

Same with OO.

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

That depends entirely on the job you are doing and the environment in
which you are doing it, and how well you cope with abstract thought. (Everybody is different...)

I have had people say to me: "There's nothing new about OO; methods get executed serially just as they always have."

And registers get loaded and memory gets accessed and updated just as it always has, but the circumstances and the environment are NOT the same
as it always was. I covered it at length in some pages on the PRIMA web
site which are referenced in other posts here.

Not all programs execute serially, and there is a big difference between thinking in terms of code execution and thinking in terms of application functionality. (They both have their place.)

The FACT is that the OO approach is particularly suited to at least one paradigm which traditionally centralized processing is not: Event
oriented programming.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files

3NF is nothing to do with OO... It is part of the Relational Model
proposed by Codd and Date in the early 1980s.

However, when using an ORB to access an RDB from an OO instance, it is
best if the DB is normalized, because that minimizes the need for
redundant fields.

Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

This is just food for thought

A maybe list of chapter headings from a book on OO design is not
necessarily a definitive description of OO design or OO programming.

OO is no more "obfuscated" than any other computer technique.

Some people still write APL. To a normal Human Being that could
reasonably be called "obfuscated", but to someone who knows the language
it is a masterpiece of succinct elegance.

You could say the same about Regular expressions... People who use them
see no obfuscation; people who don't, get irritated by their power and
the fact that what would take many lines of COBOL can be done with a
single statement.

Cheers,

Pete.

(PS The fact that we disagree does not mean I have intended to cause you affront or flame you, Greg. My opinion is what it is and you asked for thoughts. There is nothing ad hominem here. Some people in this forum
seem to be offended easily so I'm making this disclaimer.)
--
I used to write COBOL; now I can do anything...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 10/14/2018 02:49 AM, Greg Wallace wrote:

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files
Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

This is just food for thought
Cobol Greg

I agree completely. And a major part of the second part is
choosing the right tools for the job, including the language.
Newer is not always better and complicated doesn't simplify.

bill

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files
Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

This is just food for thought
Cobol Greg

Re OO OBFUSCATION
Pete, thanks for the response and no offence taken and no offence being given. It is a discussion.
So you seem to be saying these are not REALLY important (as terms).
Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

Does that just mean you ignore the obfuscating nature and just work with a new syntax? What is different in practical terms? What does OO Programming do for you that is special?

There are many books on the subject that try to explain these obfuscating terms. OO Programming was sold to the programming community on the basis of these new terms. It was a new Paradigm. COBOL OO was one of many that purists said was not pure OO.
Java quickly became popular because it started as OO. It also tends to start with 'Public Static Void'. How obscure is that.
Also: Why Java is not 100% object oriented language?
Java is not because it supports Primitive datatype such as int, byte, long... etc, to be used, which are not objects. Contrast with a pure OOP language like Smalltalk, where there are no primitive types, and boolean, int and methods are all objects. ... No, Java is not purely object oriented language.
Is not the above just getting deeper into obfuscation?
Cobol Greg
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Sunday, October 14, 2018 at 7:49:12 PM UTC+13, Greg Wallace wrote:

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

That is like claiming that the French only speak their own language to obfuscate what they are saying (actually that might be true!).
Those terms describe real things being done by the computer language. In many ways OOP overcomes problems in computer languages, mainly in C and Pascal and derivatives, that COBOL didn't suffer from. Or at least, the problems didn't arise in the types of applications that COBOL was typically used for.
Some years ago, in 2005, I posted a comparison between coding a module, rawprint, in COBOL85 and in OO COBOL of the Fujitsu variety. It may be instructive for you to read the thread and study the differences in the two sets of code.
https://groups.google.com/forum/#!searchin/comp.lang.cobol/rawprint/comp.lang.cobol/QfKHRvD-A2Y/virQJAFAmoAJ

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

Interactive programs do not necessarily execute 'serially'. There is a difference between the program determining the order of execution (based on data item values) and the user, via the UI, determining the order that the program executes code.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files
Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

I agree with Pete that it may be 'design' but that doesn't mean it is OO-design.

This is just food for thought
Cobol Greg

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, October 15, 2018 at 2:48:18 AM UTC+13, Bill Gunshannon wrote:

Newer is not always better and complicated doesn't simplify.

In order to understand OO you need to understand the problems that it solves. Those problems, to a large extent, did not exist in COBOL because of the types of applications it was used for. COBOL batch processing was done with 'serial reuse-ability'. That is: the programs mostly used, and reused, record buffers and arrays and stepped through the data record by record.
With OO, objects are not generally reused, they are created and discarded as needed. This overcomes the problem, eg, of having just one record buffer for a file. When processing an invoice, eg, an object can be created for every item line in the invoice so that discounts or taxes can be applied when all the items have been read. In COBOL this might be done in an array, but that array is fixed length and an invoice might exceed that.
Of course creating and discarding objects takes processing time, so COBOL may run faster with its fixed arrays and record buffers being reused, and thus be more appropriate.
Where OO does simplify is when language such as C needs to be extended to, say, use complex numbers. In C an expression can use +,-,*, etc like a COMPUTE, but these only work for int, float, etc. If, however, you wanted to have a complex number, or a long decimal, or a BCD, then you could write a group of subroutines to deal with this but you couldn't write longdec_result = longdec_a + 45, it would have to call longdec_add_int(longdec_result, longdec_a, 45);. There would have to be routine for every combination of types, operator and result required.
By writing the long decimal routines as a class and creating an object for each long decimal number the operators (+,-,*,etc) can be overloaded in the class to define what is to happen (method) for each combination of operands and required results. While the class itself is very complicated, having many parts, it makes the writing of the code using the class very much easier.
COBOL doesn't have that particular problem as much: decimal, binary, fixed point, floating can all be mixed in a COMPUTE and the compiler sorts it out.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, October 15, 2018 at 4:38:11 AM UTC+13, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files
Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines
Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

This is just food for thought
Cobol Greg

Re OO OBFUSCATION

Pete, thanks for the response and no offence taken and no offence being given. It is a discussion.

So you seem to be saying these are not REALLY important (as terms).
Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

Does that just mean you ignore the obfuscating nature and just work with a new syntax? What is different in practical terms? What does OO Programming do for you that is special?

There are many books on the subject that try to explain these obfuscating terms. OO Programming was sold to the programming community on the basis of these new terms. It was a new Paradigm. COBOL OO was one of many that purists said was not pure OO.

Java quickly became popular because it started as OO. It also tends to start with 'Public Static Void'. How obscure is that.

'public static void' is not obscure at all to the target audience of C programmers.

Also: Why Java is not 100% object oriented language?
Java is not because it supports Primitive datatype such as int, byte, long... etc, to be used, which are not objects. Contrast with a pure OOP language like Smalltalk, where there are no primitive types, and boolean, int and methods are all objects. ... No, Java is not purely object oriented language.

Is not the above just getting deeper into obfuscation?

'Primitive datatypes' might be faster than objects. With Java there is the int datatype and also an Integer class so you can have primitive int, or an Integer object which wraps an int. The object is useful because it includes methods which make it easier to use.

Cobol Greg

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.

The context is Commercial Programming which usually involves Transaction Processing and usually money.

Object Oriented Programming involves terms like:
Polymorphism
Inheritance
Objects and Methods
Encapsulation
Polymorphism and Overloading
Members
Classes
Class Members and Instance Members
Inheritance

These are just obfuscating terms.

Programs execute serially and the programmer should think in these terms and not in the above abstract terms.

The better thing is Object Oriented Design and I could write a book about this.

Object Oriented Design involves terms like:
File and field naming conventions
3rd form normalised files
Reusable components
Copy Modules
Backend or Black Box programs that are called by many front ends
Common business logic is captured by Black Box programs or common routines Standard program structures. I can name two that provide 90% of all commercial programming
Discrete components.

This is just food for thought
Cobol Greg

I am getting some good responses and I prefer people with a Cobol background to tell me about OO programming. I have followed Richard's link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO programming.

OO-design is little understood. If you search Google you get more obfuscation. I have used it for 30 years without giving it a name. I really need to write extensively to explain what I am talking about.

I agree with Pete that 3rd Form Normalised is not unique to OO-design but it one of those great concepts. I suspect SQL databases enforce it.

I'll ask another question. Do you go with OO Programming because it is prevalent and acceptable or because it is the better way?

Cobol is not acceptable these days due to misconceptions, misunderstandings and bad marketing from the main providers.

Cobol Greg


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol background to tell me about OO programming. I have followed Richard's link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO programming.

OO-design is little understood. If you search Google you get more obfuscation. I have used it for 30 years without giving it a name. I really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer
who told me that OO-design was more important than using an
OO-programming language. His position was that a good OO-design could
be implemented in a non-OO-programming language.

I agree with Pete that 3rd Form Normalised is not unique to OO-design but it one of those great concepts. I suspect SQL databases enforce it.

I'll ask another question. Do you go with OO Programming because it is prevalent and acceptable or because it is the better way?

I think OO-Programming is a little bit of a fad, but then Structured Programming was also a fad and it is still useful in its domain.

My guess is that many programming problems can be solved either
procedurally or in an Object-Oriented manner.

Here's an old (1987) critique of OO-Programming that might have some entertainment value:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1989/8912/8912g/8912g.htm

https://tinyurl.com/y7mmhp5p

It seems to me that OO-programming is most prevalent and most useful in Graphical User Interface (GUI) programming, where the program must
respond to events like mouse clicks and key-presses and must know the
context where the mouse is located or the key is pressed.

Many years ago I took a class in programming in Microsoft Visual BASIC.
For me the frustrating part was not being able to see the entire program
as a single source code file (what I was used to). But that wasn't
really needed for GUI programming. Essentially the program was "drawn"
by connecting objects (combo-box, drop down list, etc.) on a design
screen, and the BASIC code was little subroutines that responded to a
mouse click or key press in a certain context. That's the event-driven nature.

I've done event-driven programming in assembler, POST-ing and WAIT-ing
for events handling network messages. It can be done in a procedural language, but it's a different kind of programming. It seemed
conceptually harder to me, especially when waiting for any one event to
be posted from a list of multiple events. That's essentially what
happens when a GUI program responds to a user input.

Naturally I'm more comfortable with procedural programming than OO,
based on my previous COBOL experience. Even a pseudo-conversational
CICS COBOL program with screens has to respond to user interface events,
but it is still primarily procedural.

Cobol is not acceptable these days due to misconceptions, misunderstandings and bad marketing from the main providers.

Cobol Greg

COBOL has never been popular in academia. It's designed to solve
business financial accounting problems and it's a very good tool for
that, although not the only tool. But financial accounting is not at
all interesting or sexy in Computer Science departments.

Just my opinion, and I'm sure I have a lot to learn.

Kind regards,
--
https://www.arnoldtrembley.com/

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, October 15, 2018 at 4:58:36 PM UTC+13, Arnold Trembley wrote:

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol background to tell me about OO programming. I have followed Richard's link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO programming.

OO-design is little understood. If you search Google you get more obfuscation. I have used it for 30 years without giving it a name. I really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer
who told me that OO-design was more important than using an
OO-programming language. His position was that a good OO-design could
be implemented in a non-OO-programming language.

Of course. C++ was originally implemented as 'C-with-classes' by a pre-processor called cfront. cfront output normal C code which could be compiled by a standard C compiler. A programmer could have written the C code directly if he had a mind to. The C compiler outputs machine code. An assembler programmer could have written that directly too, who needs compilers ?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Sun, 14 Oct 2018 23:15:30 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

On Monday, October 15, 2018 at 4:58:36 PM UTC+13, Arnold Trembley wrote:

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol background to tell me about OO programming. I have followed Richard's link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO programming.

OO-design is little understood. If you search Google you get more obfuscation. I have used it for 30 years without giving it a name. I really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer
who told me that OO-design was more important than using an
OO-programming language. His position was that a good OO-design could
be implemented in a non-OO-programming language.

Of course. C++ was originally implemented as 'C-with-classes' by a pre-processor called cfront. cfront output normal C code which could be compiled by a standard C compiler. A programmer could have written the C code directly if he had a mind to. The C compiler outputs machine code. An assembler programmer could have written that directly too, who needs compilers ?

cfront output was hard to read and probably impossible to write. Some
samples are here:
http://www.cpptips.com/c++_c_output
Louis
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 10/14/2018 11:58 PM, Arnold Trembley wrote:

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace  wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol
background to tell me about OO programming. I have followed Richard's
link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO
programming.

OO-design is little understood. If you search Google you get more
obfuscation. I have used it for 30 years without giving it a name. I
really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer
who told me that OO-design was more important than using an
OO-programming language.  His position was that a good OO-design could
be implemented in a non-OO-programming language.

Of course it can. This should be obvious from the fact that many
of the original OO languages, C++, OOPascal and even Ada, started
out being translated to C and then being compiled with a standard
C compiler.

I agree with Pete that 3rd Form Normalised is not unique to OO-design
but it one of those great concepts. I suspect SQL databases enforce it.

I'll ask another question. Do you go with OO Programming because it is
prevalent and acceptable or because it is the better way?

I think OO-Programming is a little bit of a fad, but then Structured Programming was also a fad and it is still useful in its domain.

OO is much more of a fad but it was pushed by the academics who had
a captive audience who could easily be forced to accept it (or fail
their needed courses!!)

My guess is that many programming problems can be solved either
procedurally or in an Object-Oriented manner.

All programming problems can be solved with either OO or procedural
solutions. The problem is the modern notion that only OO is
acceptable.

Here's an old (1987) critique of OO-Programming that might have some entertainment value:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1989/8912/8912g/8912g.htm

https://tinyurl.com/y7mmhp5p

It seems to me that OO-programming is most prevalent and most useful in Graphical User Interface (GUI) programming, where the program must
respond to events like mouse clicks and key-presses and must know the context where the mouse is located or the key is pressed.

The most known GUI systems in the business pre-date OO by a very
long time.

Many years ago I took a class in programming in Microsoft Visual BASIC.
For me the frustrating part was not being able to see the entire program
as a single source code file (what I was used to).  But that wasn't
really needed for GUI programming.  Essentially the program was "drawn"
by connecting objects (combo-box, drop down list, etc.) on a design
screen, and the BASIC code was little subroutines that responded to a
mouse click or key press in a certain context.  That's the event-driven nature.

This "let's hide everything from the programmer" is what leads to the obfuscation claims. Might work when things go smoothly but when things
start to go south, watch out.

I've done event-driven programming in assembler, POST-ing and WAIT-ing
for events handling network messages.  It can be done in a procedural language, but it's a different kind of programming.  It seemed
conceptually harder to me, especially when waiting for any one event to
be posted from a list of multiple events.  That's essentially what
happens when a GUI program responds to a user input.

Naturally I'm more comfortable with procedural programming than OO,
based on my previous COBOL experience.  Even a pseudo-conversational
CICS COBOL program with screens has to respond to user interface events,
but it is still primarily procedural.

And the answer you get for that is that CICS is anachronistic and
shouldn't even still be in existence.

Cobol is not acceptable these days due to misconceptions,
misunderstandings and bad marketing from the main providers.

Cobol Greg

COBOL has never been popular in academia.

Sorry, but it was. At one time all schools taught COBOL, if not
for mainstream CS courses definitely for CIS courses. It was the
advent of OOP and the refusal of the COBOL world to drink the Kool-
Aid that led to the academic demise of COBOL. (I know, I was there
at the time and watched it happen while fighting it all the way
down.)

It's designed to solve
business financial accounting problems and it's a very good tool for
that, although not the only tool.  But financial accounting is not at
all interesting or sexy in Computer Science departments.

The reasons were much more pedantic than that. It was the COBOL
worlds refusal to accept that academia knows all that led to this
attack.

Just my opinion, and I'm sure I have a lot to learn.

Kind regards,

The only good news is that every day I learn of more and more
segments of the business that still rely on COBOL and know it
is not going away any time soon. And I have watched a lot of
languages fade in to oblivion without the direct attacks that
COBOL has withstood during this time. I expect COBOL to still
be going strong when they finally plant me in the ground.

bill

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 10/15/2018 03:04 AM, Louis Krupp wrote:

On Sun, 14 Oct 2018 23:15:30 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

On Monday, October 15, 2018 at 4:58:36 PM UTC+13, Arnold Trembley wrote:

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol background to tell me about OO programming. I have followed Richard's link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO programming.

OO-design is little understood. If you search Google you get more obfuscation. I have used it for 30 years without giving it a name. I really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer >>> who told me that OO-design was more important than using an
OO-programming language. His position was that a good OO-design could
be implemented in a non-OO-programming language.

Of course. C++ was originally implemented as 'C-with-classes' by a pre-processor called cfront. cfront output normal C code which could be compiled by a standard C compiler. A programmer could have written the C code directly if he had a mind to. The C compiler outputs machine code. An assembler programmer could have written that directly too, who needs compilers ?

cfront output was hard to read and probably impossible to write. Some
samples are here:

http://www.cpptips.com/c++_c_output

It was never intended for humans to read or write. And not the only
example. There have been numerous COBOL generators (I worked with
SCORE many years ago and Tandy had one at one time, too!) You were
expected to make any modification to the original Source and not
try to tweak the generated COBOL. I am sure there were other languages
as well. (Well, RATFOR but the output from that was as readable as any
other Fortran. :-)

bill

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, October 16, 2018 at 2:13:40 AM UTC+13, Bill Gunshannon wrote:

On 10/14/2018 11:58 PM, Arnold Trembley wrote:

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace  wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol
background to tell me about OO programming. I have followed Richard's
link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO
programming.

OO-design is little understood. If you search Google you get more
obfuscation. I have used it for 30 years without giving it a name. I
really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer who told me that OO-design was more important than using an
OO-programming language.  His position was that a good OO-design could
be implemented in a non-OO-programming language.

Of course it can. This should be obvious from the fact that many
of the original OO languages, C++, OOPascal and even Ada, started
out being translated to C and then being compiled with a standard
C compiler.

I agree with Pete that 3rd Form Normalised is not unique to OO-design
but it one of those great concepts. I suspect SQL databases enforce it.

I'll ask another question. Do you go with OO Programming because it is
prevalent and acceptable or because it is the better way?

I think OO-Programming is a little bit of a fad, but then Structured Programming was also a fad and it is still useful in its domain.

OO is much more of a fad but it was pushed by the academics who had
a captive audience who could easily be forced to accept it (or fail
their needed courses!!)

That sounds more like dogma than a rational argument.

My guess is that many programming problems can be solved either procedurally or in an Object-Oriented manner.

All programming problems can be solved with either OO or procedural solutions. The problem is the modern notion that only OO is
acceptable.

That sounds more like dogma than a rational argument.
In fact there are several other current different paradigms which are not OO, such as functional programming or Process-oriented programming.

Here's an old (1987) critique of OO-Programming that might have some entertainment value:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1989/8912/8912g/8912g.htm

https://tinyurl.com/y7mmhp5p

It seems to me that OO-programming is most prevalent and most useful in Graphical User Interface (GUI) programming, where the program must
respond to events like mouse clicks and key-presses and must know the context where the mouse is located or the key is pressed.

The most known GUI systems in the business pre-date OO by a very
long time.

The first acknowledged OO programming language was Simula-67 and that number is the year. Even the Alto was in the next decade.

Many years ago I took a class in programming in Microsoft Visual BASIC. For me the frustrating part was not being able to see the entire program as a single source code file (what I was used to).  But that wasn't really needed for GUI programming.  Essentially the program was "drawn" by connecting objects (combo-box, drop down list, etc.) on a design screen, and the BASIC code was little subroutines that responded to a mouse click or key press in a certain context.  That's the event-driven nature.

This "let's hide everything from the programmer" is what leads to the obfuscation claims. Might work when things go smoothly but when things
start to go south, watch out.

OO doesn't hide everything, in fact it often supports reflection which exposes the interface. You could assert that 'modular programming' "hides everything" compared to having _all_ the code in one huge source file (such as some old COBOL programs) but that is the point: you create modules, or classes, that work correctly and assemble these to solve the problem rather than rewriting everything each time.

I've done event-driven programming in assembler, POST-ing and WAIT-ing
for events handling network messages.  It can be done in a procedural language, but it's a different kind of programming.  It seemed conceptually harder to me, especially when waiting for any one event to
be posted from a list of multiple events.  That's essentially what happens when a GUI program responds to a user input.

Naturally I'm more comfortable with procedural programming than OO,
based on my previous COBOL experience.  Even a pseudo-conversational
CICS COBOL program with screens has to respond to user interface events, but it is still primarily procedural.

And the answer you get for that is that CICS is anachronistic and
shouldn't even still be in existence.

Cobol is not acceptable these days due to misconceptions,
misunderstandings and bad marketing from the main providers.

Cobol Greg

COBOL has never been popular in academia.

Sorry, but it was. At one time all schools taught COBOL, if not
for mainstream CS courses definitely for CIS courses. It was the
advent of OOP and the refusal of the COBOL world to drink the Kool-
Aid that led to the academic demise of COBOL. (I know, I was there
at the time and watched it happen while fighting it all the way
down.)

Schools teach what industry wants. Industry wanted better productivity. COBOL, or more particularly, COBOL programmers when measured by LOC to solve a problem, were well behind 'modern' languages.

It's designed to solve
business financial accounting problems and it's a very good tool for
that, although not the only tool.  But financial accounting is not at
all interesting or sexy in Computer Science departments.

The reasons were much more pedantic than that. It was the COBOL
worlds refusal to accept that academia knows all that led to this
attack.

Just my opinion, and I'm sure I have a lot to learn.

Kind regards,

The only good news is that every day I learn of more and more
segments of the business that still rely on COBOL and know it
is not going away any time soon. And I have watched a lot of
languages fade in to oblivion without the direct attacks that
COBOL has withstood during this time. I expect COBOL to still
be going strong when they finally plant me in the ground.

bill

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, October 15, 2018 at 8:04:52 PM UTC+13, Louis Krupp wrote:

On Sun, 14 Oct 2018 23:15:30 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

On Monday, October 15, 2018 at 4:58:36 PM UTC+13, Arnold Trembley wrote:

On 10/14/2018 7:10 PM, Greg Wallace wrote:

On Sunday, 14 October 2018 16:49:12 UTC+10, Greg Wallace wrote:

I may get some flak here but am interested in opinions.
(snip)

I am getting some good responses and I prefer people with a Cobol background to tell me about OO programming. I have followed Richard's link and saved it as text for closer perusal. Also absorbing responses.

I wonder if you can just use dot points as to why you prefer OO programming.

OO-design is little understood. If you search Google you get more obfuscation. I have used it for 30 years without giving it a name. I really need to write extensively to explain what I am talking about.

I don't really understand OO-programming, or OO-design, but about 20
years ago I had an interesting conversation with a very smart programmer >> who told me that OO-design was more important than using an
OO-programming language. His position was that a good OO-design could
be implemented in a non-OO-programming language.

Of course. C++ was originally implemented as 'C-with-classes' by a pre-processor called cfront. cfront output normal C code which could be compiled by a standard C compiler. A programmer could have written the C code directly if he had a mind to. The C compiler outputs machine code. An assembler programmer could have written that directly too, who needs compilers ?

cfront output was hard to read and probably impossible to write. Some
samples are here:

http://www.cpptips.com/c++_c_output

I wasn't suggesting that a programmer would have written code that matched the cfront output, but he could have achieved the same effect in a more readable way, though with much more effort, and probably many macros.

Louis

--- Synchronet 3.20a-Linux NewsLink 1.114