Draft Unix manual written by Dennis Ritchie circa 1971---at a time when Unix had been running for a "few months" on the PDP-11.

Here's a great blog post on insurance and healthcare: https://healthcareinamerica.us/how-to-ask-good-questions-abo...

I think insurance is not an accurate word for the health care industry. I, like you, think of that word as coverage for risk, and in fact that is how the industry started in sixteenth century Netherlands (mentioned in that blog post).

But the business of insurance is about defining and measuring risk, and putting people into pools so that you can charge the riskier people more.

I don't think that maps well to health care, especially when you consider how good DNA testing will be in a matter of years. "Yup, your kid is in a high-risk pool for leukemia. You get to pay $50,000 a year for family insurance instead of the normal $19,000." [The first number is made up.]

Also, if you run an insurance business and someone with a pre-existing condition knocks on your door, their "market" rates will be their cost of treatment as their risk has become a certainty.

If you don't think charging people based on your best knowledge of the risk is fair, then it is a government program, a forced redistribution of risk across a larger pool; not insurance.

I see what you're saying, thanks.

Also, as far as I know health insurance companies can't charge different rates based on genetic testing. How would this be different, than, say, laws preventing car insurance companies from charging different premiums based on race?

> I hear a lot about OTP and the "let it crash" mantra, but > I just don't quite understand what's so great about it.

The top two for me are:

(1) you start to just program the sunny path. It's faster and more fun to code in this mode. And with pattern matching of function arguments and return values (as well as guards) and you get pre- and post-condition asserts all while programming the sunny path.

(2) What are you supposed to do when your system raises an run-time error anyway? I think in practice, in the majority of cases simply restarting your process in some known state is the best you can do.

And that "start in some known state" is non-trivial for a system that handles concurrent inputs. OTP helps you do that correctly.

Edit: Formating. Add note pattern matching of function args and guards.

By default, the erl interpreter starts up the otp app, which loads lots of modules (50+?) and multiple (5?) different processes. It takes a second. To get things running faster, you can use the -boot argument to erl. There is a appendix in Joe Armstrong's book that steps you through it.

Do gas taxes cover the costs of road repairs and all other government spending that benefits car owners? Hell, even parking isn't self-supporting, why should transit fares cover all operating costs?

Wow, they sure don't. In fact, nationwide gas tax and tolls cover about 32% of highway costs. [http://taxfoundation.org/article/gasoline-taxes-and-tolls-pa...]

(But that just says to me our gas taxes should be higher. :)

The benefit I see is that (at least in Erlang) pattern matching combines pre-condition asserts with programming the sunny path. For example,

   "/" ++ X = HttpRequest:get(path).

will crash if PATH_INFO doesn't include leading slash. Writing just the sunny path and getting asserts "for free" (without any clutter) is a fun way to program.

I also find that statement very readable.

BTW, here's some Java code that does the same thing:

  String Path;
  if (HttpRequest.getPathInfo().startsWith("/")) {
     Path = HttpRequest.getPathInfo().substring[1:];
  } else {
     String emsg = "no match of right hand side value \"%s \"";
     throw new IllegalStateException(emsg.format(HttpRequest.getPathInfo());
  }

Nice. Here's an Erlang version of your code, which I think reads even more like math:

  gcd(A, B) when B == 0 -> A;
  gcd(A, B) when A < B  -> gcd(B, A);
  gcd(A, B)             -> gcd(B, A rem B).

I also really appreciated the posting of more of Dijkstra's thoughts (from rer0tsaz) above, in particular this line struck a chord:

  When programming languages emerged, the "dynamic" nature of
  the assignment statement did not seem to fit too well into the
  "static" nature of traditional mathematics.
  

(Along those lines, Erlang's recasting of the equals sign as a pattern matching operator felt so natural when I learned how it worked.)

[Edit: zap redundant sentence.]

That syntax definitely helps. It is readable even though the variable names are non-descriptive.

> Nokia 635, $40

I don't understand why these low cost Nokia's get so little love here in the U.S. My 520 was $50 a few years ago and is a rock solid piece of hardware. I guess it's the missing apps on Windows mobile?

I bought a Nokia 640 for $99

It's great. I love it. It's not quite as nice as my old phone, but it's 90% of the value, for 15% of the price.

And in some ways, it's better than my old phone (lighter, more damage resistant, better battery life, better cellular reception)

They created a ton. Transistors, solar cells, lasers, satellites, cell phones, LEDs, UNIX and C all came out of that monopoly. That's an unparalleled track record of technical innovation.

With a great deal of government subsidies and grants. Left to own devices, private companies don't do theoretical, long-tail R&D, and you can see this in the fate of Bell Labs under the tutelage of Alcatel-Lucent. Its staff was cut 90% and their projects were subordinated to narrow, short-term commercial objectives with a 3-5 year go-to-market horizon.

Such an environment does not churn out transistors, fibre optics and TCP/IP.