You Can Write FORTRAN in any Language

A recent user-submitted CodeProject article took an interesting perspective on the VB.NET/C# divide by proposing that the culture of Visual Basic is not conducive to professional software development:

We’ve seen that the cultures of VB and C# are very different. And we’ve seen that this is no fault of the programmers that use them. Rather this is a product of the combination of factors that collectively could be called their upbringing – business environment, target market, integrity and background of the original language developers, and a myriad other factors.

One factor, however, that seems to have a greater effect on the culture than others, is the syntax and semantics of the language. To what extent do syntax and semantics play a part in the culture that builds up around a language and to what extent, vice versa, do the syntax and semantics depend on the culture in which the language was created? The truth is, both – just as spoken languages both grow out of culture and influence culture. For instance, in the far north the language syntax has evolved several words for the different types of snow. Interactions then use the language to express nuances of snow, creating a more snow-centric culture.

So in Visual Basic, the decision to include in the syntax and semantics the ability to assign numbers directly to strings and vice versa was a result of the designers’ desire to attract a broad base of developers who would probably not understand the notions of strongly typed variables. Once the syntax permitted it, such assignment became widespread, reinforcing the designers’ original premise. Once this cycle of self-reinforcement begins, the cultural habits quickly become entrenched and widespread, and are extremely resistant to change. Minds tend to gravitate to like minds. User groups tend to attract homogenous followings. Visual Basic instructors tend to propagate what their instructors taught them.

While I appreciate the idea that the culture around a language can influence you, the implication that choosing the “wrong” language can somehow cripple your professional development is disturbing. This concept is known in linguistic circles as the Sapir-Whorf hypothesis. It proposes that the vocabulary and syntax of our language guide and limit the way we see the world: form dictates content. Edsger Dijkstra, for example, believed that programming in Fortran or Basic not only condemned us to produce bad code, it corrupted us for life.

The author also offers a few predictions:

In the near future, there will be less good VB programmers than C# programmers. This is because many of the good VB programmers are switching to C#. This is partly because they like the language better, but mostly because they like the culture better. As the cultural separation becomes more evident and self-reinforcing, it will accelerate until there are very few good VB programmers left.

I’m hesitant to dismiss this article outright because I have observed first hand the mass migration of VB developers to C#, and in my experience the early adopters do tend to be the better developers. However, I cannot agree that code quality is predestined by choice of language, environment, or IDE – it’s almost entirely determined by the skill of the developer. Ergo, you can write FORTRAN in any language:

There are characteristics of good coding that transcend all general-purpose programming languages. You can implement good design and transparent style in almost any code, if you apply yourself to it. Just because a programming language allows you to write bad code doesn’t mean that you have to do it. And a programming language that has been engineered to promote good style and design can still be used to write terrible code if the coder is sufficiently creative. You can drown in a bathtub with an inch of water in it, and you can easily write a completely unreadable and unmaintainable program in a language with no go-tos or line numbers, with exception handling and generic types and garbage collection.

I agree that cultural factors are significant, however, individual developer skill is a far more accurate predictor of success than whether or not you chose the “cool” language. Like Java in its early days, the shiny patina of newness surrounding C# is attracting a disproportionate number of talented developers. Today, any Java-related google query will return reams of truly mediocre “explosion at the Pattern Factory” Java code. All I can say is, enjoy it while it lasts.