Sat, 10 May 2003
I know I gave Paul Graham a bit of a hard time earlier, but I have nothing negative to say about his latest essay, Hackers and Painters. He weighs into the dynamic vs. static languages with this great characterization:
… a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.
I’m seeing writings all about dynamic vs. static languages all over blogspace. In the meta-sense, it’s really interesting to see a common topic over such a wide variety of individual writers. Good writers, must first be good readers.
I also was quite struck by this insightful, but disheartening observation:
Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.
The only slightly contrary point I’d make about the whole essay is that experimental scientific research is a lot more like debugging than he realizes.
Sat, 12 Apr 2003
Paul Graham’s The Hundred-Year Language essay got me to thinking. Which is good because I was somewhat distracted by the secondary between-the-lines message. It’s clear that he’s leading people down the garden
path, trying to lead them to the conclusion: “Lisp is it!” I’d much prefer that he be upfront and state that as his thesis rather than this failure at subtlety. He may well be right. I’m not going to argue against it, but the average developer today is not ready for it. So, how do we pragmatically take mainstream development, and average developers into the future now?
The answer is to get the mainstream to stepwise accept new languages that truly improve productivity. I’m talking about the types of steps such as moving from assembler to compiled languages, from procedural to object orientation, from pointer arithmetic to garbage collection. Each new language we learn requires a time investment — mostly of tools and available libraries; syntax issues get easier with each successive language. Sometimes there’s a deeper paradigm shift such as the steps above. When choosing a new language to learn, that’s what I look for — something that will truly broaden my thinking and that might be that next step ahead that the industry needs to go.
Thinking through this helped me to explain my intuitive reluctance to embrace Objective C. I truly admire the language, especially as an alternative to C++. In an IM session Glenn Vanderburg eloquently said: “It’s an exceptionally beautiful ugly kludge.” I share the sentiment. It was a great engineering choice for Apple because it allows them to have one foot in the C ruled world of unix, and another foot in the loosely typed world conducive to GUI development. Still, it is a step backward to manual memory management for me, and not something that will move me ahead as a developer.
That’s also what bugs me so much about .NET from a technical perspective (I won’t go into the political objections ;-). It’s purely a lateral move that will require a lot of time gaining expertise in the libraries and tools with no fundamental forward motion in the state of software development. I’m probably going to have to learn it in order to pay the bills, but it won’t move me forward as a developer.
I think RubyCocoa is my next step of development.
