I suppose, as I claimed that I would somehow defend Blub programmers, that I should mention why anyone would be better off hiring a Blub programmer than a Hacker.
Hackers are interested in technology rather than "the business process". This is evident in the eligibility requirements as stated by the Hacker pundits. In Raymond's essay on How to Become a Hacker, he waxes wonderful on the freedom and power of being such a person. The most motivating thing (to me) in the essay is how Hackers see the world as full of interesting problems and have a desire to solve them. Then mentions something loopy like how I should download an open-source *nix system and make changes to it. My favorite thing about programming is division of labor, and keeping the resources on my computer managed is definitely someone elses responsibility. I don't even like messing with partitions.
Peter Norvig has a nice essay called Teach Yourself Programming in Ten Years. I was rolling with it, singing along with the choir, when he suggested I memorize, "how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk." I have a hard enough time remembering my passwords!
And the list goes on: Raganwald wants you to be interested in writing domain-specific-languages, and Joel thinks you have to have a firm grasp on pointers to be worthwhile. Paul Graham suggests that one base a programming language choice on the ease of use of library functions only when writing "a short, throwaway program." Bleah!
The more I look at it, the more Hacker pundits think the interesting problems are close to the metal. They are really interested in computer hardware and fundamental structure. So what to Blubs find interesting?
Blubs see computers/networks/IT in general as a means to solve interesting problems. We are "business analysts" rather than "system engineers," and we are more interested in facilitating and improving the social/organizational process via technology than in technology itself. Rails and Django are great because they accelerate the capacity to get things done for the organization, not because they are great examples for other domain-specific language development. (And yes, I realize that engagement with technological possibility is a requirement for optimizing an organization's use of technology to solve its non-technological problems.)
So why would you hire a Blub rather than a Hacker? What if your organizational problems are not technological? What if your software does not give your organization a competitive edge, but you have a jillion legacy applications that need to stay running to keep the administration of your organization afloat? What if your upper management are more interested in the comparison of the legacy app running on the mainframe with a commercial ERP than the possiblity of open-source cooperation? Then you probably need people skilled at keeping the crank turning with Blub programs than starry-eyed radicals who want to rewrite the system using DSLs they invented themselves.
Wednesday, January 17, 2007
Saturday, January 13, 2007
Why the Name
My wife tells me that my posts require too much context, and if I want anyone to understand what I am saying, I should provide a little background.
"Erethizon" is the genus of the North American porcupine, and I have been using "porcupine" and its cognates to generate usernames for years.
'Blub' is an imaginary programming language coined in an article by hacker-pundit Paul Graham. This language lies somewhere in the middle of the language "power-continuum" (which has Lisp at the top and assembler at the bottom). The language itself is not important to Graham's discussion, but rather the attitude of the people who program Blub.
One of the big dreads of hacker-pundits like Raganwald is that they might be Blub programmers (just read his article and the subsequent commentary). So as I read the hacker pundits, I keep coming across sneering disdain towards Blubs.
Starting this blog was a reaction to this disdain. It is an attempt to rise in the defense of we, the Blubs.
"Erethizon" is the genus of the North American porcupine, and I have been using "porcupine" and its cognates to generate usernames for years.
'Blub' is an imaginary programming language coined in an article by hacker-pundit Paul Graham. This language lies somewhere in the middle of the language "power-continuum" (which has Lisp at the top and assembler at the bottom). The language itself is not important to Graham's discussion, but rather the attitude of the people who program Blub.
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
One of the big dreads of hacker-pundits like Raganwald is that they might be Blub programmers (just read his article and the subsequent commentary). So as I read the hacker pundits, I keep coming across sneering disdain towards Blubs.
Starting this blog was a reaction to this disdain. It is an attempt to rise in the defense of we, the Blubs.
Sunday, January 7, 2007
Emacs: cool and wrong
I have to say that emacs has several features that make me almost willing to put up with its idiosyncratic nonesense. (And a big thanks to Raganwald for being snotty about emacs.)
The first things are the kill-ring and registers. I have never worked with an editor that understands that I might want to have more than one thing on my "clipboard" to have available for pasting ("yanking" in emacs parlance), and emacs makes it simple. Well, perhaps not "simple" simple, but relatively easy and almost close to painless.
The second things are how it handles searching through text. Not only does it do incremental searching, showing you all your matches and highlighting the one you are currently "on," but it remembers where you were when you started. So you can easily (as long as you remember the particular key combination) go back to where you were when you started. Also, when doing search-replace, you can enter "recursive-mode", where you can go ahead and type whatever you want at the point in question, then jump back out of the mode and continue search-replacing. How cool is that?
But despite these features, I cannot see myself actually using emacs to do my job. It is too different, and you have to really embrace it to get full value from it. I am a blub programmer; I don't want to embrace anything hackerish too tightly. I need to be able to jump to the next cool thing with as little baggage as possible (and fyi, for me Eclipse is the current cool thing). Other editors work in similar ways (ctrl-c/x/v, to copy/cut/paste vs emacs crazy key combos for kill (but leave behind), kill, and yank), and I can use my experience with other applications to get up to speed on any given gui editor, but emacs seems to be a dead end.
Lisp strikes me as exceedingly similar (and not just because Lisp and emacs are so closely bound). Lisp and emacs are both very powerful, abstract, extensible, and used by frighteningly bright people. But the very power seems to isolate them, as if with all that power they do not have to interact with the great unwashed blub programmers. One of my favorite lines by Paul Graham is in his essay on why programmers at startups should use Lisp. The quote is actually about choosing a language to work in, and he says, "And if you're writing a short, throwaway program, you may be better off just using whatever language has the best library functions for the task." I live and die by libraries other people write, and the community, the libraries, the tutorials, and the general online help are critical to my language decisions. The power of the language for me comes from the community that uses it, not the abstraction of the language itself.
>>PS
I have just been playing with Django, and I found emacs pretty useful.
The first things are the kill-ring and registers. I have never worked with an editor that understands that I might want to have more than one thing on my "clipboard" to have available for pasting ("yanking" in emacs parlance), and emacs makes it simple. Well, perhaps not "simple" simple, but relatively easy and almost close to painless.
The second things are how it handles searching through text. Not only does it do incremental searching, showing you all your matches and highlighting the one you are currently "on," but it remembers where you were when you started. So you can easily (as long as you remember the particular key combination) go back to where you were when you started. Also, when doing search-replace, you can enter "recursive-mode", where you can go ahead and type whatever you want at the point in question, then jump back out of the mode and continue search-replacing. How cool is that?
But despite these features, I cannot see myself actually using emacs to do my job. It is too different, and you have to really embrace it to get full value from it. I am a blub programmer; I don't want to embrace anything hackerish too tightly. I need to be able to jump to the next cool thing with as little baggage as possible (and fyi, for me Eclipse is the current cool thing). Other editors work in similar ways (ctrl-c/x/v, to copy/cut/paste vs emacs crazy key combos for kill (but leave behind), kill, and yank), and I can use my experience with other applications to get up to speed on any given gui editor, but emacs seems to be a dead end.
Lisp strikes me as exceedingly similar (and not just because Lisp and emacs are so closely bound). Lisp and emacs are both very powerful, abstract, extensible, and used by frighteningly bright people. But the very power seems to isolate them, as if with all that power they do not have to interact with the great unwashed blub programmers. One of my favorite lines by Paul Graham is in his essay on why programmers at startups should use Lisp. The quote is actually about choosing a language to work in, and he says, "And if you're writing a short, throwaway program, you may be better off just using whatever language has the best library functions for the task." I live and die by libraries other people write, and the community, the libraries, the tutorials, and the general online help are critical to my language decisions. The power of the language for me comes from the community that uses it, not the abstraction of the language itself.
>>PS
I have just been playing with Django, and I found emacs pretty useful.
Chimpanzees and Orangutans
Years and years ago, I read an article in a magazine at the dentist (I can't recall if it was Psychology Today or People) about orangutans. One of the major themes of the article was how much more difficult it was to work with orangutans than chimpanzees, either in research or in circuses. The main difference seems to be that chimpanzees react in ways that make sense to logical positivists, and orangutans don't. Also, orangutans have odd senses of humor. In short, organgutans are a lot harder to manage, but they seem to be more fun.
For me, the clearest distinction between these apes is in the way they solve problems. Some researchers were engaging in one of those tedious behavioral modification experiments, where the subject was given a reward for doing the appropriate thing. In this case, the apes were given a board with a variety of different holes cut into it -- stars and diamonds and so forth -- and a set of blocks cut to fit the holes. It is very much like a game I played as a child in which the board would jump up at you if you failed to put all the pieces in in time (a game which accounts for my jumpy disposition). After the ape put a piece in, he or she would get some sort of ape treat.
The researcher said that chimpanzees were very cooperative subjects in this experiment. The chimp would pick up a piece, look at it, move it around, try it in various holes, and so forth. The chimp seemed to be solving the problem in a straightforward, empirical way. And most importantly, when the chimp was not interacting with the pieces, the chimp was off doing something else. So the researcher knew when to pay close attention, and when she could let her attention wander.
The orangutan was not so easy to monitor. The orangutan would scratch itself, then maybe look at the pieces, then look off in the distance, then look at the board, then groom a little, and at some point would simply pick up a piece and put it in the correct hole. The orangutans were not faster than the chimpanzees, but the method by which the orangutan solved the problem was not evident. And the researcher had to pay close attention all the time, as she never knew when the orangutan might act. In fact, in several cases, the researcher noticed the piece was in the hole without having seen the orangutan put it in the whole, which made positive reinforcement problematic.
I have a lot of empathy for the orangutans, and almost none for the chimpanzees. When I solve a problem, it is very rarely by methodically plugging away at it. I am more likely to read comics, chat with my officemate, play flash games, and so forth when I am stuck, and eventually a solution often comes to me. Or I get so bored that I try the plugging method.
Chimpanzees are much easier to manage.
For me, the clearest distinction between these apes is in the way they solve problems. Some researchers were engaging in one of those tedious behavioral modification experiments, where the subject was given a reward for doing the appropriate thing. In this case, the apes were given a board with a variety of different holes cut into it -- stars and diamonds and so forth -- and a set of blocks cut to fit the holes. It is very much like a game I played as a child in which the board would jump up at you if you failed to put all the pieces in in time (a game which accounts for my jumpy disposition). After the ape put a piece in, he or she would get some sort of ape treat.
The researcher said that chimpanzees were very cooperative subjects in this experiment. The chimp would pick up a piece, look at it, move it around, try it in various holes, and so forth. The chimp seemed to be solving the problem in a straightforward, empirical way. And most importantly, when the chimp was not interacting with the pieces, the chimp was off doing something else. So the researcher knew when to pay close attention, and when she could let her attention wander.
The orangutan was not so easy to monitor. The orangutan would scratch itself, then maybe look at the pieces, then look off in the distance, then look at the board, then groom a little, and at some point would simply pick up a piece and put it in the correct hole. The orangutans were not faster than the chimpanzees, but the method by which the orangutan solved the problem was not evident. And the researcher had to pay close attention all the time, as she never knew when the orangutan might act. In fact, in several cases, the researcher noticed the piece was in the hole without having seen the orangutan put it in the whole, which made positive reinforcement problematic.
I have a lot of empathy for the orangutans, and almost none for the chimpanzees. When I solve a problem, it is very rarely by methodically plugging away at it. I am more likely to read comics, chat with my officemate, play flash games, and so forth when I am stuck, and eventually a solution often comes to me. Or I get so bored that I try the plugging method.
Chimpanzees are much easier to manage.
Subscribe to:
Comments (Atom)