AH - the off-site computer systems labs at UW-Madison. ECE had a Harris installed in the basement of their 'domain' back in 1978-79. It was run by graduate students ('nuff said). It had a card reader and a number of 'interactive terminals' (a good come-on line to your date, if you were careful). That Harris was not the most reliable machine in the world and had a pocket watch hanging inside the main cabinet.
After a few nights working with this machine I learned the following:
If the card reader and 'interactive terminals' stopped working at once, look into the glass box at the grad students. If they were consulting the pocket watch and typing on the console keyboard, you could stick around for a re-boot and, perphaps get your job done before the crack of dawn. If, on the other hand, they opened the drawer in the desk and got out the soldering iron it was time to go home and open a bottle of Golden Glow as the night was done.
I spent a lot of time at MACC from 1974-1978. I was an ECE ugrad, but hung around MACC mostly because (unlike Engineering at the time) there were female students there. I think I was a bit after sixscrews' time because we transitioned to the UNIVAC 1110 fairly early on. We still had the FASTRAND movable-head magnetic drum memory, which The Devil's DP Dictionary describes as "a device for storing angular momentum".
Actually, I spent most of my time at the Computer Systems Lab, which was down the hall from the Big Room with all the tables. CSL had the PDP-11, which was "love at first byte". You could sign up for it one hour at a time. Students taking classes that used it had higher priority, but if you had flexible hours you could get enough PDP-11 time to have a lot of fun. Besides, most of your time was keypunching ASM programs so you didn't need that much time actually on the PDP-11 if you were a good programmer.
During one of the years I was there, the computer nerds who never had dates on Saturday night would go across the street to Union South and watch Space 1999 on a communal TV. Space 1999 was on a local station at 10:30 PM. If you've never seen it, it's a British science fiction series that took place on the Moon, which had been knocked out of orbit in 1999 due to a disaster on the far side. Space 1999 had excellent special effects, good actors including Martin Landau and Barbara Bain, and absolutely awful writing which took itself way too seriously. So we watched it for laughs, and there were plenty of those.
@betajet: "Personally, I suspect that those who didn't learn these languages also have a hard time adjusting to OOP languages"
I eventually worked part way through the jungle. A few years ago I had to learn Tcl (Tool Control Language) to run reports against a Unix system. I finally got to the point were I could solve most of my errors on my own, and even found a solution online using a technique that even the Guru who taught me didn't know. Once I got good at it, they gave the task to a contractor and transferred me to another area.
"Personally, I think Pascal is a great first programming language. You get structured control, procedures, clean data structures, and the discipline of declaring all variables before using them. Pascal was designed to tech good programming practices from the beginning."
I learned the value of declaring variables and structures in PL/I. PL/I had both the virtues and the vices of FORTRAN and COBOL. It could be as easy to code but non-self-documenting as FORTRAN but as self-documenting as COBOL.
For example, as in FORTRAN, PL/I variable names starting with I, J, K, L, M, and N defaulted to Fixed Decimal (15); all other defaulted to Fload Decimal (6) (@betajet: This time I did pull my old DOS/TOS PL/I D Language Reference and Programmer's Guide manuals from my bookshelf!). So for a quick and dirty program it was easy to use FORTRAN rules for names. In COBOL, I recall that variable declarations were mandatory; in PL/I they were optional, and one could not only delcare variables and arrays but also structures, which could be used to read a record containing different types of data into a single structure. It was easy to be organized and self-documenting in PL/I if one so desired. ;- )
Maybe 30 years ago I was in a Pascal course for a system that was being delivered to us. I remember the instructor telling us that the first byte of a string set the length, but we had to use a function to change the length. I said, "Why can't I just stomp on the first character to change the length? It's more efficient!" "Because you wouldn't work for me if you did that!" was his reply. "Even if I document it?" "Yes!"
I never had a chance to complete the course, because after a couple of days they hauled me out of the course to work on a datacomm hardware problem for the new system.
A short while later I asked the instructor why the sliding alpha test for the line printer was so slow -- it couldn't even drive a 600 LPM printer at 300 LPM. He said the programmer was regenerating the line on each pass. I asked him why he didn't just create the line, glue of copy of itself to the end, and step across it with a substring loop. He replied that it was written by a trainee. My first thought was, why are we paying to train your programmers?
@betajet with the stern-looking icon: "First, I feel compelled to point out that FORTRAN IV comments begin in column 1. Otherwise columns 1-5 are used for a numeric label for GOTOs and FORMATs. Column 6 is for "continuation", i.e., this card is a continuation of the previous statement."
I sit corrected (I don't stand for much in our office environment -- chairs are so much more comfortable!). Some brain cell connections fade with age, which is why I keep books that otherwise might only induce nostalgia. I should have reached over to my bookshelf for my copy of Programming the IBM 360 by Clarence B Germain, the textbook from out PL/I course which also covered some basic FORTRAN, COBOL and Assembler, as well as some of the various peripherals for the 360. (There is a COBOL coding sheet still tucked away inside the book.)
"Columns 73-80 are reserved for card sequence number so that if you drop your deck you can sort it back into the proper order, assuming that (1) you actually put sequence number in the deck, and (2) you can figure out how to use the card sorter."
LOL! I usually used the shortcut, on smaller decks, of standing the deck up and drawing a diagonal line across the top. At least you could see an out-of-sequence card before you dropped it in the hopper.
"The compiler ignores 73-80 and a common error made by newbies is entering a line longer than 72 characters. I kept an IBM flowcharting template handy since it had a ruler with inches and tenths so you could quickly see if a newbie had characters past 7.2 inches."
Somewhere I still have the steel ruler with numbers every 0.1" to check spacing on printouts, as well as a later plastic version with a yellow highlight strip down the center to make one line stand out when measuring spacing.
"My favorite FORTRAN statement is REAL BUMMER which a frustrated student once included in his FORTRAN program according to an operator."
I like that one! A redundant statement but still all too true at times! It reminds me of the time in Piss Chem Lab when our Inversion of Sucrose experiment wasn't going well. When my lab partner came back from making the carefully measured sucrose solution for the 3rd or 4th time he had the volumetric flask labelled SUCKROSE!
After we broke the stem off the gas cell for the IR in a late-night make-up lab, I sometimes wonder if they graduated us just so they wouldn't have to see us again!
Stargzer wrote: I once read that those who learned on early languages such as FORTRAN, COBOL, BASIC, and PL/I had a hard time adjusting to Object Oriented languages. Sadly, I have found this to be true. :- (
Personally, I suspect that those who didn't learn these languages also have a hard time adjusting to OOP languages. A FORTRAN programmer is used to telling a computer what to do and having it do it. The OOP challenge is figuring out what OOP hoops you must jump through to accomplish this. People who are starting which OOP languages don't have this challenge. Instead, they're faced with so many levels of abstraction that they haven't a clue as to what is going on.
Personally, I think Pascal is a great first programming language. You get structured control, procedures, clean data structures, and the discipline of declaring all variables before using them. Pascal was designed to tech good programming practices from the beginning.
(No, Pascal was not my first programming language. That honor goes to assembly language and FOCAL.)
Stargzer wrote: My favorite FORTRAN statement is REAL MEAN.
First, I feel compelled to point out that FORTRAN IV comments begin in column 1. Otherwise columns 1-5 are used for a numeric label for GOTOs and FORMATs. Column 6 is for "continuation", i.e., this card is a continuation of the previous statement.
Columns 73-80 are reserved for card sequence number so that if you drop your deck you can sort it back into the proper order, assuming that (1) you actually put sequence number in the deck, and (2) you can figure out how to use the card sorter.
The compiler ignores 73-80 and a common error made by newbies is entering a line longer than 72 characters. I kept an IBM flowcharting template handy since it had a ruler with inches and tenths so you could quickly see if a newbie had characters past 7.2 inches.
My favorite FORTRAN statement is REAL BUMMER which a frustrated student once included in his FORTRAN program according to an operator.
EQUIVALENCE is a lot of fun. You can use it to get around FORTRAN IV's restriction that arrays are numbered from 1. I used it to number arrays from 0 when writing a Fast Fourier Transform, which is quite nice in FORTRAN since the language has built-in COMPLEX numbers.
When it comes to FORTRAN, my favorite was the mismatched COMMON
In one module:
COMMON REAL MEAN(2o)
In another module:
Link these modules into your gigunda program and see what happens.
Compilers (and programmers) weren't too smart back then so the first one defined an array of three REALS (the 'o' character was dropped in the first compiler pass, leaving a '2') and the second defined an array of 21 INTs. Any data defined after the first COMMON statement would get stepped on by the second. Much merriment and confusion all around.
I once saw an article about how to self-document your FORTRAN code by using a "COME FROM" statement, which is really just a Comment (FORTRAN comments start with a "C" in column 6, so you could type "C" or a word beginning with "C" in column 6 to designate that line as a comment), like using the keyword "REM" or the word "REMARK" for a BASIC comment (in the days before an apostrophe became common for comments).
My favorite FORTRAN statement is REAL MEAN.
(For those unfamiliar with FORTRAN, variables beginning with I, J, K, L, M, or N default to Integer representation, which is why they are used for loop counters. ALl others default to Real (floating point, with a decimal point). For the variable MEAN to represent a Real Number it has to be specified as REAL.)
Freshman year of college, the fall of 1969, I managed to get into a FORTRAN course, followed by a PL/I course the next semester, both on the college's small IBM 360/25 mainframe. Somewhere in between I learned BASIC - Beginner's All-purpose Symbolic Instruction Code - on an ASR-33 dial-up link to the Dartmouth Time Sharing System (DTSS), the home planet for BASIC. I can't seem to chase it down, but I think the book put together by Kemeny and Kurtz was call "BASIC Programming." It contained small programs showing how the language could be used both in science classes and in the humanities. It was, after all, designed for beginners and for both science/math majors and for non-science majors.
One of the several jobs I held after graduation was teaching computer programming to 4th, 5th, and 6th graders at a private school. We had a TTY link to a local time-sharing system. They had a BASIC program that was a text version of a Star Trek game, so I listed it off and kept a copy of it (I swear, it's somewhere in the basement to this day, along with several boxes of IBM punch cards, including a digitized version of "Nude On A Stool" that used different print characters to shade the picture to a grey-scale representation. It's an object module ready to go as soon as I find a System 360 with DOS ... .).
Several years later I visited a plant in Florida (I think it was Racal or Racal-Milgo) that made an automated tech control system that could be based on a DEC PDP system (10 or 11?) or an 8080, depending on the size of the network you needed to control. The 8080 version had one alarm signal programmed to play the tune of the watch that would wake up the agent in the movie "Our Man Flint." It wasn't written in BASIC, but the plant's mainframe did have a BASIC compiler ...
Now, BASIC can be somewhat portable as long as you don't use PEEKs and POKEs or other special implementation-dependent instructions. I gave one of the engineers a listing of the Star Trek program and not too long after that the sales rep told me that a plant-wide directive went out that there would be no Star Trek during the day shift -- it was slowing down the big PDP system!
I once read that those who learned on early languages such as FORTRAN, COBOL, BASIC, and PL/I had a hard time adjusting to Object Oriented languages. Sadly, I have found this to be true. :- (
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.