Knuth is wrong and should stick to what he is good at.

You are right to raise doubts. He should have called his book:

‘The Craft of Computer Programming’

Using the word ‘Art’ with a capital ‘A’ is incredibly pretentious and philosophically unjustifiable. He could have gotten away with calling it:

‘The aesthetics of Computer Programming’

Using the word ‘aesthetics’ with a small ‘a’, but I feel that ‘Craft’ is better. After all there are many masterpieces in furniture. Code beauty is also a reasonable phrase to use – one that may be less obscure than ‘aesthetics’ (which actually imply a set of informal rules that may help you achieve beauty and harmony).

Having done a degree in Fine Art which involved writing philosophical essays on all of these topics for the Art History component of the course after which I became a programmer, working on UX and a functional end-user programming language, I can confidently assert that writing software has nothing to do with Art, but that the lessons of aesthetics (harmony, symmetry, coherence, concision, appropriate use of emphasis and the suppression of unimportant details) apply very well to code.

I’m still reading through most of the FRP material online. It appears to be well suited to modelling mixed discrete/continuous systems, such as real world robots, but I’m not yet sure that this translates very well to games or graphics in practice. Games are really quite discrete systems at heart. The concept of a frame is fairly deeply embedded, and I’m not sure if the FRP style of doing thing would obfuscate this.

Yes, FRP intentionally obfuscates the discrete nature of typical game implementations. Or put differently, the intent that led to FRP is to unobfuscate the essence of the interactive behavior that typically gets implemented discretely (and imperatively) in applications like games.

A question to meditate over: Are games purely discrete systems at heart? Or maybe are programmers so in the habit of implementing games in a purely discrete fashion that we’ve come to think of games as being purely discrete at heart?

@dons Thanks, I haven’t see either before. I’ll check them out.

I’m still reading through most of the FRP material online. It appears to be well suited to modelling mixed discrete/continuous systems, such as real world robots, but I’m not yet sure that this translates very well to games or graphics in practice. Games are really quite discrete systems at heart. The concept of a frame is fairly deeply embedded, and I’m not sure if the FRP style of doing thing would obfuscate this.

Conal Elliotts ideas for how to apply it to rendering were interesting though.

* LambdaCube – Haskell: Lambda Cube 3D Engine, http://www.haskell.org/haskellwiki/LambdaCubeEngine

* hpysics. http://www.youtube.com/watch?v=uziCn2SBbxs – the Google SoC project using data parallelism for a physics engine

Just demos of using a) reactive programming, and b) data parallelism, to write game engines. Proof of concept stuff.

I suppose that more practical solution would be to adopt a language like ATS, which allows one to work on a very low level but still maintaining safety (you can statically guarantee termination if you wish, for example — not that you’d want to and you can get rid of any “free freed memory” errors, etc.). It has many interesting features regarding it’s type system (that is far more expressive than Haskell’s).

Haskell OTOH is so beautiful.

And thanks, I would like to take a look at Beautiful Code at some point if that’s ok! I’d need to clear some space from my desk first though. I have a more-ridiculous-than-usual pile of backed up reading material to get through first.

http://en.wikipedia.org/wiki/Software_Craftsmanship

“Craft” is used in the mediaeval sense; a term that includes portrait painting, bridge building, instrument making, baking and so on. You can choose your metaphor (art, science, engineering, architecture, recipes) to suit your needs.

The Software Craftsmanship movement also espouses the three stages of competence used by the mediaeval guilds:

Apprentice (can get useful things done; has limits)
Journeyman (has the core skills needed on any normal project)
Master (understands the limits of his craft; ready to push the boundaries)

I’m not sure how practical it is to apply these static categories in such a dynamic field, but it has to be better than scribbling “_x_ years of experience in _y_” on your CV.

By the way, if you haven’t got it yet, I have a copy of Beautiful Code you can borrow. The main thing I got from the book is that beauty is in the eye of the beholder. Code is beautiful when it solves a problem and makes you say, “Wow! I didn’t know that was possible.” In other words, it is contingent on the problems you have and repertoire of solutions you’ve tried. The first time I saw a binary tree I thought it was beautiful.

I suspect the API problem is not unique to software development. Large scale (physical) engineering has similar issues. In fact they have a worse one – previously working components can deteriorate and fail over time. Apart from cosmic rays and hardware ageing around it, software is largely immune from this.

Perhaps it is the close coupling of sofware components that is our downfall at the moment. Maybe we need more redundancy, or more flexible abstractions?

I hadn’t read Andrei Ershov’s lecture before – it’s a good recommendation. He has an interesting point about programming resisting assembly line construction. This seems to be true of any creative process I’ve ever witnessed.

I’m not sure how well it bodes for the future though. I think large scale collaborations have value in there own right, and software engineering is tricky to scale up.