hhyndman

What a great idea. I am a musician and use an iPad for my scores. It would be wonderful to replace my glasses with a pair that can display the music.

I noticed the iron ring on your pinkie -- Canadian engineer?

My Roland piano, with weighted keys, has MIDI.

Back in the early 70s, I wrote software for the PDP11/20 (in ASM) to collect data from counters for accelerated particles. I recall handcrafting interrupt service routines to ensure they stayed ahead of the counters. And using paper tape to load the software after I hand-toggled the bootstrap loader.

For the next 15 years, I was an APL programmer, and later a Q/K developer. It would have been a hoot to use K was back in the 70s to analyze the collected data!

What a fun project! Bravo

An interesting article relating to "operator precedence is broken". https://www.foonathan.net/2017/07/operator-precedence/

APL was the first language I learned in school and I was thrown by the precedence of the mathematical operators, but once the other operators were put in play, it was an incredibly simple rule -- and rarely did I or other APL developers have bugs relating to order of operation.

I then moved to C++ and was gobsmacked the the precedence rules and was forced to use parentheses to get things right. I have seen hundreds of bugs produced by programmers that tried to be clever and avoid parens relying on their faulty memory of the precedence priorities.

Just look at the C++ Operator Precedence table listed at the following URL. It's wild!

https://en.cppreference.com/w/cpp/language/operator_preceden...

Roger was a colleague of mine when I worked at IP Sharp. Lovely guy. My condolences to his family. Rest in peace.

An excellent article. Thank you for your insights. I used to run a software engineering practice and I must admit that almost all of your points resonated with me.

I'd like to add that one should catch oneself when falling into the "Perfect is the enemy of good" trap. As engineers, we would like things to be perfect, but sometimes at the peril of late delivery, little feedback, and development of features not required.

Back in university (1974), I took a course in AI. The prof wanted us to write a brute-force solution to solve the 8-queens problem -- any language!

I wrote the solution in APL in about an hour and it only had 3 lines of code. The rest of the class spent days on their terminals and keypunches trying to solve it. Most solutions took hundreds of lines of code.

I got a D from my professor. I questioned why and was told that it was unreadable, and that the solution was inefficient. This annoyed me because he didn't know APL, and I figured that since I solved the problem in one hour, while the rest took days, it was very efficient.

I protested the result with the department head (who liked APL) and ended up getting an A+. As you can imagine, all the rest of my assignments, written in a variety of languages, were graded by that AI prof with significant prejudice.

I passed nonetheless. I loved APL and ended up working for one of the major APL providers as my first job out of school.

The APL language has this system variable ⎕IO (called QUAD IO -- index origin), which could be set to 0 (for 0-based indexing) or 1 globally in the environment.

Also, ⎕IO can be set as a local variable of a function to limit the scope of the indexing origin, which made it convenient to simplify the code to implement certain algorithms.

While studying Comp Sci at University of Toronto in the early 70s, I recall the 360/20 was used as a node to connect suburban colleges (Erindale and Scarborough) to the "mainframe", which was a 360/65 (I believe).

We would iterate from the keypunch room, to the 360/20's card reader, and wait for the mainframe to process our code and transmit the code output to the local printer, for review at tables large enough to page through fan-fold paper, to check and mark-up the code. Back then, we didn't need watches to remind us to stand up and walk around every 30 minutes -- the coding workflow forced us to!

Reading the Principles of Operations for the 360/20, the processor was supported half-word (16 bit), and had no floating point, but support packed decimal numbers. Our machine had 16K.

It was great to see the article -- made me reminisce about the days of me carrying boxes of punch cards and inches of output back and forth to my residence.

I downloaded a very high-resolution version of this map and created a 1m x 1m "poster" in my office. Accompanied with an illuminated magnifying glass, I often take a nice break from the computer monitor to examine the odd details Monte provides in his pictures.