State of New Jersey needs COBOL programmers

On 4/5/2020 8:46 PM, ben via cctalk wrote: On 4/5/2020 8:46 PM, ben via cctalk wrote:> On 4/5/2020 6:44 PM, Toby Thain via cctalk wrote: Well, I'd have called the PDP-10 a minicomputer nonetheless, but that's just me. ;) Plus, he was essentially stealing campus resources for personal aggrandizement. Its one thing to mess around learning stuff outside of a course setting. Quite another to take that time, without even asking, in order to turn a profit. Not a fan. As for Lots of Insipid Stupid Parentheses - I can't see that as a beginning language. For anyone. Of the many many (well over a hundred) programmers I worked with outside of a university setting, less than a handful had even *heard* of it. <RANT> As for teaching, there are multiple needs. One size doesn't fit all institutions. One is plain old programming. That does get taught in computer science at universities, but it really ought to be just a means to an end: learning about how programs get written, how to compile them, data structures, semaphores, and so on. During my ECE & CS studies, aside from my student job, I got exposed to: BASIC (1 day) and FORTRAN (both while still in HS), ALGOL (2 dialects), at least 4 different assemblers/machine languages, SNOBOL, LISP, PLUS (Programming Language for UNIVAC Systems - their PL/S), AMINOL (You won't find anything about that anywhere any more), PLUM (Maryland's PL/I subset). During my student jobs I picked up 1410 Autocoder, COBOL and a tiny bit of System/370 Assembler. I learned about data structures up the wazoo: linked lists, stacks, activation records for block structure languages (3 times), and heaven only knows what else, with exposure in many courses. Also multitasking/multiprocessing and all that went with that in multiple courses. And performance measurement and management. [FWIW, this was a time before PASCAL and databases] I got exposed to soooo much stuff that picking up anything else later was essentially trivial. So, when I got to a 360/65-MP and had to do Assember and COBOL no biggy. When we had an Amdahl 470 that was fast enough that poorly designed software had threading issues (as in an idiot developer of a commercial product that expected to use MVS task dispatching priority to avoid deadlocks), that was easy too. As was teaching my co-workers how to use a stack structure to implement a recursive algorithm without having to do recursive subroutine calls. I was able to explain to the other system programmers what happened when utilization of a resource gets to me more than about 80% (think disk queue) and how fast things go to Hades in a handbasket. Queing theory came in handier than heck when I was able to model the effect of response time store and retrieve image documents and demonstrate to our management and our vendor that we would have lines around the block - the project got delayed a year as a result. That is the kind of thing a Computer Science program ought to be doing. Teaching advanced techniques and concepts that can be used in situations folks haven't even discovered that show up 30 years hence. These are things that MOST ordinary programmers are not likely to learn or even need as long as they have access to that kind of expertise. Some call it "ivory tower", but I hope my explanation has shown that there is MUCH more to it than that. (Of course, there are some who learn such stuff and can never apply it, just as there are engineers that can't apply knowledge in that domain, either. That isn't the fault of the university. That is the fault of the student or whomever pushed the student into a situation they were either not a good fit for, or were not sufficiently prepared for.) BUT, outside of a 4 year degree environment, ah, that is an entirely different story. THAT is where we should be teaching "real world problems". Stuff that folks can use immediately to land, keep and succeed at a job. How to do the things that developers encounter each and every day. Current technology and practices and languages that folks are actually using every day. Think about it as an analog between carpentry and structural engineering. When a carpenter really needs engineering help, they go to an engineer (for example, as the contractor did to cantilever the deck off the back of my house), but that doesn't mean that every carpenter should have all the complex skills an engineer has, nor does it mean that an engineer needs all of the skills a carpenter has - though of course the engineer had better know practical and doable from crazy. ;) Trouble arises when you try to teach EITHER ONE broadly/completely in the other environment. The (MIX) assembler course I took focused WAY too much on "niceties" and trying to squeeze out every last bit of performance, instead of teaching conceptually how to wring bits from a turnip. It was a horrible waste of time (and pretty much out of date before it even started.) There can be exceptions, of course. There is a place, for example, for teaching non CS majors in a university setting Python (not my favorite) because they may need it in their studies and research these days. Sorta like teaching Calculus to broad numbers of student who are not math majors. I tried to teach my Linux OS students at a tech school a little bit about how virtual memory worked so that when faced with real world performance issues they might better cope rather than just rote numbers - with mixed results at best, but hopefully some of it stuck. Same thing with multi-processing and what could go wrong with programs and systems in that Linux OS class. But I would never ever dream of teaching them LISP -- wrong place for that. </RANT> JRJ