I recently stumbled accross this article from a few years ago. It argues that significant differences in the culture surrounding VB and C#, not the actual differences in the language, contribute to C# coders being generally more talented than VB coders. Obviously, that caused a lot of flame wars and the question of whether C#ers or VBers are the dumber will never be answered. That being said, the writers claim that the culture surrounding a particular platform contributes to the quality of the team could still be plausible. For example, even though Java is more efficient to develop apps with at the moment, a team of Google Go developers would seem likely to be of a higher caliber on average than a team of Java developers, since to learn Go, a developer probably has to be a super-early adopter and a frontier-hacking whiz. So, in a nutshell, how does the culture surronding one platform or another affect the quality of the average developer on that platform, if at all?
-
Is it a day of C# vs. VB.NET? – May 04 '11 at 19:46
-
@DeveloperArt- That is not my intention. In fact, the question I had was interesting due to the fact that the article seems very dated today, but the concept might be salvagable. The article makes it seem like C# devs are all geniuses. I am one, so I know first hand that we can all be just as sloppy when the mood strikes. – Morgan Herlocker May 04 '11 at 20:42
-
1@Developer Art: I read that article just yesterday, and I'm pretty sure it was a link posted in an answer here that took me to it. Maybe that's how Prof Plum hit it too - one C# vs. VB.NET question leads to another. :-) – Carson63000 May 04 '11 at 23:17
3 Answers
Really interesting question. My personal opinion is that it's one that's asked far too often and really holds no water whatsoever.
Script kiddies (and companies that hire them) let the language of choice dictate their status amongst the echelons of "programmers". Good engineers couldn't care less about the language of choice, but concentrate on solving the given problems with in the most optimal manner (obviously optimal is a general statement and can be applied to many different factors). Whether this is C#, VB, C++, Python or hand written assembly, it doesn't matter as there's a clear benefit to using that technology to solve the problem.
So in short, I think it's more valuable to look at the complexity of problems that one solves on a regular basis as opposed to what language they use to solve them.
Just my two cents on the subject :)

