 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
70%-80% of UK business transactions are handled by COBOL programs.
I knew it was still big, but not that big.
http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> 70%-80% of UK business transactions are handled by COBOL programs.
> I knew it was still big, but not that big.
> http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming
Looking at COBOL example code, it looks like a mix between INTERCAL and
LOLCODE. Except that perhaps LOLCODE is easier to understand.
(Looking at Fortran examples, it doesn't look any better...)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Looking at COBOL example code, it looks like a mix between INTERCAL and
> LOLCODE.
Heh. A bit. It was supposed to be something you could read. Not unlike
LOLCODE a bit, but I don't see the connection to INTERCAL except that some
of the terms are spelled out in prose.
Even reading the COBOL for 99 bottles, I found it difficult to understand. I
guess COBOL has changed a lot in the last 40 years or so. For example, the
last COBOL I used you couldn't put the body of the loop near the loop
control - you had to say "go call that subroutine 99 times" and write the
subroutine somewhere else. As in the "Cobol typical mainframe" version.
Put it this way, tho. If you knew neither (say) C nor COBOL (to pick
languages vaguely in the same timeframe), which would be easier to read? If
you didn't know how to program at all, what would be easy to ready? That was
one of the design goals for COBOL.
> (Looking at Fortran examples, it doesn't look any better...)
The FORTRAN 90 looks pretty straightforward. Fortran IV was the last FORTRAN
I actually did any serious work in, and that looks pretty straightforward,
if you understand how printf() works in Fortran.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Put it this way, tho. If you knew neither (say) C nor COBOL (to pick
> languages vaguely in the same timeframe), which would be easier to read? If
> you didn't know how to program at all, what would be easy to ready? That was
> one of the design goals for COBOL.
I don't know if it's just that I have been exposed way too much to the
C family of languages (obviously C and C++, but also some PHP and Perl,
and to an extent the POV-Ray SDL) and to shell-scripting type of languages,
but it just feels like when a language like COBOL explicitly states out
with full words what you want to do, rather ironically, it seems to make
the code more obfuscated rather than easier to understand.
Maybe it's the lack of delimiters. It's difficult to see where logical
code blocks begin and end when there are no visually distinguishing delimiter
symbols. Not even indentation to make them stand out (such as eg. in Python).
Probably a question of getting accustomed to the syntax.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> The FORTRAN 90 looks pretty straightforward. Fortran IV was the last
> FORTRAN I actually did any serious work in, and that looks pretty
> straightforward, if you understand how printf() works in Fortran.
Yet it seems almost all Fortran code out there is still in 77, and is
still written in 77.
I don't know Fortran well - only coded it once. Had to modify someone's
code to add some numerical algorithm. So am not an expert. However, a
friend of mine who knows it much better, and is comfortable with it
(albeit while disliking it) told me the reason almost all (scientific)
Fortran code is still written in 77 is that 90 onwards performed poorly.
--
186,000 miles/sec: Not just a good idea, it's the LAW.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't know if it's just that I have been exposed way too much to the
> C family of languages
I think that's it. As I said, one of the original design goals was that
non-programmers could read it. It's pretty straightforward what each
individual sentence does. The overall structure is obscured in the way you
say, in part due to the verbosity making it spread much bigger, and in part
due to the lack of familiar control structures, indenting, etc.
> Maybe it's the lack of delimiters. It's difficult to see where logical
> code blocks begin and end when there are no visually distinguishing delimiter
> symbols. Not even indentation to make them stand out (such as eg. in Python).
Yeah. On the other hand, lots of COBOL programs tend to not have a whole lot
of deep structure in them, in my very limited experience. One tends to
structure 30 programs with bunches of intermediate files rather than one
program with 30 subroutines nesting 5 deep. Not unlike shell scripting, sorta.
Of course, it's from before structured programming, let alone before OO or
anything like that, so yeah, it's going to have funky control structures.
Altho I did see a book on object-oriented COBOL sitting on a shelf not too
long ago.
> Probably a question of getting accustomed to the syntax.
That too. The data declarations are pretty cool for a business language,
tho. Lots of the older machines had hardware support for COBOL data types,
back when doing things like printf() or decimal arithmetic in software was
prohibitively slow.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> It was supposed to be something you could read.
I don't think it makes any sense to write out mathematical formulae
as english expressions. It only makes the result confusing and very
hard to understand. I don't even understand why the thought it would
be a good idea. What businessman doesn't understand "x = a+b" equally
well as, if not even better than "ADD A TO B GIVING X"?
The latter form becomes ridiculous when the expression is any longer,
such as:
MULTIPLY B BY B GIVING B-SQUARED.
MULTIPLY 4 BY A GIVING FOUR-A.
MULTIPLY FOUR-A BY C GIVING FOUR-A-C.
SUBTRACT FOUR-A-C FROM B-SQUARED GIVING RESULT-1.
COMPUTE RESULT-2 = RESULT-1 ** .5.
SUBTRACT B FROM RESULT-2 GIVING NUMERATOR.
MULTIPLY 2 BY A GIVING DENOMINATOR.
DIVIDE NUMERATOR BY DENOMINATOR GIVING X.
Who ever thought that would be a good idea? Who understands that?
It seems that COBOL does support the more intuitive way too, ie:
COMPUTE X = (-B + SQRT(B ** 2 - (4 * A * C))) / (2 * A)
So what's the point in having both syntaxes?
Maybe because it was the 50's and computers were a brand new invention,
people thought that it's cool if you can write "plain English" and have
the computer understand it. Whether it's actually practical is secondary.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Who ever thought that would be a good idea? Who understands that?
Grace Hopper?
> So what's the point in having both syntaxes?
Because an awful lot of times, just the one addition or multiplication is
what you need.
MULTIPLY RETAIL-PRICE BY DISCOUNT-PERCENT GIVING DISCOUNTED-PRICE.
MULTIPLY DISCOUNTED-PRICE BY SALES-TAX-PERCENTAGE GIVING SALES-TAX.
ADD SALES-TAX TO DISCOUNTED-PRICE GIVING TOTAL-DISPLAYED-ON-REGISTER.
It makes it trivially easy to see that the sales tax is applied to the
discounted price, not the original price, for example.
In all the programs I wrote in 2 years of full time cobol programming, I
think I used COMPUTE maybe twice? You almost always need the intermediate
values anyway, in business calculations.
> people thought that it's cool if you can write "plain English" and have
> the computer understand it. Whether it's actually practical is secondary.
No. It's because the boss can understand stuff like what I wrote above. Just
like lots of the limitations of early FORTRAN[1] were there to make it
possible to compile into something as efficient as assembler.
Look at something like a US tax form. The math is all trivial, one operation
per line.
Scientific computing (a la fortran) didn't work this way for a reason: the
formulae aren't usually trivial in science, and you usually don't need the
intermediate values.
[1] Like the fact that there were only a handful of valid expression forms
you could use for a subscript, because that was the only way to ensure you
could use these new-fangled index registers.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
70-80%? I thought COBOL was pretty much dead after SQL. Do COBOL programs use
SQL databases?
BTW, recently Lisp turned 50 as well:
http://www.lisp50.org/50-years-of-lisp/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Because an awful lot of times, just the one addition or multiplication is
> what you need.
> MULTIPLY RETAIL-PRICE BY DISCOUNT-PERCENT GIVING DISCOUNTED-PRICE.
> MULTIPLY DISCOUNTED-PRICE BY SALES-TAX-PERCENTAGE GIVING SALES-TAX.
> ADD SALES-TAX TO DISCOUNTED-PRICE GIVING TOTAL-DISPLAYED-ON-REGISTER.
I still find this clearer:
DISCOUNTED-PRICE = RETAIL-PRICE * DISCOUNT-PERCENT.
GIVING SALES-TAX = DISCOUNTED-PRICE * SALES-TAX-PERCENTAGE.
TOTAL-DISPLAYED-ON-REGISTER = SALES-TAX + DISCOUNTED-PRICE.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
