Cobol - Cobol work?

Author

Cobol work?

Martik

2005-10-14, 6:55 pm

Just discovered this group.

I was not aware anyone used Cobol anymore. Is there a (telecommuting) market
for a 'retired' Cobol programmer?

2005-10-14, 6:55 pm

In article <9OV3f.23230$S4.19969@edtnps84>, Martik <xxxxxxxxxx@yyy.net> wrote:
>Just discovered this group.
>
>I was not aware anyone used Cobol anymore. Is there a (telecommuting) market
>for a 'retired' Cobol programmer?

'Active' ones have been asking this for a few years, as well... and, to
the best of my experience, such jobs are few and far between, usually
going to someone the Boss knows very, *very* well.

Oh... nice to have you aboard, also.

DD

Martik

2005-10-14, 6:55 pm

<docdwarf@panix.com> wrote in message news:dip9ho$ej2$1@reader2.panix.com...
> In article <9OV3f.23230$S4.19969@edtnps84>, Martik <xxxxxxxxxx@yyy.net>
> wrote:
>
> 'Active' ones have been asking this for a few years, as well... and, to
> the best of my experience, such jobs are few and far between, usually
> going to someone the Boss knows very, *very* well.
>
> Oh... nice to have you aboard, also.
>
I checked out dice.com but most were on-location 'jobs'. Not interested in
going back to the office grind but it would be fun to do a little Cobol
programming. Wishful thinking.....

My last exposure to Cobol involved mirroring a legacy financial app to
mirror output to an Oracle DB for sql reporting tools.

Prior to that I had written many financial apps on everything from
mainframes to mini's usually on proprietary file systems.

2005-10-14, 9:55 pm

In article <cdW3f.23234$S4.14235@edtnps84>, Martik <xxxxxxxxxx@yyy.net> wrote:
>
><docdwarf@panix.com> wrote in message news:dip9ho$ej2$1@reader2.panix.com...
>I checked out dice.com but most were on-location 'jobs'.

This has been my experience, as well; most folks, from what I've seen, not
only want the code written but they want to, at any given moment, be able
to hear the keyboards and count the 'noses and assholes'. Were I feeling
unkind I'd call this a close-minded and inappropriate holdover from an
industrial/Taylorite mindset...

.... but usually I just say 'They sign the paychecks, they make the rules.'

>Not interested in
>going back to the office grind but it would be fun to do a little Cobol
>programming. Wishful thinking.....

Hey, if you're gonna wish, wish *big*!

>
>My last exposure to Cobol involved mirroring a legacy financial app to
>mirror output to an Oracle DB for sql reporting tools.

My last exposure to COBOL is... my current one, working on a payroll
system that's composed, mainly, of batch programs in a style that's old
enough to vote.

>
>Prior to that I had written many financial apps on everything from
>mainframes to mini's usually on proprietary file systems.

Prior to this I've done... whatever who is signing the checks has told me
to do, for the most part, and in a way which has earned me the sobriquet
of (echo chamber on) CCCCAAAAPPPPTTTAAAAIIIINNNNN... COBOL... OBOl...
OBol... Obol. In my spare time I tend to wander the streets and collect
spit; would you care to see my collection of Phlegmish Masters?

(don't worry... soon enough someone else will join this thread and
apologise to you for having the luck of exchanging postings with me as
your introductory experience to the newsgroup)

DD

Martik

2005-10-15, 3:55 am

> (don't worry... soon enough someone else will join this thread and
> apologise to you for having the luck of exchanging postings with me as
> your introductory experience to the newsgroup)
>

You gotta be a wee bit weird to code Cobol nowadays, and old, so no need to
apologize :)

Christopher Pomasl

2005-10-15, 3:55 am

On Sat, 15 Oct 2005 04:23:31 +0000, Martik wrote:

>
>
>
> You gotta be a wee bit weird to code Cobol nowadays, and old, so no need to
> apologize :)

Who you callin' old?
I'm only 41....only....that's fairly young for a COBOL programmer.
I can code assembler too.....ooooooohhhhhhh!

Dodging canes....

CJP

2005-10-15, 7:55 am

In article <7v%3f.24234$Io.5197@clgrps13>, Martik <xxxxxxxxxx@yyy.net> wrote:
>
>
>
>You gotta be a wee bit weird to code Cobol nowadays, and old, so no need to
>apologize :)

Eh? What's that... speak *up*, now, why do people have to mumble so much
nowadays... as for 'weird' I was labelled as such *long* before I started
coding; granted, I cannot speak as to what said labellers are doing now...
but for me Life is Good... and It just keeps Getting Better.

DD

2005-10-15, 7:55 am

In article <pan.2005.10.15.05.57.08.499580@starband.net>,
Christopher Pomasl <pomasl-NOSpam@starband.net> wrote:
>On Sat, 15 Oct 2005 04:23:31 +0000, Martik wrote:

[snip]

>
>Who you callin' old?
>I'm only 41....only....that's fairly young for a COBOL programmer.

Matters of age are, many might say, a bit... relative; when I was in my
late twenties I recall a lass - a trust-fund baby with a fondness for
intoxication - who disappeared for a bit... and then came back on
crutches, having been a passenger in an automobile which had suffered an
accident. As I, too, had spent some time 'on the sticks' (the
motorcycle-accident that gave me my weather-shoulder) I bought her a
ball-and-a-brew and we shared a bit of the Fraternity of the Disabled.
Through the fog of booze and painkillers (legally prescribed, for once!)
she muttered something about changing her life, that she was too young to
be laid up like this, she was only twenty-five...

.... and Wiser, Older Man that I was - by three, four years - I said 'Too
young for this at twenty-five? You wouldn't have said that when you were
seventeen!'... and she furrowed her brow... and laughed, and slurred
'Well, somethin's gotta change...' ... and then she stopped showing up,
perhaps she really *did* make things change... or just found another
neighborhood local, who knows...

.... but anyhow, next Sunday I'm going back to my Alma Mater for the annual
Talk To A Geezer day; it is the school's recent attempt to change how
students get jobs after graduation (and that's a whole 'nother story for a
different thread). Being the independent consultant/contractor/hired gun
that I am I can't offer too much in the way of networking or leads... but
at least I can offer encouragement... and besides, I get to see the campus
again and think 'The stones have no memories...' ... and I get to see the
students again and think 'So young... so thin... so... white!'

DD

Judson McClendon

2005-10-15, 6:55 pm

"Martik" wrote:
>
> I was not aware anyone used Cobol anymore. ...

There's probably still more COBOL code in use than anything else.
Unfortunately, the management of most of the corporations and government
agencies that are still doing their bread and butter daily stuff on COBOL
don't appear to be aware of the fact.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Christopher Pomasl

2005-10-16, 3:55 am

On Sat, 15 Oct 2005 12:28:53 -0500, Judson McClendon wrote:

> "Martik" wrote:
>
> There's probably still more COBOL code in use than anything else.
> Unfortunately, the management of most of the corporations and government
> agencies that are still doing their bread and butter daily stuff on COBOL
> don't appear to be aware of the fact.

I really think that the thing about it is this....
The COBOL code that is out there now is stagnant. It is doing what is
designed for, has its bugs worked out and is a stable base upon which
businesses are running.

Of the code that is be WRITTEN these days the numbers probably favor C and
its various flavors, ++ and # on small systems. People are leveraging
this stability to build new interfaces into old and stable infrastuctures.
So COBOL really is a hidden commodity in that not much progressive work
is being done there BUT it is running the business of the 00's the same
as it ran the business of the 90's which ran the business of the 80's.

Chris
Senior Software Engineer
Computer Associates
BTW, I speak for myself, not the company. I mention the company only for
disclosure of where I'm coming from.

Judson McClendon

2005-10-16, 7:55 am

"Christopher Pomasl" <pomasl-NOSpam@starband.net> wrote:
> Judson McClendon wrote:
>
> I really think that the thing about it is this....
> The COBOL code that is out there now is stagnant. It is doing what is
> designed for, has its bugs worked out and is a stable base upon which
> businesses are running.
>
> Of the code that is be WRITTEN these days the numbers probably favor C
> and its various flavors, ++ and # on small systems. People are leveraging
> this stability to build new interfaces into old and stable infrastuctures.
> So COBOL really is a hidden commodity in that not much progressive work
> is being done there BUT it is running the business of the 00's the same
> as it ran the business of the 90's which ran the business of the 80's.

And the 70's. I agree with you, Chris. The problem with the situation is
that
because this COBOL code is 'invisible' to the Powers That Be, they think it
is
nonexistent or insignificant. We are in the same place as a society,
depending
on a huge number of extremely reliable, very low maintenance engines, that
decides to stop training people to design, build and maintain those engines.
Not smart. Most of the new generation of pointer-clickers building these
glitzy
front-end applications today wouldn't have a clue how to recreate those
huge,
ultra-reliable and efficient, 'invisible' COBOL workhorses. Some very
important knowledge and skills are retiring with my generation, and by the
time
the Important People realize it, I'm afraid the consequences may be bad,
very
bad. That knowledge and skill took decades to learn, and they won't be re-
learned overnight. It's not just the knowledge of COBOL, but the knowledge
of how and why the systems were designed, and how and why they work the
way they do. Today, almost half of all new systems attempted are abandoned
because of cost & time overruns and failure to meet design goals. If such a
situation had been described 20/30 years ago, it would have been ludicrous.
My career started in 1968, and only in the last few years has such a
situation
occurred. What does this say about those great new tools and the wonderful
new talent and paradigms being applied? It says a lot, to me. I just wish it
spoke as clearly to the rest of the IS community.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

