The six kinds of programmers there are
In 2017, Wayne Booth published a taxonomy of programmers. He distinguished between six kinds of programmers, and different corresponding approaches to the multiplicity of programming languages. It is a sure bet that you have encountered at least one of each type in your programming days. The easiest way to introduce these approaches is to simply enumerate them, one at a time, so here goes:
1. Conflict breeds insight
This approach cherishes the multiplicity of programming languages, and emphasizes that the sum total of individual and collective knowledge can only grow from continued debate. Whether one language is better than another is beside the point; the constant comparisons and competition (such as it is) gives everyone involved a solid understanding of the strengths and weaknesses of each respective language. The end result is that we all know what there is to be known, and newcomes can see for themselves what works and what does not — by simply reading what has been said up to this point.
2. Semantic clarity will sort it out
This approach recognizes that different languages have different terminologies for what amount to the same things. This programmatic Tower of Babel inevitably causes confusion whenever programmers sit down to discuss their craft. Where there is confusion, there is very likely also conflict. Unlike the previous type, however, the semanticists worry that most of these conflicts are of the sort summarized in the expression “six of one and half a dozen of the other”. There is much ado about nothing, and more productive discussions can be had once the linguistic confusion has been sorted out. Efforts should therefore be directed towards achieving semantic clarity, a standardized API, if you will, to allow programmers to talk to each other with a minimum of fuss.
The most recognizable approach: monists insist that there is one correct language, and that the others do not perform up to the standards of the one true lingua franca. The language in question might vary from person to person, but the general attitude remains the same across the board. By virtue of their extended practice with their preferred language, monists tend to be very familiar with the obscure linguistic nooks and crannies that might stump those of lesser proficiency.
The sceptics pride themselves on their critical reasoning (and fault-finding) skills. Rather than asserting that a single language is correct, sceptics assert that there are flaws in to be reckoned with in all languages. Thus, it is important to properly catalogue and document these flaws in a systematic manner, to give everyone involved the best possible starting point in their programming endeavors. It is a preventative measure rather than a positive program (pun intended); while there is no single point on which all sceptics agree, they have in common the methodological starting point of critically examining what is there to be examined, and proceeding from there.
Eclectics dabble in several languages, without a strong commitment to any one of them. Knowing a language allows things to be done with that language; knowing several allows for choosing which is most appropriate for the task at hand. Moreover, it allows a programmer to avoid the “if the only thing you have is a hammer” kind of thinking. Being competent across languages stimulates a creativity of the mind, and at times result in lateral leaps of insight which simply would not have occurred in a monolinguistic frame of reference.
In the presentation so far, I have focused on the key strengths of each approach, so as to underscore the respective advantages of each. Booth, however, finds faults in all of them, so let’s go over these five approaches again, this time with a less sympathetic eye.
1. Conflict for its own sake is not always productive, and at times the results are a massive waste of time and energy for everyone involved. A prime example of this is when someone writes an impassionate (perhaps including expletives) manifesto detailing everything someone else did wrong. In the best of worlds, it would all be constructive criticism allowing for better practices in future endeavors. However, it might just as well turn out to be an enthusiastic torching of a straw man, where little of genuine insight is actually achieved, aside from mobilizing strong emotions on both sides. A flame war is not the same as reasoned debate, and encouraging conflict for its own sake is not always the best means of achieving the stated goal of increased knowledge and understanding.
2. Avoiding unnecessary conflicts about things which everyone fundamentally agrees upon is, in general, a good thing to do. However, as anyone who has ever marveled at the ever increasing number of standards has no doubt noted, sometimes the solution is not to create yet another standard. The ambition to achieve semantic clarity has a tendency to be bogged down in details, sorting out minute differences that do not matter in a bigger picture. For this reason, efforts in this direction tend, upon completion, to be greeted with a less than enthusiastic response. At times, it is even seen as an attempt to impose a new standard without anyone having asked for one, which could very well be an inciting incident to a brand new conflict.
3. A big drawback of being a monist is, of course, the prevalence of languages that are not the language of choice. Being adamant that, say, PHP is the best thing since sliced bread is not likely to win friends and influence people. Moreover, insisting that there is one true way of going about things, and that those who inexplicably choose to dabble with other languages are confused or misguided at best, incompetent at worst, is directly counterproductive to collaborative efforts. The degree to which monists make their opinions known differs, but the tendency to alienate one’s peers is well-known and extensively documented.
4. Applied scepticism has its advantages, and having someone proficient at critical thinking around tends to be a positive thing. The drawback of indulging in indiscriminate scepticism is, ironically, a tendency towards rejecting everything, finding that very little has a stable foundation upon which to rely. When everything is fair game to attack, the sceptics over time choose to attack some things and leave other things off the hook. This happens either because of inertia and the limitations of the human body — one can only do so much with the time available, and it is easy to get into a habit of targeting certain things rather than others — or because the relentless adherence to critical thinking is not combined with sufficient self-reflection to realize that some bias or other is at work. When everyone else is wrong all the time, the number of people who are right asymptotically approaches one.
5. Monists have the advantage of knowing their chosen language really well. Conversely, eclectics know a little bit of this and a little bit of that, without necessarily knowing anything particularly well. There is a tradeoff at play between breadth and depth, and eclectics have a tendency to err on the side of the former at the expense of the latter. There are exceptions, of course, but given the aforementioned limitations of the human body, there is only enough time to learn so many things to any significant degree. Being a Jack of all trades is useful at times, but some occasions call for a specialist.
All of this leads us to the sixth kind of programmer. It also means I have to admit to having lied up to this point. Booth did not actually write about programmers, and the book was published in 1979 rather than 2017. It is an immensely useful book, titled Critical Understanding, which concerns itself almost exclusively with the domain of literary criticism and the challenges facing a critic in their professional endeavors. It also does double duty as one of the best books on the scientific method you are likely to come across, albeit in a roundabout way. But enough ado:
6. Methodological pluralism
This is, as you might already suspect, not an approach to the multiplicity of programming languages. Rather, it is an approach to systems of knowledge as such, of which programming as a general category might be said to be one. The aim of methodological pluralism is not to combine different paradigms into a single way of thinking, but to acknowledge that there are a large number of distinct traditions of knowledge out there, that each have to be understood on their own terms in order to be fully grasped. By knowing the history and lore of different such traditions (plural), life and/or workplace situations can be approached through multiple lenses and perspectives. What is invisible from a certain perspective might be figuratively lit up by blinking neon signs from another. The only way to find out is to be able to move back and forth between perspectives at will. This requires an immense effort, given that it is natural to combine all the things one know into a singular perspective and call it “me”. The pluralistic aim is to keep these ways of knowing distinct, yet apply them in concert.
The rewards, should you choose to adopt this approach, ought to be obvious by now. You will (to take an example completely at random) be able to read a book about literary criticism and end up having something to say about the present state of programming. You become a bigger human being, and will find yourself thinking outside the box with startling regularity. Granted, it might be argued that you are now jumping back and forth between a slightly larger number of boxes, but — as the ancients used to say — ars longa, vita brevis.
[Shameless self-promotion: you can find most of my writings listed here.]