45+ years ago when I started playing around with this stuff, even then there were too many programming languages for it to be practical for students to take formal courses to learn all the major programming languages, and since then languages and their dialects have continued to change and expand. Students then were given basic understanding of some macro assembler language and at least one procedural oriented language and then expected to become fluent enough in what was available to complete other assignments that depended on programming skills.
Language Reference manuals were your friend. Once you understood the basics, you could pick up a new assembler or higher-level language in few days from the manuals, and become reasonably proficient from examples and experience after a few weeks of use. I think the only semi-formal class I had in the early days was a week Introduction to 1410 Autocoder one summer. By the time I would have taken an undergraduate Fortran class, I already knew the material and became a lab instructor. In graduate school at Purdue, I was expected to already know how to use their computers, which had a different architecture and different dialect of Fortran than I had previously used. After reading the available Assembler and IBSYS manuals, I wrote a IBM 7094 macro-assembler implementation of a bootstrap compiler for a simple language that generated 7094 object decks, and later used reference manuals to become proficient in writing CDC 6000 Assembler code for other projects. One of the most useful courses at Purdue was a survey course that introduced a number of different programming languages, including PL/I, COBOL, SNOBOL, LISP, etc. - enough to give a flavor of the context in which a language would be useful with no attempt to teach proficiency in any language. Considering how many different programming languages I've had to deal with over the course of my career, one of the most useful skills I acquired in school was the ability to learn new programming languages, not the ability to program in some specific language. The most critical programming skills for having a long-term career in this business are the ability to think logically, to understand how to convert requirements into algorithms, and to understand the nature of the process of mapping algorithms to available language features. If you have that, you can quickly learn how to be proficient in some specific implementation language. If you lack those skills, you will be a bad programmer no matter what the language. JC Ewing On 04/21/2010 12:21 PM, Ted MacNEIL wrote: >> Who cares whether the universities are requiring COBOL or not? > > In co-op programmes, it does matter if you are preparing for the work force, > so it (IMO) is important. > >> There are plenty of places and ways to learn it ... > > But, if I'm already enrolled in a Computer Science stream, why should I have > to spend extra (time or money) to learn it, elsewhere? > > I'm not trying to put words in your mouth, but this sounds suspiciously like > the argument: "Universities are not here to prepare you for the work > place; rather to teach you how to learn". > > If that's the case, I disagree. > I enrolled in the University of Waterloo to prepare myself for a career in > computers. > Many, along with UOW, have co-op programes. > All have employment counselling programmes to help place you post-graduation. > If that isn't preparing for the workplace, what is? > > To me, not teaching COBOL, is like a future surgeon not being taught anatomy. > > - > Too busy driving to stop for gas! > ... -- Joel C. Ewing, Fort Smith, AR jremoveccapsew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