2005-10-16, 7:55 am

In article <20051016072630.182$1m@news.newsreader.com>,
Judson McClendon <judmc@sunvaley0.com> wrote:

[snip]

>Today, almost half of all new systems attempted are abandoned
>because of cost & time overruns and failure to meet design goals. If such a
>situation had been described 20/30 years ago, it would have been ludicrous.

Quite right... decades on back I was taught that 70 - 80% of all new
systems were abandoned before completion, folks would have laughed at a
figure as low as 'almost half'.

>My career started in 1968, and only in the last few years has such a
>situation
>occurred.

Our experiences, Mr McClendon, are *very* different.

DD

Judson McClendon

2005-10-16, 6:55 pm

<docdwarf@panix.com> wrote:
> Judson McClendon <judmc@sunvaley0.com> wrote:
>
> [snip]
>
>
> Quite right... decades on back I was taught that 70 - 80% of all new
> systems were abandoned before completion, folks would have laughed at a
> figure as low as 'almost half'.

I would have to see proof to believe such a figure was widely touted in
those days.

>
> Our experiences, Mr McClendon, are *very* different.

Yes, you have obviously worked surrounded by a sea of incompetence. I have
never been involved in, or was immediately aware of, a single project that
was cancelled for those reasons. I've personally been involved in around 70
projects, all successful and met or exceeded design goals. Some did ran over
time and budget, but none grievously so. Only one project I was ever
involved in was cancelled, and it had nothing whatsoever to do with the
software. What kind of "professional" does not know, even remotely, what is
and is not possible in their own field of expertise?
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Michael Wojcik

2005-10-16, 6:55 pm

In article <7v%3f.24234$Io.5197@clgrps13>, "Martik" <xxxxxxxxxx@yyy.net> writes:
>
>
> You gotta be a wee bit weird to code Cobol nowadays, and old, so no need to
> apologize :)

I've met plenty of younger COBOL programmers among our customers,
actually. Not too many fresh out of school, perhaps, but people in
their 30's. COBOL is still very widely used, and there's still a lot
of new development.

"Weird" I'll grant you.

--
Michael Wojcik michael.wojcik@microfocus.com

There are some, who do not understand true enjoyment, will tell you that
rules spoil convivial meetings, and that a merry company becomes a dull
committee as soon as it is called a club. Do not believe them: the
precedents are all against them. -- Arthur Ransome

2005-10-16, 6:55 pm

In article <20051016092917.086$QM@news.newsreader.com>,
Judson McClendon <judmc@sunvaley0.com> wrote:
><docdwarf@panix.com> wrote:
>
>I would have to see proof to believe such a figure was widely touted in
>those days.

I have no idea what would constitute 'proof' for you, Mr McClendon... and
I'll grant that 1987 is a mere 18 years ago so it isn't *quite* 'decades
on back'... but from
http://www.findarticles.com/p/artic...v16/ai_18731983 :

-- begin quoted text

Statistically, the overall IT failure rate is horrendous, and doesn't seem
to be improving. For example, a 1987 study by the Association for
Computing Machinery noted an IT project failure rate of about 75%, while a
study by The Standish Group published in 1995 noted an IT project failure
rate in the 65% to 85% range.

--end quoted text

.... and what a coincidence, the numbers appear to fall rather close to the
range I cited of 70 - 80% that I recall having been taught lo, those many
decades ago... but as I've said before, my memory is, admittedly, porous.

>
>
>Yes, you have obviously worked surrounded by a sea of incompetence.

Not only that, Mr McClendon, but my powers were such so as to direct the
results of an ACM study right into that sea at almost exactly the depth I
was taught to expect... quite the Mighty Coder, aren't I?

>I have
>never been involved in, or was immediately aware of, a single project that
>was cancelled for those reasons. I've personally been involved in around 70
>projects, all successful and met or exceeded design goals. Some did ran over
>time and budget, but none grievously so. Only one project I was ever
>involved in was cancelled, and it had nothing whatsoever to do with the
>software. What kind of "professional" does not know, even remotely, what is
>and is not possible in their own field of expertise?

It appears, Mr McClendon, that our experiences are *very* different... and
what a wonderful thing that is, as well, since otherwise all we'd be able
to do is agree with each other.

DD

HeyBub

2005-10-16, 6:55 pm

Christopher Pomasl wrote:
> On Sat, 15 Oct 2005 12:28:53 -0500, Judson McClendon wrote:
>
>
> I really think that the thing about it is this....
> The COBOL code that is out there now is stagnant. It is doing what is
> designed for, has its bugs worked out and is a stable base upon which
> businesses are running.
>
> Of the code that is be WRITTEN these days the numbers probably favor
> C and its various flavors, ++ and # on small systems. People are
> leveraging this stability to build new interfaces into old and stable
> infrastuctures. So COBOL really is a hidden commodity in that not
> much progressive work is being done there BUT it is running the
> business of the 00's the same as it ran the business of the 90's
> which ran the business of the 80's.

Likewise a great number of novels are written these days, but few novels are
great. The difference between COBOL programming and C++ is the difference
between Beethoven and Bojangles.

"Small systems?" The smallest of systems today are legions more powerful
than the systems on which much COBOL programming took place.

Judson McClendon

2005-10-16, 6:55 pm

<docdwarf@panix.com> wrote:
> Judson McClendon <judmc@sunvaley0.com> wrote:
>
> I have no idea what would constitute 'proof' for you, Mr McClendon... and
> I'll grant that 1987 is a mere 18 years ago so it isn't *quite* 'decades
> on back'... but from
> http://www.findarticles.com/p/artic...v16/ai_18731983 :
>
> -- begin quoted text
>
> Statistically, the overall IT failure rate is horrendous, and doesn't seem
> to be improving. For example, a 1987 study by the Association for
> Computing Machinery noted an IT project failure rate of about 75%, while a
> study by The Standish Group published in 1995 noted an IT project failure
> rate in the 65% to 85% range.
>
> --end quoted text
>
> ... and what a coincidence, the numbers appear to fall rather close to the
> range I cited of 70 - 80% that I recall having been taught lo, those many
> decades ago... but as I've said before, my memory is, admittedly, porous.

Not sure those were "widely touted," but 1995 is well after these "great and
wonderful new toys and techniques" were in full swing.

>
> Not only that, Mr McClendon, but my powers were such so as to direct the
> results of an ACM study right into that sea at almost exactly the depth I
> was taught to expect... quite the Mighty Coder, aren't I?

Question: Is it your own personal experience that somewhere in the range of
3/4 of all systems projects you have been associated with and have direct
knowledge of, have been canned for reasons of cost/time overruns and failure
to meet design goals?

>
> It appears, Mr McClendon, that our experiences are *very* different... and
> what a wonderful thing that is, as well, since otherwise all we'd be able
> to do is agree with each other.

If your experience has been as you are describing (see question above), then
my experience has been exceedingly different.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

2005-10-16, 6:55 pm

In article <20051016185941.183$hP@news.newsreader.com>,
Judson McClendon <judmc@sunvaley0.com> wrote:
><docdwarf@panix.com> wrote:
>
>Not sure those were "widely touted," but 1995 is well after these "great and
>wonderful new toys and techniques" were in full swing.

That might account for the Standish study, Mr McClendon... it does not
account for the ACM study and it does not account for what I recall being
taught before the ACM study... and all of those numbers over all of those
decades are in a rather close ballpark.

>
>
>Question: Is it your own personal experience that somewhere in the range of
>3/4 of all systems projects you have been associated with and have direct
>knowledge of, have been canned for reasons of cost/time overruns and failure
>to meet design goals?

I cannot say, Mr McClendon... my experience is such that most projects
I've been involved with I have not seen from birth to implementation.
What happens most often is that a project will be started and then get
bogged down in Real World details... meanwhile, the fellow who proposed it
with the equivalent of an 'all ya gotta do is' has been promoted someplace
else, the Big 8/5/4 Accounting/Software team has carved a niche for
it'sself and a new manager is bringing in independents - like me - to
end-run around the rapidly ossifying structures.

I'll then remain in place for a few years, humping code and pointing out
essential design flaws, until someone higher up decides that a New Team is
needed... and I get handed my walking-papers. Did it ever get
implemented? No idea.

[snip]

>
>If your experience has been as you are describing (see question above), then
>my experience has been exceedingly different.

I have described my experience, Mr McClendon... as to what has been
implemented, as noted above, I cannot say.

DD

Michael Wojcik

