(Message perl/com:871) showproc perl/com/871 /home/mjd/bin/mailpager /home/mjd/MH-Mail/perl/com/871 Return-Path: Clinton.Pierce@decisionconsultants.com Return-Path: Delivered-To: mjd-filter-deliver@plover.com Received: (qmail 13332 invoked by uid 119); 12 May 2000 17:44:21 -0000 Delivered-To: mjd-filter@plover.com Received: (qmail 13327 invoked by uid 119); 12 May 2000 17:44:19 -0000 Delivered-To: mjd@plover.com Received: (qmail 13324 invoked from network); 12 May 2000 17:44:18 -0000 Received: from cor-exc.dcicorp.com (12.15.3.16) by plover.com with SMTP; 12 May 2000 17:44:18 -0000 Received: by cor-exc.dcicorp.com with Internet Mail Service (5.5.2448.0) id ; Fri, 12 May 2000 13:40:56 -0400 Message-ID: <57808C6BAC6FD211AFF500805F0DEE838FD032@det-exc.dcicorp.com> From: "Clinton Pierce (DET)" To: 'Mark-Jason Dominus' Subject: RE: COBOL stuff Date: Fri, 12 May 2000 13:41:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I'd like to pitch in a couple of other traps that I see happen, include these if you'd like. (I'm currently teaching a class of 18, with 10 being dyed-in-the-wool COBOL IMS/Mainframe programmers--so this is all fresh.) Questions/Edits to your article follow this. The first mental trap that catches COBOL programmers early on is the concept of a scripted application program. To them, the application is a compiled object loaded when needed but to shorten the edit-compile-run cycle down to two steps seems strange. Also strange is the concept of a text file as a stream. This kind of file has an equivalent in COBOL, but my students are used to fetching records from an MQ Series or DB2 database. Reading lines of text (records) and taking time to parse them into fields seems redundant. This usually starts a long discussion about why Perl programs bother to construct formatted text files -- only to have to parse them apart again; instead of simply letting the record-reading library routines parse things for you. Inter-process communication, as simple as backticks or system(), seem to throw them as well. What seems more natural is to encapsulate the functionality given by the external program in a library routine and simply call that as a native function. If a separate program is needed, one is written as a wrapper for the library routine. Cooperative (external) programs just aren't in the design of most Mainframe systems, apparently. I'm happy to report, they take to the concept of CPAN and modules like ducks to water. Including some other program's functionality into your own at run time (actually compile time for Perl) seems natural. Where teaching COBOL programmers Perl becomes bizarre is when the topics of CGI programming or Tk (GUI) programming come up. Normally these people aren't writing small programs that do a task and exit as CGI does (without saving state). And when teaching Tk, with no exposure to event-based programming, it takes a while to train them that a program can just "go to sleep" and wait for an event and then dispatch the event to a handler. This concept just doesn't exist in their world at at. If they've done any RPG programming it's possible to lead them down the path that events are like handlers on different record types on an incoming data stream--but the analogy only goes so far. Now for edits: > >In fact, they were totally unfamiliar with the punctuational >conventions that are shared by every programming language of the last >forty years, including Fortran. They thought it was a clever >innovation that Perl has operator precedence and follows the same >order of operations that you learn in grade school. > Any other punctuational conventions? brackets for array indexes? You mentioned the curly-brace blocking? I think this is amusing. Fortunately most of mine have at least SEEN another language, they just work all the time in COBOL. >That reminded me of a story about the mainframe people seeing Unix for >the first time back in the 1970's, and they asked how you allocate a >file on unix. Dennis explained that you didn't have to allocate a >file, you just create it, but they didn't get it. Finally he showed >them > > cat > file > >and they were astounded. ``You mean that's *all*?'' This was kind of >like that. Good story. :) >Some things they picked up on much *better* than other programmers I >have taught. As soon as I explained the pattern /cat$/, someone >pointed out that that wouldn't match unless you had chomped the string >first, Which string? The one to be matched against? It took me a couple reads to parse that. >It was an interesting experience. This begs the question though, did they learn Perl? I know with the Wizard-in-training MJD teaching, they surely had to...but I know what a great instructor you are. (stroke...stroke...) Did they come away with sort of a rudimentary knowledge of programming in Perl, or are these gonna be great Perl programmers that just trip over syntax for a while? This is a whole new way of thinking for them. In my groups anyways, I seem to get a 50/50 mix with Mainframers. Some of them leave the class still thinking about things the Anti-Perl way, and I'm not sure if they'll ever get it. The rest just sort of fall into it naturally. (Message perl/com:870) showproc perl/com/870 /home/mjd/bin/mailpager /home/mjd/MH-Mail/perl/com/870 Return-Path: mjd@plover.com Return-Path: Delivered-To: mjd-filter-deliver@plover.com Received: (qmail 12821 invoked by uid 119); 12 May 2000 17:00:53 -0000 Delivered-To: mjd-filter@plover.com Received: (qmail 12815 invoked by uid 119); 12 May 2000 17:00:51 -0000 Delivered-To: mjd@plover.com Received: (qmail 12811 invoked by uid 119); 12 May 2000 17:00:51 -0000 Message-ID: <20000512170051.12810.qmail@plover.com> To: clintp@dcicorp.com cc: mjd@plover.com Subject: COBOL stuff Date: Fri, 12 May 2000 13:00:51 -0400 From: Mark-Jason Dominus I was hoping you could erad this and jot down any notes that might come to mind. I'd like to post a short note about it on perl.com. If you do contribute some notes, I can pay you $100. If you're too busy, don't worry about it. ------- Forwarded Message To: perl-training-instructors@jhereg.perl.com cc: mjd@plover.com Subject: COBOL world Organization: Plover Systems Date: Thu, 20 Apr 2000 20:55:13 -0400 From: Mark-Jason Dominus I just got back from a 4-day beginning perl class at the Philadelphia Gas Works. Sure enough, my class was populated by experienced programmers. What I didn't know was that their only experience was in COBOL. This was real interesting. All my expectations were turned ninety degrees from where they needed to be. For example, none of these folks had ever seen a block-structured programming language before. it took several repetitions before they got confortable with the idea that the curly braces control what happens. In fact, they were totally unfamiliar with the punctuational conventions that are shared by every programming language of the last forty years, including Fortran. They thought it was a clever innovation that Perl has operator precedence and follows the same order of operations that you learn in grade school. All this tended to put me into total-novice mode, and so I found myself wanting to explain what a variable is, and of course that's inappropriate because they all know what a variable is already. In fact, they got bored while I was explaining buffering, because they all know all about buffering already. I didn't have to explain filehandles; they already understand filehandles. But they use weird jargon: They say ``Oh, you're establishing addressibility on the file.'' Then they enthuse about how easy it is to do in Perl. That reminded me of a story about the mainframe people seeing Unix for the first time back in the 1970's, and they asked how you allocate a file on unix. Dennis explained that you didn't have to allocate a file, you just create it, but they didn't get it. Finally he showed them cat > file and they were astounded. ``You mean that's *all*?'' This was kind of like that. Some things they picked up on much *better* than other programmers I have taught. As soon as I explained the pattern /cat$/, someone pointed out that that wouldn't match unless you had chomped the string first, because of the trailing newline. I had to explain what $ really does. I've never had to do that before, because I've never met anyone before who picked up on that so fast. Usually Perl programmers remain blissfully unaware of this problem for years until someone points it out to them. At Perl conferences when I explain this about half the audience is thunderstruck. I ascribe this to the fact that the COBOL folks found the idea of a newline character so strange and new. They were constantly aware of it, like a stone in the boot. One of the exercises asks you to make a copy of a file in which all the lines that begin with # have an extra # inserted on the front. The sample solution looks like: while (<>) { print '#' if substr($_, 0, 1) eq '#'; print; } The COBOL programmers found this bizarre. One of them asked if a beginner could reasonable be expected to come up with something like that. I said yes, and then I thought about it and said that I had taught some classes in which every student decided to do it that way. Then I thought some more and realized that it was a very natural way to solve the problem---if you were already a C programmer. Clint Pierce says that you have to think of them as bright programmers who have been living in a cave for twenty (or forty) years. That's exactly right. It was an interesting experience. Mark-Jason Dominus mjd@plover.com I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details. ------- End of Forwarded Message