Hackers and Painters

Embracing the Art of Hacking is a review of a book coming out from O’Reilly called Hackers & Painters. (Thanks to Matt Patey for this reference.)
The similarities and differences between art and programming are hopefully worked out beyond the platitude that “programming is an art.” Art is much more than an “art” in the sense of something that can’t be reduced to rules. Just about everything is a small-a art from cooking to dishwashing. To argue that programming is an Art one would have to look at the practices of training, production and consumption. While I doubt the cultures are that similar at the moment, I expect that programming jobs in North America are going to be increasingly in the entertainment area (from games to special effects) and thus programming as a practice will expand our configurations of the arts.

Open to Providence

One of the ideas that mystified me in Giambattista Vico’s Scienza Nuova (New Science) was the importance of divine providence to his new science. Like piety in Plato, providence in Vico seemed an anachronistic idea in an otherwise modern work.

Now I know less – which is better. Providence is a looking-before. It is the foundation of open (source and research) movements. It is a trust in things working out if you get your part right and open up right to the unexpected. Providence is a making ready for the unexpected future, which unlike teological philosophies that try to control/predict the future, does not presume to know.

Providence is not blind trust in market forces to cure that which we have given up trying to fix. That is a turning away from looking before that is used to justify short term gain. It is a rationalization of selfishness – “if I look after myself here and now the hand of God will fix the downstream consequences”. Providence is a middle way between complete control and abandonment.

The open movements are trying to find that middle ground where you frame a project in a way that leaves it open for others to contribute in unexpected ways.
Continue reading Open to Providence

Slow Food, Slow Code

Slow food is a movement (and registered name) that celebrates hospitality, long slow meals, the preservation of culinary heritage, and rest (after a long meal.) The movement organizes “conviti”, an old Renaissance term of a symposium of ideas while eating (and drinking.)
What about “Slow Code”? Isn’t it time to celebrate the slow appreciation of coding? Rather than be extreme about coding, I think we should slow the pace of programming, slow the pace of new releases, and slow down our computers.
As Willard McCarty has pointed out, you learn so much more when you take your time marking up a text. The encoding journey is its own reward. Why not take longer, learn more, and have a glass of Barolo while you are at it.
Read on for the Slow Code manifesto.
Continue reading Slow Food, Slow Code

Problems with Open Source

Fundamental issues with open source software development is an essay in First Monday that lists 5 problems with many open source tools. The essay is by Michelle Levesque at U of T and is based on her experience with adapting an open source package. The problems are:
– Poor user interface design
– Poor documentation
– Feature-centric development
– Programed for the programmers
– Religious blindness
She points out how many of these problems also apply to commercial developments – the question is whether any of these are linked to the nature of open source development. She doesn’t quite complete the job of working from characteristics of OS development to the problems demonstrating the inherent strengths and weaknesses in the approach. That is perhaps for a further study.
Continue reading Problems with Open Source

Untitled #4

How to write about the relationship between programming and coding? In the dialogue that Steve Ramsay and I gave at the ACH in Georgia we delivered a dialogue called Untitled Number 4: A Brechto-Socratic Dialgoue. This was actually based on a series of playful experiments at writing code that could be read which led to literary program in Ruby that could be read or run. See the IE web archive of what the print version of the program looked like this – Untitled Number 4. A literary program is written like prose with code fragments woven in the flow of the text (as opposed to comments in the flow of the code.) Software can then generate the documentation or the code to be interpreted.

Some of Matt’s students commented on the dialogue. See Code as Writing as Code.

Ruby Book and Share Publishing

Why’s (Poignant) Guide to Ruby is an online Ruby book full of cartoons and commentary suitable for people wondering about languages. Looks great, but I’ve just started it.

What strikes me about the Ruby community is that many of its books are online – the so-far best guide Programming Ruby is also online and, despite having it there, I bought it. I like having things in both print and online for when the book isn’t at hand. (And now they have added a convenient table of contents and jump targets to the online one.) For programming online publication can only help. Anyone serious needs to carefully read to get programming and hence print is still best. The online version helps with looking up and as a preview.

Now I need to think about the poignant side of this e-book. Does its style work?