2005-10-17, 6:55 pm

In article <11l5em9nkca7318@news.supernews.com>, "HeyBub" <heybubNOSPAM@gmail.com> writes:
>
> The difference between COBOL programming and C++ is the difference
> between Beethoven and Bojangles.

This is patently absurd. Lousy software can be written in any
language. I've seen plenty of COBOL code that was utter dreck.

--
Michael Wojcik michael.wojcik@microfocus.com

Do not "test" parts, as this may compromise sensitive joinery. Those who
suffer difficulty should abandon the enterprise immediately. -- Chris Ware

Howard Brazee

2005-10-17, 6:55 pm

On 17 Oct 2005 15:45:23 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>
>This is patently absurd. Lousy software can be written in any
>language. I've seen plenty of COBOL code that was utter dreck.

The difference between Beethoven and Bojangles isn't the difference
between good and dreck. Both have their place.

However, a Beethoven symphony with a simple basic tune (#5) is much
more complex when looked at closely. Which leads me to think it might
be the C++. Try to make a real complex program at the level of
Windows XP, and you don't have much choice - even though it looks
simple, it is the complex composition that hopes that one instrument
missing a note doesn't ruin it. CoBOL is simple, direct, and
reliable - but in practice is limited to applications that are simple
and direct - and which have to be reliable.

Judson McClendon

2005-10-17, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote:
>
> ... CoBOL is simple, direct, and
> reliable - but in practice is limited to applications that are simple
> and direct - and which have to be reliable.

I take issue with that middle part, Howard, about COBOL "in practice is
limited to applications that are simple and direct." The tool being simple
and the application being simple are two virtually unrelated issues. I have
written applications, to which COBOL was as well (or better) suited as any
programming language, which are about as difficult and complex as anyone
(meaning me :-) would want to attempt.

I do agree that COBOL is simple and direct (a great strength IMO), and
eminently suitable to create reliable systems. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Ian Dalziel

2005-10-17, 6:55 pm

On 17 Oct 2005 15:45:23 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>
>In article <11l5em9nkca7318@news.supernews.com>, "HeyBub" <heybubNOSPAM@gmail.com> writes:
>
>This is patently absurd. Lousy software can be written in any
>language. I've seen plenty of COBOL code that was utter dreck.

Sure - so have we all.
More to the point, have you seen any C++ code that was legible?
--

Ian

Richard

2005-10-17, 6:55 pm

> have you seen any C++ code that was legible?

Legibility is entirely what one is used to. Sero-Croat looks like hen
scratching to me, they probably think the same of English.

Ian Dalziel

2005-10-17, 6:55 pm

On 17 Oct 2005 10:40:13 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>Legibility is entirely what one is used to. Sero-Croat looks like hen
>scratching to me, they probably think the same of English.

Indeed. I wasn't being entirely serious - you can write clear,
well-structured code in Assembler or Basic, you can write spaghetti
carbonara in COBOL or Pascal. C does rather lend itself to write-only
programs, though!
:-)
--

Ian

Howard Brazee

2005-10-17, 6:55 pm

On Mon, 17 Oct 2005 12:21:09 -0500, "Judson McClendon"
<judmc@sunvaley0.com> wrote:

>
>I take issue with that middle part, Howard, about COBOL "in practice is
>limited to applications that are simple and direct." The tool being simple
>and the application being simple are two virtually unrelated issues. I have
>written applications, to which COBOL was as well (or better) suited as any
>programming language, which are about as difficult and complex as anyone
>(meaning me :-) would want to attempt.

It's all relative. Try writing an application the size of Windows in
CoBOL!

Although I worked in a shop which recently moved from RPGII to CoBOL,
and it had applications that were very unsuited for RPG2. And I've
worked with CoBOL programs that had many thousands of spaghetti code
lines. You work with the tools you have.

>I do agree that COBOL is simple and direct (a great strength IMO), and
>eminently suitable to create reliable systems. :-)

clvrmnky

2005-10-17, 6:55 pm

On 16/10/2005 10:58 AM, Michael Wojcik wrote:
> In article <7v%3f.24234$Io.5197@clgrps13>, "Martik" <xxxxxxxxxx@yyy.net> writes:
>
>
> I've met plenty of younger COBOL programmers among our customers,
> actually. Not too many fresh out of school, perhaps, but people in
> their 30's. COBOL is still very widely used, and there's still a lot
> of new development.
>
> "Weird" I'll grant you.
>
I'm no expert, but the analysts say that knowing web services in the
enterprise _and_ COBOL is a nice combination for the future. I suppose
this means that things like .NET and MQSeries is supposed to grow, and
old-timers who can get up to speed enough to talk to the Java developers
on the other side of the wire might find their mad COBOL skillz much
appreciated.

No surprise, then, that the only reason *I* write any COBOL is because,
well, we had to hook up our enterprise client-server app to a mainframe.
We used COBOL as the glue for that (i.e., not 390 assembler), and I was
chosen to get up to speed and write that code.

My apologies to any COBOL consultants here looking for work, but my
company tends to leverage our own as much as possible. In this case it
was a reasonable move, though it could have gone pear-shaped at a few
points. Astute readers who will have searched for my previous posts on
this newsgroup might find some scary questions from someone who is now
regarded as the "COBOL expert" in the office.

Be afraid. To be fair, we do not sell ourselves as a COBOL shop, and
always recommend that our customers, if they need COBOL assistance, hire
some smart cookies who know what they are doing. I just wrote the glue
code other people can hook into.

The moral of this story is that it helps to have been exposed to a great
number of languages as an impressionable child when handed a COBOL
project and Murachs, and told to come up with a working prototype in a
few w

Judson McClendon

2005-10-17, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote:
>
> It's all relative. Try writing an application the size of Windows in
> CoBOL!

Personally, I would *much* rather maintain 10 (or 50) million lines of COBOL
than 10 million lines of C/C++/Assembly. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Judson McClendon

2005-10-17, 6:55 pm

"Richard" <riplin@Azonic.co.nz> wrote:
>
> Legibility is entirely what one is used to. ...

Not entirely! To a large degree, yes. Not all languages are equally
assimilable by the human mind. You can prove this easily with a simple
thought experiment: Imagine a language where each word contains at least 20
letters and a dozen syllables. And it has been proven that humans do better
with letter based languages than with pictogram type languages, which were
abandoned by everybody but Asians long ago. Some indication of this
particular aptitude of the brain for lettered languages can be seen in that
the following can be fairly easily read:

-----------------------------
I cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The
phaonmneal pweor of the hmuan mnid. Aoccdrnig to rscheearch at Cmabrigde
Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the
olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit
pclae. The rset can be a taotl mses and you can sitll raed it wouthit a
porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by
istlef, but the wrod as a wlohe. Amzanig huh? Yaeh and I awlyas thought
slpeling was ipmorantt !!!! (evne befro slpel ckech)
-----------------------------
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Richard

2005-10-17, 6:55 pm

>> Legibility is entirely what one is used to. ...

> Not entirely! To a large degree, yes. Not all languages are equally
> assimilable by the human mind.

The ones that you are used to are infinitely more assimilable than ones
that you have never seen before, or only infrequently seen.

> You can prove this easily with a simple
> thought experiment: Imagine a language where each word contains at least 20
> letters and a dozen syllables.

So you are saying that if you image something that you have never seen
before it will be difficult to read. Anyway that sounds like German
which is perfectly well read by Germans. All that it means is that
spaces are not put between 'words' as often as English does.

> And it has been proven that humans do better
> with letter based languages than with pictogram type languages,

Nonsense. Humans that are more used to letter based systems do better
with letter based systems than with pictograms. And vice versa. Studies
have shown that a fluent Kanji reader can read a newspaper faster than
an English reader can read the same stories in English.

Where pictogram systems don't work better is where there are 'words'
that are new or have not been seen before. With assembled words it is
possible to work out what they mean sufficiently.

> which were abandoned by everybody but Asians long ago.

What evidence do you have that 'everybody' used pictograms. Europeans
never did.

> Some indication of this particular aptitude of the brain for lettered languages can
> be seen in that the following can be fairly easily read:

Certainly English has a lot of redundancy. That has a negative effect
on programming languages where misspelling and transpositions are not
readily identified by exactly that mechanism.

2005-10-17, 6:55 pm

In article <zqT4f.35459$Lp.18470@bignews5.bellsouth.net>,
Judson McClendon <judmc@sunvaley0.com> wrote:
>"Richard" <riplin@Azonic.co.nz> wrote:
>
>Not entirely! To a large degree, yes. Not all languages are equally
>assimilable by the human mind. You can prove this easily with a simple
>thought experiment: Imagine a language where each word contains at least 20
>letters and a dozen syllables.

With all due respect, Mr McClendon, this might say something more about
one's ability to imagine things than anything else.

>And it has been proven that humans do better
>with letter based languages than with pictogram type languages, which were
>abandoned by everybody but Asians long ago.

.... and there's only, what... two, two-and-a-half billion of 'em?

DD

Michael Wojcik

2005-10-18, 6:55 pm

