Mail Archives: djgpp/1999/07/28/12:00:22
Judson McClendon wrote in message ...
>Martijn Lievaart wrote:
>>Judson McClendon wrote
>>>As both a BASIC and COBOL (at least) programmer yourself, would
>>>you choose BASIC with no decimal variables over COBOL, to write
>>>financial applications, assuming both were available?
>>
>>As a multi language programmer that wrote financial applications in (a.o.)
>>COBOL and BASIC, if I have to choose from those two, it'll be BASIC.
>>
>>The only reason for choosing COBOL here would be portability. If
portability
>>is of any concern, you can rule out BASIC anyhow, so your question becomes
>>non-sensible then.
>
>I see you misapprehend what is important about COBOL. The vast majority
I'm not so sure about that.
>of COBOL programs are custom tailored code, written for a specific task
>for one organization. This makes portability a second level issue.
OK, that is clear.
>Why do you think there are 30+ year old COBOL programs around? How many
>even 10 year old C programs are still in active use, even though C has
>been around since the 70's?
A lot actually, the same argument you make for COBOL programs in a mainframe
toko, goes for C programs in a unix toko, and Basic program in early PC
toko's. Many unix utilities we take for granted are examples of those C apps
that are around for over 20 years. I would even argue that Unix itself
qualifies in some ways. I routinely encounter ancient unixes with equally
ancient C programs, humming along just fine. And you'ld be amazed how many
ancient C and Basic programs are still in use in f.i. labaratories.
>COBOL isn't brain dead, it is very simple.
>Remember, this isn't a question of which is the 'best' language. Such
>a question misses the point of tools. It is like asking 'Which is best,
>a hammer or a screwdriver?" The answer is "It depends on the task to be
>done with it." There is no 'best' tool, and no 'best' programming
>language, and there never will be. Computer languages, like any other
>tool ever devised by man, are more or less applicable to certain kinds
>of tasks. No tool is best for every task, and no programming language
>is best for every programming task. My point about the compiler in COBOL
>was simply to say that just because you can do something in a certain
>language is no sign that it is a good choice. It is true that COBOL was
>created before structured programming was a gleam in anybody's eye, not
>to mention OO. But the language has been updated in a number of ways to
>make it support much more structured programming techniques, and the new
>standard under development supports OO.
That was exactly the point I wanted to make, choose the right tool for the
job. For any financial application that does calculations beyond the trivial
COBOL is imho not the best tool. Did you ever write an application to
calculate insurance premiums? The math and rounding can be killing in COBOL,
where they are relatively trivial in say BASIC. I often ported programs to
Excel or Basic first before coding in COBOL!
>
>The fact is this: There exists no programming language in which large
>business applications can be developed more quickly, cheaply or reliably
>than in COBOL.
Uhm, allow me to differ of opinion. F.i. a friend of mine does wonders using
Focus, and does so much more quickly and reliably than with COBOL. In fact
I've seen many organizations switch to 4GL and multilanguage solutions
because COBOL didn't cut it anymore. And many of these projects were
succesfull, just because they were not trying to "do it all", just
incrementaly go from where they were.
Also, I had to develop financial applications in both basic and COBOL, and I
*very* quickly choose Basic as language of choice. Better debugger was one
factor. Flexible layout of reports was another. Interfacing to other systems
using serial I/O was a nightmare in COBOL (we resorted to linking in 3rd
party libraries for that, and it was expensive), but it was relatively
trivial in Basic. Interfacing to other languages was definately simpler in
Basic. (I once had to link Borland C routines to MSCobol. Yuck! That was
definately _not_ _trivial_). Not to mention "real" control structures[1].
Most of this is clearly very implementation dependent, but I think my
mileage will not differ very much from others here.
>The 'conventional wisdom' you are speaking from is more
>than 10 years out of date, and most large enterprise sized organizations
I didn't speak of "conventional wisdom" so I have no idea what you think
that I was thinking.
>are well aware of the fact. Based on a recent (3-4 months old) massive
>survey of over 1500 such agencies, several other facts are clear. One
>is that the great majority of them (> 80% as I recall) plan on increasing
>their use of COBOL to develop new applications. The reasons are very
>easy to understand. Industry wide, only 16% of the attempts to rewrite
>COBOL based mainframe apps using newer technologies have been successful.
Yes, I've seen enough failures in this field as well. None I've seen had
anything to do with the technoligy per-se, but the failures were *always*
related to the way these projects tried to replace existing, well working
(well..) systems by new systems with unproven technoligy.
I've also seen projects succeed. Always these were not trying to replace,
but to augment technoligy. I've also seen many fail that did augment instead
of replace, but that was never a great problem, because that risc was
calculated in from the start.
The important thing I think is that these figures roughly correspond to my
personal experience. In *each* *and* *every* case I personally witnessed,
when the failures were costly, the desicions were taken by poorly informed
managers (and sometimes by overenthousiastic hobbyists[2]). Often the
decisions were not well supported/accepted by the workfloor most affected by
the technoligy shift. This is a recipe for disaster. You and I know this.
But you'ld be amazed how often I've seen just this happening.
Of course I do *not* claim that this is authorative explanation for those
figures, absolutely not. It is just food for thought.
Another thing to think about, why are those applications replaced in the
first place? I suspect a large number of those are not functioning very
well, and instead of doing it right in COBOL, people are trying to do it
reight with a new technoligy. As perfectly working systems can be (and are)
build in COBOL, it might be wise to first determine why the applications
were not functioning in the first place. I suspect that these projects would
also have a high failure rate in the first place.
But aside from that, your reasoning is incorrect. You state that the reason
for expanding use of COBOL is that replacing COBOL apps works only 16% of
the time. You are comparing apples and pears here, as expanding is not the
same as replacing.
>The remaining 84% failed, from massive cost and/or time overruns,
>failure to meet design goals, and extremely poor reliability, compared
>to mainframe based COBOL systems. This is not an opinion, but hard,
>cold fact. For example, a front page article in the Wall Street Journal
>(about a year ago) explained how a number of large companies had spent
>millions on the newer technology just to learn that, not only did it cost
>a whole lot more, but even when it worked it did not work nearly as well
>as had their old COBOL systems, some of them 20 years old. That article
>reported that a number of those large companies had already rewritten
>some of their systems in COBOL to much better results, and more are on
Exactly the same can be said (and is said) about any surplanting of existing
(lagecy) technoligy with new technology. It doesn't say anything about COBOL
per-se.
>the way. The difference in costs between writing and debugging a large
>business system in C/C++ vs. COBOL is almost staggering.
Hmmm, my personal experience differs a lot here. Nowadays I don't write
financial applications anymore, but debugging our C++ programs doesn't take
(much) more time than I used to spend on COBOL programs (and the C++
projects are *much* larger, some over 150 KLOC, and remember that C++
generaly needs a lot less lines than COBOL).
Good design and use of proven technoligy are the key issues here. Projects
wih new technoligy are always tricky and getting the unexplainable bugs out
is one of the fields where we expect great costs. Generaly this assumption
turns out true.
>
>But my point here is not to push COBOL, and certainly not to attack
>BASIC or any other language. My point is that tools are designed for
>different purposes. BASIC and C/C++ are general purpose programming
>languages, and neither was designed with an eye toward financial
>programming. I is not reasonable or logical to expect them to do
>every single task better than other languages designed specifically
>for those tasks. I love BASIC, and have used it by choice almost every
>day since 1975. Yes, I have written financial applications in BASIC,
>but it was not my language of choice for that. I also like COBOL, not
>because it is fun, but because it is very good for certain tasks, even
>though it is very poor for other tasks. The wise programmer doesn't
>cling to a specific programming language, but looks at them objectively.
>It is just as important to see the warts as it is to see the beauty.
>Learn as many languages as you can, and use each of them for tasks
>where they make the most sense.
Absolutely. I personally know over 20 languages and find that I still react
emotionally on the subject of choosing a language, as do other people I
know. Knowing that I do luckily makes it easier to set aside those emotions
and try to react in a (more) sensible way.
As an aside, the platform is also very important because it affects the
availability of languages and features. I find that I solve problems very
differently on Unix than NT (the OSses I work with most nowadays), and that
again is very different from how I used to do it on mainframes (don't see 'm
very much these days).
Lastly, I can decide that Perl is the perfect language for a specific
problem (it often is), but I also have to consider who will maintain that
application after I'm gone. Programmers in an organization -- within
bounds -- should be able to take up where another left off. So I may have to
decide to use a (imho) less than optimal tool, because the optimal tool is
not known well enough by other programmers. If this happens enough, it's
also time to think about introducing that "new technoligy". (Luckily Perl is
gaining in our company :-) ).
Martijn
[1] For the cobol gurus out there, what does this peace of code do (except
for syntax errors, it has been a while since I wrote COBOL, you'll get the
meaning)
PERFORM xxxxx VARYING I FROM 1 TO 9
VARYING J FROM I+1 TO 10.
[2] The worst are the poorly informed managers that are also
overenthousiastic hobbyists.
--
Please post replies to this newsgroup. If you must reach me by email, use
<newsgroup-name> at greebo.orion in nl.
Senders of unsollicited bulk or commercial email will be prosecuted to the
maximal extend possible by law and any other means.
- Raw text -