- 17,555
- 1
- 47
- 81
-
2+1: Further, the idea that there's a VB culture that somehow transcends company boundaries is ludicrous. How would this culture preserve itself? Secret meetings among VB programmers outside of work? A "union" or "guild" of VB programmers to enforce this "culture"? Having spent 30 years bouncing around among 100's of IT shops I can say that the only culture I've ever seen is purely localized. Language choice does not create this "other" culture referenced in the question. – S.Lott May 04 '11 at 19:50
-
1
-
@Demian Brecht: Be careful of what you assume about the score and comments. It's legal to say "+1" without actually upvoting. – S.Lott May 04 '11 at 20:04
-
1@S.Lott: I stand corrected then (gotta love the byproduct of assumptions ;)). More times than not, I've received downvotes on topics such as these without actually getting any feedback, which can sometimes be valuable and provide me with information of which I was previously oblivious :) – Demian Brecht May 04 '11 at 20:06
-
@Demian - so it platform/language choice has nothing to do with average quality of the developer? I would think that the barrier to entry at the very least would weed out certain coders for certain technologies, and even more so when considering the effect that the problem domain has on the technology. For example, your average MVC dev is probably a bit more experienced than your average ASP.Net dev because it tends to be less automated development. Also, do you disagree that Google Go coders are probably more passionate than the average CRUD developer? – Morgan Herlocker May 04 '11 at 21:03
-
1@prof: Does automation *really* make one inferior, or would you think superior because they understand what shortcuts they *can* take to achieve the same output, but more efficiently? :) Of course, this is over-generalization and nearly impossible to answer accurately. I'm kind of on the fence about Go coders being more passionate. You can still find people who are just as passionate about Fortran. It *would*, however, lead me to believe that the Go programmer is more passionate about *new* technology and practices, which is a good thing imho :) – Demian Brecht May 04 '11 at 21:10
-
+1 @Demian Hey, I'm a .Net developer, so I certainly hope automation doesn't make one inferior. At the same time, I know that some of my cohorts simply COULD NOT use any language that did not have the Visual Studio drag 'n drop toolbox available given an infinite amount of time to complete every project. So I guess what I mean is that perhaps .Net attracts an even smattering (doing the basics of CRUD in .Net is practically trivial), while certain platforms kill off the weak early?... – Morgan Herlocker May 04 '11 at 21:24
-
@prof: Yep, and that's where you get the separation between companies who hire script kiddies vs. those who hire engineers :) – Demian Brecht May 04 '11 at 21:26
-
1@Prof Plum: "platform/language choice has nothing to do with average quality of the developer". Correct. How can it be otherwise? More than anything, the culture of the **organization** matters. Google Go coders -- themselves -- are just people. The **organization** limits people to VB or encourages them to use Go. People are all people. – S.Lott May 05 '11 at 01:14
Quality of code developed in each of these languages is based on these fundamental philosophies and less on the individual developers
Each language does have a culture around it, because each language was developed for a reason by someone with an agenda and an underlying philosophy to why their language was going to be better at something than what existed at the time was created.
Like religions, programming languages tend attract people that already have the same predisposition to the core principals and philosophies of the language creator.
Example on perceived Quality of Solutions
In one Microsoft camp you have:
The C# philosophy is that it is more purely Object Oriented, promotes more modern idioms and requires more knowledge to do it correctly and thus should provide more higher quality solutions. This is what draws people to it over VB.
In the other Microsoft camp:
The VB philosophy is I can quickly and with little knowledge or effort build something that will let someone click a button and do something useful and of business value, how it does it isn't so important. This is what draws people to it over C#.
Here are some tongue and cheek takes on languages and their philosophies:
Perl people tend to care about the exact opposite thing Python people care about.
Java people care about making money.
JVM languages ( Groovy, Scala ) care about the JMV and not about Java the language.
All the Microsoft specific languages (VB,C#,F#, managed C++) tend to care about making money on Windows.
Erlang people care about stuff everyone other people haven't needed to care about, and don't appreciate what they don't know.
Lisp people don't care about what anyone else thinks they care about.
What these groups care about shapes the language, its development and its community.
Philosophies change with experience and need
I adopted ASM and BASIC because in 1983 that was all you had. I wanted to write games and demos, those were the tools to do it. Mostly ASM for demos.
I adopted C and then C++ back when it was the only way to write things like 3D rendering and pretty much anything else that was space and time critical. It wasn't ASM so I learned it.
I adopted VB to make money, it was the closest thing to the Scala, Director, and CanDo development environments that I was accustom to on the Amiga. I agreed with the rapid development philosophy
I adopted Java early on to make better money. I made money with VB until 1999 and left it behind when Java 1.2 got stable and mature and the web had fully kicked in by then, I had 4 years of Java experience when people really started taking it seriously. I agreed with the write once, run anywhere in that the more places my code ran the easier it would be able to sell it. philosophy.
I adopted Python late in its timeline, 2005 because it scratched an itch that Java didn't. I needed to quickly write code to use some libraries that were only available in C and also I needed to do rapid webservice prototyping Python was quicker and less code to do the same thing in Java. Somethings went to production as Java some stayed Python, lots of stuff never made it into the wild. I agreed with its batteries included, single idiom philosophies as well as the others.
I adopted Lua when I needed to put a lightweight scripting engine in my C++ and Java programs. This was way before the JSR233 support in Java. I agreed with the embedding a fully featured scripting language that is easy to use should be simple Lua philosophy.
I adopted Erlang in 2006 when I started needing massive scalability and relatively painless multi-core execution on highly parallel problems and have cross platform execution. **I agree with its no shared state, message passing, immutable state philosophy.*8
I adopted Objective-C when I started needing to build OSX and iOS applications. I agree with its add just the right about of Object Orientation to C to make it better philosophy. Also to make better money.
I adopted JavaScript officially in 2009 because I agreed with the CouchDB philosophy and it uses JavaScript. Still don't like JavaScript when I have to deal with the DOM.
I still haven't officially adopted Lisp, but I am going to eventually! I agree with its Those who don't know lisp are condemned to re-invent it philosophy.
An interesting question indeed. It is one of those where you understand the answer at the subconscious level but strive to put it into words.
It is best seen as a causality loop.
The culture is responsible for the "ethnic" composition of the developers attracted to the platform. That composition in its turn defines the qualities of the "average" programmer. The quality of the developers now using the platform influences the culture or its perception outside which consequently has an effect on the developers coming to the platform or leaving it. The value of the "quality" changes as a result.
I've been trying to come up with specific rules but I find it difficult to generalize. We need to separately investigate each platform. A few observations I've made:
The speed at which a particular platform is developed, extended, improved has a direct correlation with the quality of the developers. The constant flow of new shiny features and tools attracts enthusiastic developers (which on the average are more capable of quality work) and repels conservative minds who are irritated by the constant learning effort.
The less limits a platform offers even at the cost of a higher risk to shoot oneself in the foot equally attracts enthusiastic experimental minds
The more complex the things are which one needs to understand and master in order to use the platform equally attracts resolved individuals and scares away lazy developers
-
-
1@Lott Technology almost always transends cultural boundaries. There are huge cultural divides between different OS users. A lot of graphic designers and audio engineers I know would think it was a deal breaker to go to a company that used anything but Mac. Mac has fostered a culture around those two groups in particular that is entirely tangible. Programming languages are tools just like Photoshop and GIMP, so its not suprising that they have cultures built around them. If they didn't, then we wouldn't have flame wars. – Morgan Herlocker May 04 '11 at 21:11
-
@Prof Plum: Your examples do not map to "culture" based on tools. Your examples are the exact opposite. The actual culture (audio engineers) pick common tools. Not that all users of Logic Pro are forced to become audio engineers because somehow Logic Pro creates a culture. I think the examples in your comment (same job -> similar tools) are excellent proof that there is no "language cultural history". Rather, there's common use case culture or common end-user job culture. – S.Lott May 05 '11 at 02:33