Home > Archive > Cobol > August 2005 > Reviving REMARKS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| john@wexfordpress.com 2005-08-02, 4:59 pm |
| In my salad days one indicator of a careful programmer was a
well-written REMARKS paragraph in the IDENTIFICATION DIVISION. In a fit
of well-intentioned foolisheness the powers that be eliminated that
dedicated paragraph name, but left in such things as AUTHOR,
INSTALLATION and so on. The basic princple of COBOL beng a self
documenting and English-like language was pretty much ignored.
Now I have found a workaround that is so simple it is easy to miss. No
longer do I have to pepper column 7 with *'s just to insert a REMARKS
paragraph. I use a construct like this:
....
000100 INSTALLATION. WEXFORD PRESS.
000200*REMARKS.
HERE ARE MY REMARKS DESCRIBING THE PROGRAM
CONTINUED AS LONG AS I LIKE.
The trick is that the compiler sees those lines as just a continuation
of the
INSTALLATION paragraph. Only one asterisk is needed. This trick works
on OpenCobol. I hven't tested it elsewhere.
To many textbooks today, and too many instructors, view the
IDENTIFICATION DIVISION as just an anachronism to be disposed of as
quickly as possible.
IMO it is a vital part of what maked COBOL different, and better, than
other languages---readibility and understandability.
John Culleton
COBOLing since 1968, no fooling!
| |
| William M. Klein 2005-08-02, 9:59 pm |
| The INSTALLATION, AUTHOR, etc paragraphs are "OBSOLETE" in the '85 Standard and
removed from the '02 Standard. Therefore, this technique will NOT work in a
"strictly" conforming '02 Standard compiler (of which there aren't any - that I
know of). Using the asterisk in column 7 really IS the best way to make a
comment in "fixed form reference format". (With free form reference format,
start a comment line with "*>" in any old column)
--
Bill Klein
wmklein <at> ix.netcom.com
<john@wexfordpress.com> wrote in message
news:1123022014.372602.43750@g49g2000cwa.googlegroups.com...
> In my salad days one indicator of a careful programmer was a
> well-written REMARKS paragraph in the IDENTIFICATION DIVISION. In a fit
> of well-intentioned foolisheness the powers that be eliminated that
> dedicated paragraph name, but left in such things as AUTHOR,
> INSTALLATION and so on. The basic princple of COBOL beng a self
> documenting and English-like language was pretty much ignored.
>
> Now I have found a workaround that is so simple it is easy to miss. No
> longer do I have to pepper column 7 with *'s just to insert a REMARKS
> paragraph. I use a construct like this:
>
> ...
> 000100 INSTALLATION. WEXFORD PRESS.
> 000200*REMARKS.
> HERE ARE MY REMARKS DESCRIBING THE PROGRAM
> CONTINUED AS LONG AS I LIKE.
>
>
> The trick is that the compiler sees those lines as just a continuation
> of the
> INSTALLATION paragraph. Only one asterisk is needed. This trick works
> on OpenCobol. I hven't tested it elsewhere.
>
> To many textbooks today, and too many instructors, view the
> IDENTIFICATION DIVISION as just an anachronism to be disposed of as
> quickly as possible.
> IMO it is a vital part of what maked COBOL different, and better, than
> other languages---readibility and understandability.
>
> John Culleton
> COBOLing since 1968, no fooling!
>
| |
| Pete Dashwood 2005-08-02, 9:59 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:EGSHe.787167$pI6.491269@fe06.news.easynews.com...
>
> The INSTALLATION, AUTHOR, etc paragraphs are "OBSOLETE" in the '85
> Standard and removed from the '02 Standard. Therefore, this technique
> will NOT work in a "strictly" conforming '02 Standard compiler (of which
> there aren't any - that I know of). Using the asterisk in column 7 really
> IS the best way to make a comment in "fixed form reference format". (With
> free form reference format, start a comment line with "*>" in any old
> column)
>
Sometimes the "facts" are a bit brutal.
I have a feeling that John will not be happy to hear this. He started
writing COBOL a year after I did. (I started programming in 1965 and COBOL
in 1967). It was a different time and we were all pretty impressed with the
power of COBOL. It became precious to all of us and that veneration has not
been continued by the succession of new standards which have compromised the
language to make it more acceptable in a modern environment. (I have no
opinion about whether that was good or bad; just note it in passing...)
Would it really have done any harm to leave the IDENTIFICATION DIVISION
alone?
But then, far be it from me to criticise the standards process...
Pete.
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> <john@wexfordpress.com> wrote in message
> news:1123022014.372602.43750@g49g2000cwa.googlegroups.com...
>
>
>
| |
| Richard 2005-08-02, 9:59 pm |
|
john@wexfordpress.com wrote:
> In a fit
> of well-intentioned foolisheness the powers that be eliminated that
> dedicated paragraph name,
What they actually did was introduce a much more general commenting
mechanism that made REMARKS and NOTE statements obsolete.
> The basic princple of COBOL beng a self
> documenting and English-like language was pretty much ignored.
Actually the point about _self_ documenting is that it doesn't need
remarks or comments.
> INSTALLATION paragraph. Only one asterisk is needed. This trick works
> on OpenCobol. I hven't tested it elsewhere.
Actually you probably don't need the asterisk at all - just put the
word REMARKS in column 12. You may find that once a comment paragraph
has been started it only stops when there is something in area A.
I started using '*' for all comments 30 years ago and don't see why you
feel the need to revert to the 60s. Next you will be adopting a
standard that requires each paragraph to start with a NOTE sentence
that comments on what the paragraph is to do. ;-)
I often put comments in programs that are designed to be extracted to
build user documentation. The parts that are to be extracted are
comments (* in 7) that are between pairs of *<html> and *</html>
comments. These comments may be anywhere including the identification
division so I will always use '*' even there.
| |
|
| john@wexfordpress.com wrote:
> In my salad days one indicator of a careful programmer was a
> well-written REMARKS paragraph in the IDENTIFICATION DIVISION. In a fit
> of well-intentioned foolisheness the powers that be eliminated that
> dedicated paragraph name, but left in such things as AUTHOR,
> INSTALLATION and so on. The basic princple of COBOL beng a self
> documenting and English-like language was pretty much ignored.
Eliminating REMARKS, IMO, didn't do anything to the readability of
COBOL. All you have to do is comment the lines - in fact, in our shop,
we have a "standard" top-of-program comment block that is supposed to be
there. When we converted from COBOL 74 to COBOL 85, it was a simple
task to either move that information into the comment block, or simply
remove it. (I had a good laugh at the commented-out "DATE-COMPILED.
TODAY."... ;> )
I see that others have told you about the comment facilities. A block
comment start/comment end would be nice, but not really necessary. With
the editor we use, we can highlight a column of text, and tell it to be
filled with the "*" character, which comments the whole mess out. We
also use a comment box on each paragraph, like so...
100-MY-PARAGRAPH.
****************************************
***********************
* You can tell I didn't write this paragraph, because the name
* is all caps!
****************************************
***********************
> Now I have found a workaround that is so simple it is easy to miss. No
> longer do I have to pepper column 7 with *'s just to insert a REMARKS
> paragraph. I use a construct like this:
>
> ...
> 000100 INSTALLATION. WEXFORD PRESS.
> 000200*REMARKS.
> HERE ARE MY REMARKS DESCRIBING THE PROGRAM
> CONTINUED AS LONG AS I LIKE.
>
>
> The trick is that the compiler sees those lines as just a continuation
> of the
> INSTALLATION paragraph. Only one asterisk is needed. This trick works
> on OpenCobol. I hven't tested it elsewhere.
INSTALLATION (along with everything else except PROGRAM-ID) has been
removed from COBOL 2002. In its place are a host of new keywords that
allow you to define objects, repositories, factories (constructors), etc.
> To many textbooks today, and too many instructors, view the
> IDENTIFICATION DIVISION as just an anachronism to be disposed of as
> quickly as possible.
> IMO it is a vital part of what maked COBOL different, and better, than
> other languages---readibility and understandability.
It does have its place - and, until the 2002 standard is more widely
implemented, it'll be difficult to convince instructors that there's
something "new" in COBOL.
> John Culleton
> COBOLing since 1968, no fooling!
Heh - and I was born in... well, never mind. ;) (I'll be 32 next
month...)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| john@wexfordpress.com 2005-08-02, 9:59 pm |
| In fact the structured layout of the IDENTIFICATION DIVISION with its
fixed paragraph names encouraged the inclusion of significant
documentation in a standardized way. Every language has a commenting
facility. What was unique about the ID DIV was that it had a standard
format. The standard mavens, in their eternal and rather foolish quest
to make COBOL "just like" every other language gave up some of its
unique virtues.
Fortunately compiler writers tend to cater to old programs and hence
features stay in long past their scheduled execution date. Hopefully I
will still be able to use the ID DIV the way GMH intended for the rest
of my programming career.
BTW the "self documenting" nature of the language does not tell the
person reading a program years later the who what when why of the
creation of the program. And without someencouragement programmers
will take the easy way out. How many internally documented program
written in Java or Perl have you seen lately? In a text book, maybe.
A "generalized commenting facility" may as well be no facility at all.
Programmers are busy and will skip over it.
(end grump)
John Culleton
| |
| Richard 2005-08-02, 9:59 pm |
|
john@wexfordpress.com wrote:
> In fact the structured layout of the IDENTIFICATION DIVISION with its
> fixed paragraph names encouraged the inclusion of significant
> documentation in a standardized way.
They may have been 'fixed' but they weren't compulsory.
> Every language has a commenting
> facility. What was unique about the ID DIV was that it had a standard
> format.
Actually Java has a standard for documention implemented by javadoc. It
uses 'paragraphs' headed by such things as @version, @author, etc.
> The standard mavens, in their eternal and rather foolish quest
> to make COBOL "just like" every other language gave up some of its
> unique virtues.
An interesting viewpoint, but what I don't see is how they have stopped
programmers using *REMARKS, *AUTHOR, *DATE-COMPILED. It is not as if
they originally forced one to use the old paragraphs and then later
prevented them using those names.
| |
|
| <john@wexfordpress.com> wrote in message
news:1123037908.989224.99930@g47g2000cwa.googlegroups.com...
> In fact the structured layout of the IDENTIFICATION DIVISION with its
> fixed paragraph names encouraged the inclusion of significant
> documentation in a standardized way. Every language has a commenting
> facility. What was unique about the ID DIV was that it had a standard
> format. The standard mavens, in their eternal and rather foolish quest
> to make COBOL "just like" every other language gave up some of its
> unique virtues.
I think they failed if that was their goal. COBOL is awfully quirky, always
will be, though I don't expect huge changes to the COBOL 2015 Standards.
> BTW the "self documenting" nature of the language does not tell the
> person reading a program years later the who what when why of the
> creation of the program.
Self documenting means that you don't need comments - the code is "self
documenting".
But anyhooo..
Who - Some contractor who left 5 years ago
When - 5 years ago
Why - A 5 year old requirement for something
One of the things I do when getting into code is to take the god awful
"documentation prologs" out of programs (if allowed) and if not move them to
the end. Who made a change is irrelevant for the most part (code ownership
is an outdated paradigm), when they made it _might_ be useful, but not if
it's more than a few months ago at which point it's rarely useful to know,
and more often the comments are "undone" later on. It's kind of like
prohibition - if you stop reading history at a certain point all of america
is tea total. The issue with comments is that they require maintenance
JUST like source code.
Far more useful is a good source code management tool. It records that junk
(who what) for you.
Far more useful is someone or some group being responsible for maintaining a
list of the actual requirements requested, approved, executed. That's what
QA uses...and that philosophy exists from mainframe accounting apps to
console games.
As someone once said, "Function is King" and the source code is NOT the
place to document function as function is nearly ALWAYS >>>>> a program.
> And without someencouragement programmers
> will take the easy way out.
Which is why shops have "standards".
My standard is to start each paragraph with
*----------------------------------------------------------------------*
*
*
*----------------------------------------------------------------------*
LOOKUP-CUSTOMER-PHONE-NUMBER.
Why? Because I like the spacing. Why don't I comment ? Because I figure
that the paragraph makes it clear.
I don't need to write "Look up the customer phone number because this is the
part of the program where we get the phone number to attach it to his call
history report and key into our other data".
If there was something unusual (then I may add something). I've NEVER had
anyone tell me that they didn't understand the code I had written. I follow
basic rules - name things in a simple manner, and don't do things that you
don't imply.
> How many internally documented program
> written in Java or Perl have you seen lately?
All of them. Find me any usable product/API/Freeware that doesn't have them?
Someone close to me has asked me for help with some undocumented Java...but
it was clearly written by a PL/I programmer (it was _that_ obvious). That's
my exception. People that I work with - everything has been commented and
nauseatingly so - it's kind of mandated.
Most documentation for Java APIs are generated from Java comments.
Reusable objects are worthless without the APIs.
I find that more often that NO comments I see POOR comments. The worst
comments I've ever seen are PL/I and then COBOL comments ...I've seen things
like:
* DO NOT update customer if it is Jamie
IF Rajinder THEN
continue
ELSE
update
END-IF
One assumes that Jamie in A/R was sacked and Rajinder took over.
Or even.
* Use the values (B)lue, (R)ed from the Table for available Colors.
Before the DBA decides to make (Y)ellow a valid value too...
> In a text book, maybe.
> A "generalized commenting facility" may as well be no facility at all.
> Programmers are busy and will skip over it.
It's very simple. If there needs to be comments in the code, then
management mandates comments. If comments are not added then you started
giving low ratings and firing people. Of course, one then would ask for
"quality comments" etc etc This is why you have different people in teams -
the "LEADS" and the "DUMBASSES" :-) One makes sure the other is doing
well...no?
Basic rule of thumb - don't let ANYTHING install without a review. In
public companies not doing this would in most cases violate Sarbanes Oxley
if there is anything that will affect any financials - which is just about
anything these days. It should be done to protect customers, clients,
networks, systems, managers, personal pride or whatever...If what you're
doing is for personal use then one assumes that you don't have short term
memory issues combined with disorganized code.
If the review indicates that the code is unclear then it should be
rewritten, or clarified. Often refactoring clarifies more than commenting.
<DISCLAIMER>
That is of course for those of us who still believe that maintenance of
source code is an issue
> (end grump)
>
> John Culleton
Kind of a small grump I hope. Seems to me that comments and their location
is somewhat of a trivial issue. :-)
JCE
| |
| Howard Brazee 2005-08-03, 4:59 pm |
|
On 2-Aug-2005, john@wexfordpress.com wrote:
> Now I have found a workaround that is so simple it is easy to miss. No
> longer do I have to pepper column 7 with *'s just to insert a REMARKS
> paragraph. I use a construct like this:
I infer that there is some reason you don't care for column 7 asterisks.
| |
| Howard Brazee 2005-08-03, 4:59 pm |
|
On 2-Aug-2005, LX-i <lxi0007@netscape.net> wrote:
>
> Heh - and I was born in... well, never mind. ;) (I'll be 32 next
> month...)
I was a late starter - I didn't start CoBOLing until 1969.
| |
| Howard Brazee 2005-08-03, 4:59 pm |
| NNTP-Posting-Host: ums.cusys.edu
X-Trace: peabody.colorado.edu 1123077234 20125 192.12.240.129 (3 Aug 2005 13:53:54 GMT)
X-Complaints-To: abuse@colorado.edu
NNTP-Posting-Date: 3 Aug 2005 13:53:54 GMT
X-Newsreader: News Rover 10.2.3 (http://www.NewsRover.com)
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:115765
On 2-Aug-2005, "jce" <defaultuser@hotmail.com> wrote:
> My standard is to start each paragraph with
> *----------------------------------------------------------------------*
> *
> *
> *----------------------------------------------------------------------*
> LOOKUP-CUSTOMER-PHONE-NUMBER.
>
> Why? Because I like the spacing. Why don't I comment ? Because I figure
> that the paragraph makes it clear.
This thread started off with someone who wanted comments without asterisks.
Your message appears that you want blank lines without being blank (having
asterisks).
Is there some advantage in having an asterisk in column 7 of an otherwise blank
line that I have failed to understand? I suspect so, because it is not
uncommon.
| |
| docdwarf@panix.com 2005-08-03, 4:59 pm |
| In article <1123022014.372602.43750@g49g2000cwa.googlegroups.com>,
<john@wexfordpress.com> wrote:
[snip]
>Now I have found a workaround that is so simple it is easy to miss. No
>longer do I have to pepper column 7 with *'s just to insert a REMARKS
>paragraph. I use a construct like this:
>
>...
>000100 INSTALLATION. WEXFORD PRESS.
>000200*REMARKS.
> HERE ARE MY REMARKS DESCRIBING THE PROGRAM
> CONTINUED AS LONG AS I LIKE.
>
>
>The trick is that the compiler sees those lines as just a continuation
>of the
>INSTALLATION paragraph. Only one asterisk is needed. This trick works
>on OpenCobol. I hven't tested it elsewhere.
How interesting. I was taught, lo, those many years ago, that the
compiler (in this case IKFCBL00) would see an asterisk in column seven and
then stop examing the card... ummmmm, line at that point and loop back to
read the next card, thus saving Valuable System Resources; this is why
completely blank lines were wasteful (the compiler would have to check
eack position on the input card... errrrr, line to see if there was
anything there to check).
(this was also the justification given for favoring a '/' in column 7 as
an indicator for advancing the page... fewer resources were required for
responding to a single character than for reading the entire word EJECT
and looking it up in the reserved word table, once again saving Valuable
System Resources)
(a '/' also requires fewer keystrokes, which some folks seemed to think
was a Very Good Reason, also... these same folks would also mention that
keying in PIC XXXX was more economical than PIC X(4), PIC XXXXX was
equally costly as PIC X(5) and anything beyond six was most economically
expressed as numerals... but there were disagreements as to whether a
parenthesis counted as one keystroke or two because the shift key had to
be used)
(Ahhhhhh, for the Oldene Dayse... when a programmer could debate about
minutiae and micro-efficiencies such as *ten* programmers cannot, today!)
Your method makes me wonder what's going on between reading the
INSTALLATION card and whatever it might be that tells the compiler 'All
right, back to work, here is Stuff That Matters'... not that it is likely
to change the way I code (given that Valuable System Resources are no
longer so... Valuable) but as a matter of interest and curiousity.
DD
| |
| docdwarf@panix.com 2005-08-03, 4:59 pm |
| In article <dcqi9i$jkt$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
[snip]
>Is there some advantage in having an asterisk in column 7 of an otherwise blank
>line that I have failed to understand?
See another posting about saving Valuable System Resources.
DD
| |
| Howard Brazee 2005-08-03, 4:59 pm |
|
On 3-Aug-2005, docdwarf@panix.com wrote:
> (a '/' also requires fewer keystrokes, which some folks seemed to think
> was a Very Good Reason, also... these same folks would also mention that
> keying in PIC XXXX was more economical than PIC X(4), PIC XXXXX was
> equally costly as PIC X(5) and anything beyond six was most economically
> expressed as numerals... but there were disagreements as to whether a
> parenthesis counted as one keystroke or two because the shift key had to
> be used)
>
> (Ahhhhhh, for the Oldene Dayse... when a programmer could debate about
> minutiae and micro-efficiencies such as *ten* programmers cannot, today!)
CoBOL programmers tended to lose these arguments to those who knew how to make C
as cryptic as possible.
| |
| docdwarf@panix.com 2005-08-03, 4:59 pm |
| In article <dcqkrq$kta$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 3-Aug-2005, docdwarf@panix.com wrote:
[snip]
>
>CoBOL programmers tended to lose these arguments to those who knew how to make C
>as cryptic as possible.
I believe that COBOL programmers were making these arguments before C was
invented.
DD
| |
| Chuck Stevens 2005-08-03, 4:59 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:EGSHe.787167$pI6.491269@fe06.news.easynews.com...
> The INSTALLATION, AUTHOR, etc paragraphs are "OBSOLETE" in the '85
Standard and
> removed from the '02 Standard. Therefore, this technique will NOT work in
a
> "strictly" conforming '02 Standard compiler (of which there aren't any -
that I
> know of). Using the asterisk in column 7 really IS the best way to make a
> comment in "fixed form reference format". (With free form reference
format,
> start a comment line with "*>" in any old column)
In '02-compliant compilers and other compilers that include this feature of
'02 COBOL as an extension: you can also start a comment with "*>" in any
old column in fixed-form reference format, with or without preceding text,
and whatever follows it will be treated as a comment. In neither fixed-form
nor free-form reference format are you required to make the entire line a
comment.
-Chuck Stevens
| |
| Richard 2005-08-03, 4:59 pm |
|
docdwarf@panix.com wrote:
> Your method makes me wonder what's going on between reading the
> INSTALLATION card and whatever it might be that tells the compiler 'All
> right, back to work, here is Stuff That Matters'...
What tells the compiler is something, anything, in Area A.
| |
| Peter Lacey 2005-08-03, 4:59 pm |
| Richard wrote:
> mechanism that made REMARKS and NOTE statements obsolete.
>
>
> Actually the point about _self_ documenting is that it doesn't need
> remarks or comments.
>
That's incomplete. I have come across innumerable examples of code that
were perfectly easy to follow but were completely inexplicable. An
example - a price was determined by looking things up in a 2-d table;
easy; but then $1.26 was added. No indication why; nobody could tell
me; I eventually found a five-year-old memo by an engineer that cleared
things up. Now if the programmer had included as a comment, a reference
to the memo and (possibly) where to find it I'd have saved several hours
of exasperation.
There are many other possibilities where the code, by itself, doesn't
tell you what you need to know. (I'm speaking of maintaining the code,
of course).
PL
| |
| Chuck Stevens 2005-08-03, 4:59 pm |
| Huh?? I don't think I get your point.
If any of the following "paragraph headers" are present in a COBOL '85
program, they must be in Area A *and* those that are there must be in order:
AUTHOR, INSTALLATION, DATE-WRITTEN, DATE-COMPILED and SECURITY. (As Bill
K. points out, they're all obsolete in '85 COBOL and gone from '02; they
were neither in '74).
The only "work" that gets done by any of these, aside from reproducing the
source line on the compilation listing, if any, is from DATE-COMPILED.
What do these paragraph headers contribute to the Stuff that Matters to the
compiler? Three of them appear after INSTALLATION, two of those have no
compiler-related function at all save to get recognized as something that
contains a comment entry, and all must appear in Area A.
-Chuck Stevens
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1123096787.208206.274560@g43g2000cwa.googlegroups.com...
>
> docdwarf@panix.com wrote:
>
>
> What tells the compiler is something, anything, in Area A.
>
| |
| Richard 2005-08-03, 4:59 pm |
|
[color=darkred]
Chuck Stevens wrote:[color=darkred]
> Huh?? I don't think I get your point.
Doc appeared to be unsure of "whatever it might be ..". The answer was
"something in Area A".
Each of those paragraphs in Identification division is terminataed by
the next heading in Area A. However, if the heading is not recognised
it will give an error.
This is why REMARKS in column 12 will 'work', or if it on a comment
line, but if the compiler does not recognise REMARKS as a pargraph in
ID then it will cause an error if it is in column 8.
| |
| Chuck Stevens 2005-08-03, 4:59 pm |
| OK, I think I see.
REMARKS, when it existed in standard COBOL, was a "paragraph heading" in the
division, and as such needed to go in Area A. If you need to put it in Area
B as part of the "comment entry" of one of the paragraphs other than
PROGRAM-ID, well, OK, but you've got to have one in the first place (like
INSTALLATION), and that itself marks a change from when it had to be in Area
A.
REMARKS was eliminated between "first standard COBOL" (ANSI X3.23-1968) and
"second standard COBOL" (ANSI X3.23-1974). It had actually been deleted
from the JoD in '68, but the '74 standard was pretty well set by mid-'66,
according to the "History of COBOL" section in the '74 standard.
Thus, I would say that if you're going to have to move REMARKS from Area A
to Area B, and ensure that it follows another paragraph heading that allows
a comment entry, you might as well make it a standard comment in the first
place.
-Chuck Stevens
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1123102427.784166.117250@f14g2000cwb.googlegroups.com...
>
>
>
> Chuck Stevens wrote:
>
> Doc appeared to be unsure of "whatever it might be ..". The answer was
> "something in Area A".
>
> Each of those paragraphs in Identification division is terminataed by
> the next heading in Area A. However, if the heading is not recognised
> it will give an error.
>
> This is why REMARKS in column 12 will 'work', or if it on a comment
> line, but if the compiler does not recognise REMARKS as a pargraph in
> ID then it will cause an error if it is in column 8.
>
| |
| William M. Klein 2005-08-03, 4:59 pm |
| On a related (but slightly different) topic. (Still talking about
"comment-entry" items in the Identification Division.)
IBM has previously (publicly) indicated that they have no (current) intention of
removing ANY of the '85 Standard "OBSOLETE" items even if (when) they provide an
'02 Standard compiler. Instead, they will keep them as "extensions" (which
should be valid - at least in most cases).
HOWEVER, there is an "amusing" item concerning paragraph-headers and
comment-entries. In an '85 Standard compiler (without an EXTENSION ignoring
A-/B-margin) the word "COPY" appearing in the B-margin (where a comment-entry
may appear) is treated as part of the comment-entry. While the word "COPY" in
the A-margin is the COPY "compiler directing statement" (and may - itself -
include the next "paragraph" - or "division") header.
Therefore, if IBM tries to keep the comment-entries (as an extension) but also
implements the '02 Standard removal of A-/B-margin restrictions, they will be
left with a rather "odd" upward compatibility situation - that "COPY" in some
places is a comment and in others it is compiler-directing, but they won't have
any margin/terms to "handle" this distinction.
I don't know how other vendors with an extension to the '85 Standard ignoring
A-/B-margin currently handle this, but it does amused me. (which just goes to
show how easily amused I can be<G> )
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dcrcd8$2vv0$1@si05.rsvl.unisys.com...
> OK, I think I see.
>
> REMARKS, when it existed in standard COBOL, was a "paragraph heading" in the
> division, and as such needed to go in Area A. If you need to put it in Area
> B as part of the "comment entry" of one of the paragraphs other than
> PROGRAM-ID, well, OK, but you've got to have one in the first place (like
> INSTALLATION), and that itself marks a change from when it had to be in Area
> A.
>
> REMARKS was eliminated between "first standard COBOL" (ANSI X3.23-1968) and
> "second standard COBOL" (ANSI X3.23-1974). It had actually been deleted
> from the JoD in '68, but the '74 standard was pretty well set by mid-'66,
> according to the "History of COBOL" section in the '74 standard.
>
> Thus, I would say that if you're going to have to move REMARKS from Area A
> to Area B, and ensure that it follows another paragraph heading that allows
> a comment entry, you might as well make it a standard comment in the first
> place.
>
> -Chuck Stevens
>
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1123102427.784166.117250@f14g2000cwb.googlegroups.com...
>
>
| |
| docdwarf@panix.com 2005-08-03, 9:59 pm |
| In article <1123096787.208206.274560@g43g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>docdwarf@panix.com wrote:
>
>
>What tells the compiler is something, anything, in Area A.
I see... and you know this is happening because of... ?
DD
| |
| Richard 2005-08-03, 9:59 pm |
| > I see... and you know this is happening because of... ?
_I_ know what should happen because of what is written in the
documentation.
""" ... ; the next line commencing in Area A will begin the next
non-comment entry."""
There are, however, variations and extensions which may affect this.
| |
| Richard 2005-08-03, 9:59 pm |
| > I see... and you know this is happening because of... ?
_I_ know what should happen because of what is written in the
documentation.
""" ... ; the next line commencing in Area A will begin the next
non-comment entry."""
There are, however, variations and extensions which may affect this.
| |
| Richard 2005-08-03, 9:59 pm |
| > I see... and you know this is happening because of... ?
_I_ know what should happen because of what is written in the
documentation.
""" ... ; the next line commencing in Area A will begin the next
non-comment entry."""
There are, however, variations and extensions which may affect this.
| |
|
| john@wexfordpress.com wrote:
> BTW the "self documenting" nature of the language does not tell the
> person reading a program years later the who what when why of the
> creation of the program. And without someencouragement programmers
> will take the easy way out.
How was the presence of a REMARKS paragraph more encouraging than
allowing any line to be preceded (in column 7) by a "*"? Did the
compiler actually flag programs that *didn't* have a REMARKS paragraph?
I promise I'm not trying to be argumentative - but I just don't see that
REMARKS is any harder to ignore than "*". Never underestimate the
laziness of the human spirit. ;)
> How many internally documented program
> written in Java or Perl have you seen lately? In a text book, maybe.
> A "generalized commenting facility" may as well be no facility at all.
> Programmers are busy and will skip over it.
Most Java I have seen has good comments - but then again, JavaDoc is far
from a "generalized" facility. If the comments are written a certain
way, it really *is* possible to generate programmer documentation from
it. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| "Howard Brazee" <howard@brazee.net> wrote in message
news:dcqi9i$jkt$1@peabody.colorado.edu...
>
> On 2-Aug-2005, "jce" <defaultuser@hotmail.com> wrote:
>
>
> This thread started off with someone who wanted comments without
> asterisks.
>
> Your message appears that you want blank lines without being blank (having
> asterisks).
>
> Is there some advantage in having an asterisk in column 7 of an otherwise
> blank
> line that I have failed to understand? I suspect so, because it is not
> uncommon.
No, it's aesthetically pleasing to my eye. The two lines that are not blank
show up as different colors in any editor I use so it makes it nice and easy
visually...that's all.
It is also so that the ar people after me can put comments in the box should
they so desire ;-)
JCE
| |
|
| "Peter Lacey" <lacey@mts.net> wrote in message
news:42F11CFC.1880825E@mts.net...
> Richard wrote:
[color=darkred]
> That's incomplete. I have come across innumerable examples of code that
> were perfectly easy to follow but were completely inexplicable. An
> example - a price was determined by looking things up in a 2-d table;
> easy; but then $1.26 was added. No indication why; nobody could tell
> me; I eventually found a five-year-old memo by an engineer that cleared
> things up. Now if the programmer had included as a comment, a reference
> to the memo and (possibly) where to find it I'd have saved several hours
> of exasperation.
> There are many other possibilities where the code, by itself, doesn't
> tell you what you need to know. (I'm speaking of maintaining the code,
> of course).
>
> PL
The code was self documenting..it was saying lookup a price and add $1.26.
The reason why is a not part of the code - that's part of the system
functionality and should be documented with the system function guide or
whatever you call it. If someone was to ask a non programmer what the price
would be for a customer you wouldn't ask them to read code would you?
In addition using something like 77 [reason]-SURCHARGE PIC 9.99 VALUE 1.26
may have helped even more.
JCE
| |
|
| <docdwarf@panix.com> wrote in message news:dcqjhm$ehc$1@panix5.panix.com...
> In article <1123022014.372602.43750@g49g2000cwa.googlegroups.com>,
> <john@wexfordpress.com> wrote:
>
> How interesting. I was taught, lo, those many years ago, that the
> compiler (in this case IKFCBL00) would see an asterisk in column seven and
> then stop examing the card... ummmmm, line at that point and loop back to
> read the next card, thus saving Valuable System Resources; this is why
> completely blank lines were wasteful (the compiler would have to check
> eack position on the input card... errrrr, line to see if there was
> anything there to check).
> (this was also the justification given for favoring a '/' in column 7 as
> an indicator for advancing the page... fewer resources were required for
> responding to a single character than for reading the entire word EJECT
> and looking it up in the reserved word table, once again saving Valuable
> System Resources)
Was this justification of favouring of a '/' all of the people you knew,
just some of the people you knew, or all or some of the people you do and do
not know...or was this your *personal* justification...and was it true for
all platforms or just not Unisys?
I'm fearful of the truth behind *generalizations* these days.
> (a '/' also requires fewer keystrokes, which some folks seemed to think
> was a Very Good Reason, also... these same folks would also mention that
> keying in PIC XXXX was more economical than PIC X(4), PIC XXXXX was
> equally costly as PIC X(5) and anything beyond six was most economically
> expressed as numerals... but there were disagreements as to whether a
> parenthesis counted as one keystroke or two because the shift key had to
> be used)
>
> (Ahhhhhh, for the Oldene Dayse... when a programmer could debate about
> minutiae and micro-efficiencies such as *ten* programmers cannot, today!)
Similar (or not) efficiencies cost the US economy roughly $114 billion in
the years leading up to Y2K too.
During that time Project Managers could debate minutiae and
micro-efficiencies such as *ten* Project Managers cannot, today!)
JCE
| |
| Richard 2005-08-04, 3:59 am |
| > In addition using something like 77
> [reason]-SURCHARGE PIC 9.99 VALUE 1.26
> may have helped even more.
In my view that doesn't belong in the program at all. It belongs in a
file that can be edited by authorised people in the application area.
The program would then read the file when required to add the value
therein.
| |
|
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1123135117.172289.39720@g43g2000cwa.googlegroups.com...
>
> In my view that doesn't belong in the program at all. It belongs in a
> file that can be edited by authorised people in the application area.
> The program would then read the file when required to add the value
> therein.
>
Agreed, and point taken, but it was for the sake of argument. Even if it
was in a file one would hopefully call it something sensible with a record
layout titled imaginatively to indicate it was 'price-uplift' or something
sensible and not "OPEN FILE-1 READ FILE-1 MOVE FILE-1-VALUE TO
ADD-VALUE....COMPUTE PRICE = PRICE + ADD-VALUE".
JCE
| |
| docdwarf@panix.com 2005-08-04, 8:59 am |
| In article <1123117039.111835.206530@g47g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>_I_ know what should happen because of what is written in the
>documentation.
>
>""" ... ; the next line commencing in Area A will begin the next
>non-comment entry."""
Ahhhh... excellent. Thanks much.
>
>There are, however, variations and extensions which may affect this.
That is often the case, aye.
DD
| |
| docdwarf@panix.com 2005-08-04, 8:59 am |
| In article <z0iIe.35065$iG6.12808@tornado.tampabay.rr.com>,
jce <defaultuser@hotmail.com> wrote:
><docdwarf@panix.com> wrote in message news:dcqjhm$ehc$1@panix5.panix.com...
[snip]
>Was this justification of favouring of a '/' all of the people you knew,
>just some of the people you knew, or all or some of the people you do and do
>not know...or was this your *personal* justification...and was it true for
>all platforms or just not Unisys?
The answer is: E) Some of the Above
>
>I'm fearful of the truth behind *generalizations* these days.
Is that generally so?
>
>
>Similar (or not) efficiencies cost the US economy roughly $114 billion in
>the years leading up to Y2K too.
It wasn't seen as broken so nobody bothered to fix it... until, of course,
*everyone* needed to fix it and resources got tighter.
>During that time Project Managers could debate minutiae and
>micro-efficiencies such as *ten* Project Managers cannot, today!)
Maybe they got their starts as programmers.
DD
| |
| Howard Brazee 2005-08-04, 8:59 am |
|
On 3-Aug-2005, "jce" <defaultuser@hotmail.com> wrote:
> No, it's aesthetically pleasing to my eye. The two lines that are not blank
> show up as different colors in any editor I use so it makes it nice and easy
> visually...that's all.
>
> It is also so that the ar people after me can put comments in the box should
> they so desire ;-)
Ahh. My eye gets pleased in a different way. I remove asterisks from blank
lines to make them more pleasing to my eye.
And people after me know don't find the lack of a pre-existing asterisk to be a
stumbling block to their desire to add comments.
| |
| Chuck Stevens 2005-08-04, 4:59 pm |
| Note also that the use of "*" in Column 7 to indicate that the source image
is a comment, according to ANSI X3.23-1974 page XIV-7, was *not* s standard
feature of COBOL in the '68 standard (although I believe it was a *very*
widely implemented extension even to implementations prior to '68). The
only two *standard* mechanisms for introducing explanatory material prior to
the '74 standard were the REMARKS paragraph in the IDENTIFICATION DIVISION
and the NOTE statement in the PROCEDURE DIVISION. The asterisk comment
convention was intended to replace them.
-Chuck Stevens
"LX-i" <lxi0007@netscape.net> wrote in message
news:825de$42f17a7f$45491c57$29980@KNOLO
GY.NET...
> john@wexfordpress.com wrote:
>
> How was the presence of a REMARKS paragraph more encouraging than
> allowing any line to be preceded (in column 7) by a "*"? Did the
> compiler actually flag programs that *didn't* have a REMARKS paragraph?
>
> I promise I'm not trying to be argumentative - but I just don't see that
> REMARKS is any harder to ignore than "*". Never underestimate the
> laziness of the human spirit. ;)
>
>
> Most Java I have seen has good comments - but then again, JavaDoc is far
> from a "generalized" facility. If the comments are written a certain
> way, it really *is* possible to generate programmer documentation from
> it. :)
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ 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++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Michael Wojcik 2005-08-04, 4:59 pm |
|
In article <dcqkrq$kta$1@peabody.colorado.edu>, "Howard Brazee" <howard@brazee.net> writes:
>
> CoBOL programmers tended to lose these arguments to those who knew
> how to make C as cryptic as possible.
C is a piker when it comes to inscrutability. Even the best IOCCC
entries are hardly less comprehensible than the average APL program.
See http://pws.cablespeed.com/~mwojcik/find-unique-apl.png for an
image of an APL one-liner (note that any computable function can be
expressed as a one-line APL program) that takes a list of integers,
where all but one of the values is duplicated, and finds the one
that's not duplicated. (It expands the list into a matrix that
represents the binary expansion of each value in the list;
exclusive-ORs them together, leaving only the unique value; and
converts that back to base 10.) It's probably not the best APL
implementation of that algorithm, as I'm a rank amateur APLer, but
it does the job.
Now imagine a couple of pages of that stuff.
Of course, though there are some minor differences in syntax and
semantics, APL and COBOL compute precisely the same set of functions,
so they're exactly equivalent. And, curiously, they're both popular
in the finance industries.
--
Michael Wojcik michael.wojcik@microfocus.com
Proverbs for Paranoids, 2: The innocence of the creatures is in inverse
proportion to the immorality of the Master. -- Thomas Pynchon
| |
| Howard Brazee 2005-08-04, 4:59 pm |
|
On 4-Aug-2005, mwojcik@newsguy.com (Michael Wojcik) wrote:
> See http://pws.cablespeed.com/~mwojcik/find-unique-apl.png for an
> image of an APL one-liner (note that any computable function can be
> expressed as a one-line APL program) that takes a list of integers,
> where all but one of the values is duplicated, and finds the one
> that's not duplicated. (It expands the list into a matrix that
> represents the binary expansion of each value in the list;
> exclusive-ORs them together, leaving only the unique value; and
> converts that back to base 10.) It's probably not the best APL
> implementation of that algorithm, as I'm a rank amateur APLer, but
> it does the job.
How do we open that?
| |
| Oliver Wong 2005-08-04, 4:59 pm |
| "Howard Brazee" <howard@brazee.net> wrote in message
news:dcteht$9cn$1@peabody.colorado.edu...
> On 4-Aug-2005, mwojcik@newsguy.com (Michael Wojcik) wrote:
> How do we open that?
It's an image file in the PNG format (pronounced "ping"). You can read
about it at http://www.libpng.org/pub/png/. WindowsXP, MacOS and modern
distributions of Linux tend to have an image viewer capable of displaying
PNG files.
Also, it appears that the reason the source code is being represented by
an image file as opposed to a text file is that it uses characters that are
not part of any character encoding that I know of (i.e. ASCII and Unicode).
I have no idea what that character after the second (and final) arrow is,
for example.
- Oliver
| |
| Howard Brazee 2005-08-04, 4:59 pm |
|
On 4-Aug-2005, "Oliver Wong" <owong@castortech.com> wrote:
>
> It's an image file in the PNG format (pronounced "ping"). You can read
> about it at http://www.libpng.org/pub/png/. WindowsXP, MacOS and modern
> distributions of Linux tend to have an image viewer capable of displaying
> PNG files.
>
> Also, it appears that the reason the source code is being represented by
> an image file as opposed to a text file is that it uses characters that are
> not part of any character encoding that I know of (i.e. ASCII and Unicode).
> I have no idea what that character after the second (and final) arrow is,
> for example.
Ah, I have W2k here. I'll look at it at home.
| |
| Peter Lacey 2005-08-04, 4:59 pm |
| jce wrote:
>
> "Peter Lacey" <lacey@mts.net> wrote in message
> The code was self documenting..it was saying lookup a price and add $1.26.
> The reason why is a not part of the code - that's part of the system
> functionality and should be documented with the system function guide or
> whatever you call it.
"SHOULD" is a very far cry from "IS". In my 40-odd years of I/T
experience I have never been able to rely on the external documentation
- neither for completeness nor for up-to-date-ness. Therefore I
maintain that in every case such information must be at least mentioned
in the source code. The source code is the ONLY document I can count on
(and I've had a few cases where even that was lost!)
These days it's becoming more & more the pratice to include such things
with (commented) HTML tags so that it can be extracted for external
documentation. Q.E.D.
>If someone was to ask a non programmer what the price
> would be for a customer you wouldn't ask them to read code would you?
>
Code isn't for a non-programmer by definition. Most likely these days
customer service reps would just run the price inquiry program.
> In addition using something like 77 [reason]-SURCHARGE PIC 9.99 VALUE 1.26
> may have helped even more.
>
> JCE
It's true that using a named variable instead of a literal would have
been better programming practice. But one word can't possibly replace
an explanation in every case, not even in most cases. Write in a
comment then there are no doubts left.
PL
| |
| Peter Lacey 2005-08-04, 4:59 pm |
| jce wrote:
>
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1123135117.172289.39720@g43g2000cwa.googlegroups.com...
> Agreed, and point taken, but it was for the sake of argument. Even if it
> was in a file one would hopefully call it something sensible with a record
> layout titled imaginatively to indicate it was 'price-uplift' or something
> sensible and not "OPEN FILE-1 READ FILE-1 MOVE FILE-1-VALUE TO
> ADD-VALUE....COMPUTE PRICE = PRICE + ADD-VALUE".
>
> JCE
As a matter of fact, 99% of the pricing was table-driven. This was an
exceedingly complex manufacturing configurator application. There was a
table for each product which gave the prices for each two-dimensional
possibility. There was one table which gave the values for properties
common to all the products (such as maximum width, maximum width if
anodized, maximum width if painted, maximum section width, ... etc.,
etc.); there were if I remember properly about 120 different potential
properties per product. Not all of them applied: if you used stainless
steel you couldn't anodize or paint; zillions of rules like that. There
was another table of properties unique to a product which might change
occasionally; it was easier to change the table entry if needed than
find the references in the programs. These last two tables were used in
formulas used to modify the basic prices. The engineers were in charge
of these two tables. I'm guessing that it was too late on a Friday
night to have implemented the $1.26 properly. All I know for sure is it
was done that way and I had a devil of a job figuring it out, and if the
programmer that did it had left me a comment in the pricing program
s/he'd have saved me a lot of exasperation.
PL
| |
| Howard Brazee 2005-08-04, 4:59 pm |
|
On 4-Aug-2005, Peter Lacey <lacey@mts.net> wrote:
> "SHOULD" is a very far cry from "IS". In my 40-odd years of I/T
> experience I have never been able to rely on the external documentation
> - neither for completeness nor for up-to-date-ness. Therefore I
> maintain that in every case such information must be at least mentioned
> in the source code. The source code is the ONLY document I can count on
> (and I've had a few cases where even that was lost!)
Nor internal documentation. Documentation can be a help when we try to
determine why the code was written the way it is - but we can't rely on it.
| |
|
| Chuck Stevens wrote:
> Note also that the use of "*" in Column 7 to indicate that the source image
> is a comment, according to ANSI X3.23-1974 page XIV-7, was *not* s standard
> feature of COBOL in the '68 standard (although I believe it was a *very*
> widely implemented extension even to implementations prior to '68). The
> only two *standard* mechanisms for introducing explanatory material prior to
> the '74 standard were the REMARKS paragraph in the IDENTIFICATION DIVISION
> and the NOTE statement in the PROCEDURE DIVISION. The asterisk comment
> convention was intended to replace them.
At what point did the NOTE end - was it a sentence-level statement, or
was it a "until the next paragraph, everything is a comment" statement?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| Howard Brazee wrote:
> On 4-Aug-2005, mwojcik@newsguy.com (Michael Wojcik) wrote:
>
>
>
>
> How do we open that?
A web browser. :) (PNG = Portable Network Graphics, a royalty-free
GIF-style image type. IE, Firefox, Mozilla, and Konqueror all support
them.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Pete Dashwood 2005-08-04, 9:59 pm |
|
"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dct9070vk1@news4.newsguy.com...
>
>
> In article <dcqkrq$kta$1@peabody.colorado.edu>, "Howard Brazee"
> <howard@brazee.net> writes:
>
> C is a piker when it comes to inscrutability. Even the best IOCCC
> entries are hardly less comprehensible than the average APL program.
>
> See http://pws.cablespeed.com/~mwojcik/find-unique-apl.png for an
> image of an APL one-liner (note that any computable function can be
> expressed as a one-line APL program) that takes a list of integers,
> where all but one of the values is duplicated, and finds the one
> that's not duplicated. (It expands the list into a matrix that
> represents the binary expansion of each value in the list;
> exclusive-ORs them together, leaving only the unique value; and
> converts that back to base 10.) It's probably not the best APL
> implementation of that algorithm, as I'm a rank amateur APLer, but
> it does the job.
>
In the mid/late 1980s I worked with some financial people in Spain who were
APL experts. They were constantly amused by the time it took to do stuff in
COBOL, and the amount of code required. After our team implemented some
fairly major stuff, they offered to show me the same thing in APL. I went to
have a look. They wrote it while I waited and produced a couple of lines of
APL which would have taken at least 2000 lines of COBOL. I had to agree that
the functionality was identical, but they couldn't manipulate data and drive
databases on the mainframe. I came away extremely impressed by the power of
APL but realising it was a 'write-only' language... :-)
> Now imagine a couple of pages of that stuff.
>
As I recall, the whole point was that you DIDN'T write pages of it...
> Of course, though there are some minor differences in syntax and
> semantics, APL and COBOL compute precisely the same set of functions,
> so they're exactly equivalent. And, curiously, they're both popular
> in the finance industries.
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> Proverbs for Paranoids, 2: The innocence of the creatures is in inverse
> proportion to the immorality of the Master. -- Thomas Pynchon
>
| |
| Richard 2005-08-05, 3:59 am |
| > At what point did the NOTE end - was it a sentence-level statement, or
> was it a "until the next paragraph, everything is a comment" statement?
Both of those.
If NOTE was the first statement in a paragraph then the whole paragraph
was comment. If it was not the first statement then only the sentence
it started was comment.
This duality, as well as the errors caused by adding and removing full
stops, was reason enough to have it strangled.
| |
| Howard Brazee 2005-08-05, 4:59 pm |
|
On 4-Aug-2005, LX-i <lxi0007@netscape.net> wrote:
>
> A web browser. :) (PNG = Portable Network Graphics, a royalty-free
> GIF-style image type. IE, Firefox, Mozilla, and Konqueror all support
> them.)
I tried Firefox and Opera on a W2K machine at work without luck. At home, with
a WXP machine, I had no problem.
| |
| Oliver Wong 2005-08-05, 4:59 pm |
| "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11f6ro8l9rfq26f@news.supernews.com...
> Pete Dashwood wrote:
>
> Neat-oh.
>
> I remember a program of several hundred (if not thousands) of lines of
> FORTRAN to compute the inverse of a matrix while somebody pointed out the
> project was only one line of code in APL or LISP or RPG or SNOBOL or
> something (I forget).
>
> Of course we didn't have that compiler - nor was one available for our
> computers - and nobody spoke whatever language it was.
I'm usually not too impressed by languages in which one can write a
program using fewer lines of code than in another language. You could
imagine, for example, a language in which the empty string (i.e. the size of
the file containing the source code is 0 bytes) is compiled into some
arbitrary Linux distribution with all optional packages installed (perhaps
normally requiring several 2 DVDs to install), and any other string is
compiled as if a normal Pascal program. Then you could point at that Linux
distribution and demonstrate that what took several million if not a billion
line of codes in one language, could be written in zero lines of code in
this new fictitious language.
Of course, not too many people will take this language seriously because
while it may certainly be the "best" tool for one particular job (generating
that specific Linux distribution), generally it won't be the best tool for
most other jobs.
Of course, what will be considered the best tool for a particular job
varies depending on who's trying to accomplish that job, but factors I
commonly see taken into consideration (assuming that 'jobs' here mean
software development/migration/refactoring/whatever efforts) include how
painless it is to create new functionality with the tool, how painless it is
to understand existing functionality created by other people using the tool
and how painless it is to modify existing functionality created by other
people using the tool.
One factor that might determine how painful (in a business sense) an
effort is, is how long it takes to accomplish that effort: If you can write
a program that satisfies all the requirements in language X in a matter of
hours, whereas writing a program that satisfies the same set of requirements
in language Y would take a few months, then everything else being equal, X
is a better tool for this job.
Unfortunately, a lot of people assume that there's a direct
correspondance between lines of code (or some other measure of size) with
the amount of time it'll take to write/understand/modify that code. I guess
they figure that the bottleneck for us programmers is that we can't
type/read fast enough!
- Oliver
| |
| Chuck Stevens 2005-08-05, 4:59 pm |
| LX-i asked:
<<At what point did the NOTE end - was it a sentence-level statement, or was
it a "until the next paragraph, everything is a comment" statement?>>
I don't have a '68 standard, but I do have some early reference materials
and I think I can draw some valid conclusions from them. I think the
answer is "Yes".
The wording from a reference manual for a COBOL-60 (!) implementation on the
Burroughs B6500 (!!) from '68 and the corresponding wording from an IBM DOS
COBOL manual from '73 is the same:
"If a NOTE sentence is the first sentence of a paragraph, the entire
paragraph is considered to be part of the character string. Proper format
rules for paragraph structure must be observed.
If a NOTE sentence appears as other than the first sentence of a paragraph,
the commentary ends with the first instance of a period followed by a
space."
-Chuck Stevens
| |
|
| Richard wrote:
>
>
> Both of those.
>
> If NOTE was the first statement in a paragraph then the whole paragraph
> was comment. If it was not the first statement then only the sentence
> it started was comment.
So, you had to name your longer-than-sentence comments by putting them
in their own paragraph? ick...
> This duality, as well as the errors caused by adding and removing full
> stops, was reason enough to have it strangled.
They could have just added END-NOTE... ;)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| Howard Brazee wrote:
> On 4-Aug-2005, LX-i <lxi0007@netscape.net> wrote:
>
>
>
>
> I tried Firefox and Opera on a W2K machine at work without luck. At home, with
> a WXP machine, I had no problem.
Strange - I'll have to have my friend at work who runs Win2K try to pull
up my Linux site. It's got a PNG in the header.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| Oliver Wong wrote:
> I'm usually not too impressed by languages in which one can write a
> program using fewer lines of code than in another language. You could
> imagine, for example, a language in which the empty string (i.e. the size of
> the file containing the source code is 0 bytes) is compiled into some
> arbitrary Linux distribution with all optional packages installed (perhaps
> normally requiring several 2 DVDs to install), and any other string is
> compiled as if a normal Pascal program. Then you could point at that Linux
> distribution and demonstrate that what took several million if not a billion
> line of codes in one language, could be written in zero lines of code in
> this new fictitious language.
But imagine the savings on maintenance! :)
> Unfortunately, a lot of people assume that there's a direct
> correspondance between lines of code (or some other measure of size) with
> the amount of time it'll take to write/understand/modify that code. I guess
> they figure that the bottleneck for us programmers is that we can't
> type/read fast enough!
I've never understood that. On the Unisys 2200 mainframe, our main
network database is commonly and quite easily manipulated with COBOL.
For some reason, though, our customer has it in their head that it's
"expensive" to write a COBOL program.
The need arose to write a "data extract" program, which basically dumps
the status of each airplane into a file, that's the FTP'd to another
server, aggregated, and displayed (to commanders, or anyone else who
cares about fleet-wide status). It also shows, if the planes are
broken, why they're broken, and when they should be back in commission.
A COBOL program was deemed "too expensive" for this, so they wrote a
utility using Unisys's Query Language Processor (QLP). Once this was
deployed for a few w s, we got an e-mail. Seems this run was costing
them over $100 a pop, and it ran every 30 minutes on 100+ bases. They
started figuring out in a hurry that this was way too inefficient. They
then tasked us to rewrite it in... (COBOL? No, that would make too
much sense.) IQ/U, which is another ad-hoc query utility (albeit more
efficient than QLP) produced by KMSys Worldwide (formerly KMSystems).
Run cost went down, but at that point, they were *still* running
non-standard production software in a production manner. I probably
could have written the data extraction in COBOL in probably 3 or 4 times
the amount of time it's taken me to relate this story, and it would be
running under production-quality efficiency.
So the QLP and IQU were 100-200 lines, and my COBOL program probably
would have been closer to 300. :) Who cares? You still incur the same
testing workload and same release paperwork as a COBOL program (and, in
fact, we had to "adapt" our COBOL processes to work with QLPs and IQUs,
causing yet more work for this "simpler" solution).
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Richard 2005-08-05, 9:59 pm |
| >> I tried Firefox and Opera on a W2K machine at work without luck. At home, with
[color=darkred]
> Strange - I'll have to have my friend at work who runs Win2K try to pull
> up my Linux site. It's got a PNG in the header.
Your site works fine in Firefox. I suspect that there is something not
quite right with the apl png. When loaded to Firefox on Linux it
offers eog (Eye of Gnome) as the program to view it.
| |
| Russell 2005-08-06, 4:59 pm |
| LX-i <lxi0007@netscape.net> wrote in news:47002$42f3e071$45491c57$3491
@KNOLOGY.NET:
> Richard wrote:
statement?[color=darkred]
paragraph[color=darkred]
>
> So, you had to name your longer-than-sentence comments by putting them
> in their own paragraph? ick...
>
>
> They could have just added END-NOTE... ;)
>
>
If you really want a block of comments, without using a star
in column 07, just use the conditional compile feature, eg "$IF 1 = 0",
followed (eventually) by "$END". I understand that the "$" will be
replaced by ">>" in later versions.
It might be best to avoid columns 01 - 06 out of caution. You
really can't guarantee the survival of those columns.
| |
|
| Russell wrote:
> If you really want a block of comments, without using a star
> in column 07, just use the conditional compile feature, eg "$IF 1 = 0",
> followed (eventually) by "$END". I understand that the "$" will be
> replaced by ">>" in later versions.
>
> It might be best to avoid columns 01 - 06 out of caution. You
> really can't guarantee the survival of those columns.
Our compiler doesn't support that. However, Visual SlickEdit has a nice
feature that enables us to easily comment a block of code.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Michael Wojcik 2005-08-15, 4:59 pm |
|
[Sorry this is late - I've just returned from vacation.]
In article <FprIe.207753$on1.54587@clgrps13>, "Oliver Wong" <owong@castortech.com> writes:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:dcteht$9cn$1@peabody.colorado.edu...
>
> Also, it appears that the reason the source code is being represented by
> an image file as opposed to a text file is that it uses characters that are
> not part of any character encoding that I know of (i.e. ASCII and Unicode).
They may all be in Unicode; I haven't checked. It's likely that many
people running Unicode-capable systems wouldn't have fonts installed
with the correct glyphs for those codepoints, though.
> I have no idea what that character after the second (and final) arrow is,
> for example.
It's a lowercase iota. The APL font I'm using has fairly large serifs
for some characters; I wouldn't write an iota that way myself.
--
Michael Wojcik michael.wojcik@microfocus.com
Americans have five di vantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride
| |
| Michael Wojcik 2005-08-15, 4:59 pm |
|
In article <1123288790.616007.219930@g44g2000cwa.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
>
>
> Your site works fine in Firefox. I suspect that there is something not
> quite right with the apl png. When loaded to Firefox on Linux it
> offers eog (Eye of Gnome) as the program to view it.
Possible, though the server may not be setting Content-type
correctly, too. I don't control that server - the site is included
with my broadband subscription, so I use it as a temporary dumping
ground for posting little tidbits like this.
I don't recall what I used to generate the PNG, which was probably
just a cropped screen capture.
--
Michael Wojcik michael.wojcik@microfocus.com
Duck: No secret what's worth a hoot ought to be kept quiet.
Pogo: Secrets is usually perty doggone fascinatin'.
Duck: Egg-zackly ... it's completely illogical to keep a secret secret.
Pogo: An' unfair. -- Walt Kelly
| |
| Michael Wojcik 2005-08-15, 4:59 pm |
|
In article <3lg116F12ihb4U1@individual.net>, "Pete Dashwood" <dashwood@enternet.co.nz> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dct9070vk1@news4.newsguy.com...
> In the mid/late 1980s I worked with some financial people in Spain who were
> APL experts. They were constantly amused by the time it took to do stuff in
> COBOL, and the amount of code required. After our team implemented some
> fairly major stuff, they offered to show me the same thing in APL. I went to
> have a look. They wrote it while I waited and produced a couple of lines of
> APL which would have taken at least 2000 lines of COBOL. I had to agree that
> the functionality was identical, but they couldn't manipulate data and drive
> databases on the mainframe.
Not natively, true. Like most programming languages, APL has only
minimal built-in I/O capabilities, and looks to external libraries
for more extensive functionality.
> I came away extremely impressed by the power of
> APL but realising it was a 'write-only' language... :-)
That's the accusation usually levelled against it. You can express
many mathematical relationships very clearly - for readers who are
comfortable with the notation - and you can write structured APL
programs (really workspaces) by decomposing larger sequences into
functions and so forth. However, it does seem that many people find
APL easier to write than to read.
> As I recall, the whole point was that you DIDN'T write pages of it...
While you can knock off short APL sequences that perform impressive
computations (often in surprising ways), there are a lot of serious
APL programs which are relatively long. Often, of course, a program
has to implement lots of relatively arbitrary rules (imposed by
government and other non-rational influences) which don't have any
neat mathematical expression, so it'll require a significant amount
of code in any language.
--
Michael Wojcik michael.wojcik@microfocus.com
What is it with this warm, quiet, nauseating bond between them?
-- Rumiko Takahashi, _Maison Ikkoku_, trans. Mari Morimoto, adapt. Gerard
Jones
| |
| Oliver Wong 2005-08-15, 4:59 pm |
| "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:ddqc6s0195h@news4.newsguy.com...
> Often, of course, a program
> has to implement lots of relatively arbitrary rules (imposed by
> government and other non-rational influences) which don't have any
> neat mathematical expression, so it'll require a significant amount
> of code in any language.
If only they could invent some sort of common business oriented language
to handle arbitrary business rules like that...
- Oliver
|
|
|
|
|