Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.I think there's a lesson to be learned here for anyone, in the vein of knowing what one does and does not know. When considering any question, especially particularly complex ones like the above, it pays to be sure that one really has a grasp of the context in which his decision is being made. The idea that some tool/method/software/theory other than that with which one is most familiar is similar but for some fuzzy difference should be a flag that one's knowledge is incomplete. It may well be that expanding that knowledge is not the proper course in a given situation, but one should at least be ready to admit a knowledge gap rather than taking false comfort in the assumption that the gap is necessarily inconsequential.
And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).
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.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs. [bold added]
Human beings are not omniscient. It amazes me that so few people are comfortable with that that idea, and yet are happy to pretend they know enough, rather than any of (a) confirming that they know enough for the particular purpose at hand; (b) determining that they don't (but can remedy the problem) and acting accordingly; or (c) determining that they they don't know everything about some problem, but at least satisfy themselves that the risk posed by this gap is acceptable and proceed anyway.
-- CAV
It may well be that expanding that knowledge is not the proper course in a given situation
ReplyDeleteHow to tell though, that is the question. The problem is; unless you have some idea of how large the gap is, it can be difficult to answer. If you make one error, you may never solve the problem; if you make the reverse error you can waste a lot of time chasing a red herring.
That is a tough question. An example from my own work has been my decision to learn emacs on the premise that doing so could solve several problems more easily than I had thought possible. I think I am probably right, but the jury is out on that question. Fortunately, it is already paying off in other ways, so I already know that I won't have completely wasted my time.
ReplyDelete‘Fortunately, it is already paying off in other ways…’
ReplyDeleteThis matches some of my experiences as well; the serendipity thing. It’s probably fairly common but difficult to factor in to the calculation. It doesn’t feel right to spend time learning new methods or techniques on the off chance that they might pay off (even though based on experience, they probably often would).
What's been interesting about the case of emacs is that I doubt I would have learned about these new things had I not tried emacs in the first place. This is also amusing, because some of these things -- like editing and browsing in one window -- have been things I've wanted to do for some time.
ReplyDeleteI am allowing myself time to learn the system I hope to implement (vs. building my own system), but I see that I have to keep my eyes on the prize, and not allow the serendipitous gains distract me from why I am doing this.