By Nathan L. Walls

  • .
  • .
  • .
  • .

Articles tagged “links”

🔗 Harry Leslie Smith, first time author at 87, dies

Katharine Q. Seelye writes in “Harry Leslie Smith, ‘World’s Oldest Rebel,’ Is Dead at 95” - The New York Times:

His son’s death finally tipped him over the edge to start writing his memoirs, at 87. His first was a book called “1923,” the year of his birth, published in 2010. Other books and essays spilled forth. An Englishman who lived part time in Canada, he wanted to shake the world into appreciating what had been won in World War II.

He went on to write four more books and was working on a sixth, about the refugee crisis, when he died on Wednesday at 95 in a hospital in Ontario.

Remarkable. I’d like to be that productive that late in life. Heck, I’d love to be that productive now.

🔗 Fun with parsers

In The Hardest Program I’ve Ever Written – journal.stuffwithstuff.com, Bob Nystrom writes:

The hardest program I’ve ever written, once you strip out the whitespace, is 3,835 lines long. That handful of code took me almost a year to write. Granted, that doesn’t take into account the code that didn’t make it. The commit history shows that I deleted 20,704 lines of code over that time. Every surviving line has about three fallen comrades.

If it took that much thrashing to get it right, you’d expect it to do something pretty deep right? Maybe a low-level hardware interface or some wicked graphics demo with tons of math and pumping early-90s-style techno? A likely-to-turn-evil machine learning AI Skynet thing?

Nope. It reads in a string and writes out a string. The only difference between the input and output strings is that it modifies some of the whitespace characters. I’m talking, of course, about an automated code formatter.

This is an interesting walkthrough. In particular, I like the extra detail on paths pursued and later abandoned in the face of new information, new optimizations, or, particular code paths raising the Halting Problem.

Another element I appreciate here is Nystrom not trivializing the amount of work that went into the project.

🔗 MRI costs: Why this surgeon is challenging NC’s certificate of need law

Dylan Scott Writing for Vox:

Dr. Gajendra Singh walked out of his local hospital’s outpatient department last year, having been told an ultrasound for some vague abdominal pain he was feeling would cost $1,200 or so, and decided enough was enough. If he was balking at the price of a routine medical scan, what must people who weren’t well-paid medical professionals be thinking?

The India-born surgeon decided he would open his own imaging center in Winston-Salem, North Carolina, and charge a lot less. Singh launched his business in August and decided to post his prices, as low as $500 for an MRI, on a banner outside the office building and on his website.

There was just one barrier to fully realizing his vision: a North Carolina law that he and his lawyers argue essentially gives hospitals a monopoly over MRI scans and other services.

I hope Dr. Singh’s lawsuit succeeds. American healthcare in 2018 is supposed to be driven by consumerism. Call around to different providers and determine how much you’ll pay for quality care. Choose a provider based on wherever you want to land on the quality/price matrix that accepts your insurance and you’re golden, right?


Healthcare is not a market. First, not all qualified players can join the market, as is the case here. That effectively prevents Dr. Singh (and others) from putting downward pressure on prices. Second, medical pricing isn’t necessarily discoverable, transparent or negotiable.

🔗 Escaping the SPA rabbit hole with modern Rails

Jorge Manrubia writes:

I remember thinking that Rails was focusing on the wrong target when DHH announced Turbolinks in 2012. My conviction back then was that offering an instant response time to user interactions was key to excellent UX. Because of network latency, such interactivity is only possible if you minimize your dependency on it and, instead, manage a lot of state on the client.

I thought this was necessary for the kinds of apps I was working on. And with that in mind, I tried many approaches and frameworks for implementing the same pattern: Single-page applications (SPA). I believed that the SPA wagon was the future™. A few years of experience later, I am not sure what the future is, but I really want to have an alternative.

This piece really spoke to me. There’s a wide world of possibility with JavaScript, front-end frameworks and Single Page Apps these days. JavaScript’s maturing and growth over the past few years are a fantastic story. What I’m less enthusiastic about is the complexity that seems to pervade front-end development work.

I think a lot of it is getting used to having these rich tools available to solve problems. I also think, in many cases, we’re over-applying these tools when simpler solutions would fit many problems better than the full framework Single Page App approach.

← Previous