Re: Java apps have most flaws, Cobol is cleanest.

2011-12-13 Thread John Gilmore
The line

> Automatic, LIFO dynamic storage IS readily available in PL/I . . .

in my post is literal nonsense.  It should be

> Automatic, LIFO dynamic storage IS readily available in COBOL . . .

David Crayford wrote:

> I'm a rare bird in the z/OS sense in that I code in C++. I'm lucky enough to 
> have linked
> lists, sets, trees, vectors, queues, stacks, hash tables - not to mention 
> algorithms  as
> part of the standard library.

These C++  Standard-Library routines vary widely in quality, as do the
[vanilla] C Standard-Library routines.  Some are superb per se, and
others are mediocre.  They all have the defect of specialism.  In
working systems queues, say, are often imperfect examples of the ideal
type 'queue'; one must occasionally, for example, perform operations
more appropriate to a stack on them; and as soon as such requirements
arise their defects become apparent and their virtues disappear.
Reusability is desirable and possible, but C++ has not achieved it
meaningfully.

C++ programmers often accuse C (and other) programmers of writing
things that are "too procedural"; and in my view C++ is "too
declarative"; but discussions of this sort are seldom productive: they
turn into religious warfare.

All statement-level procedural languages share one generic defect:
They embody a particular episteme, a world view that makes some
questions meaningful and tractable and others, if not quite
meaningless, intractable, hard to talk about, because no conceptual
machinery for treating them is made available.

This, finally, is the rationale for resorting to assembly language.
It provides an escape from the parochial.   The Scots poet Blair noted
that archangelic visits to the earth, needed to keep things in order
here below, were and by implication could be "short and far between";
and this is not a bad description of the rationale for
assembly-language subroutines.

Blair's line is usually mangled to come out "few and far between",
which is repetitive or worse; and I imagine that what I have just
written will be misrepresented too; but I expect that.

John Gilmore, Ashland, MA 01721 - USA

On 12/12/11, David Crayford  wrote:
> On 13/12/2011 6:48 AM, John Gilmore wrote:
>> I was aware of the presence of ALLOCATE and FREE in the 'new' COBOL
>> standard
>>
>> This thread has wandered far from its initial topic, and perhaps it is
>> time to let it expire quietly.  Frank likes variable-length tables.  I
>> agree that self-defining tables like those achievable with the
>> ALLOCATE and REFER of PL/I are desirable, but linked lists are
>> essential; and until COBOL can do them it will not, in my view, have
>> any proper claim to be classified as an adult language: move-mode
>> processing schemes are juvenilia at their best.
>
> There are examples in the LE manuals on how to process linked lists in
> COBOL
> http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ceea200/cobbls.htm.
> If the language supports pointers and memory management then you can
> have linked lists.
>
> I'm a rare bird in the z/OS sense in that I code in C++. I'm lucky
> enough to have linked lists, sets, trees, vectors, queues, stacks, hash
> tables - not to mention algorithms  as part of the standard
> library. And they have been implemented by experts with PHDs in computer
> science (dinkumware). And I do trust them to implement top quality
> libraries.
>
> Without COBOL the mainframe is essentially dead as we know it. MAINFRAME
> = COBOL.
>
>
>> Differences of this kind are one of the chief reasons why languages
>> continue to get bigger and bigger.  As Justice Holmes put it long ago,
>> "If you like diamonds and I like rubies we have just three options:
>> battle, compromise, or a jeweler who has both"; and the jeweler who
>> has both is obviously the politic choice.
>>
>> --jg
>>
>> On 12/12/11, Frank Swarbrick  wrote:
>>> ALLOCATE and FREE are part of the 2002 COBOL international standard
>>> (ISO/IEC
>>> 1989:2002); a standard which IBM has made no commitment to implement...
>>>
>>> While certainly useful if you would like to build linked lists, I
>>> personally
>>> would much prefer dynamic-length tables and dynamic-length "strings".
>>>
>>> Frank
>>>
>>>
>>>
>>>
>>>> 
>>>> From: John Gilmore
>>>> To: IBM-MAIN@bama.ua.edu
>>>> Sent: Monday, December 12, 2011 1:26 PM
>>>> Subject: Re: Java apps have most flaws, Cobol is cleanest.
>>>>
>>>> Automatic, LIFO dynamic storage IS 

