The Cult of Language Expertise

It happens time and time again on mailing lists and discussion forums – someone posts some code in the context of an example and then there is an outcry. “The code is lousy!”, someone says.  So you look and you realize that “lousy”, to this person, means that that it doesn’t use language feature X, that just came out in the last release; or that its author didn’t use idiom Y, which someone in some recent article proved is necessary to write “good” code in a particular language. 

Sound familiar? It happens all the time.

The truth is, I was one of those guys. Years ago, I took a lot of pride in the fact that I was knew all of the nooks and crannies of C++. I nearly memorized the ARM (Annotated C++ Reference Manual), and in flamewars on the net, I did my language-lawyerly best to point out little problems in posted code, and (I thought) advance the state of practice a bit. But, I always felt odd about it. If writing code one way was okay before the introduction of a new language feature, what made it bad immediately afterward? 

Java and C# offer some great examples. If you are working in Java 5 or 6, you must use varargs when you can. If you’re working in C# 2.0, well, you must make a class static if all of its members are static. It’s just the right thing to do. Then, of course, there’s the issue of generics. Before their introduction, people would cast objects as they retrieved them from containers. Afterward, “good practice” dictated that you use type-safe collections and avoid the casts. It was just seen as “the right thing to do.” But, of course, if you work in JavaScript, Python, or Ruby, you can play by different rules because these "rightness" rules vary across languages.

It’s hard to fault anyone for trying to keep up with language developments. If there are, now, safer and better ways of writing code, isn’t it important to move along? I think it is, but only to a point. 

The fact of the matter is, there is a strong psychological component to language expertise. The people who become language lawyers (and I was one of them) aren’t doing anything complex, they are actually doing something very simple. They are sitting down and learning all of the rules and using them as a point of leverage.  They think, "I am valuable if I know the right way to use the language." But, frankly, there is harder work out there.

If you want to see that harder work, try to give advice to people who are working in less than current environments. Try to write libraries and tools for people who are working in antiquated environments. That is the point where you see the continuum.  You can write good code without the latest features. People do it all the time.

There isn't some continually moving standard for good practice in a language, there are hundreds of islands, places where people have discovered what works for them in their environment.  Sure, there are incremental advantages to using the new bells and whistles but they aren't going to make you or break you.

Language expertise is fine, but it isn’t the most valuable thing out there. If someone programs conscientiously, I can work with them. I have a lot of respect for people who write solid code despite not having completely up to date language knowledge. Language knowledge is easy: you read, you think, you try.  And, you can catch up.  Conscientiousness, though, is the thing that really matters.  Next to it, language expertise is easy.

Comments

[chan kok leong]

Agreed. In the end,a program is but a textual representation of a finite state machine.

[IvanK]

I disagree. "New language features", are probably in there for a reason. "The new way" usually brings something new to the game - it's easier to remember, it's more optimized, it's easier to extend, it's more powerful or something like that. You certainly can do it the old way, but you'll sleep better if you do it "right". Otherwise, why don't we all code in C or even Assembler? If it's turing compatible(and nearly everything is) you can do it even in machine code... "Advancing the state of practice a bit" is not as bad as you make it sound - it's useful and even important to do so. I don't consider those who do this as "wise and revered scholars", but I do listen when they speak.

[Yelsgib]

The problem is really that there are multiple "types" of programmers. Namely, there are at least two:

One type lives in a world of concerns/concepts, the other in a world of implementations.

Languages are changing so fast that if the former keeps his or her head in the clouds (where it aught to be) then he or she cannot keep up.

Everyone of the latter type should keep up with what is "new and right" because their primary functional mode is cooperative. Implementation is necessarily so. Cooperation requires communication and communication requires common knowledge. The "new" is the only real standard, so they must know it.

Thinking of a truly novel idea is an individual exercise. Communication is not as strong a requirement and, when it is, usually requires only a common language of concepts. Standards for this sort of thing are much slower to change.

[Bob]

Another aspect of interest along these lines is "Multilingual experience": If you have worked with C++ generics and years later you see them re-appear in the Java world - it feels good to see good ideas return :-)

Then again, if you have been exposed to Fortran and all of a sudden you are told about this cool language called Python that uses
indentation as a syntactic element ... I was lucky enough that I was "forced" to work with Python at that time, otherwise I would
not have overcome this strange initial feeling of disgust :-)

(Sometime later I read that Eric Raymond seems to have had similar thoughts about Python ...)

[Vesa Karvonen]

The way I see it, having language knowledge means that one understands the semantics of the language. What you seem to be talking about is something different. You characterize language expertise with the thought pattern "I am valuable if I know the right way to use the language." I would characterize it with something like "I am valuable if I can work out how and why a given program works." This is, of course, an incomplete picture.

Perhaps the crucial difference is that you associate "expertise" with being prescriptive, while I associate it with being analytical. If you actually watch language lawyers, what you'll see is that they tear apart programs explaining what is wrong with the programs. That is primarily an analytical process. A language lawyer might not even tell you how to write the program correctly.

I'm sure the acronym TINTWIWHDI is familiar to you. An expert is someone who can also explain precisely why.

"Language knowledge is easy: you read, you think, you try." You call that easy? Most developers don't seem to read a lot and their thinking seems to be quite sloppy at best. Reading, thinking and trying are activities I would associated with being conscientious. The opposite of language expertise isn't conscientiousness, it is voodoo (and cargo cult) programming.

[Marcelo Lopez]

@Vesa: The problem is that a great many people judge others on precisely that. When was the last interview you had where the questions posed were more about analytical skills than what's "new and hot" ? Having worked as a consultant for a great portion of my career ( over 2 decades and counting ) I can count on the fingers of one hand where the interviewers were more concerned with actual problem decomposition and resolution skills, than recognizing what ( if anything ) the difference between Nullable and T? meant ( for instance ).

And the issues posed by TINTWIWHDI go beyond simply considering whether you would've chosen the same underlying constructs that the other developer used or not. That's a whole discussion onto it's own.

@Ivan: I hear what you're saying, but the reality is that just as with, for instance, Microsoft Word, programming frameworks/languages have come to a point there is simply a ridiculum ( a ridiculous continuum ) of fluff. 42 different collection classes ? C'mon, GMAB. If the different between a Sorted List and Sorted dictionary is sorting of the values as well as the keys, then keep the dictionary, and specify a property where the extra value sorting is disabled, and call the resultant collection SortableDictionary, or something meaningful that describes both behavior. Don't just create constructs "just because".

"Just because" development is malady that's infested everything from Operating System design to web apps. The excuse of "just because" didn't float when our parents used it in some lame argument to justify their rationale, it doesn't float in respect to the argument of the programming language-police. You go ahead and use your foreach's, I'll go "old school" and stick to my for loops. The person having to read my code may say to himself "TNHIWHDI" but he/she certainly won't say "WITHWHT" when he wrote this.