ssrc

Well, there's the relatively recent Schön scandal.

https://en.wikipedia.org/wiki/Sch%C3%B6n_scandal

What I've seen in my career is that when developers were motivated by joy and wonder like 2830 said, or by a sense of mission, etc. productivity and customer satisfaction was high. But when the emphasis turned to productivity (CMMI 5, KPIs, OKRs, Big "Agile", punch clock tool in JIRA issues), the only thing that went up were numbers in a paper.

It's not that money and output are not important for a business, but obsessing with productivity may cause the opposite effect.

And yet at some complexity level you have things like ARINC 653 where the usual implementation is to have a classic RTOS running on each of the partitions provided by the "application executive", and today's serverland is hypervisors running VMs running containers. I believe we are too centered on the "Linux vs Minix" debate while in actual practice both tendencies are reflected in most systems.

I mean, I don't like shellfish and people tell me it's my loss, but as long as I have a balanced diet why should I care?

* This book, PAIP, by Peter Norvig

* SICP, by Abelson and Sussman

* Lisp (3rd ed), by Winston and Horn

* The Art of Prolog, by Sterling and Shapiro

It's like the same book written by different authors, and all of them are good.

In the late 70s to early 80s that wasn't an obviously wrong idea, especially because in the posts above, as I understand it, when they say hardware it mostly means microcode, which is more software than hardware. At that moment many architectures like the iAPX432, Lisp machines, Xerox machines, the VAX, etc. were microcoded.

I try to write informative comments. That said, 99% of the comments I see are

* Useless, like "locks the mutex" before a mutex.lock().

* Contrary to the code, like "This parameter contains the proc name without the instance" and then the parameter does contain the instance.

* Dubious, like it's not obvious what the comment means nor if what you are doing follows the comment or not.

Worst thing is when the code and the comment contradict and there's no good reason to trust one over the other in what the code should do (never go to sea with two chronometers).

I suppose it depends on the codebase you are working on. If it's your own code the likelihood of you agreeing with the comment increases, ofc.

He would have looked like Omni-Man.

The jack-in-the-box (or hellraiser's box) style of OOP. You call a succession of 0 or 1 argument methods that change the object state until suddenly something happens.