Re: Java apps have most flaws, Cobol is cleanest.

2011-12-12 Thread David Crayford

On 13/12/2011 6:48 AM, John Gilmore wrote:

I was aware of the presence of ALLOCATE and FREE in the 'new' COBOL standard

This thread has wandered far from its initial topic, and perhaps it is
time to let it expire quietly.  Frank likes variable-length tables.  I
agree that self-defining tables like those achievable with the
ALLOCATE and REFER of PL/I are desirable, but linked lists are
essential; and until COBOL can do them it will not, in my view, have
any proper claim to be classified as an adult language: move-mode
processing schemes are juvenilia at their best.


There are examples in the LE manuals on how to process linked lists in 
COBOL 
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ceea200/cobbls.htm.
If the language supports pointers and memory management then you can 
have linked lists.


I'm a rare bird in the z/OS sense in that I code in C++. I'm lucky 
enough to have linked lists, sets, trees, vectors, queues, stacks, hash 
tables - not to mention algorithms  as part of the standard
library. And they have been implemented by experts with PHDs in computer 
science (dinkumware). And I do trust them to implement top quality 
libraries.


Without COBOL the mainframe is essentially dead as we know it. MAINFRAME 
= COBOL.




Differences of this kind are one of the chief reasons why languages
continue to get bigger and bigger.  As Justice Holmes put it long ago,
"If you like diamonds and I like rubies we have just three options:
battle, compromise, or a jeweler who has both"; and the jeweler who
has both is obviously the politic choice.

--jg

On 12/12/11, Frank Swarbrick  wrote:

ALLOCATE and FREE are part of the 2002 COBOL international standard (ISO/IEC
1989:2002); a standard which IBM has made no commitment to implement...

While certainly useful if you would like to build linked lists, I personally
would much prefer dynamic-length tables and dynamic-length "strings".

Frank






From: John Gilmore
To: IBM-MAIN@bama.ua.edu
Sent: Monday, December 12, 2011 1:26 PM
Subject: Re: Java apps have most flaws, Cobol is cleanest.

Automatic, LIFO dynamic storage IS readily available in PL/I in the
form of local storage.  In my experience it is not much used because
misunderstood: people who attempted, uninstructed, to use it early on
were dismayed when they discovered that successive subroutine calls
did not  leave it in its last-used state.

Based, non-LIFO dynamic storage that does persist in last-used state
is available in COBOL only via LE calls.  (As I mentioned in another
post these services are easy to rename perspicuously.)

This situation may change.  IBM would object, strongly and correctly,
to the notion that there is some sort of implicit promise embedded in
its choices, but it is interesting to note that among the keywords not
yet used in Enterprise COBOL but reserved for possible future use are
two,

ALLOCATE and FREE,

that are suggestive, at least to anyone who knows PL/I.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-12 Thread Shmuel Metz (Seymour J.)
In
,
on 12/12/2011
   at 03:26 PM, John Gilmore  said:

>Automatic, LIFO dynamic storage IS readily available in PL/I in the
>form of local storage.  In my experience it is not much used because
>misunderstood: people who attempted, uninstructed, to use it early on
>were dismayed when they discovered that successive subroutine calls
>did not  leave it in its last-used state.

Most of the PL/I code that I've seen uses AUTOMATIC. Most of the PL/I
programmers that I've met know about STATIC.

BTW, if you need a LIFO stack that's not coupled to the control stack,
there's CONTROLLED.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-12 Thread John Gilmore
I was aware of the presence of ALLOCATE and FREE in the 'new' COBOL standard

This thread has wandered far from its initial topic, and perhaps it is
time to let it expire quietly.  Frank likes variable-length tables.  I
agree that self-defining tables like those achievable with the
ALLOCATE and REFER of PL/I are desirable, but linked lists are
essential; and until COBOL can do them it will not, in my view, have
any proper claim to be classified as an adult language: move-mode
processing schemes are juvenilia at their best.

