While am I an unashamed Reagan worshipper, I don’t particularly miss the regular “nuke drills” that we endured at that time in our schooling.

There was a major concern and daily narrative that the nuclear missiles would be coming at any moment - combined with a completely vitriolic and uncivil standard of discourse and disagreement about what, if anything, should be done about it, which makes today’s political divisions and issues seem silly and quaint in comparison.

“Discussion” of the two solutions would usually result in, at a minimum, brawling, those solutions being either the need for building more nuclear missiles or destroying them all and disarming, with supporters of both sides being accused of treason and wanting to bring about the literal end of the world. Serious threats to kill those on the ‘other’ side became a normal thing - after all, everyone thought the time for civil discourse was past.

This was the era of films such as “Red Dawn” and “Miracle Mile” and “Testament” and “The Day After” and “Threads” and “WarGames” in the theaters, after all. I remember we were made to watch “Threads” in class at one point.

In the schools, it was playing out sort of like a more depressing version of “duck and cover”, that is, “hide under the desk and prepare to die”. That was the default action for all of the drills - hurricane drills, tornado drills, nuclear missile drills.

Oh, and “don’t look at the flash!” (Don’t you know, you’ll go blind doing that?)

Also, tornado drills involved hiding in the hallway and waiting to die. The rest of them were under the desk, however.

Gives a little perspective on why the arcades and gaming were so important and a needed distraction in those days. Millennials these days don’t know how easy they have it.

Missile Command, anyone?

Would recommend to any developer who has a few months of mostly-free-time-ahead to dive deep into the Haskell world without regards to such concerns. Just a few months, then step back. Chances are high from numerous anecdotals including myself you’ll be a whole-new-developer in whatever “real-world languages” you come back to. Not in the ivory-tower over-abstracting sense either. Just in the sense of almost-deeply-instinctively circumventing the more subtle pitfalls of all non-purelyfunctional languages, and devising more-principled, less-convoluted designs. Maybe you won’t have that and maybe you’re already there anyhow — just saying, “chances are high”. In any event such time won’t be wasted and in your future real-world-work you will thank yourself for it, maybe even others (slightly less likely, nobody quantifies or detects infinite-numbers-of-troubles-avoided ;)

FWIW, I don’t think I’ve ever really learned a language from a book. The examples / exercises usually feel too isolated and far-removed from the domains I work on.

I do have a ton of language books, but I use them more as references while I apply the language to some problem. That focuses what you need to know. Usually what I do is to find a bunch of 500-line code snippets in the language, and choose one to add a feature to.

I went through Real World OCaml a few years ago, and it was useful. But then I found an ocamlscheme project that I hacked on a bit, and that was a more useful learning experience. It wasn’t exactly practical, but I think it focused me on a few things rather than trying to ingest every concept in a book. There are still a bunch of things about OCaml I don’t know (and I think that is true for most people).

The Pareto rule generally applies – 20% of the language allows you to solve 80% of problems. There is usually a long tail of features for library authors (e.g. in C++).