YTechnology

When it comes to coding, we developers take pride in writing programs that run fast and aren't bloated. Taken to the extreme, the cost would be readability, scalability, and maintainability.

We also take pride in writing software that is robust. Programs that recover gracefully when the unexpected happens are not just ideal, but real world requirements. Add security and privacy, and the cost here would be extensive testing, longer periods between roll outs, and a hit to performance.

This tension between efficiency and robustness is something developers wrestle with all the time, and a popular saying among programmers (and engineers) is  "Good, fast, or cheap. Pick two."¹

The impact of Covid-19 has prompted a bit of soul searching regarding efficiency and resiliency in the economy, supply chains, and manufacturing. Evidently, the world has tilted too far toward efficiency, and now finds itself vulnerable to shocks.

For example, Will Oremus explains on Medium that there …

Rules are mostly made to be broken. 
-- Douglass Macarthur
I would emphasize mostly and would add, only when you fully understand the rule and realize it doesn't fit the situation.
The Art of UNIX Programming isn't exactly a rule book.  Rather, it explores the philosophy and culture behind UNIX -- its strengths, weaknesses, patterns, and associated tools.  First published in 2004, it is still relevant today and essential reading for server side developers.

As for rules, in my career writing software, I may have broken two.  The first was using threads. I felt a little panic when I read the section titled Threads -- threat or menace?

It was in the early days of threads, and I had already implemented a threaded server. Did I make a mistake? Could I have done a better job with UNIX processes and IPC?  Raymond argued that the complexity of threads outweighed their advantages.  Performance gains were lost to data locking and synchronization.  Abstraction was compromised because you n…

In my post Swift vs Kotlin, I wrote how the pursuit of "one codebase to rule them all" sometimes doesn't end well. Experience has shown me this, and DropBox also shared the same hard won lesson.  Now it's Facebook's turn.

Facebook's framework -- React Native -- allows you to create native apps for Android and iOS, and proudly carries the catch phrase Learn once, write anywhere. The hidden costs, however, were code bloat, low performance, and increasing maintenance.

When I first heard of React Native, it was from positive press that declared it, without any sense of irony, "one of the best things to come out of Facebook."  But in 2018, AirBnb wrote in Medium that it was retiring its use of React Native:

Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.

Other developers began to wonder if they should drop React Native as well, and Braus Blog tried to …

After using the milk, you:

a) return the carton to where you found it in the fridge
b) return the carton to any free space in the fridge
c) leave the carton on the kitchen table

It doesn't matter that you know how to reverse a linked list; any answer other than "a" suggests you aren't a very good programmer.

Details matter, and symmetry helps you manage them.  Return the milk to where you found it. Close files you have opened.  Free memory you have allocated.

During a talk about Java, memory management, and garbage collection, one speaker (I can't recall his name) explained why Java wouldn't be suitable for embedded systems.  Feigning a heart attack, he clutched his chest and collapsed onto the podium.  Moments later, he raised his hand, saying "I'm okay, I'm okay.  It's just my pacemaker doing garbage collection."

C has no such limitation, and simply stated, for every malloc(), there should be a free(). There are situations though, tha…

I graduated Cornell in 1982, but it was Frank H.T. Rhodes' words from his 1987 commencement speech that I remember most:
"I hope that zest for living, and for giving yourself to others, will accompany you on the continuing journey. For if you mortgage all your todays for some vague and gossamer tomorrow, you may find, in the end, that life's greatest joys and satisfactions have eluded you. As you continue life's journey, I encourage you to ride more merry-go-rounds and eat more ice cream. That does not mean a life of hedonism, but it does mean a life lived in the present, which is the only time we have." I was a serious student, and now feel I should have explored more of my surroundings and availed myself more to the resources at Cornell.  Frank Rhodes created programs and opportunities for his students, and I benefitted unknowingly.   I've written about Cornell here, and how I worked with Penny Rhodes one summer at Uris Library, albeit unknowingly.  Hmm, th…

AI would stop the car in the straightest, shortest, possible line.  That would be my answer to the trolley problem which asks an autonomous vehicle to chose between hitting a pedestrian or avoiding a pedestrian by veering off a cliff and taking you, the occupant, with it.

In the same vein as "Who would win in a fight, Hulk or Superman?" the trolley problem is entertaining but doesn't produce practical answers. As Jason Hong laments in the link above,  "... the problems are framed such that the autonomous vehicle is the only entity with any agency. Or to put it more simply, pedestrians are completely passive and won't try to dodge oncoming vehicles."

Anyone who has done the "hallway dance" would readily agree with Mr. Hong.  Indeed, my wife recounted an accident in her youth when she hit a goat with her car, doing precisely this dance.

We should, instead, focus on long-range embedded road sensors to detect wayward pedestrians, and braking systems …