Posts in the “programming” category

Type Safety definition

I saw this definition of type safety yesterday in a book named Programming TypeScript and I thought it was very simple and good:

Type Safety: Using types to prevent programs from doing invalid things.

Yoda Conditions

I had never heard of the term “Yoda Conditions” until now, but I have seen them in some Java code where programmers put the constant first in an effort to avoid null pointer exceptions.

Joe Armstrong: Why OO Sucks

Famed programmer Joe Armstrong passed away this weekend. He created the Erlang programming language, based on the actor model, and without using Google, I’m pretty darned sure that Erlang had an impact on Akka, the very cool actor library for Scala. Here’s an article Mr. Armstrong wrote some years ago, titled, Why OO Sucks (OO as in OOP).

Testing takes time, just like structural analysis takes time

“Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary.”

~ Neal Ford (as seen on this tweet)

A nice story about Lisp

twobithistory.org has a nice story about Lisp titled, How Lisp became God’s own programming language. That page links to Paul Graham’s old Beating the averages post where he shares this Eric Raymond quote: “Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.”

An honest reviewer of apps

A friend of mine is an honest reviewer of apps. When I asked her to use the AAA iOS app while we were driving back from Florida, she said, “OMG, please don’t make me use that piece of crap again.”

The lack of type safety was difficult to scale ...

From this AirBnB article about using React Native: “JavaScript is an untyped language. The lack of type safety was both difficult to scale and became a point of contention for mobile engineers used to typed languages who may have otherwise been interested in learning React Native ... A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone.”

Kent Beck’s Four Rules of Software Design (also known as “Simple Design”)

For the first time in many years I just came across Kent Beck’s Four Rules of Software Design:

  1. Passes the tests
  2. Reveals intention (should be easy to understand)
  3. No duplication (DRY)
  4. Fewest elements (remove anything that doesn’t serve the three previous rules)

There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so ‘passes the tests’ takes priority over ‘reveals intention.’”

For more information on Kent Beck’s Four Rules of Software Design, see that link, or this link to the original rules on c2.com.