Lunchtime WSJ book reviews

I started a paper subscription to WSJ right as the pandemic started, and as we eat family lunch, with no phones allowed, I quickly skim the paper.

I wish I had done this earlier, but also, I know I couldn’t have, because this “15-minute window” is the only way that that I could physically read it — mornings and evenings are too rushed, and night is for doing uninterrupted work that the fragmented daytime doesn’t permit.

Also, I’ve found the reviews are surprisingly useful, I definitely didn’t expect to be reading and learning about new stuff this way.

Here, as an example, a book review excerpt from today’s (well, yesterday’s, I have a one-day reading lag) paper.

Steve Yegge is always awesome.

I recently came across this excerpt:

Desperate or not, those people aren’t going to work for me. I demand excellence from my co-workers. The disease, nay, the virus of programming-language religion has a simple cure: you just write a compiler. Or an interpreter. One for any language other than the one you know best. It’s as easy as that. After you write a compiler (which, to be sure, is a nontrivial task, but if there’s some valid program out there that you couldn’t ever write, then you’re not justified in calling yourself a programmer), the disease simply vanishes. In fact, for weeks afterwards, you can’t look at your code without seeing right through it, with exactly the same sensation you get when you stare long enough at a random-dot stereogram: you see your code unfold into a beautiful parse tree, with scopes winding like vines through its branches, the leaves flowering into assembly language or bytecode.

When you write a compiler, you lose your innocence. It’s fun to be a shaman, knowing that typing the right conjuration will invoke the gods of the machine and produce what you hope is the right computation. Writing a compiler slays the deities, after which you can no longer work true magic. But what you lose in excitement, you gain in power: power over languages and over language-related tools. You’ll be able to master new languages rapidly and fearlessly. You may lose your blind faith, but you gain insight into the hauntingly beautiful machinery of your programs. For many, it deepens their real faith. Regardless, it lets them sit at the table with their peers as equals.

From here

On type systems

From this thread, a perspective on types:

 

Getting a type system right requires so much detailed specification that the cost is so high that mistakes are actively discouraged. this cost is not necessarily offset by the benefits of using such types, especially not if the program needs to adapt its specification to changing needs discovered only as the program is being used in preliminary forms (often called “prototypes”, but I’m not sure building a prototype only to discard it and build “the real thing” is a good idea. It seems the projects that go into a state of completion such that they are no longer learning from the experience of use are extremely rare. projects that no longer can learn from the experience of use is, however, quite common.

My conclusion is that less strongly typed (i.e., dynamically typed) systems are the ultimate type systems, because they allow growth and change, while preserving the ability to use machine reasoning about types. strict type systems, where every “object” is a type, do not scale well because the computer is not involved in the typing decisions, only in checking them. still, some of the lessons of “object-oriented” programming in the Algol family can be fruitfully employed in dynamically typed systems.

Essentially, it is the a priori aspect of strongly typed systems that is fundamentally unsuited to the process of acquiring the knowledge of the types necessary to implement them and relate them correctly.