In article <57j7l150d4hm6ctfsd2chn1ll9v2cs1qj1@4ax.com>, Howard Brazee <howard@brazee.net> writes:
> On 17 Oct 2005 15:45:23 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
> ["HeyBub" wrote:]
>
> The difference between Beethoven and Bojangles isn't the difference
> between good and dreck. Both have their place.

I didn't claim that it was, but point taken. It's not clear to me now
what HeyBub intended by that comment.

> However, a Beethoven symphony with a simple basic tune (#5) is much
> more complex when looked at closely. Which leads me to think it might
> be the C++.

Again, I've seen highly convoluted and complex COBOL programs, and
very simple C++ ones. Even complex systems written in C++ can be
quite clear and simple in source form, particularly if the author
makes good use of the standard library (especially templates).

> CoBOL is simple, direct, and
> reliable - but in practice is limited to applications that are simple
> and direct - and which have to be reliable.

I'm afraid I'll have to disagree. COBOL is not a simple programming
language, as these things go - the 2002 standard is 800+ pages and
leaves 184 elements for implementor definition (so there can be
significant differences among implementations even without exten-
sions); there are hundreds of reserved words; the grammar is complex
and loaded with syntactic sugar (eg abbreviated conditionals).

I don't see any objective measure by which COBOL can be considered
"simple". I'm not sure what "direct" would mean in this context, but
that's not an adjective I'd be inclined to apply either.

And while there are certainly aspects to COBOL which encourage the
use of reliable coding practices (as there are in, say, Ada, but
which are largely lacking in, say, C), and that certainly is to
COBOL's credit, I think it's inaccurate to ascribe reliability to a
programming language. Reliability is a characteristic of a program,
not of the language it's written in. I deal with unreliable COBOL
programs every day.

I'll agree that COBOL is better suited to some things (the things it
was designed for) than it is to others.

--
Michael Wojcik michael.wojcik@microfocus.com

HTML is as readable as C. You can take this either way. -- Charlie Gibbs

Michael Wojcik

2005-10-18, 6:55 pm

In article <hrn7l1daddpu1m368c3mpievfad47tt24v@4ax.com>, Ian Dalziel <iandalziel@lineone.net> writes:
> On 17 Oct 2005 15:45:23 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
> Sure - so have we all.
> More to the point, have you seen any C++ code that was legible?

Yes - quite a lot of it. Some of it I wrote myself, though I work
mostly in C.

There's nothing inherent in C++ which makes code written in it hard
to read. I've read a number of studies of what makes source code
easy or difficult to read, and C++ does not enforce any characteristics
that interfere with reading.

--
Michael Wojcik michael.wojcik@microfocus.com

That's gotta be one of the principles behind reality. Accepting things
that are hard to comprehend, and leaving them that way. And bleeding.
Shooting and bleeding. -- Haruki Murakami (trans Philip Gabriel)

Michael Wojcik

2005-10-18, 6:55 pm

In article <zqT4f.35459$Lp.18470@bignews5.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> writes:
> "Richard" <riplin@Azonic.co.nz> wrote:
>
> Not entirely! To a large degree, yes. Not all languages are equally
> assimilable by the human mind.

Aside from strawman degenerate cases, do you have any evidence that
in practice anyone has demonstrated a significant difference in the
relative comprehensibility of programming languages among seasoned
practitioners?

> And it has been proven that humans do better
> with letter based languages than with pictogram type languages,

Citation?

> which were
> abandoned by everybody but Asians long ago.

So by everyone except a large fraction of the world's population.
Hardly a compelling argument. (And many of the phonemic-symbol
languages were imposed by force on subject populations, not adopted
due to some natural superiority.)

> Some indication of this
> particular aptitude of the brain for lettered languages can be seen in that
> the following can be fairly easily read:
> [Snip the example from the Cambridge word-order study]

And how does this demonstrate that users of logographic languages
(which are not, incidentally, pictographic) cannot cope with
similar misorderings in their languages? Or that, if they cannot,
that this is due to some innate capability in the human brain, and
not, say, lower information entropy (and thus higher redundancy) in
written English as compared to other languages?

--
Michael Wojcik michael.wojcik@microfocus.com

The lark is exclusively a Soviet bird. The lark does not like the
other countries, and lets its harmonious song be heard only over the
fields made fertile by the collective labor of the citizens of the
happy land of the Soviets. -- D. Bleiman

HeyBub

2005-10-18, 6:55 pm

Michael Wojcik wrote:
> In article <11l5em9nkca7318@news.supernews.com>, "HeyBub"
> <heybubNOSPAM@gmail.com> writes:
>
> This is patently absurd. Lousy software can be written in any
> language. I've seen plenty of COBOL code that was utter dreck.

Who said anything about lousy?

I was comparing something of timeless, enduring worth, that uplifts and
ennobles, that is a pean to higher aspirations - the voice of God, if you
will - and something appreciated only in a drug-induced stupor by those who
consider it a virtue to smell bad.

HeyBub

2005-10-18, 6:55 pm

Richard wrote:
>
> Cobol <-> Beethoven ?
>
> I find Beethoven to be overlong, boring, and tedious.
>
> C++ <-> Bojangles ?
>
> Aren't they a chain of chicken restaurants ?

My point exactly.

Martik

2005-10-18, 9:55 pm

"Ian Dalziel" <iandalziel@lineone.net> wrote in message
news:bro7l1tsvhjgtbuclm0lv1sp3lph2sm3mg@
4ax.com...
> On 17 Oct 2005 10:40:13 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
> Indeed. I wasn't being entirely serious - you can write clear,
> well-structured code in Assembler or Basic, you can write spaghetti
> carbonara in COBOL or Pascal. C does rather lend itself to write-only
> programs, though!
> :-)

When I used to program Cobol I insisted on a few simple rules:

1. Comment almost every paragraph.

2. Use standard paragraph and variable naming conventions. ie:
D100-main-process, W010-write-master, P010-print etc.

3. Never use a 'go to' outside a paragraph unless aborting.

4. Review your program design with other programmers before final coding.

Richard

2005-10-19, 3:55 am

Martik wrote:

> 3. Never use a 'go to' outside a paragraph unless aborting.

You seem to have a strange idea about what 'a paragraph' is.

Howard Brazee

2005-10-19, 6:55 pm

On Wed, 19 Oct 2005 02:32:17 GMT, "Martik" <xxxxxxxxxx@yyy.net> wrote:

>
>When I used to program Cobol I insisted on a few simple rules:
>
>1. Comment almost every paragraph.
>
>2. Use standard paragraph and variable naming conventions. ie:
>D100-main-process, W010-write-master, P010-print etc.
>
>3. Never use a 'go to' outside a paragraph unless aborting.
>
>4. Review your program design with other programmers before final coding.

All of those rules can be followed with other languages.

Howard Brazee

2005-10-19, 6:55 pm

On 18 Oct 2005 20:48:22 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>You seem to have a strange idea about what 'a paragraph' is.

The only thing I can figure is that his other 'go to' commands are to
the top of that paragraph. That used to be common practice in the
bad old days.

Ian Dalziel

2005-10-19, 6:55 pm

On Wed, 19 Oct 2005 07:50:34 -0600, Howard Brazee <howard@brazee.net>
wrote:

>On 18 Oct 2005 20:48:22 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
>The only thing I can figure is that his other 'go to' commands are to
>the top of that paragraph. That used to be common practice in the
>bad old days.

Or to a common exit point? (all right, I do know that's another
paragraph)
--

Ian

Michael Wojcik

2005-10-19, 9:55 pm

In article <11la14vtejr947e@news.supernews.com>, "HeyBub" <heybubNOSPAM@gmail.com> writes:
> Michael Wojcik wrote:
>
> Who said anything about lousy?
>
> I was comparing something of timeless, enduring worth, that uplifts and
> ennobles, that is a pean to higher aspirations - the voice of God, if you
> will - and something appreciated only in a drug-induced stupor by those who
> consider it a virtue to smell bad.

I'm afraid this explanation has done nothing to redeem your argument
in my estimation. But thanks for providing it nonetheless.

--
Michael Wojcik michael.wojcik@microfocus.com

John Culleton

2005-10-19, 9:55 pm

Ian Dalziel wrote:

> On 17 Oct 2005 15:45:23 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
> Sure - so have we all.
> More to the point, have you seen any C++ code that was legible?

The matter of style is important here. It is perfectly possible to write in
COBOL
ADD A, B giving C
or even
COMPUTE (C = A + B)

which looks like a FORTRAN family language but you are far more likely to
see

ADD DOLLAR-AMOUNT, SALES-TAX GIVING TOTAL-CHARGES.

COBOL encourages the use of meaningful names, and other languages, at least
the way they are usually taught, don't.

COBOL also encourages meaningful internal documentation, starting with the
(original) IDENTIFICATION DIVISION. Other languages have commenting
mechanisms, but those languages are neutral on the subject. And internal
documentation is not part of the usual teaching method.

So IMO culture as much as specific capabilities encourages readable COBOL.
That was a principal goal of GMH when she conceived the language.

