From: "Martijn Lievaart" Newsgroups: comp.os.msdos.djgpp,alt.comp.lang.learn.c-c++,alt.lang.basic Subject: Re: A small bussiness billing application Date: 28 Jul 1999 15:10:58 GMT Organization: EuroNet Internet Message-ID: <7nn6i2$9il@news3.euro.net> References: <8E0A6B90Bjsampsonpostmasterco AT news DOT earthlink DOT net> <9APl3.1054$XG6 DOT 30509 AT dfiatx1-snr1 DOT gtei DOT net> <90_l3.4474$xN4 DOT 43628 AT news3 DOT mia> <7na84u$4d7 AT news3 DOT euro DOT net> NNTP-Posting-Host: p243.asi.euronet.nl X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Lines: 215 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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 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.