Posts in the “programming” category

“What makes a clean test? Three things. Readability, readability, and readability.”

Robert C. Martin (from this twitter page)

“It seems like there is a sound case for a ‘pure’ keyword in future C/C++ standards.”

(A quote from id Software co-founder and technical director John Carmack in this article. I wrote about using an impure annotation in Scala many moons ago.)

“Programming is similar to golf. The point is not getting the ball in the hole, but how many strokes it takes.”

~ Harlan Mills

From the Erlang Programming Rules and Conventions page, Rule 3.13 is “Do not program defensively.”

I like the statement in this image because it says something I’ve always thought: Your design of the data types show that you understand the problem (or not). Every time I start writing code without understanding the problem, I waste a lot of time. (If you don’t understand the problem, exactly what code are you going to write?)

Netflix has a good, short article on their “journey to asynchronous programming.”

“How do we convince people that in programming, simplicity and clarity — in short, what mathematicians call “elegance” — are not a dispensable luxury, but a crucial matter that decides between success and failure?”

~ Edsger Dijkstra

“Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.”

~ John Carmack

This image is from a tutorial titled, Learning FP: Experiences on the Elm language.

I don’t know much about Elm yet, other than it’s an FP language for writing browser code, and it looks a lot like Haskell. As the tutorial author states, “Elm is a programming language that compiles to HTML5: HTML, CSS and JavaScript.” Another good quote is, “There are no worries about bugs due to weird mixed state as the state is always a direct result of input.”

“To me, the most important part of a program is laying out the data structure.”

~ Dan Bricklin

Psychologists have identified a state of mind called flow in which we’re capable of incredible concentration and productivity.

The importance of flow to programming has been recognized for nearly two decades since it was discussed in the classic book about human factors in programming Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1987). The two key facts about flow are that it takes around 15 minutes to get into a state of flow and that even brief interruptions can break you right out of it, requiring another 15-minute immersion to reenter.

DeMarco and Lister, like most subsequent authors, concerned themselves mostly with flow-destroying interruptions such as ringing telephones and inopportune visits from the boss.

Less frequently considered but probably just as important to programmers are the interruptions caused by our tools. Languages that require, for instance, a lengthy compilation before you can try your latest code can be just as inimical to flow as a noisy phone or a nosy boss. So, one way to look at Lisp is as a language designed to keep you in a state of flow.

(From the online book, Practical Common Lisp)

In the last few weeks I learned that Miranda is a lazy, functional programming language that preceded and greatly influenced Haskell. Here are some examples of the Miranda language.

The name of this language, along with the use of the name in the movie Serenity, got me wondering about its origin. BehindTheName.com states, “Derived from Latin mirandus meaning ‘admirable, wonderful.’ The name was created by Shakespeare for the heroine in his play ‘The Tempest’ (1611). It did not become a common English given name until the 20th century. This is also the name of one of the moons of Uranus.”

“C wears well with experience” ~ a quote from the classic book, The C Programming Language.

(I like to think that well-written Scala code wears well with experience.)

Seibel: What do you enjoy about programming?

Peyton Jones: For me, part of what makes programming fun is trying to write programs that have an intellectual integrity to them ... so I think a good attribute of a good programmer is they try to find a beautiful solution.

(A quote from the book, Coders at Work)

From the python.org website: “Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding principles for Python's design into 20 aphorisms, only 19 of which have been written down.”

Parinfer is a tool that is currently in development, and it’s intended to help with the management of all those parentheses in languages like Lisp and Clojure. It looks like it is written in JavaScript, and intended to work with editors like Atom and Sublime Text.

“In Erlang it’s OK to mutate state within an individual process but not for one process to tinker with the state of another process ... processes interact by one method, and one method only, by exchanging messages. Processes share no data with other processes. This is the reason why we can easily distribute Erlang programs over multicores or networks.”

Joe Armstrong, in the book Programming Erlang

This quote from Meredith Monk on LionsRoar.com reminds me of writing software and designing things:

“I’ve always thought that making art is like jumping from the edge of a cliff. At the beginning of every new work — and every day of work — is the unknown. Being an artist is being unsure, asking questions, stumbling around with only an inkling of what will manifest and tolerating the fear of hanging out in the unknown. When curiosity and interest become more present than discomfort, the mystery becomes enjoyable and its exploration vivid and vibrant.”

If you ever want to find some motivation for learning Lisp/Scheme/Clojure programming, I was reminded recently that plugins for Gimp are written in Scheme.

Three golden rules for giving code reviews, from this article on sofiacole.com: 1) Ask questions rather than give statements, 2) Limit personal preference, and 3) Check its purpose.

Regarding the second rule, I don’t know anything about it, as I’ve never been on a team that allowed “personal preference.” Each team (or company) agreed on coding standards, and used them.