--
John Culleton
Able Indexers and Typesetters

Oliver Wong

2005-10-19, 9:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:OZadnYRVUOPeKcveRVn-ig@adelphia.com...
> COBOL encourages the use of meaningful names, and other languages, at
> least
> the way they are usually taught, don't.

I'm not sure what you mean by this; I've never heard a computer science
teacher say "Don't use meaningful names", while I have heard several
computer science teachers say "(Do) use meaningful names". Some of then even
go so far as to take off marks if your program is "difficult to understand"
in their (incontestable) opinion.

> COBOL also encourages meaningful internal documentation, starting with the
> (original) IDENTIFICATION DIVISION. Other languages have commenting
> mechanisms, but those languages are neutral on the subject. And internal
> documentation is not part of the usual teaching method.

This is true. For many languages I'm familiar with, a documentation
system is usually processed by a third party application, and not the
compiler (e.g. JavaDoc, Doxygen, C#'s XML documentation system, etc.)
However, it seems that the developper's toolset is moving more and more
towards intelligent IDEs, where it starts to become difficult to know where
one tool (e.g. the compiler) ends and another (e.g. the documentation
processor) begins.

> So IMO culture as much as specific capabilities encourages readable COBOL.
> That was a principal goal of GMH when she conceived the language.

As an aside, I was surprised to discover that there actually did exist a
language which seemed to DIScourage meaningful names: The GPSS language had
"arbitrary" lengths for function names and variable (I forget the exact
figures, but it was something like all names had to be between 4 and 8
characters long), and restrictions such as variables whose type were integer
had to start with either I, J or K, and variables whose type were real had
to start with X, Y or Z (all other variables were assumed to be Strings).

I say "arbitrary", but the reason laid in the fact that GPSS programs
were originally written on fixed-grid cards, with column-based areas like
COBOL.

Assuming you wanted an integer, after the I/J/K, you only had 7
characters left with which to name the variable, so variable names were very
rarely meaningful in GPSS programs I've seen and written. To make up for it,
my GPSS programs were often documented liberally. In fact, the combined size
of just the comments often exceeded the size of the code itself.

- Oliver

Richard

2005-10-19, 9:55 pm

> but those languages are neutral on the subject.

Not true. Java for example has JavaDoc specifically for creating
documentation and the language specifies how commenting is to be done.

Python also has specific documentation mechanisms.

Michael Wojcik

2005-10-20, 6:55 pm

In article <4iz5f.37655$S4.20966@edtnps84>, "Oliver Wong" <owong@castortech.com> writes:
> "John Culleton" <john@wexfordpress.com> wrote in message
> news:OZadnYRVUOPeKcveRVn-ig@adelphia.com...
>
> I'm not sure what you mean by this; I've never heard a computer science
> teacher say "Don't use meaningful names", while I have heard several
> computer science teachers say "(Do) use meaningful names".

I think it's a highly suspect claim. It sounds like a generalization
from anecdote. I'd like to see some evidence for it.

>
> This is true. For many languages I'm familiar with, a documentation
> system is usually processed by a third party application, and not the
> compiler (e.g. JavaDoc, Doxygen, C#'s XML documentation system, etc.)

Doxygen is "third party", but Javadoc and the C# documentation system
are part of the standard toolset from the primary vendor.

While C and C++, say, don't standardize an internal documentation
mechanism, Javadoc markup *is* a standard part of Java. Ditto for
the documentation systems of Perl and Python, for example. COBOL is
far from unique in this regard.

And using a separate tool for generating documentation is not a
compelling objection. My COBOL toolchain uses more than one step;
why should any other language be penalized for separating build steps
into separate processes? In fact, I consider that a distinct
advantage of a language implementation.

> However, it seems that the developper's toolset is moving more and more
> towards intelligent IDEs, where it starts to become difficult to know where
> one tool (e.g. the compiler) ends and another (e.g. the documentation
> processor) begins.

Which is precisely why I don't like IDEs - but I don't think they're
relevant to this matter anyway. Incorporating documentation into
source code doesn't depend on IDEs in any significant way. A
developer knows how to use the toolset or doesn't; whether it's
wrapped up in an IDE is inconsequential, at least for questions of
what tools are available.

> As an aside, I was surprised to discover that there actually did exist a
> language which seemed to DIScourage meaningful names: The GPSS language had
> "arbitrary" lengths for function names and variable (I forget the exact
> figures, but it was something like all names had to be between 4 and 8
> characters long), and restrictions such as variables whose type were integer
> had to start with either I, J or K, and variables whose type were real had
> to start with X, Y or Z (all other variables were assumed to be Strings).

Early BASICs had similar requirements.

Strictly-conforming C programs must not exceed the minimum limits
required of all implementations, which means that in the current
(1999) standard internal identifiers have only 63 significant (case-
sensitive) initial characters, and external identifiers have only 31
significant (case-insensitive) initial characters. That's usually
plenty, but prior to the 1999 standard the limits were 31 characters
for internal identifiers and only 6(!) significant initial case-
insensitive characters for external ones.

No one writes strictly-conforming C programs (there's a line of
argument that it's impossible to do so, because of the requirement
that a strictly-conforming program not depend on any implementation-
defined behavior), of course. And since nearly all C implementations
treated considerably more than six characters as significant for
external identifiers, that limit is almost universally ignored. But
you could have a conforming C implementation that treated all
external identifiers beginning with the same six characters as the
same identifier.

But that's not because C discourages meaningful names; it's because
it tries to support as many platforms as possible, including some
old, very limited ones.

--
Michael Wojcik michael.wojcik@microfocus.com

"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_

john@wexfordpress.com

2005-10-20, 6:55 pm

Oliver Wong wrote:
> "John Culleton" <john@wexfordpress.com> wrote in message
> news:OZadnYRVUOPeKcveRVn-ig@adelphia.com...
>
> I'm not sure what you mean by this; I've never heard a computer science
> teacher say "Don't use meaningful names", while I have heard several
> computer science teachers say "(Do) use meaningful names". Some of then even
> go so far as to take off marks if your program is "difficult to understand"
> in their (incontestable) opinion.

I have only documentary evidence, lacking paparazzi shots of
professors' whiteboards:
--------------------------------------------------------
strcmp(s,t) /* return <0 if s<t, 0 if s==t, >0 if s>t */
char *s *t
{
for ( ; *s ==*t; s++ t++)
if (*s == '\0')
return (0);
return (*s - *t);
}
_The C Programming Language_, Kernighan & Ritchie p102
---------------------------------------------------------
set b ""
for {set i [expr [llength $a]-1]} {$1 >=0} {incr i -1{
lappend b[lindex $a $1]
}
_Tcl and the Tk Toolkit_, John Ousterhout p74
---------------------------------------------------
To be fair there are also examples from _Programming Perl_ which make
an effort to use meaningful names. But the general trend is cryptic
rather than readable.

John c.

Volker Bandke

2005-10-20, 6:55 pm

On Mon, 17 Oct 2005 11:45:06 -0600, Howard Brazee <howard@brazee.net>
wrote:

>It's all relative. Try writing an application the size of Windows in
>CoBOL!

And? Your point is? CICS for OS/2 Version 1 was written in COBOL,
and don't tell me CICS is simple, or direct

With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)

Life moves pretty fast, if you don't stop and look around once in a while you can miss it. -- Ferris Bueler in Ferris Bueler'ss Day Off

(Another Wisdom from my fortune cookie jar)

Richard

2005-10-20, 6:55 pm

> I have only documentary evidence, lacking paparazzi shots of
> professors' whiteboards:
> --------------------------------------------------------
> strcmp(s,t) /* return <0 if s<t, 0 if s==t, >0 if s>t */
> char *s *t
> {
> for ( ; *s ==*t; s++ t++)
> if (*s == '\0')
> return (0);
> return (*s - *t);
> }
> _The C Programming Language_, Kernighan & Ritchie p102

What is not readily and immediately understandable in this ?

One of the advantages of local variables and parameters is that they
will not clash with any other part of the code. Replacing s and t
(which are _by_convention_ used as string variable parameters) by
the_first_string and the_second_string would add nothing to the code
other than making it unwieldy.

If you looked at strcpy it would probably have the same s and t, it is
an idiom.

I also noticed immediately on glancing at the code that you had missed
out a comma.

Michael Wojcik

2005-10-21, 6:55 pm

In article <1129839699.197305.4940@g44g2000cwa.googlegroups.com>, john@wexfordpress.com writes:
>
> Oliver Wong wrote:

For that matter, how does COBOL "encourage the use of meaningful
names"? Is there something I've missed in the Standard about
meaningful names?
[color=darkred]
> I have only documentary evidence, lacking paparazzi shots of
> professors' whiteboards:
> --------------------------------------------------------
> strcmp(s,t) /* return <0 if s<t, 0 if s==t, >0 if s>t */
> char *s *t
> {
> for ( ; *s ==*t; s++ t++)
> if (*s == '\0')
> return (0);
> return (*s - *t);
> }
> _The C Programming Language_, Kernighan & Ritchie p102

Leaving aside for the moment the question of whether this is
representative of "how C is usually taught" (particularly since this
example is from the ancient first version of K&R, which has been out
of date for sixteen years), what would be *more* meaningful names for
s and t in this case? Their contents and the uses those will be put
into have no meaning in this function.

You might as well complain that students who are taught the quadratic
formula using the traditional notation with variables a, b, and c are
being discouraged from using meaningful variable names.

[snip Tcl example, which I agree seems unnecessarily terse]

> To be fair there are also examples from _Programming Perl_ which make
> an effort to use meaningful names.

The half-dozen Java books I have on hand all employ verbose,
"meaningful" variable names. That's true of pretty much all the
Java code I've looked at.

> But the general trend is cryptic rather than readable.

This would be the "general trend" demonstrated by two data points
(one of them dubious), and discarding at least one (_Programming
Perl_) that by your own admission doesn't fit the trend?

--
Michael Wojcik michael.wojcik@microfocus.com

[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_

Judson McClendon

2005-10-21, 6:55 pm

"Michael Wojcik" <mwojcik@newsguy.com> wrote:
>
> john@wexfordpress.com writes:
>
> This would be the "general trend" demonstrated by two data points
> (one of them dubious), and discarding at least one (_Programming
> Perl_) that by your own admission doesn't fit the trend?

I have yet to find an organized International Obfuscated COBOL Code
contest, complete with several mirror sites. :-)
http://www.ioccc.org/
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

LX-i

2005-10-21, 9:55 pm

Lueko Willms wrote:
> . On 21.10.05
> wrote judmc@sunvaley0.com (Judson McClendon)
> on /COMP/LANG/COBOL
> in c7d6f.5173$V67.1408@bignews6.bellsouth.net
> about Re: Cobol work?
>
>
> JM> I have yet to find an organized International Obfuscated COBOL Code
> JM> contest, complete with several mirror sites. :-)
> JM> http://www.ioccc.org/
>
> Well, every COBOL shop tries to keep their obfuscation masterpieces
> secret.

heh! :) Thanks for making me spurt coffee out of my nose!

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Lueko Willms

