Sorry to point out your straw man, but most COBOL developers writing web apps would just concentrate on solving the problem instead of wrestling with the technology.
How about trading in all that 1960s monolithic design for what (I thought) we all learned in the 1970s: UI loosely coupled to business rules loosely coupled to data access. Then you can switch your layers around to whatever the current fad is.
Web client app using SOAP or REST or POX to access a CICS/COBOL server app. The latest technology is available to you to create a rich UI and you've got industrial strength OLTP and DBMS technology for the server side.
Most real-world problems are parallel problems. Even the ones that aren't (say... compiling a file in C) you can usually run a lot of instances of in parallel.
Programming, or compiling programs, is a very tiny subset of real-world problems. Most real-world problems are boring, single-threaded, input-process-output problems.
Regarding TCO, the C is rarely T. It is, at best, the Total Cost of What I Can Account For Easily. At worst, it is Total Cost of What Supports the Decision I've Already Made.
Most often, it's Total Cost of Acquisition.
Programming languages are tools used to solve problems. Any decent programmer will have more than one tool in their toolbox. Some tools are appropriate for > 1 problem space; there is overlap.
The problem space for COBOL is usually confined to, you know, implementing business rules.
If your problem with COBOL is that you're having trouble using it to process/var/log then you're probably trying to use it in the wrong problem space.
Truly unfortunate are all the comments modded as informative that are anything but. Even more unfortunate is I've come to expect that of slashdot.
I work on z/OS in COBOL, et. al. Most of the posts in this thread labeled "informative" are anything but.
There is a difference between a system design and an implementation of that design in a particular programming language. If the design is bad, the implementation is bad regardless of programming language.
I think it's a pretty safe bet that the intersection of the set of problems for which COBOL is a good fit and the set of problems for which Perl is a good fit is empty.
Someone in this thread bemoaned the fact that COBOL doesn't include a library of things like linked lists. Of course it doesn't, they aren't needed for the sort of problem you solve with COBOL.
COBOL does have built-in support for check-protect printing, fixed-point arithmetic with rounding on request, and binary table searches.
This isn't to say you can't do idiotic things with pointers in COBOL, just that most COBOL programmers have the good sense to solve a business problem in an efficient and maintainable fashion without resorting to such foolishness.
As far as the plaintive cry of "no one teaches COBOL any more," apparently no one can use google any more.
Slashdot Mirror
...except it's wrong.
This is not surprising. Backwards compatibility has never been Microsoft's strong suit, despite the plaintive cries of historical revisionists.
'They'll be doing themselves a disservice if, because of XPM, they're not making sure that all their apps support Windows 7.'
Many Windows apps weren't upgraded to run as native OS/2 applications and look how well that turned out.
Sorry to point out your straw man, but most COBOL developers writing web apps would just concentrate on solving the problem instead of wrestling with the technology.
How about trading in all that 1960s monolithic design for what (I thought) we all learned in the 1970s: UI loosely coupled to business rules loosely coupled to data access. Then you can switch your layers around to whatever the current fad is.
Web client app using SOAP or REST or POX to access a CICS/COBOL server app. The latest technology is available to you to create a rich UI and you've got industrial strength OLTP and DBMS technology for the server side.
Most real-world problems are parallel problems. Even the ones that aren't (say... compiling a file in C) you can usually run a lot of instances of in parallel.
Programming, or compiling programs, is a very tiny subset of real-world problems. Most real-world problems are boring, single-threaded, input-process-output problems.
And experience tells us that most business problems are solved with single-threaded solutions.
Regarding TCO, the C is rarely T. It is, at best, the Total Cost of What I Can Account For Easily. At worst, it is Total Cost of What Supports the Decision I've Already Made. Most often, it's Total Cost of Acquisition.
Programming languages are tools used to solve problems. Any decent programmer will have more than one tool in their toolbox. Some tools are appropriate for > 1 problem space; there is overlap.
/var/log then you're probably trying to use it in the wrong problem space.
The problem space for COBOL is usually confined to, you know, implementing business rules.
If your problem with COBOL is that you're having trouble using it to process
Truly unfortunate are all the comments modded as informative that are anything but. Even more unfortunate is I've come to expect that of slashdot.
I work on z/OS in COBOL, et. al. Most of the posts in this thread labeled "informative" are anything but.
There is a difference between a system design and an implementation of that design in a particular programming language. If the design is bad, the implementation is bad regardless of programming language.
Like most programming languages, COBOL is suited to some tasks and not to others.
I think it's a pretty safe bet that the intersection of the set of problems for which COBOL is a good fit and the set of problems for which Perl is a good fit is empty.
Someone in this thread bemoaned the fact that COBOL doesn't include a library of things like linked lists. Of course it doesn't, they aren't needed for the sort of problem you solve with COBOL.
COBOL does have built-in support for check-protect printing, fixed-point arithmetic with rounding on request, and binary table searches.
This isn't to say you can't do idiotic things with pointers in COBOL, just that most COBOL programmers have the good sense to solve a business problem in an efficient and maintainable fashion without resorting to such foolishness.
As far as the plaintive cry of "no one teaches COBOL any more," apparently no one can use google any more.