Working in the language space, especially in language design, you frequently encounter people who fall victim to what I call the “Use/Build Fallacy.” It goes something like this:
Because I know how to use something, I know how to build it as well.
This fallacy is best illustrated by a story I heard from a friend who’s a teacher (another profession that frequently has to deal with this). She was teaching middle-school when teacher conferences rolled around. Talking to the father of one of her students, she explained to him that his daughter was having a lot of trouble in English class and that, based on her observations of how hard the daughter was working, she was pretty sure that the daughter had some sort of language learning disability. She therefore strongly recommended that he take his daughter to an expert to get tested, and that she be tutored by someone trained to deal with the specific kind of learning disability. The father was nonplussed, mainly because he didn’t like the idea that all this would cost him money. “Can’t you just help her more in class?” he asked. My friend explained that she was helping her all she could, but she wasn’t an expert in diagnosing learning disabilities and his daughter really needed to see someone who had the appropriate training.
After a bit of back-and-forth, the father finally got exasperated and said, “Fine, I’ll just tutor her myself! I mean, how hard could it be? I went to school!” My friend then shot back, “Look, you’re a general contractor, right? What would you think if I came to you and said, ‘I don’t need you to build my house—I’ve lived in a house before, so how hard could it be to build one myself?” This, finally, stumped him. I’m not sure whether he actually got his daughter the help she needed, but the story stuck with me because my friend’s response is the perfect distillation of the Use/Build Fallacy.
Note that I’m not saying that just because you’re not an expert on something you can’t have an opinion. I may not know how to build a house, but that doesn’t mean I have nothing to say to the contractors if I decide to do some renovations on my house. Not falling prey to the fallacy, though, means that I always keep a healthy respect for the expert in a field—as long as they truly seem to know what they’re talking about. (I hear this from friends who are architects all the time—they get hired by someone to build or renovate a house for them, and then their client spends all their time endlessly arguing with everything they do. Why bother to hire an expert if you think you already know how to do it yourself?)
I try to remember this myself every time I encounter some aspect of some programming language that I don’t like. Right now, I’m neck-deep in C++ code and it’s tempting to spend all my time kvetching about how how horrible a job Bjarne has done over the years. And then I try to remember—even as someone who’s actually built a language—that this stuff is hard. A language of any complexity has a huge number of moving parts, all of which interact with each other in an unpredictable manner. Historical choices can come back to bite you in all sorts of unexpected ways. Oftentimes all you have are a bunch of imperfect choices, and you have to simply pick the least bad of them all. And then you get to sit there and listen to everyone on the sidelines complain about how horrible a job you’ve done and how they could do it so much better than you because, hey, they’ve used a programming language before.
So I try to temper my complaints with a little humility, and remember how much different building is from using.
The hypothetical “Part 2” of this post should remind the experts that, just because the users can’t build, you can’t assume that they are clueless and have no insight into what it takes to build. Case in point: I’m no doctor, but there have been a couple of occasions where I argued with a doctor until they saw my point and recommended different treatment. In short, don’t let your expertise blind you.
Interesting article. I tend to get around the problem of language inflexibility by writing languages which are designed to solve very specific tasks: the transfer of data from one data structure to another, for example, or the control of a certain IP-addressable device. So in a sense, I’m thinking of the language more as a shorthand to allow me to put together sets of instructions quickly without having to think about coding them at a lower level in C, or whatever… the languages concerned don’t need to be particularly flexible (a data transfer language doesn’t need to have good graphics routines in it, for example) just as long as they can take care of the tasks at hand… but they do need to be extensible, so that I can always extend them if I need to. I think the key in designing languages is to make sure that the syntax is as extensible as you can make it, within the constraints of what you’re designing the language to do… so that if you need to extend the language at some point, you can do so without having to redefine what’s already there: as you say, historical decisions come back to bite you if you’re not careful. This can be done by means of libraries (C, etc.) or by means of a seemingly infinitely extensible command structure (SQL, xbase, etc.) or by both; essentially, designing such a thing is more a matter of “don’t design something which restricts itself” than “design something you can expand on later”, in that the former implies the latter.
Nice. There’s a relevant cite from a field that’s closer to what I do as well: “If the topic is physics, most people are happy to defer to physicists; if the topic is digestion, even though most people can digest food, they still defer to the gastroenterologists. But if the topic is language, everyone thinks they’re a linguist.” (Ronald Kephart)