2005-10-22, 7:55 am

.. On 21.10.05
wrote lxi0007@netscape.net (LX-i)
on /COMP/LANG/COBOL
in e78c8$4359a220$45491c57$453@KNOLOGY.NET
about Re: Cobol work?

[color=darkred]

l> heh! :) Thanks for making me spurt coffee out of my nose!

Do you claim intellectual propterty for that, too?

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Nach einem dreißigjährigen Krieg mit sich selbst kam es endlich zu einem Vergleich, aber die Zeit war verloren. -G.C.Lichtenberg

Michael Mattias

2005-10-22, 7:55 am

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:c7d6f.5173$V67.1408@bignews6.bellsouth.net...
>
> I have yet to find an organized International Obfuscated COBOL Code
> contest, complete with several mirror sites. :-)
> http://www.ioccc.org/

But... there was an (singular, one only) International Obfuscated BASIC code
contest - back in 1998. And I ought to know...as evidenced by the email
which follows....

MCM

From: INTERNET:iobcc@ptd.net, INTERNET:iobcc@ptd.net
TO: Michael Mattias, mcmattias
DATE: 5/16/98 9:06 PM
Sender: iobcc@ptd.net
Received: from mail.ptd.net (srv1.ptd.net [204.186.0.131])
by arl-img-4.compuserve.com (8.8.6/8.8.6/2.10) with SMTP id VAA20314
for <mcmattias@compuserve.com>; Sat, 16 May 1998 21:06:27 -0400 (EDT)
Received: (qmail 21451 invoked from network); 17 May 1998 01:05:37 -0000
Received: from du17.scr.ptd.net (204.186.26.17)
by postoffice.ptd.net with SMTP; 17 May 1998 01:05:37 -0000
From: iobcc@ptd.net (International Obfuscated Basic Code Contest)
To: Michael Mattias <mcmattias@compuserve.com>
Subject: Re: Entry
Date: Sun, 17 May 1998 03:05:47 GMT
Organization: IOBCC
Reply-To: iobcc@ptd.net
Message-ID: <355e5290.129513@mail.ptdprolog.net>
References: <199805021604_MC2-3BB5-A941@compuserve.com>
In-Reply-To: <199805021604_MC2-3BB5-A941@compuserve.com>
X-Mailer: Forte Agent 1.5/16.451
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hello Michael,

Thankyou for entering the IOBCC. Believe it or not, you were the
_only_ person to submit an entry. I guess you win. Congratulations.
The IOBCC website will be removed from its server before the end of
the day.

C'ya,
John G.

LX-i

2005-10-22, 7:55 am

Lueko Willms wrote:
> . On 21.10.05
> wrote lxi0007@netscape.net (LX-i)
> on /COMP/LANG/COBOL
> in e78c8$4359a220$45491c57$453@KNOLOGY.NET
> about Re: Cobol work?
>
>
>
>
>
> l> heh! :) Thanks for making me spurt coffee out of my nose!
>
> Do you claim intellectual propterty for that, too?

Remember, I work for the Air Force. It's not "intellectual property",
it's "national security". ;)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

James Johnson

2005-10-22, 9:55 pm

On Mon, 17 Oct 2005 15:03:40 -0500, "Judson McClendon" <judmc@sunvaley0.com>
wrote:

>"Richard" <riplin@Azonic.co.nz> wrote:

Not necessarily. A lot of it was the culture of the code shops.

COBOL shops emphasized documentation in code and controls because this code was
controlling/directing big money throughout the corporation. And that people
were going to have to maintain and modify the code was usually understood from
the very beginning. And undocumented code took longer to fix/modify and
therefore wasted the business's money. Its roots are in business processes.

C and C++ and its syntactical cousins originated in research labs and grad
student programs where code elegance and sparseness were emphasized. And if the
code had some cute function that wasn't obvious then that was better still in
the contest of "who is the most skilled programmer". This resulted in a bias
against documentation as it was against the unwritten standard - that if you
need documentation to understand it then you don't measure up, and putting
documentation in was an insult against good coders.

JJ
[color=darkred]
>
>Not entirely! To a large degree, yes. Not all languages are equally
>assimilable by the human mind. You can prove this easily with a simple
>thought experiment: Imagine a language where each word contains at least 20
>letters and a dozen syllables. And it has been proven that humans do better
>with letter based languages than with pictogram type languages, which were
>abandoned by everybody but Asians long ago. Some indication of this
>particular aptitude of the brain for lettered languages can be seen in that
>the following can be fairly easily read:
>
>-----------------------------
>I cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The
>phaonmneal pweor of the hmuan mnid. Aoccdrnig to rscheearch at Cmabrigde
>Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the
>olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit
>pclae. The rset can be a taotl mses and you can sitll raed it wouthit a
>porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by
>istlef, but the wrod as a wlohe. Amzanig huh? Yaeh and I awlyas thought
>slpeling was ipmorantt !!!! (evne befro slpel ckech)
>-----------------------------

James Johnson
remove the "dot" from after sail in email address to reply

Judson McClendon

2005-10-23, 6:55 pm

See? Only C/C++/Java are biased enough toward obfuscated to make the project
worthwhile. :-)

On the other hand, "languages" (loose use of the word) like APL, RPG, etc.
are so inherently obfuscated they are already "write only languages." Normal
programs written in such languages are so obfuscated already, that no one
can judge whether an attempt was made to purposefully obfuscate them, making
the issue moot. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

"Michael Mattias" <michael.mattias@gte.net> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> But... there was an (singular, one only) International Obfuscated BASIC
> code
> contest - back in 1998. And I ought to know...as evidenced by the email
> which follows....
>
> MCM
>
> Hello Michael,
>
> Thankyou for entering the IOBCC. Believe it or not, you were the
> _only_ person to submit an entry. I guess you win. Congratulations.
> The IOBCC website will be removed from its server before the end of
> the day.
>
> C'ya,
> John G.

Donald Tees

2005-10-23, 6:55 pm

Judson McClendon wrote:
> See? Only C/C++/Java are biased enough toward obfuscated to make the project
> worthwhile. :-)
>
> On the other hand, "languages" (loose use of the word) like APL, RPG, etc.
> are so inherently obfuscated they are already "write only languages." Normal
> programs written in such languages are so obfuscated already, that no one
> can judge whether an attempt was made to purposefully obfuscate them, making
> the issue moot. :-)

Good day, Judson. Been a long time since we have chatted.

I think Lisp is mt favourite for obscurity, though a well written macro
for a text editor could probably beat it out in the long run.

Donald
;< )

Judson McClendon

2005-10-23, 6:55 pm

"Donald Tees" <donald_tees@sympatico.ca> wrote:
> Judson McClendon wrote:
>
> Good day, Judson. Been a long time since we have chatted.
>
> I think Lisp is mt favourite for obscurity, though a well written macro
> for a text editor could probably beat it out in the long run.

Hello back, Donald. :-)

