May 11, 2007
Over the last four years, I've basically given up on the idea that .NET is a multiple language runtime.
- The so-called choice between the two most popular languages, C# and VB.NET, is no more meaningful than the choice between Coke and Pepsi. Yes, IronPython and IronRuby are meaningfully different dynamic languages, but they're somewhere on the horizon and far from first-class IDE citizens.
- There's simply too much cognitive friction when translating back and forth between these two very, very similar languages. Semicolons or underscores? Case sensitivity or case insensitivity? Parens or brackets? Arrays that begin at one, or arrays that begin at zero? To-may-to or to-mah-to? It's just not worth the mental effort it costs to keep track of all these nitpicky little differences that can bite you so easily.
- Mixing source code in different languages is awkward at best. You have to segregate each language into its own compilable project. Separate-- but equal. Sort of. Well, mostly.
- Most of the community has settled on C# as the de-facto standard, so you're in for a rough slog of code translation if you want to stick with VB and cleanly integrate commonly available source code libraries into your codebase. And if you want to understand the code you're absorbing into your application (note: this isn't really optional in my experience), you better learn how to read it without a bunch of mental translation gymnastics. And once you've learned how to read and write the language well enough to integrate it, you've come full circle. Like me, you'll be left wondering why you didn't just cut out the translation penalty entirely and stick with one language in the first place.
This is not to say that you can't do multiple language development in .NET. But most of the time, it isn't worth the hassle. It's less painful to move with the herd and choose C# like everyone else does. For the most part, I've learned to suck it up and pretend C# is the only .NET language. I'll even grudgingly admit that explicitly ending lines with semicolons is way better than the mish-mash of carriage returns and underscores we have in VB.NET. But there are still two things that drive me nuts about C#.
The first is the evil of case sensitivity. As an advocate for people over machines, I have to go on record stating that case sensitivity in a programming language is wrong, and will always be wrong. I know the decision is written in stone at this point, and it's never going to change, so I'll leave it at that. It's a religious issue, and we software developers are nothing if not religious. Let's move on.
The second is the C# compilation tax. When working in C#, I'm constantly compiling the solution to ensure that I haven't broken anything. It's a ridiculous productivity tax in an endless loop: Write some code. Compile. Write a little more code. Compile. Change a function. Compile. Rename a variable. Compile. Refactor some methods. Compile. Then compile again, just to be sure. Wait a second.. did I compile this yet? Compile!
Notice a pattern here? I'm going to prematurely wear out my CTRL, SHIFT, and B keys. When coding in C#, I feel like a monkey in a cage that dispenses food pellets when I press CTRL+SHIFT+B. It's a complete waste of time, but you're compelled to do it through perverse incentives in the IDE.
What's particularly sad about this is that, in my experience, most C# developers think manually compiling all the time is a natural state of affairs. Well, it isn't. In VB.NET we have this clever little technology we call background compilation. Background compilation saves you the effort of all that meaningless, repetitive, mind-numbing manual compilation. It's very simple: as you type, imagine all that CTRL+SHIFT+B-ing happening automagically in the background for you.
With background compilation, I know immediately when I've made a mistake. I don't have to wait until the next time I manually invoke the compiler. Let's say I was to type in the following C# code:
s = 1;
Well, that code looks fine in the editor. Until I compile. Contrast that with the VB.NET equivalent:
Dim s As String
s = 1
The second I finish typing the assignment (e.g., move my cursor off the second line), the statement is flagged as an invalid assignment. No compilation necessary; it automatically appears as an ambient squiggly underline in the background.
This is an admittedly trivial example, but background compilation makes my life so much easier in VB.NET. It reduces the turnaround time between mistake and fix to virtually nothing. And you can do other clever things with it, such as quickly renaming a function or variable to get an idea of where it's being referenced via the stack of compiler errors that appear. If nothing else, it's one less thing I have to remember to do: oh yeah, the C# IDE shows me basic syntax problems, but I gotta compile my C# to see what's really broken. Doesn't that seem like unnecessary work to you? It sure does to me.
Background compilation is something that, unlike case sensitivity, is not written in stone, and possibly could be fixed. It's an IDE feature, not a language feature. Here's hoping the C# team eventually recognizes the massive productivity drain of the C# compilation tax for the average developer. If some developers are masochists who hate productivity, then make background compilation a configurable option they can turn off. They can march off in lockstep, back to their wheel of never-ending CTRL+SHIFT+B pain. More power to 'em.
Personally, I'd rather let the computer do the grunt work of compiling in the background. Freed from the onerous compilation tax, no longer compulsively invoking the compiler every few minutes, I can spend more time concentrating on my code.
I may have accepted the C# penance, but I wish the saints at Microsoft would see fit to grant this one small wish to a converted VB.NET sinner.
Posted by Jeff Atwood
The Telerik converter looks pretty useful.
I never did understand why VB was included in .NET. But, I guess that it makes sense given the legacy/compatibility issues that may arise.
C# code looks a lot better, to me, than VB code. It looks more like professional code, rather than play code. (I mean no offense to anyone. I am currently a VB .NET developer.)
Other than that, I have no real preference. They both do the job.
I have to chip in about the evil that is background compilation in VB.NET. Here at work we ahve a largeish project (200k+ lines) and decent machines (oodles and spare ram).
but any time a new file gets opened the IDE will freeze for 10 seconds while is background compiles everything. about twice a day this will result in the VB.NET compiler crashing and the IDE going down with it.
maybe if they managed to make a robust compiler and got the background compilation happening on a low priority thread on the background instead of freezing the IDE and all my work it would be a worthwhile effort, in the meantime i'm constantly searching for a way to switch it off.
Build a bridge and get over it.
I was once a VB developer. It was a liberating experience to be free of all the bad VB habits. VB lets you be lazy, even if you are not a lazy programmer. C# , look at the plethora of knowledge at your fingertips from sibling languages. Object oriented programming, design patterns. The mental gymnastics to covert Java examples of design patterns to VB was at best a nightmare. I don't even look back. Its nice to do one thing and do that one thing well.
"Button button = new Button();
Employee employee = new Employee();
etc. Naming is not only about variable names.
- Martin Vilcans on May 15, 2007 04:21 AM
Personally, I absolutely hate code like that. Why? Because I like to read the code, and when I'm reading there is no distinction between "button" and "Button". Also, of course, "button" tells me nothing about what the variable is for, just what it is. I already know that. "executeBtn" or "theBigButton" or "somethingToClick" are all more meaningful than "button". IMHO, case preservation is vital ("GetThere" and "GetTheRE" lead to significantly different interpretations), but relying on case insensitivity is a major maintenance nightmare.
Diatribe aside, I would LOVE to see a "case correcting" IDE. If I have the above case and I have "case correcting" on, then "bUtToN" would get a red squiggly if it really couldn't tell what I meant (or it would look at the context, determine that I am using it as a variable name, and in the variable name space there is only "button", so it uses that). For that matter, I'd also love to see a yellow squiggly when I type a variable name which differs from a class or method name only by case, but that's just me ...
IMHO, if you haven't tried working in an IDE like IntelliJ (or to a lesser extent Eclipse) then you're in for a treat there. Much of what has been asked for here has already been provided by other IDE vendors, just not necessarily for a C#-oriented IDE. This is one of those things that always makes me scratch my head when developers go on about how great VS.NET is as an IDE; am I missing something, or do they just not realize how much Microsoft is missing here?
In C# you can have unicode in identifiers, and the case folding rules are not completely defined or even sensical. So, the problem is simply avoided by abandoning case insensitivity.
I hear you, but..
If the language keywords are ASCII, why not restrict the identifiers (variables and function names, etc) to ASCII as well? I don't see the point of this. It's not like C# itself can be localized, so the keyword "if" doesn't become "si" in Spanish or "wenn" in German.
Wasn't there a previous post where most people agreed that Visual Studio was the best IDE? Netbeans, JBuilder etc. displays the errors while you type. It even adds them to a list so that you can click on the error message and jump directly to the code. They can even detect errors in one class, when another class has been changed. (the last one requires that you compile the updated class though)
This is one of those things that always makes me scratch my head
when developers go on about how great VS.NET is as an IDE; am I
missing something, or do they just not realize how much Microsoft
is missing here?
I think most of them is blinded by the ease of building GUI applications, and they overlook the features of the actual code editor. Features that other IDE's (like Netbeans, JBuilder and IntelliJ) have had for years.
IDEs are a waste of time. All this wasted effort searching for the one true IDE could be spent using an editor and the commandline which are far closer to perfection than the any bloated IDE.
I can't imagine someone building a complex system in a command line shell.
Then again, who am I?
Intellisense is enough of a background syntax checker for me, and I love it! I am wearing out my period and tab keys...
@Roddy, don't forget that Delphi.NET has a fast compiler when you do need to compile.
@steve, case insensitivity is a good thing. Variable declaration is reversed? Don't be so hard on C#. ;-)
You might want to take a look at ReSharper by JetBrains.
It solves the recompilation issue while adding a lot of other nice features.
Yes, I have heard of this Resharper thing..
.. see comment #6 on this post from January 2005.
And I'm still left wondering why background compilation is missing from Whidbey (late 2005), and Orcas (late 2007/early 2008), and Rosario.. the misses just keep on piling up for this "unimportant" feature that so many people seem to strangely fall in love with.
Odd. Very odd.
I can't shake the feeling that VB.NET is an unwanted bastard child within the .net development team, or - in another words - they (are forced to) drag it along for compatibility reasons. Let's not forget VB6 project upgrade wizard that is still along for the ride. Anyone wondered why?
In another hand, as vb.net developer that does development for a living I've been tempted to switch to C# (as ALL of my former VB6 colleagues have) but have decided not to persuaded by all the propaganda from Microsoft - that all .net languages are equal.
Well, they're not. There are plenty of examples of what VB.NET can't and C# can do - and they are not language specific.
I wonder for how long will this "unwanted child" continue to live, or in another words - when will Microsoft decide to discontinue VB.NET development...
Imagine the press MS would have received if for VB devs there was no VB.NET. Adoption of .NET might have been a bit slower. Most of the people coming from VB went straight to VB.NET thinking that they are on an absolutely equal standing with C#. I cannot tell you how many times I saw a VB.NET developer after being forced to use C# never went back. This is not to say that VB.NET should die or whatever. If someone wants to use it, go ahead and use it.
And also, I get a feeling the author of this blog loves setting fires :) Topic like this always brings loads of discussions and meaningless back and forth comments between various thought camps.
Like Jeff said, I'd strongly suggest you check out Resharper.
Among a million other useful things (like finding class/member usages, which you mention) it highlights compilation errors as you go.
Since I started using it a couple of years ago I don't develop without it.
I think the problem is that there is a compilation step in the first place. Why I just can't run my application right out of source code? I wish JIT compiler would be able to accept raw VB.NET or C# just like it does MSIL.
While I can't say I have ever worked with .NET (wrong platform for my taste), you seem to be mixing together "language" and "IDE" in your article. Is this compile on the fly really a language issue, or is it merely the IDE of your choice that has this limitation ? I know Eclipse has a C# plugin, and most Eclipse plugins seem to have the compile on the fly feature. Maybe give that a shot ?
I do agree though that the discrepancies between VB and MSVC (those are the last versions of both I worked with, I assume it's similar to VB.NET and C#) always bugged and irritated me as well.
We made the switch from vb6 to .Net about 2 years ago. At the time it was a toss-up between Java and .Net as far as we were concerned. The thing that swung it for .Net was having VB.Net as the perception was that it would be an easier transition. In practice I believe that it allows people to bring along their original bad habits. I would have been happier going straight to C#.
If you want good IDE:s, you should consider switching to Java and check out IntelliJ IDEA and Eclipse. They got what you're asking for and much more.
you seem to be mixing together "language" and "IDE" in your article
Indeed, sometimes I wonder if they should be considered different things:
am i the only one noticing that this is just a cry of frustration more than a legitimate complaint?
Jeff, you're a nice guy, but if you have to build an app to check for SYNTAX errors, that just seems lazy. i compile alot, too, but that's to find runtime errors, or incorrect output.
As far as case sensitivity goes, i'm of that camp that it's simply personal preference. I'd be nice if that were just a compiler switch, something like "\case", but i don't think that would happen any time soon.
Also, i for one have never claimed or even thought that vb.net was equal in any way to c#. i always thought the 'equality' was in the fact that they both have access to the same .net framework that all the other languages in .net do. isn't that what the CLR is all about?
"Over the last four years, I've basically given up on the idea that .NET is a multiple language runtime."
Sorry Jeff but your comments here don't add weight to that assessment. It rather seems to say "Jeff isn't a multiple language developer" which is a very different thing especially when part of your rant seems to be that the languages are so different...
The .NET runtime supports multiple languages so people who like language X can move to the .NET platform with relative ease and start taking advantage of it. Maybe they'll switch to C# later, maybe they won't but they have the option and can even start small by perhaps making a class library project in C# and adding it to their VB.NET solution.
As for some languages being second-class IDE citizens, a lack of background compilation or the one-language-per-project restriction well these are all limitations of Visual Studio and not .NET itself.
I have given up on Resharper, too many bugs and it takes too many resources. Not every company provides top$ machines. I miss some of the features, but when you use 3-4 instances of VS2005 at once, it just gets too costly.
My last job required me to write vb.net, and I did so for 9-10 months. Although I argued heavily against the language, I think it went quite ok. It should be the same but I still feel that the OO programming is lagging in vb.net and the reason for “AndAlso” and “OrElse” is beyond my understanding and so on.
But when all comes down to getting the job done, it doesn’t matter that much in .Net. It is more important how the IDE and the framework act.
but if you have to build an app to check for SYNTAX errors, that just seems lazy.
If you have to rely on a spellchecker to find your SPELLING errors, does that make you lazy, too?
I fail to see the difference between red-squiggly-underline background spell checking, and red-squiggly-underline background compilation checking. (Well, performance considerations notwithstanding)
The best I can do is to repeat what Scott said on a href="http://www.codinghorror.com/blog/archives/000195.html"this post/a:
I am a VB.NET guy so naturally I use VS.NET. I code in VB because thats what makes sense to me personally. With the evolution of the .NET CLR I am glad that VB has finally become the full fledge OOP language that we always knew it could/should be. I refuse to swtich to C# just because its the trendy thing to do. I have always been, and will continue to be a VB developer. Code in whatever language comes naturally to you. Keep it real.
Scott Schecter on January 28, 2005 11:03 AM
I've worked for companies which use C# and then I've worked for companies which use VB.NET. They both have very happy homes and I'm not sure why the C# people keep attacking the VB.NET people. The fact is that there is DEFINITELY a market for it. There are loads of companies which use it successfully. Mostly what I've seen is that each company chooses a language and sticks with it, so the translation between them does not happen so much. The VB.NET IDE has always been better than the C# one anyway.
If they just listen, There is also the XML embedded in the code feature that only VB.NET devs benefit from.
I've been using C++ CLI to write managed code and, I have to say, I love the power of freely using either Win32 or .NET calls and the power to intermix managed and unmanaged code anywhere in your source. I'm not saying that doing so is advisable, but C++ does give you that power. You know, that time when you realize that there isn't a .NET way to do something that the Win32 API offered.
Recently, I needed to write software that made use of some legacy DLLs and also some third party COM/COM+ objects (which came without any type libraries). Neither C# nor VB offered the flexibility of using .NET and doing COM and DLLs at runtime. C++ CLI was, at the time, the obvious choice for me.
An article on MSDN is even titled:
"C++: The Most Powerful Language for .NET Framework Programming"
@Damien - I think Jeff is talking about how .NET is done in practice. My experience jives with his. Most projects I work on stick to one language and one language only- C#.
The notable exception of course, is DotNetNuke. I've done a lot of DNN work and simply write all new code in C#.
Dont want to sound like a broken record. But Eclipse is really the best IDE out there, it has background compilation, which makes refactoring very quickly. With VS2005 I have to sit and wait for 3-4 windows with progress bars to show up after Ive choosen to refactor something. VS2005 is nice if you are making prototypes,etc. But to be productive I would always choose Eclipse over VS2005. I should not even mention the lack of unit testing in VS2005 (yes, it has UT BUT the people that implemented the feature do not eat their own dog food. Check out my blog for more comments about UT in VS2005)
In my eyes Eclipse is made by developers for developers, whereas VS2005 is made by someone else for everyone.
Eclipse is (still) mostly for Java development (except that I use it for Python code also) and I guess C# support is never going to happen.
I read that when you wrote it, and completely disagreed, but that might be because I use Eclipse a lot which supports a lot of languages, so for me there is no big IDE change when I switch to another language. And when it comes down to it, you almost always have choices when it comes to IDE, even if you have to use a specific language.
And to claim a different IDE is like using a different language sounds like saying that a story chiseled in marble is a different story from the same words typed down on a keyboard. Your IDE is a tool, don't put too much stock into it.
ps.: I liked your comment about case sensitivity. I'd like to see something different in the future: a compiler that automatically adjusts the case of your code. One of the main reasons I prefer case sensitivity in praxis is because it ensures that my variables and function names look the same everywhere. How nice would it be, if the compiler wouldn't complain about me writing UDPCONNECTOR.BConnected but instead correct it to UDPConnector.bConnected ?
In the spirit of what you said before, that programming languages should be more forgiving, how about starting by auto correcting case. Because really, who ever actually uses the same name for a variable but with different case ? Brrrr.
"Most of the community has settled on C# as the de-facto standard, "
Then why is it almost every .NET job I interview for wants VB.NET? :(
"What's particularly sad about this is that, in my experience, most C# developers think manually compiling all the time is a natural state of affairs. Well, it isn't."
Actually, it pretty much is. How many languages can you name that automatically compiled in the background before VB.NET did it? I can't think of any... it certainly wasn't a C, C++ or Java thing and that's where most of us started anyway. I hit Ctrl+shift+B almost as compulsively as I hit Ctrl+s in MS Word.
Lastly, if C# has a complation tax then VB.NET has a verbosity tax. Anything you save by not using ctrl+shift+b you lose by typing DIM...AS every time you declare a variable. ;)
I jumped into some Java work in Eclipse about a year ago for a brief period and noticed the background, real-time compilation. I'd just hit debug and it would run instantly.
I always wondered why, if VS is considered the best IDE, that it didn't provide this feature. Hell, edit-and-continue was in VS 2003 for VB.Net.
I agree with you on the background compilation need in C#.
However, about the "evil case sensitivity": I don't agree with you, actually I think it's excellent. Why?
Well, first of all it's a good way to ensure a programmer is thorough throughout the whole code. I find insensitivity troubling because in my opinion only sloppy programmers would actually use it.
Second, it's about code re-usability. So far, 90% of the programmers I met criticize the way another programmer wrote something. Add the case-insensitivity to that and tell me how it helps.
Thirdly, it's an easy way to impose coding standards. We are already familiar with these kind of standards, i.e. when writing: Capital letters for names , first letter of the first word in sentence,..., other words lowercase,...
Would you write your CV "case-insensitive style" ?
To be honest, I can't really see the advantage :)
Yeah, Resharper definitely eliminates this tax, but I understand the point you're getting at. If resharper can do it, clearly it can be done, so why not put it in?
Personally though, I've taken a different world-view of background compile. I like to be able to bang out a bunch of code, busting out ctrl_shift_b and feeling a great sense of accomplishment when it builds. the squiggly lines distract me. I'd rather be coding while the inspiration hits and not worrying about whatever stupid little thing I typed when my fingers were acting of their own accord until later. /shrug
"How many languages can you name that automatically compiled in the background before VB.NET did it?"
Actually, Emacs had it way before Visual Studio. There has been background syntax checking in Emacs, for multiple languages, including C, C++, C#, XML and Perl, at least since 2003.
I have recently started using C# (been a java and VC++ developer for the last 6 years). I found quite a few things that were strange.
Automatic building, is such a simple, common feature. I am surprised that it isn't even available as an option in Visual Studio!! Java IDEs have had it since the last 5 years atleast!!
ummmm, Delphi.NET, anyone ?
Case-insensitive, and background syntax checking (if not full compilation). And, pretty good portability between Win32 and .NET.
Regarding using the same name but with different case, code like this is not uncommon:
Button button = new Button();
Employee employee = new Employee();
etc. Naming is not only about variable names.
If I were sure that people would stick to casing conventions even though the language was case unsensitive, I would have no problem with it. But with current IDE:s and programmers, I guess case sensitivity is a good idea.
Interesting about the background compilation... The Java modules for the Eclipse IDE do it and it's absolutely fantastic. I know someone is writing a .NET plugin for Eclipse (although I wonder why try to compete with Visual Studio).
It makes me feel a little naked for those times that I use a different editor.
I have a fairly big app (18 prjs) and only ONE is written in VB.NET. Incidentally it was written by JEFF :))) (Unhandled Exception Handler)
I wish Jeff would have written it in C#...
If the projects that I work on are any indication, I wouldn't look forward to background compilation in VS2005 anytime soon -- merely typing in the editor pegs the CPU, and the entire IDE frequently freezes while doing something related to Intellisense (usually just long enough for me to lose my train of thought). Throwing background compilation into the mix would probably break the camel's back as far as me actually getting any work done at all.
Another vote for Resharper. I can write code for hours and be practically guaranteed it will compile. The only downside is that I am afraid to work without it at this point it's become such a crutch!
i too started with .Net as a VB coder, but i found the little diffreances from ASP to VB.Net fustrating and too simler but not the same so after a week i went to c#, where i have been happy ever since
oh and anyone who dosent get ReSharper is basicly just waanting to waste massive amounts of there own time, Yes VS 2005 has some refactoring but its no where near as good.
buy ReSharper now you will love. it. Hell try it for free for a month then see if you want to go back..
We are forced to code in VB.NET at work, and we all wish the background compiler could be turned off. I have a hi-spec machine, but I still have to put up with 2-3 MINUTES of blocked UI every time I open a file, scroll down a page, press return, paste text, type "." or "(", the list goes on.
Come back C#, all is forgiven!
stupid background compilation (like in vb.net) = evil
we had a project with a fairly large number of controls and datasets and stuff (back in the year 2002 or something like that).
everytime you typed in one character something in the background (compilation) took nearly 100% cpu time and the ide wasn't updating anymore.
compilation on demand background compilation
i want my computer to do what i want and not a 100% cpu time consuming process in the middle of some creative moments where you had to wait that your ide is willing to show you again what you had typed.
Jeff, I'm quite surprised that you see C# and VB.NET as a Pepsi vs Coke choice. You could have been right in the past but I don't see it that way any more.
You're right that the choice is more the matter of taste when the only difference is in syntax but C# and VB.NET differ in more fundamental way. C# is statically typed language while VB.NET can behave more dynamically. To be honest, I actually very much like VB concepts even though I hate its syntax (semicolons rule! :).
There are some real world implications. Look at the Jasper project: there is no support for C# language because of its static nature! Now you are hitting real limitations that C# has and VB.NET has not. That's what I call difference!
As I said, I very much dislike VB's verbose syntax but on the other hand, there are some sweat benefits of this language. I guess we still have to see the real battle of the throne of .NET languages.
I suggest Eclipse. It's a wonderful IDE and also Java is a great Programming Language. Eclipse have background compilation and tons of cool features you can't imagine. Also IntelliJ IDEA is very nice IDE Both are the Best IDE's on the planet. Visual Studio it is getting old idea from the 90's. Actually Microsft I really don't know what they are doing, They did great Tools before but right now they are failing to delivery good stuff.
Background compilation needs to be carefully evaluated before making it a default in the IDE. I take VB.Net as an example. When working with large solutions, with multiple files and projects (one example that comes to mind is dotnetnuke,) it can make the IDE very unresponsive when you're trying to simply type your code.
Another vote against background compilation. I'd hate it if I were writing up a method and the IDE would constantly paste red squigglies over every little bit of code that doesn't work yet (because I'm not finished yet, duh!). If Microsoft ever introduces this feature for REAL languages that REAL programmers use then I hope it will be optional!
For the counterpoint concerning the background compiler: first, I was trained in C[++], Java, and C#, so those little semicolons are very near and dear to my heart. The company that hired me is a VB.NET shop, so I learned. To the point: the VB.NET background compiler is crap. I would LOVE to be able to turn it off. The solutions I work on are frequently 20+ projects, and Microsoft has admitted the background compiler has issues resolving dependency trees more than 3 or 4 projects deep. When I open a new solution, the background compiler takes over, making my machine (no slouch - 2.8 P4D, 2G DDR2, 160G hdd) crawl. Opening a comparable C# solution takes almost no time at all. I LOVED the background compiler in Eclipse - it only activated when you hit save, not HALFWAY THROUGH AN IDENTIFIER when you stopped to think. Plus, you could turn it off completely. For the next version of Visual Studio, there better be a checkbox labeled "Enable Visual Basic background compiler" that I can uncheck.
@Damien -- NOT TRUE! Look at JScript.NET. It's lack of support for creating delegates is hardly a Visual Studio issue!
One comment really - why do you feel so insecure about the code you write?
I tend to write whole function / update / idea / sometimes even a little class, before I even try to correct the lines with obvious typos. Then comes first compilation.
It's not so good to switch between different thoughts and actions frequently. I'd say that correcting some mistakes while writing takes more time than correcting everything when you have an idea complete. When I see that "string" and "1" example, I don't know what you planned. Maybe it should be string, maybe an int, maybe it should be "1" and not 1.
If you made that mistake, you've done something else than you've planned - maybe there was a reason - just finish that part and see if your instinct wasn't better, than planned design... That code won't disappear - just get back to it later.
It's a bit like touch-typing - you make some mistakes at first when you're not looking at the keyboard... but it's faster to just stop looking - you've got backspace and arrows.
Try writing a full paragraph with no spell-checker and don't correct words - just write your thoughts to the end. Then correct spelling. It will be faster than thinking about spelling and content at the same time.
I agree with you here, but this is all part of what I think is the *same* principle -- the principle of revealing errors as early as possible in a project's implementation.
We use Continuous Integration to reveal our errors (with unit tests) after every check-in, we use statically typed language to show type safety errors at every compile, and, (the most extreme example), we use background compilation to reveal errors at every keystroke (or line-end).
IMO it's all part of the same glorious spectrum. Follow this path, and it will be the path to happiness. Divert from it (cough, cough, "classic" ASP/PHP/etc...) and debugging, testing, and implementation of your project seems more and more like its own circle of hell.
I come from a GWBASIC - QBASIC - Visual Basic 5,6 - VB.net, and now finally - C# background. It took only a couple of weeks to become proficient in c# and I agree that the languages are nearly identical. The case sensitivity drives me crazy too and the lack of the background compiler is a huge pain in the butt! In fact, for the last few years the major reason I was a big VB.net fan was not because of the language, but because of the superior support from the IDE!
Changing a variable here, compiling. Changing a line here, compiling...Changing a function compiling...
This approach is indeed wasteful and unproductive. I usually make it a habbit of studying the code thoroughly to prevent hacking it and wasting time like this. A descent amount of time can go by before I compile which in my workflow is okay.
And the longer I wait to compile the more likely the compiler will find code that breaks which is okay. It's doing its job and checking my syntax. Then I can go through everything and fix my mistakes in usually one or two shots.
As for checking runtime behavior that's another story but that still requires you to actually run your site or application and play with it to get an idea if it's working how intended.
This is one of the features I miss in Eclipse.
Unfortunately, I work in a place that prohibits the use of C#. So we use VB.Net.
And I don't have the luxury of changing jobs just to use a certain skill-set.
But, we are also not your standard programming house. We write lots of small utilities and report tools for a hospital. *shrug*
If the language keywords are ASCII, why not restrict the identifiers (variables and function names, etc) to ASCII as well
I realize it's an edge case, but...
Having spent several years teaching programming in Cambodia and Uganda, I am thankful that C# doesn't restrict identifiers to ASCII. Programming in .NET is a real possibility for the billions of people who don't speak English, precisely because there are only a handful of English keywords to learn.
We use ReSharper where I work and it is extremely helpful with one exception. It is absurdly slow! It slows down Visual Studio a lot in my opinion, but I love its features, so I continue to use it.
I think the root cause of the issue is that you're a weak-minded baby who is upset that you can no longer make do with the pablum that is VB. Background compilation is not a language issue. Stating that case sensitivity is a "religious issue" is a nice way to cover up for the fact that you're basically whining about having to change. Did you while all through school when some poor lecturer wasted his time trying to teach you functional programming? Why not just title this post "I'm Narrow-Minded" so people have a better idea of the basic thesis?
This is a comment about both the article and the other comments.
Yes, developers are religious about what they use, however, as one of your last articles stated, there isn't any real Microsoft "fan base".
That makes me wonder why I keep constantly hearing that Visual Studio is "the best IDE". I tried it (C#, Visual Studio 2005) and although I really gave my best to stay fair and don't judge it based on specific features I had in other IDEs that were missing in VS, the OVERALL experience was more than disappointing.
Aside from the bad code completion, lack of refactoring tools as well as code inspection, I was impressed by it's ability to actually mark a class as good when it contained obviously invalid method calls and made the compilation process break.
I'm a Java developer and have been using IntelliJ IDEA for years. It beats VS is nearly every aspect - and I never encountered a situation where IDEA said a class was OK but didn't compile.
Although I might start a flame war: VS is nice compared to coding C in VI, but it definitely isn't the best IDE.
My biggest complaint with C# is its very very strong typing. I'd like to be able as a programmer to be smarter than the compiler and allow me to use an object that I know has these methods/properties even it the compiler doesn't. A perfect example of this is if you are doing Office automation. If you reference the excel libraries in you C# application you are locking the client into having that version of Excel. I program all of my Office automation in a separate VB class so that I can late bind the objects.
Eclipse is really the best IDE out there
I strongly suggest you try IntelliJ IDEA.
the best IDE:
Come on guys, which is it???
Case insensitivity allows me (and I suspect most others) to have similarly named private variables as their accessor methods. What I hated about VB was that you couldn't do this, nor could you prefix variables with an underscore.
What C# means to me is that I can undo 6 years of bad habits forced onto me by an inflexible language. Just as I was forced into learning VB to get a job, the VB programmers are having to learn another language in order to stay relevant in the industry.
Case in-sensitivity is bad when a sloppy code writer cannot keep the casing consistent in their code.
Case sensitivity is bad when two variables are different because of casing.
Makes sense to me to flag both as errors....
one to force consistency,
the other to flag two items as too similar.
As with any language to hang yourself, these should be warnings....
Or will you be writing about the USELESSNESS OF COMPILER WARNINGS next?
I have to agree with most people who've posted comments. The background compilation in VB is annoying, it will highlight things and distract me while I'm still typing a line.
IMHO it's a crutch I will gladly do without (same thing with case sensitivity).
Put another vote up for "no background compilation". Anyone who wants VB background compilation has never worked in a solution with more than 5 or so VB projects. Period. We got to the point where it was IMPOSSIBLE to develop in the solution that held all of our projects. I spent days looking for ways to turn background compilation off because it costs me so much time in daily development, just waiting and waiting for the IDE to respond.
As someone who has developed large scale (~20 projects) solutions in VB and C#, I can attest that no developer in their right mind would choose to be subjected to the kind of torture it is to develop in VB.NET with large solutions. It's not just difficult, it's not merely annoying, it's flat out impossible. Unfortunately, by the time we got up to the ~20 project level, it was far too late to switch to C#.
Background compilation is nice for small solutions, but ReSharper does it 10 times better for C#. So be kind to your developers, choose C#.
To me case sensisitivity makes things much more readable.
getMethod() as opposed to getmethod()
I cannot understand someone disliking case sensitivity. And yeah, I am a C guy.
I always get a kick out of the Mac-vs-PC holy war that VB vs C# has become. I am an old VB6 developer, moved to ASP, then to VB.NET and ASP.NET in VB. I never really felt the need to move to C#. Yeah, there are a few things that C# can do that VB.NET can't do, but those things are NOT the bread and butter programming that pays my bills. I can write C# as well, but I can't see paying the 25% verbosity tax. When I spend a day working in C# my hands just ache from all of the extended shift typing. It's not nearly so bad in VB.NET. And if I need to incorporate C# code into my project then I can do so, or I can run it through a C# to VB converter. I don't need to grok the imported code, that is why it is imported code. If it does what it says it will do, I don't need to open the hood.
I would rather that MS let you mix C# and VB.NET code together more closely in the p-code than worry about pushing the expiration of a language that (good or bad) has eased the learning ramp for many programmers. Heck, even the accountants are using VB as their Excel macro language. Do you think they would write custom macro functions if they had to learn C# first?
I am curious. Do you have experience with large VB.NET solutions and projects? If so how did the size of the solution and projects effect performance of the IDE? If you experienced slow performance what did you do to address the situation?
In my experience VB.NET is crippled by the background compiler. It is relegated to solution/project sizes that your hardware does not puke out on. I am sure that C# has limits as well. The point is that I know, expect, and control when I will pay that performance hit by telling the IDE to compile.
I think that both C#'s and VB.NET's offering on this stink. They are both extreme. There is a need for intelligent autonimous compilation. Notice I did not use the word background as the background compiler is a hog.
Think about having Norton Antivirus and a VB.NET solution of 600KLOC. The IDE will crawl at best. Try watching it in ProcessMonitor. You will be amazed at the # of IO operations.
What about C++/CLI? Not that I'd endorse it or there's a huge gap between C# and C++/CLI but still...
I swear by Resharper now its a great tool.
Also once the ruby.net compiler is really up and going with ruby on rails support then i think it will become a two horse race. Not just C# but c# and ruby.
It's fascinating to me how people post with no idea of what they're talking about.
Case-insensitivity in a language does not mean that you can type
int banana = 3;
Banana = 4;
bANANA = 5;
It means that when you type that, the IDE will correct your code to
int banana = 3;
banana = 4;
banana = 5;
This is what VB .NET does. I find in these discussions that an extraordinary number of C# programmers rip on VB .NET despite having never used it, and having absolutely no idea what it can and can't do.
(As for me, I use both. Generally at home I try to use whichever one I'm not using at work.)
If only it were as easy as "switching to Java." If you write software for customers, you're going to write in whatever language(s) that customer supports. If they're a .NET house, then you're not writing in Java, whether or not that's your preference.
Furthermore, taking a 250,000+ line mature application and just "switching to Java" involves costs that no one wants to pay, and which could never be justified because "the IDEs are better."
"Switching to Java" might be easy for hobbyists, but those of us who put food on the table by doing custom development for large companies simply can't mandate those sorts of changes for personal convenience.
C# or VB.net? Coding for .NET. What are the member functions for this class, and what are their arguments?. Compilation tax for programming in C#.
I say to heck with it all, and just program everything in Perl.
OK seriously, if you have to hit compile after every line to make sure you didn't make any syntax errors, then YOU DON'T KNOW THE LANGUAGE AND SHOULD NOT BE PROGRAMMING IN IT.
I hope to god you don't have a real development job. It scares me that people out there are writing code and have no idea what the hell they're doing.
Just a heads-up: Arrays are 0-based in VB.Net.
If you want good IDE:s, you should consider switching
to Java and check out IntelliJ IDEA and Eclipse.
I have to strongly disagree about using Java. I am so sick of getting Java interfaces. They are slow, buggy, and resource hogs. If someone can come up with a compiler/installer that makes them executables when installed, I can stand it, until then Java should not be used for delivered apps.
In ancient times, the programmer's world was almost entirely filled by the ferocious punchcards and the angry reports. Programmer could meditate, read reports, punch some cards, meditate again and - when the Machine Time had come - he fed the evil god, with tremor and fear.
Now, where *any* report is? Or so called "cross-reference"? How can the programmer just make attempt to meditate, having nailed his eyes to the screen and his fingers stuck to the keyboard. Due to lack of meditation, the SHIFT-CTRL-B obsession came. Let's not cry for this, i LOVE this. What about you?
Background compilation only saves time when you are working on relatively small projects, on large ones it is a huge hinderance to productivity.
I use both VB.NET and C#, i find VB very verbose yet also very easy to use in throwing up a small quick application. C# is just the natural language for the .NET platform, while VB.NET has inherited its relationship with VS from its not so gifted predecessor.. :)
The second I finish typing the assignment (e.g., move my cursor off
the second line), the statement is flagged as an invalid assignment.
No compilation necessary; it automatically appears as an ambient
squiggly underline in the background.
I don't know why you don't also get the squiggly line in C#, I do.
wow, I had no idea that the C# IDE couldn't catch errors.
You might want to get over the case sensitive issue, by the way. It is pretty obvious that any given variable SHOULD ALWAYS be typed in the same exact case... So perhaps instead of case sensitive we should call it "Case Locking". I would be outraged if a compiler let me do this:
The compiler must reject the second line because of the undefined variables.
Also, if you must stick with an IDE that can't tell you about errors without compiling (I still can't believe such a monster exists!), you might want to go a little XP--as long as you're compiling anyway, throw in some test-first methodology and run the tests whenever you compile.
I don't agree with you on the multiple language thing. It's really nice to be able to use a dll compiled in vb.net in for example powershell, F# or C++ without ANY issues at all. The fact that you have to do this in separate projects is a non issue to me. I think there are very few people who want to use more than one language at the same time. But there are a lot of people who want to collaborate with people that use a different language.
I kinda agree with you on the case sensitivity thing. I think it's a good idea if C# wouldn't allow you to give two entities the same name although i wouldn't mind if the compiler would still be fussy about case and give warnings. I think t's bad even in case insensitive languages to use different casing. But the vb-editor kinda solves that for you by fixing your code while you type.
I absolutely hate background compilation. On bigger projects it slows down my computer and it bugs me when i'm not yet ready typing my code. Sometimes it even locks up my computer (dual core with 2gigs of memory) I'm used to hitting ctrl-s once in a while to save my code so i don't really mind hitting Ctrl-shift-B after that. It might be better if this was automated but i don't really care. I can fly in C#.. I crawl in VB...
I made a good living from VB6/VBA for well over a decade. And I still spend a good portion of my time in Excel/VBA even now. Which is the principal reason I accepted the annoyances of C# rather than take the more "natural" evolutionary step of VB.Net. The cognitive dissonance would have been too unpleasant. Moving to C#, having avoided C++ almost completely and not having really touched C since the mid-nineties, was really rather pleasant.
And I use F6 rather than Control-Shift-B. Middle finger of right hand is most satisfying.
Of course, this is silly:
Button button = new Button();
...that looked stupid even before I learned Ruby.
Oh, and I think Matthijs has most likely not seen the the VB IDE - if he could stand to be without the "button/Button" "standard" I think he'd rather like what VB could do. It's probably what I most miss when I switch from Excel to VS.
A few things...
First, VB will be around in some form as long as Bill Gates is around. It was his baby, and that paperweight will not go away until he does.
Second, I have always been a Borlan fan... From my first experience with Turbo Pascal and C and ultimately Delphi. I just like the Borland IDE. Most likely because it is familiar and that is always nice.
So, I guess it all boils down to what you know. If you started with VB probably like that tool... I started with Borland, so I like that tool. I am starting to like Eclipse and Java - because the place I work pays me to do it that way... Ultimately, I am a big whore and with a family I can't afford to be a zealot on any one technology or platform...
Wow, I really disagree with this artcle. Two things:
1. Case insensitivity is a GOOD thing. I would go absolutely nuts if I poured through some source code I was asked to take a look at and saw the following different ways a class was instantiated:
Variable names would be even worse. Imagine accessing a variable 10 times within a method, and a typo / pure laziness on the part of the programmer ended up with 4 different capitalisations for that variable. Hey, the compiler doesn't enforce it, so why should they?
Over the course of reading source code for even a moderately sized system, your brain will waste significant energy just slowing down and reinterpriting what has been written, to make sure that, yes, it's just the capitalisation of the variable that's different, it really is the same variable.
Your brains' ability to automatically "scan" the source code is virtually eliminated, so instead of concentrating on the logic in the code, you're concentrating on slowing down, reading and understanding the names of the variables. This is a monumental waste of brain power and of time. You say that case sensitivity would make programming more about "people", but I emphatically disagree. This would make things HARDER on us; we would tire more quickly because of the unnecessary concentration required to decipher these capitalisations, and it would slow us down.
The end result would be that companies would have to institiute a variable naming policy that says capitalisation must be a certain way; in that case, there's absolutely no reason not to have the compiler enforce it in the first place!
2. Re the "compilation tax". Others have addressed this but I will as well. My development machine is decent, but I could have many applications running - Word, SQL Management Studio (which implies the SQL database engine is running), several pages of Firefox, UML modelling tools, text / log files, and of course VS. I would find it absolutely inexcusable for the IDE to decide of its own volition to constantly compilie my code, eating away at my system resources and chewing up clock cycles. For a large project, this would be unbearable.
So yeah, I can't find myself agreeing much with this article.
I have to admit that I don't completely agree.
First, a quick note on case-sensitiveness. You say that 'As an advocate for people over machines' you think case-sensitive languages are wrong. I'm a developer, but a person too.. I'm a suer most often than not. I'm a 'business expert' in whatever activity I engage in regularly. And to me, 'Banana', 'BANANA', 'banana', 'bAnAnA' (and derivatives) are different words, different concepts. If I type them differently, there must be some reason for it. So, sorry, I think case-sensitiveness is ok, even from a 'people' perspective.
Secondly, the compilation tax that comes with C#.
All right, I'm not going to get in the whole religious debate of compiled vs interpreted languages. The bottom line is that each type of language has its own place.
However, I don't think that the comparison of C# vs VB.NET in regard to the 'background compilation' is quite fair.
At work, I have Resharper. At home, I don't. Even without it, Visual Studio seems fairly reactive in pointing out issues with the code I just type. At least in the 2005 version.
Definitely, Resharper, and other similar tools, help the developers out and are worth their price, but one can live even without them.
Don't take me wrong, I completely understand your point of view. Here at work, our current project is rather large, and keeps on growing. We ran a few tests, and it takes us at best 40 seconds to build the solution on our machines. At home, it takes me at worst 10 seconds to build the same solution. The fact that we looked into this sort of comparison should demonstrate that we are painfully aware of the cost of building (take those 30 seconds, multiply them by the average number of builds each of us is doing every day, by the number of developers on the team, and you actually get 6-to-8 hours of time. So we're debating whether it costs more to upgrade our PCs, or to add a new developer to the team).
Sure, the compilation step is an annoyance, and developers should constantly be on the lookout for ways to minimize its cost. However, things like the 'background compilation' feature are merits or drawbacks of the IDE rather than the language.
Thanks for the thought-provoking post as usual,
I think the problem is that there is a compilation step in the first place. Why I just can't run my application right out of source code? I wish JIT compiler would be able to accept raw VB.NET or C# just like it does MSIL.
It can, if you are using VB 10. Or at least that is what they are planning.
Err, obviously, I meant to say that case SENSITIVITY was a good thing, not INsensititivy. :/
ps.: I liked your comment about case sensitivity. I'd like to see something different in the future: a compiler that automatically adjusts the case of your code.
VB has done that for over a decade.
Hey hey! Finally a spammer slipped through the orange filter! Amazing it's worked so well thus far though :-)
Good list, Jonathan. Let me pile on about the VB9 XML code literals features. This builds on LINQ support in Visual Basic (which is very good), the new LINQ to XML (nee XLinq) API and of course the inherent ability to late bind types in Visual Basic (which is the key difference from C#, as Erik Meijer points out in many searchable places on the web). I should also say that this isn't just the VB9 compiler; the XML language service in VS will pick up on dynamic type information where available in XSD's and provide Intellisense for attributes and elements (and the XML code literals switches the literals into XML mode).
If you haven't actually tried this stuff, you won't believe how productive it is. If you're a regular programmer who deals with XML config files, XML message fragments, XML document scanning, XML report production (yadda yadda yadda) then I think you'll love it.(Tom, I'm looking at you here.)
http://blogs.msdn.com/xmlteam/ for XML love
http://blogs.msdn.com/data/ for links to Jasper et al
ObDisclosure: yes, I work at Microsoft, on this stuff
Haven't you just recently said something about Visual Studio 2005 being the best IDE ever?
I have to agree with some comments, go try Java Jeff. It has kinda the syntax of C# and Background-Compiling.
I personally use Eclipse, which I think, is just one great IDE, but IntelliJ seems to be pretty awesome too. (though its not free)
I have to strongly disagree about using Java. I am so sick of getting Java interfaces. They are slow, buggy, and resource hogs.
common, thats not true, go use SWT if you think Swing is to slow (which it really isnt anymore)
It's fascinating to me how people post with no idea of what they're talking about.
Case-insensitivity in a language does not mean that you can type
int banana = 3;
Banana = 4;
bANANA = 5;
Actually, that IS what case insensitivity means. You have to remember that the language is independant of the IDE, and you should be able to write VB.NET code with a simple text editor. VS may change the case to keep things neat, but VB.NET itself does not care about the case.
All of which makes your opening statement a very nice example of irony.