« Alpha, Beta, and Gamma Software Organizations | Main | Are FP and OO Incompatible Syntactic Styles? »

December 26, 2007


chan kok leong

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


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.


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.


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.

The comments to this entry are closed.