IIRC, Brief had a Lisp-like macro language.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Joe Zitzelberger

2005-10-29, 3:55 am

In article <4iz5f.37655$S4.20966@edtnps84>,
"Oliver Wong" <owong@castortech.com> wrote:

> "John Culleton" <john@wexfordpress.com> wrote in message
> news:OZadnYRVUOPeKcveRVn-ig@adelphia.com...
>
> I'm not sure what you mean by this; I've never heard a computer science
> teacher say "Don't use meaningful names", while I have heard several
> computer science teachers say "(Do) use meaningful names". Some of then even
> go so far as to take off marks if your program is "difficult to understand"
> in their (incontestable) opinion.

There is a common Cobol convention that attempts to remove as much
meaningfulness from names as possible.

It is very common to find programs where EVERY declared variable is
prefixed by "WS-". The effect of such tautologies is only to reduce the
namespace, and thus the possible meaningfulness, by three characters.

But my personal pet peeve is the idea that some people have that a
number provides some form of uniqueness. A common example, using
paragraph names:

1000-READ-FILE.
2000-READ-FILE.

Often the defenders of such crap will staunchly oppose the clear and
meaningful approach of:

READ-MASTER-FILE.
READ-TRANSACTION-FILE.

There was once a (somewhat) useful purpose behind both of these. The
data name prefix did help locate variables when you got your compile
listing back after your deck was submitted. And the numeric prefix on
the labels helped maintain order when the only control structure
available was the GO TO. But that was a long time ago.

Cobol culture and standard practices do anything but encourage
meaningful names, the encourage some level of meaninglessness in support
of conventions that have had no practical purpose for 30 years or so.

Joe Zitzelberger

2005-10-29, 3:55 am

In article <c7d6f.5173$V67.1408@bignews6.bellsouth.net>,
"Judson McClendon" <judmc@sunvaley0.com> wrote:

> "Michael Wojcik" <mwojcik@newsguy.com> wrote:
>
>
> I have yet to find an organized International Obfuscated COBOL Code
> contest, complete with several mirror sites. :-)
> http://www.ioccc.org/

That is because the common convention is to write Cobol with so much
clutter that it is naturally obfuscated.

Just look at the discussions on leaving in all sorts of dated, wasted
space like remarks paragraphs and author/installation statements. Or
the discussions on keeping card punch number in cols 1-6. With all the
noise in some Cobol programs it is downright hard to see what the
actually do.

Lueko Willms

2005-10-29, 7:55 am

.. On 29.10.05
wrote joe_zitzelberger@nospam.com (Joe Zitzelberger)
on /COMP/LANG/COBOL
in joe_zitzelberger-295F9D.00282729102005@ispnews.usenetserver.com
about Re: Cobol work?

JZ> It is very common to find programs where EVERY declared variable is
JZ> prefixed by "WS-". The effect of such tautologies is only to reduce
JZ> the namespace, and thus the possible meaningfulness, by three
JZ> characters.

JZ>
JZ> But my personal pet peeve is the idea that some people have that a
JZ> number provides some form of uniqueness. A common example, using
JZ> paragraph names:
JZ>
JZ> 1000-READ-FILE.
JZ> 2000-READ-FILE.

I remember the colleague who, in a project where I had built the
script to generate a skeleton for all transaction programs with a
SECTION "Process-Input-Data" (or similar name) for the data entered in
the program's form, prefixed all section names with some number. And
in one program he had a "10-Process-Input-Data" and a "11-Process-
Input-Data". No idea what the difference might have been.

JZ> There was once a (somewhat) useful purpose behind both of these. The
JZ> data name prefix did help locate variables when you got your compile
JZ> listing back after your deck was submitted.

The compiler would always generate an alphabetical sorted cross-
reference listing, making such task much easier.

These number-prefixes are one of the main means of obfuscation in a
COBOL program, and a source of error. One little typo in a number, and
whoops, one has an error which is very difficult to find.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Vorstellungen sind auch ein Leben und eine Welt. -G.C.Lichtenberg

Judson McClendon

2005-10-29, 6:57 pm

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> That is because the common convention is to write Cobol with so much
> clutter that it is naturally obfuscated.
>
> Just look at the discussions on leaving in all sorts of dated, wasted
> space like remarks paragraphs and author/installation statements. Or
> the discussions on keeping card punch number in cols 1-6. With all the
> noise in some Cobol programs it is downright hard to see what the
> actually do.

You are obviously kidding. "Noise" like remarks and author and installation
making a program more "obfuscated!" ROTFL

Too bad COBOL doesn't have such crystal clear, never mistaken features such
as '=' vs '=='. And the subtleties of C-style pointers makes COBOL
programmers pine for that type of impossible-to-misunderstand clarity. ROTFL
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Judson McClendon

2005-10-29, 6:57 pm

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote:
>
> It is very common to find programs where EVERY declared variable is
> prefixed by "WS-". The effect of such tautologies is only to reduce the
> namespace, and thus the possible meaningfulness, by three characters.
>
> But my personal pet peeve is the idea that some people have that a
> number provides some form of uniqueness. A common example, using
> paragraph names:
>
> 1000-READ-FILE.
> 2000-READ-FILE.
>
> Often the defenders of such crap will staunchly oppose the clear and
> meaningful approach of:
>
> READ-MASTER-FILE.
> READ-TRANSACTION-FILE.
>
> There was once a (somewhat) useful purpose behind both of these. The
> data name prefix did help locate variables when you got your compile
> listing back after your deck was submitted. And the numeric prefix on
> the labels helped maintain order when the only control structure
> available was the GO TO. But that was a long time ago.
>
> Cobol culture and standard practices do anything but encourage
> meaningful names, the encourage some level of meaninglessness in support
> of conventions that have had no practical purpose for 30 years or so.

I believe you have a limited view, my friend. :-) The reasons above are not
the only ones for those conventions. I do agree that preceding *every*
WORKING STORAGE data item with "WS-" is nutty.

The convention today is to break applications down into very small programs,
but sometimes there are practical reasons of system architecture that make
fewer, larger programs desirable. In an online program that handles 30 or 50
different screens, it makes perfect sense to prefix every paragraph that
handles screen 12, for example, with 12nnnn-, and place '12' in the prefix
of every WORKING STORAGE data item for that screen. In such a program there
may be quite a number of READ-MASTER-FILE paragraphs, all very similar,
though likely not identical, and the '12nnnn-' type of paragraph prefix
identifies them perfectly. And if you have 5000 lines of DATA DIVISION,
prefix of 'WS-' meaning a 77 level can be very useful. Sure, you can find
any data item quickly with your source editor, but why do even that, if the
name can tell what you need to know? This is so simple and powerful, I am
amazed that it isn't very obvious to you.

I sometimes build systems with hundreds of thousands, even millions, of
lines of code and many files. In such a system, I create name and
abbreviation dictionaries so that every word used in data/paragraph names is
spelled or abbreviated in *exactly* the same way in every use. Data names
for the same field never vary, except for a prefix that designates the
record (or "WS-" for 77 levels) containing the field, or when the sense of
the field changes (e.g. Current Balance -> Previous Balance). My systems are
crafted as carefully as I can build them. Nothing is left to chance that I
can prevent, and I go to great lengths to make them understandable and
maintainable. In my whole career (since '68) have never once delivered a
system that a client was less than very happy with, and typically, after
three or four w

s eliminating the few final bugs, I don't hear from the
clients for months or years, until they want something new. Two w

s ago I
fixed a bug in one of my systems that another programmer put there, and
that's the first bug in a deployed system I've fixed for over a year, and
that one was by the same programmer. If you have programming methods that
produce better results than this archaic, out-of-date methodology that I
use, then please tell me about them. :-)

Just because the reason for something isn't obvious to you, doesn't mean
there isn't a reason, even a good one. The real world is messy and chaotic.
Programming real-world applications so that they are clear and
understandable takes hard work, discipline, and careful adherence to
practical methodology, things we see too little of these days. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Rick Smith

2005-10-29, 6:57 pm

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:sVL8f.16208$_31.11321@bignews5.bellsouth.net...
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote:
>
> You are obviously kidding. "Noise" like remarks and author and
installation
> making a program more "obfuscated!" ROTFL

In Russell M. Armstrong, "Modular Progamming in
COBOL," there is a sample program (AP503) in
the Appendix. The program is 22 1/2 pages. The
first 7 1/2 pages is the REMARKS paragraph. The
procedure division is about 11 1/2 pages and NOTE
paragraphs seem to occupy about one-third of that
space. For the most part, the NOTE pargraphs
explain what the following paragraph-group does,
eventhough it is often clear from the code what is
done. I consider this to be a lot of "noise" making
the program less clear, therefore "obfuscated".
But, maybe that is just me! <g>

> Too bad COBOL doesn't have such crystal clear, never mistaken features
such
> as '=' vs '=='. And the subtleties of C-style pointers makes COBOL
> programmers pine for that type of impossible-to-misunderstand clarity.
ROTFL

