What for?
What version of COBOL?
IDENTIFICATION DIVISION.
PROGRAM-ID. Running Old Mainframe Computers.
PROCEDURE DIVISION.
MAIN.
DISPLAY 'I use it from time to time. Not usually though. Mainly I use it for old mainframe computers, that can't be upgraded and are still needed from essential projects,'.
STOP RUN.
http://www.idg.no/computerworld/article97948.ece - these guys went to a yankee college to learn COBOL. Were hired instantly by Capgemini.
>>3,4
idolt.
you can suck my coBOLS if ya know what i mean...
>>2
That DISPLAY
line is too long to be valid COBOL.
I somehow convinced my current employer that I wanted to learn COBOL. I got the job and then got assigned to the network group.
Great Success!!
why would you ever want to learn COBOL? I can see it as a requirement, if your job is maintaining mainframes, but otherwise, why?
Learning things is (almost) never bad.
Learning might not be bad, but it can be useless.
Learning things is (almost) never useless.
Business apps tend to either have a decimal arithmatic library, or subtle bugs. COBOL had real decimal arithmatic built-in to the language, and learning COBOL well makes you appreciate this.
>>10
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
I have learned a fair number of languages, and COBOL is the only one that never made me reconsider how I went about programming in general. It didn't teach me anything new or interesting, and it didn't even give me a new historical perspective.
At best, COBOL is a colossal waste of time.
Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
The easiest machine applications are the technical/scientific computations.
The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
FORTRAN —"the infantile disorder"—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.
PL/I —"the fatal disease"— belongs more to the problem set than to the solution set.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems.
We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer.
The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.
In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.
Projects promoting programming in "natural language" are intrinsically doomed to fail.
I taught myself a variant of purebasic, then went on to learn C and C++ successfully. That stereotype should be gagged, stuffed in a bag, and thrown off a cliff.
>>15 C and C++ aren't that different than modern Basics- including Visual Basic and Purebasic. The BASIC Dijkstra was talking about had no functions, no subroutines, no strings, very little I/O facilities, and lots of GOTO.
>>15
Modern Basics have their own problems, including the tendency to make their users Type In This Very Annoying Fashion With Every Word Capitalized.
BASIC programmers should still be gagged, stuffed in a bag, and thrown off a cliff, however.
>>18
So should C++ programmers.