bryanb wrote: Sat Jul 11, 2020 9:42 pm
I'm really sorry to hear your father died when you were so young. That must have been tough.
Not really. He hadn't been around for years. I really didn't know him.
bryanb wrote: Sat Jul 11, 2020 9:42 pm
Were either of your parents into technology?
My mother, no. My father was a printer, he worked on web presses for doing very large jobs. Which meant, in some cases, he would be able to bring home samples of his work. He worked for Moebius Printing Company in Milwaukee. One of their customers was Pillsbury. They contracted with the company to produce their annual cookbook that they either gave away for a small fee when you bought a certain number of their products or sold directly.
Well, anyway, if Pillsbury ordered 50,000 or 500,000 books (or sets if it was a multi-book set), the printer is not going to print exactly that many (remember, this was circa 1968 when the technology was based on linotype and rubber mat or steel plate printing.) Depending on how many pages have to print to calibrate the ink, the first one or two copies might be bad as ink properly calibrates on the page. Then, also, pages are not done individually, a book might be printed on a sheet containing 4, 8, 12, or even 16 pages. The pages are cut, inserted in order into the book, then stitched or glued together and a hard cover produced. Now, these machines are fast, paper is supplied on rolls and may run out or it uses a "dual-roll" system so it doesn't. It might be producing a book every 5 seconds. The machine will either run a few "test" or "proof copies" so they can be sure there are no errors, and some are also sent back to the customer for checking and approval.
So, once the full run is approved, the print is done on high-speed web presses. To make sure they have enough in case of accidents, damage, or failures, they might run, say, 1% more. On a run of 50,000 copies (or sets) that's as many as 500 extra copies (or sets). So, the printer keeps maybe 10 to show potential future customers of the work they can do, they send 2 copies (sets) to the Copyright Office in Washington, DC for copyright registration, they replace any damaged ones from the extras, and from any left, the employees can have them.
This was how we got a complete set of the Pillsbury cookbooks every year.
Apparently my father was very smart, and moved up at his company because he could figure out things. Had he been born later, or they had come out earlier, he'd probably have been in computers like I am.
bryanb wrote: Sat Jul 11, 2020 9:42 pmWhat I didn't inherit was his intuitive ability to fix things. I have to read instructions and even then I still largely feel like I'm winging it the whole time.
I know I got that from my father because programming came to me easily and I took to it very well. I've learned a number of programming languages through self-study.
Before that, when I was a kid I was curious about lots of things. I used to take apart telephones, and put them back together,
and they still worked after I put them back.
bryanb wrote: Sat Jul 11, 2020 9:42 pm
Tdarcos wrote: Sat Jul 11, 2020 7:25 pmI would have started ... perhaps 1980... COBOL would have remained dominant through at least 1990, perhaps even up until 1995... there were perhaps... Assembly... Basic... C
Was Pascal on your radar in the 80s? It's actually a little older than C, but it's one of the first languages that comes to my mind when I think of 80s programming.
Absolutely! I still use it even now. After perhaps Basic (my first language) and FORTRAN, I was very good at Pascal but it never gained traction as a commercial language you could make a living using; I wrote more code using Visual Basic in my work than I ever did using Pascal, or Delphi.
The Free Pascal compiler is an open source object Pascal compiler that in terms of capacity I'd put it up against C++ for any application programming. I'd say that, when you include the Lazarus IDE - written using Free Pascal - and its application prototyping tools I would say that you could develop useful programs using it faster, with fewer bugs, and with less trouble understanding a piece of code six months down the road than you could with C++.
bryanb wrote: Sat Jul 11, 2020 9:42 pm A lot of BBS software and BBS doors were written in Pascal, but overall I don't think it made huge inroads commercially and it's pretty much in stick a fork in it territory now.
Free Pascal is still being updated and they do regular releases to fix bugs and improve performance. Look, let's say there are 10,000 people using it. That's quite a few people, but it's noise if we figure maybe a couple million (mostly male) people use Java or C/C++ to develop applications.
bryanb wrote: Sat Jul 11, 2020 9:42 pmI think COBOL has been unfairly maligned over the years.
Yes, it has. It suffers from , as TVTropes put it,
"sesquipedalian loquaciousness" or excessive verbosity, such that you say
ADD OVERTIME-PAY TO GROSS-PAY GIVING NET-PAY.
as opposed to
net_pay := overtime_pay+gross_pay;
in Pascal, or the same using = instead of := in C.
bryanb wrote: Sat Jul 11, 2020 9:42 pmSometimes it seems like its longevity is actually held against it which is crazy to me. If a program written in 1977 works perfectly fine in 2020, that's great!
According to Gartner, 19 of the 20 largest banks use IBM mainframes to run their data centers. That almost certainly means Cobol, and chances are, they could be running code that was, (obviously with modifications) not from 1977, but was originally written back in 1967. The method for calculating a transaction ledger for a checking or savings account, credit card or mortgage, hasn't changed since double-entry bookkeeping was invented in the 13th century. Yes, new features get added but if the core stuff works, and works reliably, it might not get changed.
bryanb wrote: Sat Jul 11, 2020 9:42 pmIf the code is insecure or the program needs to be improved or updated in a way that would be difficult to do in COBOL, then by all means change things up. Still, let's not complain about something that continued to work as intended even as the world changed around it.
You can take an application program written for MVS on a 24-bit IBM 360/93 from 1967, set up the JCL and continue to run the unmodified binaries on a 32-bit 370/145 in 1970, a 4331 on OS/1 under VM in 1980, and a 64-bit z/System on zOS now, and it will still work. These computers have all had new machine instructions and the operating system has new features, but it's still backward compatible with software that ran as much as 50 years ago.
bryanb wrote: Sat Jul 11, 2020 9:42 pmI wish all software worked forever. Perhaps that should be the gold standard for software development, if you will.
Except that people have the pesky habit of wanting changes. As Randall Greaves said in
Clerks, "This job would be great if we didn't have to deal with the fucking customers!"
Back in 1970, a bank would provide you a printed statement once a month, and you had to go to the bank to withdraw cash (or write a check) and to get your balance you either had to visit call your branch to find out your balance. In 1975 or so, you could go to an ATM at your bank 24/7 to get your balance or withdraw money. In 1980 you could move money from one account to another over the phone. In 1985, you could go to another bank's ATM if it was on your network. In 1990 you could call the bank 24/7 to ask a teller for assistance. In 1995 your ATM card has the Visa or Master Card logo and you could use it like a credit card. In 2005 you could use your bank's website to pay bills or transfer funds. In 2015 you could use your bank's mobile app to do all those things on your phone.
Every one of these, and other developments. required changes to existing programs, or new ones, to handle them. Software has to change because the demands we put on it have changed.
bryanb wrote: Sat Jul 11, 2020 9:42 pmCOBOL's English-like syntax still seems modern to me.
The latest release of Cobol adds new features including factories for support of object-oriented programming. It's only because Cobol was invented in America that we think of its language as natural. Because almost all programming languages were developed in America by Americans (Pascal and Lua being exceptions) they tend to seem normal to us. If the development of computers had started in France we might have all sorts of weird keywords for instructions written in those programming languages.