K
Keith Thompson
Mike Schilling said:
I thought it was
ADD 1 TO COBOL.
or possibly
ADD 1 TO COBOL GIVING COBOL.
I thought it was
ADD 1 TO COBOL.
or possibly
ADD 1 TO COBOL GIVING COBOL.
J
Jukka Lahtinen
You can't compute in a MOVE statement.
...or possibly
COMPUTE COBOL = COBOL + 1.
...or possibly
COMPUTE COBOL = COBOL + 1.
C
ClassCastException
This is, quite possibly, the most frightening thing I have ever read.
C
ClassCastException
And guess which of the two he saw while on mescaline and which while
sober?
K
Keith Thompson
ClassCastException said:
If you want to have a language war, please take it elsewhere.
C
ClassCastException
Why? It's been ages since cljp has had a decent flamewar, or more than
about 1000 posts a month.
T
Tom Anderson
It was designed to be used by highly intelligent people. In the hands of
intelligent people who have learned it, it is usable and powerful, and
indeed, not difficult.
But most people, even most programmers, are not highly intelligent. For
them, i suspect it would always be difficult.
Does that make it a difficult language?
I am also dubious about the idea that it's good for writing clean code. I
see a lot of Haskell that tends towards wrapping a problem in the smallest
possible ball of the strongest possible abstractions. That makes for
concise, and perhaps elegant, code, but i'm not sure i'd call that clean.
Clean to me implies a sort of self-opening limpidness, a quality which is
at odds with cleverness.
tom
T
Tom Anderson
I'd been told it was ADD ONE TO COBOL GIVING COBOL, but perhaps i was
misled.
tom
B
BartC
Verboseness can still depend on the programmer. The only Cobol I ever did
was at college, on punched cards. Everyone was walking around with huge
stacks of cards up to 6-8" high, while my pile was only about an inch high,
for exactly the same assignment.
M
Martin Gregorie
None of the examples posted so far in this branch of the thread would
compile because COBOL is a reserved word.
There are so many reserved words in COBOL that the common idiom is to
include a hyphen in your data names and labels because very few reserved
words contain one. That said, there are three valid ways of incrementing
a variable, listed in personal order of preference:
ADD 1 TO COBOL-COUNT.
COMPUTE COBOL-COUNT = COBOL-COUNT + 1.
ADD 1 TO COBOL-COUNT GIVING COBOL-COUNT.
M
Martin Gregorie
I meant verboseness in the sense that almost any COBOL statement is
considerably longer than the equivalent statement in any other
programming language simply because its a limited subset of English
rather than the pseudo-mathematical notation used by almost every other
language. About the only exception is that you can write
MOVE ALL ZERO TO TOTAL-ARRAY.
where almost all other languages require a loop.
I wouldn't consider a line count as a good measure of verbosity in COBOL
or any other semi-free format language, because reduced line count can
make for amazingly unreadable code of the one statement per line
convention isn't followed. Compare the following:
ARRAY-TOTALLING.
MOVE ZERO TO ARRAY-TOTAL. PERFORM ADD ARRAY-ELEMENT(I) TO ARRAY-TOTAL
VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE END-PERFORM. MOVE
ARRAY-TOTAL TO TL-VALUE. WRITE TOTAL-LINE AFTER 1.
with
ARRAY-TOTALLING SECTION.
AT-1.
MOVE ZERO TO ARRAY-TOTAL.
PERFORM
ADD ARRAY-ELEMENT(I) TO ARRAY-TOTAL
VARYING I FROM 1 BY 1 UNTIL I > ARRAY-SIZE
END-PERFORM.
MOVE ARRAY-TOTAL TO TL-VALUE.
WRITE TOTAL-LINE AFTER 1.
AT-EXIT.
END.
NOTE Both can be executed with the same statement, as follows.
PERFORM ARRAY_TOTALLING.
.... 4 lines vs 11 lines - I know which I'd rather read. Now extend that
to 20-30 inline statements and the condensed code is a real mess. Anybody
who wrote code like that would be off the project so fast he wouldn't
know what happened in any shop I've worked in.
Yeah, I know that you can write Java like that too if you put your mind
to it, but IMO its less readable in COBOL if only because a full stop is
harder to spot than a semi-colon.
N
Nick Keighley
And guess which of the two he saw while on mescaline and which while
sober?
what they were the same program?!!
T
Thomas G. Marshall
On Nov 9, 5:46 pm, Martin Gregorie <[email protected]>
wrote:
....[snip]...
Just reading this @#$% makes me wanna cry.
wrote:
....[snip]...
Just reading this @#$% makes me wanna cry.
A
Arved Sandstrom
Tom said:
On the latter point, and I don't disagree about the nature of much of the
Haskell code we see, I think what you're describing there is
intermediate/beginner-expert code. In other words, stuff written by Haskell
coders who have just recently reached the point where they _can_ write like
that, and therefore delight in demonstrating it. I follow the main Haskell
NG, and also the odd mailing list, and have my share of good Haskell books,
and based on the material I see there, the true experts have generally
gotten away from that and are writing for clarity again.
The same phenomenon happens in other languages too, to the extent that a
given language makes terseness and extreme abstraction possible. It's
absolutely possible in Java.
The degree to which people do this is, I believe, also related to the amount
of exposure they've had to the real world, i.e. business experience, and the
degree to which their code is going to be seen and used by other people. You
know, and I know, that you can't perpetrate your super-concise,
super-elegant, but impenetrable-to-the-unwashed code onto the shoulders of
follow-on average maintainers, and get away with it for long. Not if you're
a professional.
AHS
M
Martin Gregorie
Sadly, there's still useful stuff that COBOL can do more concisely than
other more recent languages.
Apart from its ability to fill an array or data structure with a literal
value without using an explicit loop there's its edited fields. A field
defined like this:
PIC $,$$$,$$$,$$9.99DB BLANK WHEN ZERO
is always filled by moving a value to it with the following effects:
value effect
zero the field is entirely space-filled
5 $0.05
-1 $0.01DB
6995 $69.95
102400 $1,024.00
I don't know how to do this is any other language in a single statement
with or without the use of conditional formatting, yet its a very common
requirement in a financial program.
OK, I'll shut up now.
B
BartC
Robert Klemme said:On 06.11.2010 10:30, Nick Keighley wrote:
Well, you basically only need to know that ARGF iterates over all files in
ARGV or reads from stdin if ARGV is empty. I think the rest is pretty
self explanatory, isn't it?
Yes, but Ruby seems to delight in these kinds of off-kilter syntaxes.
For the purposes of pseudo-code, which of the following is clearer:
a.each {|line| ... } # or:
for each line in a { ... } # ?
Or which of the following:
99.times do |i| ... end # (and what's the first i value, 0 or 1?) or:
for i =1 to 99 do ... end # (or any of countless variations)?
It seems that once this way of using an iterator (or generator or whatever
it is) became available, then every program must make use of it at every
opportunity ...
B
BartC
Robert Klemme said:On 06.11.2010 16:28, Lew wrote:
That *is* just a smiley, isn't it? You can't always tell with APL.
T
Tom Anderson
Including the code needed to define the DSL, of course.
tom
T
Tom Anderson
total_array = [0 for x in total_array]
Are you serious?
tom
T
Tom Anderson
Interesting. I hadn't thought of it like that.
I can attest to that. I've done even worse things in Python.
There is a school of thought that says that if you can find a few guys who
can handle the super-rocket-science code, you don't need to hire the
average guys. I've never worked anywhere quite like that, though.
tom