April 22, 2005
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 gotos 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.
Posted by Jeff Atwood
I agree, mostly: a good programmer will write good code in any language, and a bad one will write crap in any language. But one of the marks of a good programmer, I think, is the ability to work effectively in different languages. So the programmers who are successfully switching have something going for them that the left-behind may not. I'm not saying that you have to switch languages all the time (or ever) to be a good programmer, just that switching shows a capacity that is indicative of good programmers.
I must agree with Dijkstra. It may be true that you can write bad code in any language but anyone who says you can write good code in Fortran has obviously never tried. Many VB programmers are moving to C# because they were C programmers originally or have been cross trained on Java. I have always lamented that the one worst effect of Microsoft winning the operating-system-war with IBM was that Basic and not Rexx became the approved macro language. Microsoft itself added to these problems by including a book in the MSDN by some programmers in their professional services (don't remember the exact name - something about "Advanced" or "Expert" VB programming) that was filled with the worst advice I have ever seen in any programming book. I routinely instructed juniors to read it and do exactly the opposite! I recall a very good VB3 programmer who could program circles around most and had tens of thousands of lines of code that worked and did amazing things and he was completely unable to understand even the weakened OOP support in VB4. On the good side think what an opportunity this presents for those positioned to offer an alternative to VB.Net! (Could TruBasic be the answer?) But for the hardcore that still feel the sting of the blade and the hot breath of Microsoft on the back of their neck the VBRun resource center will remain only cold comfort.
Fads come and go, good programmers remain.
Great post! I saw your comment in mine and thought I'd respond. When I was a VB 6 developer, I wrote kick ass code.
At that time, Java just happened to be a better development environment (that whole OO thing), so I tried to switch to J++, MS abandonded it, then it was back to VB 6.
Later, when .NET came out, I switched to C#, because I liked the syntax similarity to Java.
So in that respect, I agree that you can write great code in any language, by the standards of that language. I don't think C# is somehow intrinsically "better" than "VB.NET".
However, culture can play an important role. Java built up a solid community that really focused on good OO practices and design patterns. I personally think a lot of devs like C# for its similarity to Java (and I think now C# has surpassed Java).
So it may well be a phenomena that a lot of great devs moved from VB 6 to C# instead of VB.NET. But I think this is due to the sense and culture around C# based on its likeness to Java.
VB.NET doesn't intrinsically encourage worse coding. Under the hood, they are hardly different at all.
I think I mostly disagree with Dijkstra (despite his name being pounded into me as an undergrad). I think you can certainly write good code in ANY (well-formed/mature) language.
However, I think that there are some algorithms/apps/tasks that can be written more efficiently/effectively in one language over another. For instance, if I'm going to be doing a lot of text parsing, I could certainly do it well in both VBScript (ASP) and Perl, as both support RegEx and have string classes, etc. However, the Perl version is almost certainly going to be more concise and (probably) run better, while the ASP version is could be more readable and supports some propietary COM object (or whatever).
Unfortunately in that respect, many coding groups are one-language shops, so knowing that one language is better for a task is irrelevant. So often times when the only tool you have is a hammer, every problem becomes a nail.
Of course, one could also argue that VBScript isn't a well-formed/mature language, and for VB6 and earlier one might have a good argument. I think VB.NET has made great strides in improving VB, and I would hope most programmers who have used it realize that.
I come from VB6 and as soon as .Net got released i switched to VB.Net, recently i had to learn C for my job, the next day i started coding in C# instead of VB.NET and never went back. I agree that you can accomplish the same when you target .Net with C# and VB.NET, but C# is special, it has the C syntax which is unbeatable and powerful.
I'm proud to code in a C style language.
What about Ratfor/Ratfiv? They make Even the worst Fortran IV/77 better. Besides, have you tried a Fortran other than 77? 90/95/05 (and soon 08) make things better too.
I was hoping to see some FORTRAN on Rails code here!
As Xavier said, I hear modern fortran is 5 generations away from its'30 year old ancestor.
your orange tastes like chicken
My background is finance and art. Programming became a true passion when I understood how functional it was and creative you could truly be. Having an engineer father, I was drawn to "logical" things for creative outlets. I also programmed in basic as a kid.
I think the single largest influence in my growth from "hey look what I did" to "comment the hell out of your work make sure it's elegant, readable and functionally efficient" was having to support hundreds of programs for years and years and a driving need to grow my business. Having a solid foundation and understanding of good programming practice has certainly moved us closer to the 10x mark (thanks Steve for the wisdom and Jeff for the suggestion).
Many years ago the firm I worked for switched from FORTRAN77 to Ada as the main programming language for it's drawing office software. We all thought we were the bee's knees, producing excellent object code and all that.
However, we had no proper training so when, after a few months, we reviewed our code we realised that we'd still being writing FORTRAN - but with Ada syntax!
Having done both VB and C#, I can tell you first-hand that the culture difference is the driving force. My coworkers who liked elegant, maintainable code tended to prefer C#; those who just wanted to make it work tended to prefer VB.
"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."
This immediately reminded me of George Orwell's "Nineteen Eighty-Four".
Very good article!... I agree, PHP may have its downfalls, but all can be resolved with good coding practices, and future releases. The same thing has happened with dozens of other "non-professional" languages. Also, PHP is easy to configure and install, regardless of the machine it is on, and all of its weaknesses are well-documented, with work-arounds readily available to everyone. An environment where you *can* make mistakes will teach you not to make them more effectively than one where mistakes are impossible, or unlikely.
To use an analogy:
Fancy running shoes won't make you a sprinter, the best ingredients in the world won't make you a chef and world-class paints and paintbrushes won't make you an artist... only hard work, practice, patience and talent can.
And I say this coming from a Java programming background.
the more abstracted a language becomes from the hardware it runs upon, the more nonsensical it becomes, until you reach the point where there is more fluff and comments than there is working code. COBOL was an early example of this principle.
writing an algorithm is a separate process from actually coding it. the language used imposes artificial constraints upon the expression of that algorithm. the best programmers i have known or knew of used a great many different languages.
this current fad of writing programs using a certain approach (object oriented, top-down, etc) seem to impose greater limits than the choice of any particular language. again, COBOL was an early example of attempts to formalize how people should approach programming. any language that attempts to impose 'good programming habits' could therefore be considered COBOL's modern-day successor.
comment: insert capitalization at some later date...
The point Dijkstra completely missed is that FORTRAN users aren't trying to win academic points in an ivory tower. We're trying to solve real-world engineering problems. And we do that very well, thankyouverymuch.
COBOL causes brain damage. Other than that a good programmer should use whatever tools (languages) work best for a particular project. Arguments over with language is 'best' are a waste of time, except for COBOL ;-).
Ha ha ha!
You can write assembler in any language.
You can write C in any language.
You can write pascal in any language (except, perhaps, FORTRAN IV).
You can write bad rubbish in any language. Don't get to precious about these things. There is a difference between insight, and persistence. Persistence is where you fiddle anything (in any language) to get a result without knowing why or how. Insight on the other hand, delivers the why and how part.
I've seen this over and over and the choice of language does not matter. Even COBOL. (You can write co-routines in COBOL, believe it or not. Now go do that in Pascal or Ada or C or C++ or php or java.)
The only difference in all these things is ultimately how strict a language is on type enforcement. Everything else is mere details. Want proof? Ada 83. Need I say more? Classes? Mere details. Objects. Ditto. In the end, type enforcement is either strict (Ada style, super-anally so), or loose (some basic implementations, or php-style).
Whacko. Live with it. The stuff about psychological damage is just posturing bullshit, said (written) to make a strong point. And MAYBE, just maybe, it does apply to the barely competent programmers, or the truly inept. But for a professional who can change languages at the drop of hat, its rubbish.