(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Thursday, February 28, 2008
Where the rubber meets the rock
I’d like to make the following observation: Chris Sharma is a talented rock climber. He climbs 5.13 (5.13 is hard!) in his bare feet, while I only climb 5.11 in technical rock shoes. Do we therefore infer that the shoes don’t matter if you’re a great climber? Well, it seems that Chris climbs 5.15 in technical rock shoes (5.15 is even harder than the climb in the video). Maybe, just maybe, shoes won’t make you a great climber but they will make you a better climber.
This weblog is founded on the belief that the single most important thing you can do to write better programs is to be a better programmer. Wasabi cannot cure rotten fish! However, it is a false dichotomy to assert that since the programmer matters, the tools do not matter.
I understand why people buy into the idea that there is a dichotomy. There is a huge industry promoting the silver bullet that there are tools out there that allow inexperienced or apathetic programmers to write good programs. The “industry” spends billions of dollars a year championing the idea that programmers don’t matter, and it is natural to push back against this and thump your fist, to climb on top of your soap box and tell the world to stop paying attention to the tool and start paying attention to the programmer.
But let’s remember the baby before we throw out the bath water. Tools do matter, and they matter in a way that is crucial to software development: better tools make you a better programmer.
The whole point of better tools is that they change the way you write programs. I am not talking about auto-completion here (not that there’s anything wrong with that, but still). Instead, I am talking about things like Parser Combinators, Continuations, Abstractions, Monads, Metaprogramming, Higher-Order Functions, and everything else that lets you build programs out of entirely new pieces, not just putting the old pieces together a little faster.
Tools matter. Not at the expense of believing that programmers matter. Tools matter because we believe programmers matter.
I’d like to make the following observation: Chris Sharma is a talented rock climber. He climbs 5.13 (5.13 is hard!) in his bare feet, while I only climb 5.11 in technical rock shoes. Do we therefore infer that the shoes don’t matter if you’re a great climber? Well, it seems that Chris climbs 5.15 in technical rock shoes (5.15 is even harder than the climb in the video). Maybe, just maybe, shoes won’t make you a great climber but they will make you a better climber.
This weblog is founded on the belief that the single most important thing you can do to write better programs is to be a better programmer. Wasabi cannot cure rotten fish! However, it is a false dichotomy to assert that since the programmer matters, the tools do not matter.
I understand why people buy into the idea that there is a dichotomy. There is a huge industry promoting the silver bullet that there are tools out there that allow inexperienced or apathetic programmers to write good programs. The “industry” spends billions of dollars a year championing the idea that programmers don’t matter, and it is natural to push back against this and thump your fist, to climb on top of your soap box and tell the world to stop paying attention to the tool and start paying attention to the programmer.
But let’s remember the baby before we throw out the bath water. Tools do matter, and they matter in a way that is crucial to software development: better tools make you a better programmer.
The whole point of better tools is that they change the way you write programs. I am not talking about auto-completion here (not that there’s anything wrong with that, but still). Instead, I am talking about things like Parser Combinators, Continuations, Abstractions, Monads, Metaprogramming, Higher-Order Functions, and everything else that lets you build programs out of entirely new pieces, not just putting the old pieces together a little faster.
Tools matter. Not at the expense of believing that programmers matter. Tools matter because we believe programmers matter.
Comments on “Where the rubber meets the rock”:
<< Home
While tools do have SOME effect, assuming a tool is worse just because it doesn't work as well FOR YOU can be false as well. Take Lisp/Scheme for example. The level of control over source it gives you is pretty insane, but if you can't wrap your brain around how to take advantage of the power the tool gives you. Meanwhile some other language's tools may fit your mental model and you can get things out of it that someone else who CAN take advantage of a Lisp can not because THOSE techniques don't fit their own mental model.
Obviously a language like the old DOS basics or really even vb6 (which I get to use in my day job somewhat currently, joy ;)) don't compete with modern programing languages/environments, but past a certain point most current languages/environments are pretty damn good at offering productivity if you use them the way they are meant to be used. It's all about taking advantage of the idioms within the tool to maximize it's power/speed/expressiveness.
Obviously a language like the old DOS basics or really even vb6 (which I get to use in my day job somewhat currently, joy ;)) don't compete with modern programing languages/environments, but past a certain point most current languages/environments are pretty damn good at offering productivity if you use them the way they are meant to be used. It's all about taking advantage of the idioms within the tool to maximize it's power/speed/expressiveness.
Patrick:
past a certain point most current languages/environments are pretty damn good at offering productivity if you use them the way they are meant to be used
It sounds like you are trying to say that if someone is reasonably familiar with a language/environment and "thinks in that languge’s idioms," he cannot be any better if he switches to any other language/environment and learns to think in that other environment’s idioms.
I may misunderstand you, so please correct me if I am wrong. But I will say I strongly disagree with the notion that there are at most minor differences in productivity between different languages and environments for programmers who "get past a certain point" with them.
past a certain point most current languages/environments are pretty damn good at offering productivity if you use them the way they are meant to be used
It sounds like you are trying to say that if someone is reasonably familiar with a language/environment and "thinks in that languge’s idioms," he cannot be any better if he switches to any other language/environment and learns to think in that other environment’s idioms.
I may misunderstand you, so please correct me if I am wrong. But I will say I strongly disagree with the notion that there are at most minor differences in productivity between different languages and environments for programmers who "get past a certain point" with them.
If someone can learn another language then that language could be even more productive, yes. But people's brains work in different ways and aren't always easily reshaped to entirely different mindsets.
The tool must fit the person as well as the person fits the tool. After all, using your climbing shoe example, ill fitting/lose shoes aren't going to help your climbing and could well hinder it because of slippage or the like.
Plus you have to take into account using different tools for different jobs. Languages that don't have good, modern regex support are obviously going to be inferior for text processing, but it could well have excellent support for something like xml dom objects where if you are primarily manipulating dom trees when doing your work this language would be amazing.
Of course this is one of the reasons I've started gravitating towards Scheme, it lets you mold the language to your personal thought processes once you get past a certain skill/knowledge point, so the way YOU see a problem is how you code in it.
Now if a language gives up power x but doesn't give some power y back in place of it, then it likely IS inferior. But most modern languages have enough power/libraries/tools available that they aren't necessarily weaker then any other modern language (take your pick from python/ruby/various .NET languages/Java/etc).
The tool must fit the person as well as the person fits the tool. After all, using your climbing shoe example, ill fitting/lose shoes aren't going to help your climbing and could well hinder it because of slippage or the like.
Plus you have to take into account using different tools for different jobs. Languages that don't have good, modern regex support are obviously going to be inferior for text processing, but it could well have excellent support for something like xml dom objects where if you are primarily manipulating dom trees when doing your work this language would be amazing.
Of course this is one of the reasons I've started gravitating towards Scheme, it lets you mold the language to your personal thought processes once you get past a certain skill/knowledge point, so the way YOU see a problem is how you code in it.
Now if a language gives up power x but doesn't give some power y back in place of it, then it likely IS inferior. But most modern languages have enough power/libraries/tools available that they aren't necessarily weaker then any other modern language (take your pick from python/ruby/various .NET languages/Java/etc).
I may be misreading both posts, but to me it seems like the tools you talk about are not the same as the tools refered to in Jeff's post. To me the definition of tools seems a little blurry; are we talking about language features, supporting software or both?
For example, If I'm working with 'Higher-Order Functions' in a particular language does it matter what OS I use them on?
For example, If I'm working with 'Higher-Order Functions' in a particular language does it matter what OS I use them on?
Patrick:
most modern languages have enough power/libraries/tools available that they aren't necessarily weaker then any other modern language (take your pick from python/ruby/various .NET languages/Java/etc).
I don’t know what “most’ means, other than to think of Sturgeon’s Revelation.
But I do think that some modern languages are significantly weaker than others based on the exact thing I mention above: the better languages make programmers better.
most modern languages have enough power/libraries/tools available that they aren't necessarily weaker then any other modern language (take your pick from python/ruby/various .NET languages/Java/etc).
I don’t know what “most’ means, other than to think of Sturgeon’s Revelation.
But I do think that some modern languages are significantly weaker than others based on the exact thing I mention above: the better languages make programmers better.
Chuck:
The line is blurry because the space of “tools” is blurry. I am deliberately not agreeing or disagreeing with David or Jeff7rsquo;s idea of which OS is a better OS or which framework is a better framework or which language is a better language.
But I can see how an OS would matter. I am not familiar with how Vista works, and I have heard they have an interesting thing called PowerShell, but certainly for a long time Unix shells were far and away orders of magnitude better than Windows shells in how they affected the way programmers think about solving problems.
In fact, one example of this comes from Steve Yegge: if your OS doesn’t have grep, you migt be tempted to write a Java program to find all the phone numbers in 50,000 HTML files.
The line is blurry because the space of “tools” is blurry. I am deliberately not agreeing or disagreeing with David or Jeff7rsquo;s idea of which OS is a better OS or which framework is a better framework or which language is a better language.
But I can see how an OS would matter. I am not familiar with how Vista works, and I have heard they have an interesting thing called PowerShell, but certainly for a long time Unix shells were far and away orders of magnitude better than Windows shells in how they affected the way programmers think about solving problems.
In fact, one example of this comes from Steve Yegge: if your OS doesn’t have grep, you migt be tempted to write a Java program to find all the phone numbers in 50,000 HTML files.
The point in David's quote about not hiring dev using windows, as I see it, is that there is a correlation between good developers and the way they care about their tools.
Jean-François:
That is the way I read it, although I would not personally make an outright HIRE or NO HIRE decision based on OS preference.
On the other hand, if someone insisted that it was all the same, Assembler, VB, Java, C#, Windows, OS X, CP/M, AIX, Solaris, whatever, I would have a hard time believing that I could pierce their ennui.
That is the way I read it, although I would not personally make an outright HIRE or NO HIRE decision based on OS preference.
On the other hand, if someone insisted that it was all the same, Assembler, VB, Java, C#, Windows, OS X, CP/M, AIX, Solaris, whatever, I would have a hard time believing that I could pierce their ennui.
Yeah, I would not base a hiring decision on this alone. But then again, if we go back to the david's context, hiring a dev for rails work, using a mac as a job requirement is no less dumb then requiring 5+ years of experience in whatever technology. Either way, it doesn't tell you if the dev is any good, but it can help as a quick filter.
I had a whole comment about this ready to but then I checked the horst for a pulse and it seemed faint enough already so instead, check out Trotter on Cobra Crack. Damn.
You're either misunderstanding Jeff's objections or trying to reframe the argument. I don't think Jeff phrased it perfectly, but the complaint isn't with tools or camps or what does what better, it's with people who would not only be divisive, but take time out of their (theoretically) busy day of Doing Useful Stuff to make noise about their divisiveness and then revel in it.
I just can't think of a time when dividing the world into 2 camps worked well. It's a recipe for the person who does the dividing to get some notice, but that's about it. Every year something reminds me that you can graduate high school, but you can't leave. People are forever working out how they feel they were mistreated by finding some other group to look down on.
It's not useful and it's anti-ethical to a culture of Getting Things Done/ Don't Repeat Yourself. To me, it not only makes DHH look like a smaller person, but it makes me question the people willing to blindly follow him. "Yeah, Windows sucks! We've always been at war with Eastasia."
I just can't think of a time when dividing the world into 2 camps worked well. It's a recipe for the person who does the dividing to get some notice, but that's about it. Every year something reminds me that you can graduate high school, but you can't leave. People are forever working out how they feel they were mistreated by finding some other group to look down on.
It's not useful and it's anti-ethical to a culture of Getting Things Done/ Don't Repeat Yourself. To me, it not only makes DHH look like a smaller person, but it makes me question the people willing to blindly follow him. "Yeah, Windows sucks! We've always been at war with Eastasia."
Tom:
Allow me to reframe things for you. I am not arguing with Jeff. I am not reframing his post. I am not doing anything except pointing out something I believe to be true and, while I am at it, linking to a friend's post.
Now about Jeff's post. I am not saying anything about what Jeff is saying about anyone else. I am not reframing that, I am ignoring it. If you wish to discuss it, help yourself, but what Jeff thinks of someone else is off-topic.
The only thing about that post that I am discussing here is Jeff's contention that you can use any character you want to win a video game, and that selecting the character is not important.
I have a different perspective about selecting tools, and I am stating my perspective here.
That's all.
Allow me to reframe things for you. I am not arguing with Jeff. I am not reframing his post. I am not doing anything except pointing out something I believe to be true and, while I am at it, linking to a friend's post.
Now about Jeff's post. I am not saying anything about what Jeff is saying about anyone else. I am not reframing that, I am ignoring it. If you wish to discuss it, help yourself, but what Jeff thinks of someone else is off-topic.
The only thing about that post that I am discussing here is Jeff's contention that you can use any character you want to win a video game, and that selecting the character is not important.
I have a different perspective about selecting tools, and I am stating my perspective here.
That's all.
Tools sure are important, but it is also important to separate expertise from the tools. Thinking behind using the tools speaks more about the programmer, than the tools themselves. My thoughts.
anadgouda:
I don't understand the relationship between what I wrote and what you wrote.
I am talking about programming paradigms and you seem to be talking about someone talking about someone else talking about judging someone else again based on their OS of choice.
I am probably not talking about operating systems here. I prefer OS X, but the difference between OS X and Windows to me is the difference between TextMate and Notepad.
Notepad is painful, Textmate is painless. But TextMate doesn't fundamentally change the way I think about programs. I lump it with auto-completion as helping me write the programs I already know how to write faster and more efficiently.
Parser Combinators, OTOH, teach me a whole new way to write programs. Big difference.
I don't understand the relationship between what I wrote and what you wrote.
I am talking about programming paradigms and you seem to be talking about someone talking about someone else talking about judging someone else again based on their OS of choice.
I am probably not talking about operating systems here. I prefer OS X, but the difference between OS X and Windows to me is the difference between TextMate and Notepad.
Notepad is painful, Textmate is painless. But TextMate doesn't fundamentally change the way I think about programs. I lump it with auto-completion as helping me write the programs I already know how to write faster and more efficiently.
Parser Combinators, OTOH, teach me a whole new way to write programs. Big difference.
Reg, sorry if the comment seems out of place, I have not put it very efficiently.
My comment was in context of David's post about judging programmers by their tools. My mistake.
I completely agree with your post that some tools are instrumental in productivity and the way we do things. My attempt was to highlight that the thinking behind decision of using those tools is important as well. And a lot of times it is implicit, unless someone asks us about our choice.
My comment was in context of David's post about judging programmers by their tools. My mistake.
I completely agree with your post that some tools are instrumental in productivity and the way we do things. My attempt was to highlight that the thinking behind decision of using those tools is important as well. And a lot of times it is implicit, unless someone asks us about our choice.
Jeff's contention that you can use any character you want to win a video game, and that selecting the character is not important.
Let me reframe that then: instead of attending classes in college, I spent a lot of time playing the first couple iterations of Tekken. I loved that game. I had a couple of favorite characters, but I liked the game so much* I learned to play with (almost) all the characters. That way I was never stuck if someone took my Hong Kong Supercop before I got to choose, but it also showed me weaknesses and strengths of the characters I did love. It made me a much better player.
In life, I keep coming back to Kipling's line: "What do they know of England who only England know?" It's fine to decide one set of tools is better than another as long as you keep testing those assumptions. If you stop testing them and turn your assumption into "fact", that's bad. If you also spread that "fact" to others with no inclination to ever test other toolsets, that's far worse.
Let me reframe that then: instead of attending classes in college, I spent a lot of time playing the first couple iterations of Tekken. I loved that game. I had a couple of favorite characters, but I liked the game so much* I learned to play with (almost) all the characters. That way I was never stuck if someone took my Hong Kong Supercop before I got to choose, but it also showed me weaknesses and strengths of the characters I did love. It made me a much better player.
In life, I keep coming back to Kipling's line: "What do they know of England who only England know?" It's fine to decide one set of tools is better than another as long as you keep testing those assumptions. If you stop testing them and turn your assumption into "fact", that's bad. If you also spread that "fact" to others with no inclination to ever test other toolsets, that's far worse.
Tom, you are absolutely positively correct. As Oscar Wilde said, "I am not young enough to know everything."
Tom:
Further, and I think this is important, there is a distinction between believing that "some tools make better programmers by changing the way they think about programming" and believing that "I can tell which tools are the best tools by inspection."
The truth is, most things that have turned out to be really interesting looked a little weird or useless or academic at first glance.
So while I strongly believe that tools are important, I am skeptical that I can do a great job of picking the good ones.
Further, and I think this is important, there is a distinction between believing that "some tools make better programmers by changing the way they think about programming" and believing that "I can tell which tools are the best tools by inspection."
The truth is, most things that have turned out to be really interesting looked a little weird or useless or academic at first glance.
So while I strongly believe that tools are important, I am skeptical that I can do a great job of picking the good ones.
That video is amazing. I know I'm not really sticking on topic and I'm paying more attention to the metaphor - but wow. Seeing things like that always changes my perception of what the human body is capable of.
Final Cut (or is it really "finalcut"?):
it's right on topic. If that is what we can do with the coalesced mud of our bodies, what are our minds capable of when we unchain ourselves from Accidental Complexity, when we give ourselves the tools to really open our wings and fly?
it's right on topic. If that is what we can do with the coalesced mud of our bodies, what are our minds capable of when we unchain ourselves from Accidental Complexity, when we give ourselves the tools to really open our wings and fly?
A lot of programmers get really angry when you try to tell them that tools matter.
I think it's because they, as Java programmers for example, want to believe it would be trivial to become a great Ruby programmer if the job required it.
As the saying goes, you can write fortran in any language.
If I'm looking to hire a ruby programmer, I'm not going to hire the java programmer. It will take entirely too long to get him to stop thinking in java and start thinking in ruby.
I think it's because they, as Java programmers for example, want to believe it would be trivial to become a great Ruby programmer if the job required it.
As the saying goes, you can write fortran in any language.
If I'm looking to hire a ruby programmer, I'm not going to hire the java programmer. It will take entirely too long to get him to stop thinking in java and start thinking in ruby.
Sean:
I guess where I'm going with this is that if a Java programmer (like myself) learns Ruby (by which I mean, learns to think in Ruby, not learns to write Java code that the Ruby interpreter accepts), he becomes a better programmer period, even when programming in Java.
To me, that is an optimistic statement about our potential as human beings. I am not saying a Java-only programmer is bad, I am saying he could be even better.
I guess where I'm going with this is that if a Java programmer (like myself) learns Ruby (by which I mean, learns to think in Ruby, not learns to write Java code that the Ruby interpreter accepts), he becomes a better programmer period, even when programming in Java.
To me, that is an optimistic statement about our potential as human beings. I am not saying a Java-only programmer is bad, I am saying he could be even better.
Reg: I agree.
Here's an example:
Today I had to write a javascript routine that automatically put commas in the thousands place. A decade ago, I probably would've written the routine by looping backward through the string and copying chunks of it around etc.. that'd be my C experience kicking in.
However, because of my experience with functional languages, and my comfort in using the functional features of Ruby and javascript, I was able to write it like this:
num="12345678";
num=num.split('').reverse().join('');
num=num.replace(/(\d{3})(?=\d)/g,"$1,");
num=num.split('').reverse().join('');
The benefits are, one, it's easier for me to understand what that code does at a glance. Two, there aren't any off-by-one errors to worry about.
You always hear about people only using 10% of their brain. Well, I'd say most programmers only use 10% of their programming language.
Here's an example:
Today I had to write a javascript routine that automatically put commas in the thousands place. A decade ago, I probably would've written the routine by looping backward through the string and copying chunks of it around etc.. that'd be my C experience kicking in.
However, because of my experience with functional languages, and my comfort in using the functional features of Ruby and javascript, I was able to write it like this:
num="12345678";
num=num.split('').reverse().join('');
num=num.replace(/(\d{3})(?=\d)/g,"$1,");
num=num.split('').reverse().join('');
The benefits are, one, it's easier for me to understand what that code does at a glance. Two, there aren't any off-by-one errors to worry about.
You always hear about people only using 10% of their brain. Well, I'd say most programmers only use 10% of their programming language.
Sean: not to overthink this, but as long as you're using regexp lookahead extensions, why bother with all the reversi?
"987654321".gsub(/(\d{1,3})(?=\d{3}+$)/, "\\1,")
=> "987,654,321"
"987654321".gsub(/(\d{1,3})(?=\d{3}+$)/, "\\1,")
=> "987,654,321"
Devin, very nice. I tried something similar, couldn't get it to work, and went with the reverses because I needed to get it done last week.
<< Home