Differences of this kind are one of the chief reasons why languages
continue to get bigger and bigger.  As Justice Holmes put it long ago,
"If you like diamonds and I like rubies we have just three options:
battle, compromise, or a jeweler who has both"; and the jeweler who
has both is obviously the politic choice.

--jg

On 12/12/11, Frank Swarbrick  wrote:
> ALLOCATE and FREE are part of the 2002 COBOL international standard (ISO/IEC
> 1989:2002); a standard which IBM has made no commitment to implement...
>
> While certainly useful if you would like to build linked lists, I personally
> would much prefer dynamic-length tables and dynamic-length "strings".
>
> Frank
>
>
>
>
>>
>> From: John Gilmore 
>>To: IBM-MAIN@bama.ua.edu
>>Sent: Monday, December 12, 2011 1:26 PM
>>Subject: Re: Java apps have most flaws, Cobol is cleanest.
>>
>>Automatic, LIFO dynamic storage IS readily available in PL/I in the
>>form of local storage.  In my experience it is not much used because
>>misunderstood: people who attempted, uninstructed, to use it early on
>>were dismayed when they discovered that successive subroutine calls
>>did not  leave it in its last-used state.
>>
>>Based, non-LIFO dynamic storage that does persist in last-used state
>>is available in COBOL only via LE calls.  (As I mentioned in another
>>post these services are easy to rename perspicuously.)
>>
>>This situation may change.  IBM would object, strongly and correctly,
>>to the notion that there is some sort of implicit promise embedded in
>>its choices, but it is interesting to note that among the keywords not
>>yet used in Enterprise COBOL but reserved for possible future use are
>>two,
>>
>>ALLOCATE and FREE,
>>
>>that are suggestive, at least to anyone who knows PL/I.
>>
>>
>>John Gilmore, Ashland, MA 01721 - USA
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>
>>
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-12 Thread Frank Swarbrick
ALLOCATE and FREE are part of the 2002 COBOL international standard (ISO/IEC 
1989:2002); a standard which IBM has made no commitment to implement...

While certainly useful if you would like to build linked lists, I personally 
would much prefer dynamic-length tables and dynamic-length "strings".

Frank




>
> From: John Gilmore 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Monday, December 12, 2011 1:26 PM
>Subject: Re: Java apps have most flaws, Cobol is cleanest.
> 
>Automatic, LIFO dynamic storage IS readily available in PL/I in the
>form of local storage.  In my experience it is not much used because
>misunderstood: people who attempted, uninstructed, to use it early on
>were dismayed when they discovered that successive subroutine calls
>did not  leave it in its last-used state.
>
>Based, non-LIFO dynamic storage that does persist in last-used state
>is available in COBOL only via LE calls.  (As I mentioned in another
>post these services are easy to rename perspicuously.)
>
>This situation may change.  IBM would object, strongly and correctly,
>to the notion that there is some sort of implicit promise embedded in
>its choices, but it is interesting to note that among the keywords not
>yet used in Enterprise COBOL but reserved for possible future use are
>two,
>
>ALLOCATE and FREE,
>
>that are suggestive, at least to anyone who knows PL/I.
>
>
>John Gilmore, Ashland, MA 01721 - USA
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-12 Thread John Gilmore
Automatic, LIFO dynamic storage IS readily available in PL/I in the
form of local storage.  In my experience it is not much used because
misunderstood: people who attempted, uninstructed, to use it early on
were dismayed when they discovered that successive subroutine calls
did not  leave it in its last-used state.

Based, non-LIFO dynamic storage that does persist in last-used state
is available in COBOL only via LE calls.  (As I mentioned in another
post these services are easy to rename perspicuously.)

This situation may change.  IBM would object, strongly and correctly,
to the notion that there is some sort of implicit promise embedded in
its choices, but it is interesting to note that among the keywords not
yet used in Enterprise COBOL but reserved for possible future use are
two,

ALLOCATE and FREE,