Of course, the use of INSPECT CONVERTING to
rearrange characters according to their pattern is
always clear (easily understood; without ambiguity)
and obvious (lacking in subtlety)!

Defaultuser

2005-10-30, 3:55 am

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-295F9D.00282729102005@ispnews.usenetserver.com...
> In article <4iz5f.37655$S4.20966@edtnps84>,
> "Oliver Wong" <owong@castortech.com> wrote:
>

Actually - knowing some professors this is becoming less common. Today's
spoiled children do not like being told they are wrong. This leads to two
types of common questions: those with undisputable answers (what is 1 + 1
using standard integer math as taught by me) and those that get marked as
working or not working. In fact these days you get given a set of "test
cases" and it is the passing of those test cases that dictates how well you
did...not any style.
[color=darkred]
> There is a common Cobol convention that attempts to remove as much
> meaningfulness from names as possible.
>
> It is very common to find programs where EVERY declared variable is
> prefixed by "WS-". The effect of such tautologies is only to reduce the
> namespace, and thus the possible meaningfulness, by three characters.

There can sometimes be benefit to using "WS-" versus "LS-" or "DB2-" or
"IMS-" "GL-" "EX-" to state the scope or source. I find the benefit
limiting because for some reason COBOL programmers are obsessive about data
moves and it all ends up being modified everywhere anyway.
I'm not fussed about any naming convention as long as it's accurate. I don't
care if someone uses
lpsz as a long pointer to a null terminated string or not....as long as
that's what it is. I don't ask for much, just consistency.

COBOL mentality...
SELECT INTO :DB-VALUE FROM DB2
MOVE DB-VALUE TO WS-VALUE

Not sure why it now needs to be in yet another variable, but whatever. See
it all the time.

> But my personal pet peeve is the idea that some people have that a
> number provides some form of uniqueness. A common example, using
> paragraph names:
>
> 1000-READ-FILE.
> 2000-READ-FILE.

It also makes for amusement when making code changes.....
1000-READ-FILE
1500-READ-RECORD
1550-PROCESS-RECORD
1555-ADD-DATA-TO-RECORD
1555-POINT-5-ADD-ONE-MORE-THING

hmmmm...then (for the ISPF users)
C all 1000- 10000-
C all 1500- 15000-
C all 1550- 15500-
C all 1555- 15550-

C all 1555-POINT-5- 15555-

All fixed.

> Often the defenders of such crap will staunchly oppose the clear and
> meaningful approach of:
>
> READ-MASTER-FILE.
> READ-TRANSACTION-FILE.

That's good as long as that paragraph is reading the file and doing nothing
more...otherwise it's misleading. Paragraphs that state what they are doing
shouldn't do more than that.

> There was once a (somewhat) useful purpose behind both of these. The
> data name prefix did help locate variables when you got your compile
> listing back after your deck was submitted. And the numeric prefix on
> the labels helped maintain order when the only control structure
> available was the GO TO. But that was a long time ago.
>
> Cobol culture and standard practices do anything but encourage
> meaningful names, the encourage some level of meaninglessness in support
> of conventions that have had no practical purpose for 30 years or so.
I was sarcastic with my statement about COBOL programmers. I sense that you
are not. What documented standard practices are you referring to that do
anything but encourage meaningful names? I think that it's more often to do
with the "cut and paste" nature that exists in most development shops. I've
never written a prolog or identification division or file division in my
life. I copy them. More than likely from someone who is "top-dog" in the
office.

My personal pet peeve is the use of upper case to write all code. I think
that about 70% of reading is performed by "scanning" the shape of the
letters. Uppercase code is harder to read than lower case code which is why
XML generally is mixed/lower case.

IF YOU DONT BELIEVE WHAT I AM SAYING THEN YOU SHOULD CONSIDER HOW MUCH
HARDER IT IS TO READ THIS SHORT SENTENCE PART than it is to read this small
sentence part. The brain is a magical thing....shame we abuse it :-)

D

Defaultuser

2005-10-30, 3:55 am

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:TTN8f.16242$_31.8441@bignews5.bellsouth.net...
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote:
snip

> I sometimes build systems with hundreds of thousands, even millions, of
> lines of code and many files. In such a system, I create name and
> abbreviation dictionaries so that every word used in data/paragraph names
> is spelled or abbreviated in *exactly* the same way in every use.

I'm not sure what "build" means, but in my language that means
compile/link-edit but in context here it means more than that - given that
you create dictionaries and update/create code.

I recently read a book on SAP deployment in which the author had
successfully worked on deploying over 100 instances over 7 years which is
remarkable considering that this is more than one ENTERPRISE software
deployment a month....I thought the same thing of his statement as I did of
yours.

> Data names for the same field never vary, except for a prefix that
> designates the record (or "WS-" for 77 levels) containing the field, or
> when the sense of the field changes (e.g. Current Balance -> Previous
> Balance). My systems are crafted as carefully as I can build them. Nothing
> is left to chance that I can prevent, and I go to great lengths to make
> them understandable and maintainable.
Every author thinks that their novel is great. Turns out it depends on the
reader. I happen to think Citizen Kane is a great movie - but I can find
hundreds who find it tedious. I applaud your efforts - and I do think it
probably results in easier to understand code, but nothing will make a
million lines of code easily maintainable. I also believe that the hardest
bugs to find are the ones that create systematically incorrect but
consistent results. Bug Free code does *not* exist even if you are Phi
Kappa Gamma Six Sigma Black Belt with a CMM level 5 arm band development
organization.
These you never find...they become "business rules" by accident after they
are propagated to the regression test basis.

> In my whole career (since '68) have never once delivered a system that a
> client was less than very happy with, and typically, after three or four
> w

s eliminating the few final bugs, I don't hear from the clients for
> months or years, until they want something new.
I've never seen a client that was anything but less than happy. It's NEVER
cheap or fast enough. Your clients are negotiating weenies :-)

> Two w

s ago I fixed a bug in one of my systems that another programmer
> put there, and that's the first bug in a deployed system I've fixed for
> over a year, and that one was by the same programmer. If you have
> programming methods that produce better results than this archaic,
> out-of-date methodology that I use, then please tell me about them. :-)
> Just because the reason for something isn't obvious to you, doesn't mean
> there isn't a reason, even a good one. The real world is messy and
> chaotic. Programming real-world applications so that they are clear and
> understandable takes hard work, discipline, and careful adherence to
> practical methodology, things we see too little of these days. :-)
> --
> Judson McClendon judmc@sunvaley0.com (remove zero)
> Sun Valley Systems http://sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
DU

Lueko Willms

2005-10-30, 7:55 am

.. On 29.10.05
wrote joe_zitzelberger@nospam.com (Joe Zitzelberger)
on /COMP/LANG/COBOL
in joe_zitzelberger-E34590.00352129102005@ispnews.usenetserver.com
about Re: Cobol work?

JZ> Just look at the discussions on leaving in all sorts of dated, wasted
JZ> space like remarks paragraphs and author/installation statements.

For the human reader it might make no difference if the contents of
such paragraphs is a simple comment opened by an Asterisk in col. 7 or
a *> in free form.

But having such headers makes it easier to process such comments by
a machine, er, a computer program. One could even think of the
compiler putting "Author", "Date-compiled" etc into the compiled
program (please remember that the date of a file can be changed
easily, but its content not).

So, I do rather regret that the named comment paragraphs have been
declared obsolete.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Es gibt eine wahre und eine förmliche Orthographie. -G.C.Lichtenberg

Judson McClendon

2005-10-30, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> In Russell M. Armstrong, "Modular Progamming in
> COBOL," there is a sample program (AP503) in
> the Appendix. The program is 22 1/2 pages. The
> first 7 1/2 pages is the REMARKS paragraph. The
> procedure division is about 11 1/2 pages and NOTE
> paragraphs seem to occupy about one-third of that
> space. For the most part, the NOTE pargraphs
> explain what the following paragraph-group does,
> eventhough it is often clear from the code what is
> done. I consider this to be a lot of "noise" making
> the program less clear, therefore "obfuscated".
> But, maybe that is just me! <g>

I agree with you, but that is a misuse issue, not a bad feature issue.

>
> Of course, the use of INSPECT CONVERTING to
> rearrange characters according to their pattern is
> always clear (easily understood; without ambiguity)
> and obvious (lacking in subtlety)!

Rick, both your issues involve misuse of features, not features that are
problems in and of themselves. At first glance it is obvious that use of '='
vs. '==' is going to be mistaken by the human eye/brain, without a doubt.
Any programmer who denies *ever* being

by C-style pointers either
hasn't used them much, or is lying. :-)

It's not a clarity issue, but whoever selected colon-equal (:=) as an
assignment operator was insane. For such a common typed sequence to be not
only two characters, but one of them shifted as well - that's insanity.
Reminds me of the QWERTY keyboard - purposefully designed to be inefficient
so the typists of the 1890's wouldn't overrun the machines of the day
(fact). :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Judson McClendon

2005-10-30, 6:55 pm

"Defaultuser" <Defaultuser@hotmail.com> wrote:
> "Judson McC