Tag Archives: craft

Reads: E.W. Dijkstra: “The Humble Programmer”

E.W. Dijkstra ACM Turing Lecture 1972: “The Humble Programmer”:

Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind. Hierarchical systems seem to have the property that something considered as an undivided entity on one level, is considered as a composite object on the next lower level of greater detail; as a result the natural grain of space or time that is applicable at each level decreases by an order of magnitude when we shift our attention from one level to the next lower one. We understand walls in terms of bricks, bricks in terms of crystals, crystals in terms of molecules etc. As a result the number of levels that can be distinguished meaningfully in a hierarchical system is kind of proportional to the logarithm of the ratio between the largest and the smallest grain, and therefore, unless this ratio is very large, we cannot expect many levels. In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 1010 or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.

On “finding truth in the world and about ourselves”

Is Programming more like ‘art’ then ‘science’? A debate that is continuous, but I know where Richard P. Gabriel stands. In 2003 he wrote the forward to “Successful Lisp: How to Understand and Use Common Lisp,” by David B. Lamkins titled “The Art of Lisp and Writing”. Recently it got shared at “Hacker News”.

I admit to knowing enough about Lisp to be intrigued (inspired by it even) but have never used it at work or in a personal project. His essay while touching on some differences between Java and Lisp (and he would know – he worked at Sun), talks more of the act of writing and creation and how programming is akin to that. It was a good read.

Taught that programming–or the worse “developing software”–is like a routine engineering activity, many find difficulty seeing writing as a model or even a metaphor for programming. Writing is creative, it is self-expression, it is art, which is to say it isn’t a science and unlike science and engineering, it isn’t a serious activity. Judgments like this, though, are easiest made by people who don’t seriously engage in making both science and art. Art, engineering, and science are–in that order–part of a continuum of finding truth in the world and about ourselves.

…The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you’re inadvertently making.

There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus–when we are in flow–we need to change things frequently, even while we want the system to be robust in the face of such changes. In fact, most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art. And the reason is that the requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement.

Read the whole piece.

Educational video on ‘Quants’ and their role in the financial crisis

YouTube: “Quants: The Alchemists of Wall Street (Marije Meerman, VPRO Backlight 2010)”

Related: “The Modelers’ Hippocratic Oath”: I will never sacrifice reality for elegance without explaining why I have done so….I understand that my work may have enormous effects on society and the economy, many of them beyond my comprehension.

Programing Links March 7th, 2009

Mike Taylor on Kernighan and Plauger’s “The Elements of Programming Style” (gotta buy and read this)

Eli Bendersky: “The server-side Javascript meme”

PragPub–March 2010: Jason Huggins: “JavaScript: It’s Not Just for Browsers Any More”

“Algorithms are Thoughts, Chainsaws are Tools”, reviewing a short film by Stephen Ramsey on “Live Coding”. Read it and watch it.

Alex Clemesha: “Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip”

Deseret Tech: “NoSQL v. SQL is the worst holy war ever.”

Dennis Forbes: “Getting Real about NoSQL and the SQL-Isn’t-Scalable Lie”

Jesse Legg: “Emacs for Python Programmers: Basics”

the official hudson weblog: “Hudson at PyCon”

The website of Lei Chen: “Setup Perfect Python Environment In Emacs”

Extra Cheese: “Python vs. Ruby: A Battle to The Death”

Martin Fowler: “ConversationalStories”

Code Monkeyism: “What Developers Need to Know About Agile”

Coding Horror: “Cultivate Teams, Not Ideas”

Geoff Sowrey: “What makes a Senior Developer?”

Related:

“The Modelers’ Hippocratic Oath”

Practical Common Lisp

impromptu

Emma’s first poem

My friend Howard Hall is a gifted poet who can coalesce a lot of truth in a few syllables. He’s been featuring among his poems handwritten pieces from others under the tag “secondhand haiku” on his blog (non-breaking space).

Emma has a way with words and stories which is just natural – all children have greater insight into the truth of our existence than we do I think. Over time, we simply forget, or we lose touch with it. I wondered if I could scribble down some sentences of hers, could they could be constructed into a haiku we could send? I had collected a pretty good list of sentences and phrases, but the eureka moment happened when I tried to share with Emma what a poem was. I don’t remember what I said, but when Emma explained it back to me, “When you draw with pictures and draw words, it’s a poem”, it was far better put then I had put it – I felt like I learned something from her. I retrieved “Color with crayons” from her list of sentences and phrases and read it back to her. I told Emma we were going to send it to Howard, that the two sentences were a certain kind of poem. She was pretty excited.

The next challenge was finding a way for her to write it. Emma can’t spell (except for a few words like her name, mommy and daddy) yet of course. She’s just 3 and 3/4 years old! But she can write each letter independently well. Richelle is very talented with visuals and Emma listens to her whenever they work on a project together, so she instructed Emma to write each letter of each word, reading them out as they went. Having her switch markers so that each line could be indicated by color was a smart idea. Emma drew some of her trademark characters (you gotta see the art all over the house!), and we scanned it in and sent it to Howard.

He featured it November 18th!

crayonpoem.jpg

Howard calls non-breaking space “a digital expression of an analog impulse”.

What better way to describe the core that drives so much of blogging, social networking, twittering, and just reaching out online? I can’t think of one.

Some light reading (and research) on non-functional requirements in Agile/Scrum

Agile Modeling: Introduction to User Stories

Mike Cohn’s Blog: Non-functional Requirements as User Stories

aqris: Representing non-functional requirements with user stories

wikiwiki: Non Functional Requirements

Agile Coaching: Non-Functional Requirements: are user stories useful?

Artima: Johan Peeters: Dreams and Nightmares

Representing non-functional requirements is tricky. There are two kinds of non-functional requirement as mentioned in the aquis piece: independent, and distributed. When faced with a distributed non-functional requirement, adding it to your ‘definition of done‘ is called for. As you can tell by the links, there seems to be some difference in opinion in handling ‘independent’ non-functional requirements.

If you have pointers, please share in my comments. And thanks for the input in advance.

A solution to software maintenance from long ago?

Communications of the ACM: You Don’t Know Jack About Software Maintenance:

Software maintenance is not like hardware maintenance, which is the return of the item to its original state. Software maintenance involves moving an item away from its original state. It encompasses all activities associated with the process of changing software. That includes everything associated with “bug fixes,” functional and performance enhancements, providing backward compatibility, updating its algorithm, covering up hardware errors, creating user-interface access methods, and other cosmetic changes.

In software, adding a six-lane automobile expressway to a railroad bridge is considered maintenance–and it would be particularly valuable if you could do it without stopping the train traffic.

Related: Slashdot thread