that are suggestive, at least to anyone who knows PL/I.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-12 Thread Frank Swarbrick
Sorry, Steve, I was referring not to dynamic allocation using outside services 
(LE or CICS), but rather the fact that (Enterprise) COBOL doesn't natively 
support dynamic (memory) allocation.
Frank




>
> From: Steve Comstock 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Friday, December 9, 2011 5:00 PM
>Subject: Re: Java apps have most flaws, Cobol is cleanest.
> 
>On 12/9/2011 4:48 PM, Frank Swarbrick wrote:
>> Kind of a non sequitur.  COBOL programs (I am a COBOL programmer) do little 
>> in the way of dynamic allocation, thus no GC required.
>> (Not that I wouldn't like some dynamic allocation in COBOL...)
>> Frank
>> 
>
>It's there for you to use:
>
>  http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm
>  http://www.trainersfriend.com/COBOL_Courses/d704descr.htm
>  http://www.trainersfriend.com/COBOL_Courses/D725descrpt.htm
>
>
>-- 
>Kind regards,
>
>-Steve Comstock
>The Trainer's Friend, Inc.
>
>303-355-2752
>http://www.trainersfriend.com
>
>* To get a good Return on your Investment, first make an investment!
>  + Training your people is an excellent investment
>
>* Try our tool for calculating your Return On Investment
>    for training dollars at
>  http://www.trainersfriend.com/ROI/roi.html
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-11 Thread Shmuel Metz (Seymour J.)
In
,
on 12/10/2011
   at 09:57 PM, John Gilmore  said:

>Shmuel's egregiously out-of-context comments

FSVO out of context unknown to dictionaries.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-10 Thread John Gilmore
Shmuel's egregiously out-of-context comments on my latest post have
finally exhausted my patience.

I have put him on my kill list.

He is and should be free to comment on what I post, but I no longer
judge it worthwhile to look that those comments.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-10 Thread Shmuel Metz (Seymour J.)
In
,
on 12/09/2011
   at 05:10 PM, John Gilmore  said:

>I have known such programmers too; and it is a fair criticism of
>COBOL as it is currently used that---apart from not yet implemented
>new-standard language extensions---it makes this necessary.

AFAIK the language extensions for writing more structured COBOL
programs are fairly long in the tooth. Is there really a current
compiler that can't handle, e.g., IF-THEN-ELSE?


>The comment about FORTRAN is just rhetoric, misconceived for
>FORTRANs later than FORTRAN II. 

Hogwash. FORTRAN IV isn't that much better than FORTRAN II. It wasn't
until FORTRAN 77 that it ceased being a leper.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-10 Thread Steve Comstock

On 12/9/2011 7:05 PM, John Gilmore wrote:

Steve Comstock's point is well made/taken.

If you use IBM Enterprise COBOL you are inescapably in an LE
environment.  You are paying for its overheads whether or not you use
its very flexible facilities for allocating and freeing
dynamic---stack|heap---storage.  Why not then use them?

I don't know that Steve has in fact done this, but they are easy to
package as COBOL functions having perspicuous names.  The COBOL
preprocessor is still a rudimentary thing, but it is well up to that.

John Gilmore, Ashland, MA 01721 - USA


John, I'm unclear on your last paragraph:


1. What are you refering to as 'they' when you say:

   "they are easy to package as COBOL functions"


2. What do you mean by 'package as COBOL functions',
   for that matter?


3. What COBOL preprocessor?


Mystified in Denver.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Shane
On Fri, 9 Dec 2011 21:40:23 -0800 Edward Jaffe wrote:

...
> Java is often written by pimply-faced college kids
> who can only fix bugs they can recreate in a debugger.

So, if the GC was doing its job properly, there'd be nothing left ?.
A cut too close to the bone.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Edward Jaffe

On 12/8/2011 1:52 PM, Ian wrote:

Interesting article on clean code study.
COBOL scored the highest on security while .NET scored the lowest.


Security was not the issue being studied. Rather, the study focused on 
"problematic programming that violates good architectural and coding practices."



Link to Computer world news article:
http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most-flaws-cobol-apps-least-study-finds/


Most COBOL is probably written in large, mainframe environments where production 
outages hurt the business, testing and quality are ingrained in the culture, and 
post-mortem debugging is well-understood. Java is often written by pimply-faced 
college kids who can only fix bugs they can recreate in a debugger. It might be 
that Java written by mainframe programmers is of quality comparable to that of 
COBOL.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread John Gilmore
Steve Comstock's point is well made/taken.

If you use IBM Enterprise COBOL you are inescapably in an LE
environment.  You are paying for its overheads whether or not you use
its very flexible facilities for allocating and freeing
dynamic---stack|heap---storage.  Why not then use them?

I don't know that Steve has in fact done this, but they are easy to
package as COBOL functions having perspicuous names.  The COBOL
preprocessor is still a rudimentary thing, but it is well up to that.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Frank Swarbrick
Kind of a non sequitur.  COBOL programs (I am a COBOL programmer) do little in 
the way of dynamic allocation, thus no GC required.  (Not that I wouldn't like 
some dynamic allocation in COBOL...)
Frank




>
> From: Barry Merrill 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Friday, December 9, 2011 8:29 AM
>Subject: Re: Java apps have most flaws, Cobol is cleanest.
> 
>A couple of years ago at SHARE, in a mostly-Java-folks session, 
>I asked the IBM speaker why Java architected Garbage Collection
>(which I first encountered in Basic on my TRS-80, when a ham
>radio logging program stopped for 6 minutes in the middle of
>a contest), and his reply was that that was done because Java
>programmers didn't know how much memory their program needed, 
>so I asked if that meant that COBOL programmers were smarter 
>than Java programmers.
>
>Barry
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
>Of Sambataro, Anthony (NIH/NBS) [E]
>Sent: Friday, December 09, 2011 6:34 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Java apps have most flaws, Cobol is cleanest.
>
>I'm unclear as to whether the COBOL code had fewer errors or cost less to
>fix each problem, or both?
>
>-Original Message-
>From: Ian [mailto:pcs...@gmail.com]
>Sent: Thursday, December 08, 2011 4:53 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Java apps have most flaws, Cobol is cleanest.
>
>Interesting article on clean code study.
>COBOL scored the highest on security while .NET scored the lowest.
>
>Link to Computer world news article:
>http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most
>-flaws-cobol-apps-least-study-finds/
>
>(If the link does not fold right, follow the links from here:
>http://www.cicsworld.com/node/4252)
>
>Ian
>http://www.cicsworld.com
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email
>to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
>archives at http://bama.ua.edu/archives/ibm-main.html
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email
>to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
>archives at http://bama.ua.edu/archives/ibm-main.html
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Steve Comstock

On 12/9/2011 4:48 PM, Frank Swarbrick wrote:

Kind of a non sequitur.  COBOL programs (I am a COBOL programmer) do little in 
the way of dynamic allocation, thus no GC required.
(Not that I wouldn't like some dynamic allocation in COBOL...)
Frank



It's there for you to use:

  http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm
  http://www.trainersfriend.com/COBOL_Courses/d704descr.htm
  http://www.trainersfriend.com/COBOL_Courses/D725descrpt.htm


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread John Gilmore
The statements

> I have known of programmers who would never use the value of a relational 
> expression
> other than in an IF statement.

"You can code FORTRAN in any language."

require comment.

I have known such programmers too; and it is a fair criticism of COBOL
as it is currently used that---apart from not yet implemented
new-standard language extensions---it makes this necessary.

The comment about FORTRAN is just rhetoric, misconceived for FORTRANs
later than FORTRAN II.  FORTRAN IV, introduced in the middle 60s, and
its sequelæ all have logical variables and operators for negation,
disjunction and conjunction.  One can set a logical variable in an
assignment statement and use it later, in other logical assignment
statements or in IF statements.

The more general notion that one can bring the habits and idioms
appropriate to one statement-level procedural language into another
SLPL is unexceptionable if banal.  I have seen COBOL written by
someone whose métier was clearly RPG; I have seen LISP quite obviously
written by someone whose métier was COBOL; and anyone with significant
experience reading other people's code could multiply such examples.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Paul Gilmartin
On Fri, 9 Dec 2011 14:30:48 -0500, Shmuel Metz (Seymour J.) wrote:

>In <3132780518416856.wa.paulgboulderaim@bama.ua.edu>, on
>12/09/2011
>   at 12:14 PM, Paul Gilmartin said:
>
>>IMO, function point analysis measures not the complexity of a
>>problem, but the complexity of an imputed solution to the problem.
>
>I've only seen the term used in conjunction with the problem
>definition, not in conjunction with the code.
> 
Problem:  Generate a proof of the Four Color Theorem.

How many function points?

(I said "solution", not "code".)

>"You can code FORTRAN in any language."
> 
Indeed.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Rick Fochtman

--
As someone who did most of his coding in COBOL (my modifications to 
other code in Assembler are on the CBT tape), I treat this article with 
great suspicion. I might add that probably a higher percentage of Java 
programmers have a computer science or related degree than do COBOL 
programmers. As one who doesn't have that degree, I am skeptical of its 
value for most business programming.

---
In my admittedly limited experience, that degree in "Computer Science" 
is just another piece of paper for "The Facility".


There may be many highly intelligent people who have that degree; I just 
haven't met any.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Shmuel Metz (Seymour J.)
In <3132780518416856.wa.paulgboulderaim@bama.ua.edu>, on
12/09/2011
   at 12:14 PM, Paul Gilmartin  said:

>IMO, function point analysis measures not the complexity of a
>problem, but the complexity of an imputed solution to the problem.

I've only seen the term used in conjunction with the problem
definition, not in conjunction with the code.

>I have known of programmers who would never use the
>value of a relational expression other than in an IF
>statement. 

"You can code FORTRAN in any language."
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Paul Gilmartin
On Fri, 9 Dec 2011 12:50:05 -0500, Shmuel Metz (Seymour J.) wrote:
>
>Cost per function point might have been more meaningful.
>
IMO, function point analysis measures not the complexity
of a problem, but the complexity of an imputed solution to
the problem.  Consider the Rexx snippets:

B = if X==y then 1
 else 0
if B==1 then whatever = string
 else whatever = ''

versus:

B = (X==y)
   whatever = copies( string, B )

Do these contain the same number of function points?  The
former appears to contain at least one more branch than
the latter.

I have known of programmers who would never use the
value of a relational expression other than in an IF
statement.  Or who will use no construct in language
X unless language Y supports the same construct.  In
POSIX shell, they'd code:

S0
RC=$?
if test $RC -eq 0
then S1
else S2
fi

(and then they complain about the complexity of shell
coding.)  Where I code:

if S0
then S1
else S2
fi

(but it is the same number of function points.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Shmuel Metz (Seymour J.)
In <5369454423078321.wa.pcs305gmail@bama.ua.edu>, on 12/08/2011
   at 03:52 PM, Ian  said:

>Interesting article on clean code study.

More for what it omits than for what it says.

>COBOL scored the highest on security while .NET scored the lowest.

Security? The article compares repair cost per line of code. Given
that COBOL code tends to be more verbose, I'm not sure what that
means. Cost per function point might have been more meaningful.

I'd have been interested in how Ada, C, C++ and PL/I ranked.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Steve Comstock

On 12/9/2011 9:32 AM, John Gilmore wrote:

Gary Merrill writes


A couple of years ago at SHARE, in a mostly-Java-folks session, I
asked the IBM speaker why Java architected Garbage Collection . . . ,
and his reply was that that was done because Java programmers didn't
know how much memory their program needed,
so I asked if that meant that COBOL programmers were smarter than Java
programmers.


I am not sure that I would not look at language characteristics first.

COBOL aggregates are compile-time bound.  If you decide in a COBOL AP
that you want to process multiple vehicles in, say, an automotive
insurance one you also decide that you will also process, say, at most
10 vehicles and implicitly allocate storage for them at compile time.

In Java, on the other hand, open-ended lists may be and are frequently
used instead; their dynamic storage usage is in principle impossible
to determine, except in the not very helpful sense that use of a
two-byte signed binary counter limits the maximal number of vehicles
or the like to 2^15 -1 = 32767.  (The sense in which Java  is
'pointerless' is a very literal one.  It has mostly adequate
surrogates for pointers.)

Note that I am aware that list processing is now possible in COBOL,
but in my parochial experience it is only done in COBOL when I do it
to show that it is possible.


Not only is list _processing_ possible, list _creation_ is also
possible in current COBOL, with the help of LE callable services.

But, alas, you're right: although I think many COBOL programmers
would be interested in doing this if it made sense in the application,
my experience is that most COBOL programmer _managers_ do not want to
take the chance(?) of challenging their staff, so they don't train them
and they may even forbid them from using the newer features.

Instead of using COBOL, where memory management can be done clearly
and explicitly, they would rather hire Java coders, who have no
control on memory management and very little understanding of what's
really going on in either the JVM or the underlying z/OS system.

There is very little chance of changing that, I'm afraid. So it
is what it is, and we soldier on.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread John Gilmore
"Gary Merrill" sholuld be "Barry Merrill" in my previous post.  Mea
culpa maxima.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread John Gilmore
Gary Merrill writes


A couple of years ago at SHARE, in a mostly-Java-folks session, I
asked the IBM speaker why Java architected Garbage Collection . . . ,
and his reply was that that was done because Java programmers didn't
know how much memory their program needed,
so I asked if that meant that COBOL programmers were smarter than Java
programmers.


I am not sure that I would not look at language characteristics first.

COBOL aggregates are compile-time bound.  If you decide in a COBOL AP
that you want to process multiple vehicles in, say, an automotive
insurance one you also decide that you will also process, say, at most
10 vehicles and implicitly allocate storage for them at compile time.

In Java, on the other hand, open-ended lists may be and are frequently
used instead; their dynamic storage usage is in principle impossible
to determine, except in the not very helpful sense that use of a
two-byte signed binary counter limits the maximal number of vehicles
or the like to 2^15 -1 = 32767.  (The sense in which Java  is
'pointerless' is a very literal one.  It has mostly adequate
surrogates for pointers.)

Note that I am aware that list processing is now possible in COBOL,
but in my parochial experience it is only done in COBOL when I do it
to show that it is possible.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Martin Packer
Barry,  well *I* wouldn't have given you that answer. I'd've waffled on 
about java being a pointerless language and object lifecycles being 
something not to leave to programmers to attempt to manage. But then I've 
already today described javascript (not to be confused with...) :-) as 
"delightfully feral". :-) But then I'm an "off message" IBMer at the best 
of times. :-)

Cheers, Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:
Barry Merrill 
To:
IBM-MAIN@bama.ua.edu, 
Date:
09/12/2011 15:39
Subject:
Re: Java apps have most flaws, Cobol is cleanest.
Sent by:
IBM Mainframe Discussion List 



A couple of years ago at SHARE, in a mostly-Java-folks session, 
I asked the IBM speaker why Java architected Garbage Collection
(which I first encountered in Basic on my TRS-80, when a ham
radio logging program stopped for 6 minutes in the middle of
a contest), and his reply was that that was done because Java
programmers didn't know how much memory their program needed, 
so I asked if that meant that COBOL programmers were smarter 
than Java programmers.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
Of Sambataro, Anthony (NIH/NBS) [E]
Sent: Friday, December 09, 2011 6:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Java apps have most flaws, Cobol is cleanest.

I'm unclear as to whether the COBOL code had fewer errors or cost less to
fix each problem, or both?

-Original Message-
From: Ian [mailto:pcs...@gmail.com]
Sent: Thursday, December 08, 2011 4:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Java apps have most flaws, Cobol is cleanest.

Interesting article on clean code study.
COBOL scored the highest on security while .NET scored the lowest.

Link to Computer world news article:
http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most

-flaws-cobol-apps-least-study-finds/

(If the link does not fold right, follow the links from here:
http://www.cicsworld.com/node/4252)

Ian
http://www.cicsworld.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread John Gilmore
One of the classics of American social science is a multivolume work
by Samuel A. Stouffer, et al., 'The American soldier'.

It reports on the views and attitudes of the American
soldiers---chiefly of the "enlisted men", most of whom were in fact
draftees---who fought WWII in Europe and Asia.  One of its early
findings was that in the European theater job satisfaction was
inversely related to grade.   Master sergeants were very much less
satisfied with their situations than privates.

This struck Stouffer and his colleagues as odd, and one of them had
the wit to cross-tabulate these results against length of service in
Europe.  (In the jargon this is called "controlling for' a variable.)
The findings disappeared.  Master sergeants having, say, six months
service in Europe were much more satisfied with their situations than
were privates who had been in Europe for the same length of time.  The
apparent primary result was an artefact (sic) of the fact that
enlisted men of higher grade had also been in Europe longer.

The 'chief scientist' of the organization that conducted the research
that found COBOL APs to be cleaner than Java APs conjectures that this
is probably related to the fact that the COBOL APs are older, much
older.  This is 'insightful' of him, but it is also irresponsible.  He
should have 'controlled for' AP age and reported his results.

Field studies of programming and programming-language usage are in
principle possible.  How not?  I have never, however, seen one that
was not at once tendentious and incompetent.

Studies of this kind belong in the airlines' in-flight magazines, or
would do so if the airlines had not mostly stopped printing them.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Barry Merrill
A couple of years ago at SHARE, in a mostly-Java-folks session, 
I asked the IBM speaker why Java architected Garbage Collection
(which I first encountered in Basic on my TRS-80, when a ham
radio logging program stopped for 6 minutes in the middle of
a contest), and his reply was that that was done because Java
programmers didn't know how much memory their program needed, 
so I asked if that meant that COBOL programmers were smarter 
than Java programmers.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Sambataro, Anthony (NIH/NBS) [E]
Sent: Friday, December 09, 2011 6:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Java apps have most flaws, Cobol is cleanest.

I'm unclear as to whether the COBOL code had fewer errors or cost less to
fix each problem, or both?

-Original Message-
From: Ian [mailto:pcs...@gmail.com]
Sent: Thursday, December 08, 2011 4:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Java apps have most flaws, Cobol is cleanest.

Interesting article on clean code study.
COBOL scored the highest on security while .NET scored the lowest.

Link to Computer world news article:
http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most
-flaws-cobol-apps-least-study-finds/

(If the link does not fold right, follow the links from here:
http://www.cicsworld.com/node/4252)

Ian
http://www.cicsworld.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-09 Thread Sambataro, Anthony (NIH/NBS) [E]
I'm unclear as to whether the COBOL code had fewer errors or cost less to fix 
each problem, or both?

-Original Message-
From: Ian [mailto:pcs...@gmail.com] 
Sent: Thursday, December 08, 2011 4:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Java apps have most flaws, Cobol is cleanest.

Interesting article on clean code study.
COBOL scored the highest on security while .NET scored the lowest.

Link to Computer world news article:
http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most-flaws-cobol-apps-least-study-finds/

(If the link does not fold right, follow the links from here:
http://www.cicsworld.com/node/4252)

Ian
http://www.cicsworld.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Java apps have most flaws, Cobol is cleanest.

2011-12-08 Thread Clark Morris
On 8 Dec 2011 13:56:59 -0800, in bit.listserv.ibm-main you wrote:

>Interesting article on clean code study.
>COBOL scored the highest on security while .NET scored the lowest.
>
>Link to Computer world news article:
>http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most-flaws-cobol-apps-least-study-finds/

As someone who did most of his coding in COBOL (my modifications to
other code in Assembler are on the CBT tape), I treat this article
with great suspicion.  I might add that probably a higher percentage
of Java programmers have a computer science or related degree than do
COBOL programmers.  As one who doesn't have that degree, I am
skeptical of its value for most business programming.

Clark Morris 
>
>(If the link does not fold right, follow the links from here:
>http://www.cicsworld.com/node/4252)
>
>Ian
>http://www.cicsworld.com
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html