Hi,

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..

http://weblogs.asp.net/jkey/archive/2005/01/29/363227.aspx

.. 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.

Hi,

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:

<a href="http://www.codinghorror.com/blog/archives/000195.html">http://www.codinghorror.com/blog/archives/000195.html</a>

"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.

[)amien

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.

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.

@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.

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

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.

- Roddy

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.

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.

Regards,
Borek

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.

Jeff:

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!

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*

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:

Visual Studio
Eclipse
IntelliJ

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?
(hint hint)

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?

Jeff,
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...

@Martin Vilcans:

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.

Jeff,

I encourage you to go a week with minimal automated code-correctness checks. When you've gotten to the point where you rely upon continuous automated checks (which can miss a tremendous number of problems where the code is syntactically and type correct, but logically broken), you've seriously harmed your craftsmanship.

http://www.yafla.com/dennisforbes/Edit-and-Continue-Valuable-Tool-or-Sloppy-Vice-/Edit-and-Continue-Valuable-Tool-or-Sloppy-Vice-.html

Just a heads-up: Arrays are 0-based in VB.Net.

Even if VB.net is the unwanted child, which honestly it very well might be, like someone mentioned earlier MS pretty much had to incorporate VB into the .Net framework. Imagine all of those legacy VB applications that are out there. If MS wouldn't have incorporated VB then chances of those applications getting moved to a newer language becomes a lot more slim. From what I understand there are already a fair amount of VB developers that refuse to go to .Net due to the changes in the VB language from 6 to .Net.

As for C# vs VB.Net I am a VB purest, but I don't know how long I will be able to sustain that. It does seem that there is reduced demand for people who can write VB.net. If your job uses C# I don't know how people can do the conversion of code between the two. Like Jeff mentioned I can only imagine that it would be a nightmare to do. I do have to ask why is C# the new language that everyone seems to need to know? Is there the performance benefits or is it that most of the java, c++, and other languages made the move to .Net first where the VB developers just said "Screw .Net", in essence and are fighting to stay with VB 6?

>> 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.. :)

Don't forget in the punch card days. Insert your deck into the queue for processing, go to the bar come back in 3 hours to find out that 1 card is wrong. So go recode the deck and repeat everything over again and pray you don't drop your deck.

> 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:

int bob=7
Bob=boB+2

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.

no
yes
no

no,
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.

yes,
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.

no,
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...

Wayne

Have you seen the stuff coming in VB 9 and 10? The languages are certainly are diverging and VB is getting a ton of stuff not foudn in C#.

Mutable Anonymous types
http://www.infoq.com/news/2007/05/VB-Anonymous

XML Literals
http://steve.emxsoftware.com/LINQ/XLinq+has+me+wanting+to+code+in+VBNET

Scripting, REPL, Dynamic Objects like Ruby/IronPython
http://www.panopticoncentral.net/archive/2007/05/01/20383.aspx

Jasper, which C# doesn't support
http://blogs.msdn.com/aconrad/archive/2007/04/30/project-jasper.aspx

Silverlight 1.1/runtime compliation
http://blogs.msdn.com/vbteam/archive/2007/05/01/vb-on-silverlight.aspx

It has been a rough few years for VB fans, but things are going to get much, much better, especially when Silverlight 1.1 comes on the scene.

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.

No ?
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.

> 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 :-)

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)

This may have been stated before too but the background compilation in VB may be a throwback to its beginning as an interpreted language in QBASIC. Although I could be completely wrong on that point.

One thing I found interesting in my stint at Microsoft is that about half of the team I was on used Emacs. It seemed to be a generational thing - pretty much all of the old guys used Emacs, there was a group in the middle that used very weird products like SourceInsight, and then the newer people all used VS.

Emacs was interesting for a few reasons. First, C++ isn't a first-class language - lisp is the preferred language. Second, the Emacs programmers blew away all the other programmers for productivity. I imagine a good part of this is the programmers themselves. But I asked them why they didn't go for the editor with the integrated debugging/edit and continue/etc, etc. The answer was that they spent most of their time writing code, and Emacs has features that make that faster than any other editor. In many respects, VS is still trying to catch up to Emacs for pure text editing speed. They're constantly adding features to try to appeal to the Emacs crowd. For example, incremental search (CTRL-I), rectangular block selections (alt-shift-arrows), and many others. If you check the possible key bindings, there are many commands that are prefaced with 'Emacs', which emulate Emacs text editing behavior. Fast editing means other operations such as refactoring are also very fast.

The features you mention in VB over C# are nice and shiny, but they seem designed primarily for devs who don't spend most of their time typing code - they spend most of their time bouncing code they found on the internet off of their compiler. Perhaps they are making assumptions about which kinds of developers would want to use one language over the other. C# is designed primarily to attract Java and C++ developers (including most of Microsoft itself).

I get the feeling that Microsoft in general is kind of embarrassed about VB.

I'm fairly neutral in the C# vs VB debate. However, people seem to be missing the point about case-(in)sensitivity in VB.NET. VB.NET IS case-sensitive - you can use case in the naming of your variables. Code and variable names would be truly ugly if you couldn't. What VB.NET does allow you to do is to type your variables without worrying about the case - if you get it right then your entity name is automatically corrected and provides instant feedback about the correctness of your code. The only limitation, as has been pointed out, is the 'Button button = new Button();' issue.

Many C#ers complain about how verbose VB is, but in terms of typing effort, all the extra <SHIFT>s and added hand contortions more than offset the other benefits of language conciseness.

Note: I don't work on projects that are large enough to comment on the cons of background compilation and maybe case-correction in VB.NET is part of that?

> Just a heads-up: Arrays are 0-based in VB.Net.

Yeah, but in VB you may find your Arrays have an unexpected size:
http://odetocode.com/Blogs/scott/archive/2007/05/02/10763.aspx

> I absolutely hate background compilation. On bigger projects it slows down my computer

I've always said that background compilation should be a configurable option; some people hate it even on small projects. I think it's a net loss for the entire C# programming community that it isn't even available, at least not without buying a license for Resharper. And even then a few people above complained that Resharper was too slow..

>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.

By his baby, I hope you know he went out and purchased it.

Actually, VB went downhill for quite a while after MS purchased it. In fact, I still don't think it has the best feature VB3 had when I started using it.

In VB3, no matter where you were on the editor or what you were doing, if you hit F1 you got EXACTLY what you were looking for. If you were on a keyword, you got syntax and help about that keyword. If it was a library call, you got the parameter info you wanted. If you selected the header of a callback, you got when and why that function would be called.

With it's integration into the MS IDEs, an awful lot of that got lost, and I don't think they ever regained it. Now if you hit F1 you end up at the index of a massive library, or in some C# function, or...

(That's how it has seemed to me, I'm sorry if your mileage varied).

Another point. I'm getting really tired of people blaming Java for having bad GUIs.

There are some Java "programmers" out there without a clue how to program, and they tend to make bad GUIs. If you don't understand about the event thread, you should not be programming in Java. Period.

I just heard about an experiment where Sun made a VB compiler that ran in the JVM. It sped up the VB code by a factor of 10 over the .net version.

The JVM is FAST. It has the potential to be FASTER than C++ (It's currently nearly as fast for most things, and the JVM can do optimizations that C++ never will be able to do).

If CPUs were made to interpret java bytecode, it has the potential to be significantly faster than x86 assembly (Much of the bottle neck is reading and writing to/from the CPU, look at the size of a JVM instruction compared to a x86 instruction, plus the hardware would have much more room for optimization).

"Over the last four years, I've basically given up on the idea that .NET is a multiple language runtime."

I think it is.
Only that the idea was not that the same developer will write code in 10 languages. There is no point in doing that.
The idea was that different teams can write code in different languages, with the result integrating smoothly.
Same for 3rd party controls, components, etc.

Ecplise does the same thing for java too - it has IBM's jikes compiler built in. It uses this so the the code is always ready to run and that deep errors are always shown. PLus the editor / refactor code has a much deeper understanding of what its doing.

Ecplise runs rings around vs. But VS is what we have when doing c#

Some thoughts:

1. I think there is a productivity tax which VB helps out with, this is a good feature, maybe if it were more selective it what it compiled it would be better. Syntax errors should be fixed as quickly as possible. But with large project I can see a hit in performance. But why is your project so large? Shouldn't it be broken down in smaller chunks. This is a problem I see a lot, the Mega Visual Studio Project.

2. I really wish that MS give the ability to compile to native platform. The intermediate lanaguage cuts productivity in my opinion. We have to obfuscate everything in in some cases bugs are introduced in the obfuscated code which don't exist under normal compilation. We have to use some tool or use a map to figure out what a.b() is in our real method calls. This stinks. Even bugs that exist in code have to be translated when the exception occurs. With MSIL, someone can reverse engineer you code pretty easily.

3. I think the case sensitivity is stinks at first, but in the long run it will make you a better programmer. Because it will force you into conventions. You can also make it work for you. For example, a private method could be called doSomething and a public method could be called DoSomethingElse. By using case, you can use the case to differentiate the scope of the method provided everyone follows the convention.

In the future, I think Microsoft will want everyone on one language or maybe 1 managed language and 1 unmanaged language, it will certainly be easier for them to maintain. VB is (was) a popular language choice, so it will be hard to get everone off of it in the near future, or maybe that will be the managed language of choice. Really, I think C# is to woo Java programmers over to the "darkside".

The case-sensitivity issue makes me give a vote for VB.NET. I follow the proper casing conventions for variables and functions, but when I'm actually writing code, I type in all lower case. When I press return, I watch the IDE automaticalle fix the case of all of my variables, keywords, and functions. If something is not corrected, I immediately know where my error is. Lazy? Perhaps. But I can type code really fast without ever having to hit the shift key.

"Evil Case Sensitivity" is actually a good thing.

But it should be implemented as follows in the C# IDE.

Once you have typed: "int Count = 5;"

... then later in the code when you type "count = 4", it would auto-magically changes "count" to "Count".

This would ease your pain and still allow for Case Sensitivity, which should be required.

> 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.

Funny. I just swiched to VB project from C#, and I found exactly the opposite effect of productivity.

VB's instant error messages caused me to slow down tremendously. It's because I edit code by writing incomplete bits all over the place, jumping around as ideas occur to me. In VB, everytime I move off the line, it get a tedious error pop up. My reaction is "I know! I am not done yet! Fuck off!"

For C#, your whole compilation problem is really really easy to avoid: just don't compile until you need to. Really. Just don't do it. With Visual Studio's name completion, most typos are avoided.

I do know that background compilation can actually work well. Java development in Eclipse uses it very well. I think that works because errors are unobtrusive markers off to the side, with problems in a problem log that you are not forced to look at.

Dennis,

> http://tinyurl.com/2zeov3

Ah yes, that old logical trap. Better tooling makes us weak! It's a crutch we begin to rely on that cheapens our craft!

This is even debunked all the way back in Mythical Man-Month:

"There is a widespread recognition that debugging is the hard and slow part of system programming, and slow turnaround is the bane of debugging. So the logic of interactive programming seems inexorable."
http://www.codinghorror.com/blog/archives/000026.html

And then, as for the logical fallacy of "easy tools make you weak":

"So let's get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code."
http://www.codinghorror.com/blog/archives/000090.html

This isn't a zero-sum game; better tools let good programmers work faster. The bad programmers, well, it doesn't really matter what you give them because the output will be the same: disappointing.

> It's because I edit code by writing incomplete bits all over the place, jumping around as ideas occur to me. In VB, everytime I move off the line, it get a tedious error pop up. My reaction is "I know! I am not done yet! Fuck off!"

Then you guys must REALLY, REALLY hate that disturbingly similar feature in Firefox 2 which underlines misspelled words with a red squiggly.. ;)

http://www.mozilla.com/en-US/firefox/features.html#experience

Strange, because most people seem to think it's a killer feature. I guess you guys are both kick-ass spellers and coders, then!

I kid! I kid!

On background compilation...

I see some comments about 20+ projects or 200K LOC being a large solution. Try 116 projects and over 700,000 LOC (and growing). Background compilation is a travesty heaped upon unsuspecting VB developers. It's great for small projects, but the productivity drain in the IDE (even on late-model dual-core machines with plenty of fast RAM and HDDs) is a far, far worse "tax" than CTRL-Shift-B.

I'm a little mystified about the complaints about missing background compilation. Why? I guess I'm surprised that there are so many programmers who are not capable of writing syntactically correct code without an IDE. How do you get anything done when you're coding via SSH?

+1 for background compilation actually causing pain on larger projects. One of our solutions is only ~7 projects with ~100KLOC.

Background compilation is more like make a change, wait 8 seconds, did the red squiggly go away yet?, wait 8 more seconds ... is it still red because I did something stupid or is the background compiler still churning? ... wait 8 seconds ... ah, what the heck ctrl-shift-b.

- JasonL

Regarding the case sensitivity issue:

The "theory" of case insensitive identifiers has its merits, computers working for people and all of that.

However, it only makes sense in an ASCII world.

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.

The Scheme language has historically been case insensitive. The latest revision of Scheme as switch to be case sensitive for this reason.

I'll contribute almost nothing to the discussion: #Develop. It's a great IDE for the cost, and while it's no Eclipse or VS2005 at least it's rather speedy. The other added bonus is if you find a bug, you can fix it yourself (or in my case, add a very small MSBuild feature that breaks in VS2005: BaseIntermediateOutputPath). Background compilation could be added, but I'd probably go with OnSave versus OnFinishedTyping. Compiling automatically saves open documents, so it'd make sense that saving documents would start a compile session (saving the other unsaved documents in the process, though).

> Strange, because most people seem to think it's a killer feature. I guess you guys are both kick-ass spellers and coders, then!

I am a terrible speller. I actually don't mind squigglies, margin error markers, etc. They don't get in my way.

VB6's error popup actually prevents me from continuing to type, and that slows me down.

I haven't actually done any VB.NET, only C#, so I don't know if the error popup still occurs. If VB.NET has unobtrusive error markers then I am fine with any immediate error feedback.

I had too much to say for a comment. My response is on my blog, http://cullenwaters.blogspot.com/2007/05/follow-leader.html

I think it's your responsiblity as a .NET developer to know both syntaxes. I prefer VB.NET to C#, but I learned on C in college and have had run-ins with Java. So C# is not completely foreign.

And I don't think it's too much to ask to know both. Once you have .NET and OO concepts down, syntax is almost (but no completely) irrelevent.

I mean, if your a web developer, you have to know multiple syntaxes such as HTML, Javascript, SQL, plus a server language (vb.net, c#, php, perl, etc.). So what's one more trick in your bag?

Plus you can prevent pigeon holing yourself at least a little.

I'll toss another plug for Resharper... assuming you are using 2003. The 2005 version is a bug ridden nightmare of resource hogging.

Delphi allows you to write .NET apps in Pascal. (I so love the fact that Reflector will show you stuff in it!)

Mixed case is unfortunate, and I could never get my head around the "reverse order" of declaring stuff. Background Compilation is a time saver if nothing else. Hard to imagine coding without it.

Background compilation can and should be fast. A compiler doesn't have to recompile your entire project if you change one thing. Lisp compilers compile only the functions you change, and so do Smalltalk compilers. You don't even notice that they compile: you just press a key and it's done. Instantly.

This is only one of many things that "modern" language IDEs fail to do: object browsers, select and execute code immediately, access to your language in the IDE.

As a long time SQL Server guy I started years ago doing little utility apps in VBA and VB. Man I wish I would have gone C# when I made the switch to .net. Mainly out of laziness. It is so much easier to find code samples for C#

I enjoy knowing both languages and reaping the benefits of being able to take on jobs regardless of my language preference. Any .NET developer worth anything should know both.

I would certainly like to have background compilation as an option. Our current project is 52 projects (over 800k LOC) and growing. The BC does add a certain "lag" that intrudes upon my daily productivity.

There are things that you can do in one language that you can't do in the other on both sides, having debate over which language is better based on that is pointless, as is the whole case-sensitivity issue.

MS is never going to just support and promote a single language in .NET. The whole point of the platform is that any compliant language is supported in the IDE. And I don't see that ever being removed from their marketing plan.

Pick a language, learn it, love it, and live it. Then use your skills and learn the "other" language.

Your job opportunities and your wallet will love you for it later.

;)

Visual Assist also does a pretty good job at showing you all your compilation mistakes as you go. I find that it makes me fix 50% of my simple compile errors before I actually compile.

And just another quick tidbit. Quit complaining about code snippets coming in the majority as C# samples.

Take a peek over on the Telerik.com website, they have a very nifty and accurate code conversion utility that will translate C# to VB.NET and vice versa.

They have actually made it a plug-in for your MyGoogle page as well.

This is the problem with VB developers. Development is supposed to be hard, ok? We like it that way... stop trying to make it easy.

As many have already said (but it can't be said enough), try ReSharper. Incidentally, it now does VB.NET (ver 3 that is in EAP).

I have started using C# for all my BLL and DAL and use VB.NET in my ASP.NET projects. I enjoy the fact that because I'm coding in different languages I have to think more carefully about where I put my code and I do find that each language lends itself better to these particular areas.

Just my personal preference ;)

Hopefully not sacrilege, so I offer this respectfully.
What of CodeGear Studio? You get C#, as-you-type syntax checking, and a better than BASIC language in Object Pascal? <as he ducks and runs for the nearest cover>
But seriously, the pendulum may be swinging.

The Telerik converter looks pretty useful.
http://www.codechanger.com/

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.

I definitely like VB.NET, it seems to me it has a slightly more dynamic feel than C#.

Check out these slides here: http://feather.perl6.nl/~audreyt/osdc/vb.xul

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)

lol - vb.

poor loser.

> 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#. ;-)

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?

> 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)

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"
http://msdn2.microsoft.com/en-us/library/ms379617(vs.80).aspx

"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. ;)

"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.

http://flymake.sourceforge.net/

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 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.

The current project I work on is split between 3 solutions, One containing 52 projects, and the other two containing 14 and 18.

I do not want the additional tax of background compilation added.

Then again, I learned to program when you had to create a makefile, so perhaps VB just makes people lazy?

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.

>> 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.

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.)

Regarding Ctrl+Shift+B, and human factors:

Why does one of the most common things to do in the Visual Studio IDE -- build your project -- require a complicated 3-key shortcut in the first place?

One of the first things I do when I sit down at a new install of Visual Studio .Net is map "Build Solution" to the F7 key (which was shortcut key for Build back in Visual Studio 6).

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.

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:

new MySuperClass()
new MYSuPeRClAsS()
new mysuperclass()
new MYSUPERCLASS()
new mySuperClass()

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.

Err, obviously, I meant to say that case SENSITIVITY was a good thing, not INsensititivy. :/

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

Kyralessa:

>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.

why do you rebuild the whole solution? that's rarely needed, use Shift+F6 instead to compile just the project you're working on...

"It's fascinating to me how people post with no idea of what they're talking about."

Now, come on. When you start a post like that, there's a law of the Internet that states you will spout several paragraphs of pure BS before the post is done. At least the natural laws of the Internet continue to hold.

"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."

VB.NET is not the only case-insensitive language out there. It's certainly not the first. I would hazard a guess that people around here who don't like case-insensitive languages were exposed to other case-insensitive languages long before VB.NET was even conceived. All of which is to say: when discussing case sensitivity in a language, describing the particular behavior of the VB.NET environment in the Visual Studio IDE is not the be-all/end-all/QED slam-down you think it is.

A case-insensitive language is defined such that code of the first type compiles just fine, with or without IDE cleanup. A case-correcting IDE is what you are describing in the second case. They are not mutually exclusive (I understand that VB.NET is case-insensitive as well as the IDE being case-correcting). However, they are also not the same thing. There are many case-insensitive languages whose main IDEs are not case-correcting, and it is certainly conceivable (although I don't know of any examples) for an IDE to be case-correcting while the language is case-sensitive (see discussion above).

As for VB.NET: I'm quite positive that if you had code of the first type above (obviously in VB-ese instead of C-ese) written in a text editor and passed it to the VB.NET compiler, it wouldn't complain in the least. That's because it is case-insensitive.

Wow, Jeff, you've gone viral.

Good article by the way.

Like some prior comments have said, you code in c#, do it with Resharper! You'll find a lot of your niggly c# issues disappear then.

Your rant is funny from the point of view of a Mono developer. We don't have the cute frills of VS, so continous compliation means very llittle except in or IDE, monodevelop, which does have a form of, bbased on when you save, howerever the features you miss above are not found for us by comply/reflect but by an extra lexor in the IDE. In fact that is how VS does it for VB, not by contiunsly compling the way you think. Really those are hard features to support but it isn't a problem with the IDE, but your understand and your dependence on it. VVS rots your mind. I challenge you to write and maintain a basic C# app using notepad and makefiles or nant, and you will learn to break yyour dependence and understand how silly that train of though in your rrant is.

I'm not sure how to respond to this post of Jeff's. I think the problem with auto-compilation and endless compilation cycles is unrelated to how the IDE does it - these are purely, IMHO, crutches for hackers to assist them in hacking out code they have not nor ever plan to think through. If you know what you are about to code, if you understand why you are coding it, if you understand its role in the broad scheme of the project then you should be able to generate whole methods if not entire classes by simply keying them in. The compilation step then just becomes the sanity check to catch all the silly little mistakes like the minor irritation or incredible benefit that is/is not case senstivity, typos and the occasional forgotten parameter.

On the other hand, if you have to stop all the time to make sure that you are not assigning the integer value 1 to a variable that should only receive a string, namely Jeff's variable s in his example, then I suggest that you have no idea what the purpose of s is in your code and therefore you do not understand what you are coding, you do not understand why you are coding it and likely you don't know its role in the grand scheme of things. If that is the case, then my dear friend you are hacking and there is no other way to interpret that.

If you know what you are building you can develop just as quickly in TextPad with a command line makefile than you can in any IDE. These features you discuss are, IMHO, a boon and a bane to development. When you have a really nasty bug, a good visual debugger is a wonderful tool. However, when you see developers creating code by debugging until their for loop seems to do what they want, then it is clear that the debugger is hurting their productivity, not helping it. Tools that enable hacking without thought or design may be valuable when used properly; unfortunately, my experience has been that they are generally used to eliminate the need for that difficult process called thought.

"Most people would rather die than think; in fact, they do so",
Bertrand Russell

Next time you find yourself extolling the virtues of a debugger or a background compilation process or whatever, make sure you are extolling it for its virtues and not because you would rather let the computer do your thinking for you.

Tim

>This is even debunked all the way back in Mythical Man-Month

It is hardly a black and white issue (the only logically fallacy occurring here is your assumption that it's all or nothing), and the M3 certainly didn't debunk the idea that there comes a point where tools impede the craft more than they help it. I hardly railed against the appropriate use of tools, but when you rely upon the IDE to constantly compile, catching basically idiotic errors (while obviously missing much more insidious errors), I would argue that you're far past the point where your creations are craft by any measure.

Though I will provide a loose correlation that I've observed: the better the programmer, in my experience, the less they rely upon automated helpers and tools.

I can't believe that you would list only C# and VB as .NET languages giving IronPython as runner-up. What about C++/CLI? This is now definetly a first class .NET citizen. There are many pros and cons, some of which are listed here. http://www.codeproject.com/managedcpp/whycppcli.asp
For writing high performance applications, C++/CLI is far ahead of C#, alowing much more control when using native code.

Indeed, sometimes I wonder if they should be considered different things:

In Delphi, they're not. I'm not convinced that's a good thing though.

Check out "Just Code!", it's a VS2003/5 plugin that adds a background compiler and other tools.

http://www.omnicore.com/en/justcode.htm

-Jesse

> when you rely upon the IDE to constantly compile, catching basically idiotic errors (while obviously missing much more insidious errors), I would argue that you're far past the point where your creations are craft by any measure.

Thus, any author who relies on automatic, background spell checking in his or her word processor is also "far past the point where their creations are craft by any measure".

I think this is an utterly ridiculous argument.

>Thus, any author who relies on automatic, background spell checking in his or her word processor

Going for the bait of grossly dissimilar analogies, many professional authors do eschew or disregard features like automated spelling and grammar checking. I can't imagine a professional, experienced writer (which most of us bloggers are not) arguing that a given tool didn't continuously warn them when they used the verb in the passive sense, their fingers tired from invoking the shortcut.

Case-insensitivity: 1) no thanks 2) case-correction, maybe if it works well and not when I didn't intend it

Background comp: I'd like it for c# but it would have be 1) optional 2) if on, only use IF IDLE CYCLES ARE AVAILABLE, not constantly like it sounds VB does it 3) it should use multi cores for speed.

forgot this:

Background compilation: I'd prefer also if it only performed it's thing when adding the ; or } or ), not on every letter!

One word: Resharper!
I'm glad many other people also commented about this great product. I can hardly support programmers who don't have Resharper installed.
But Background Compilation isn't its strongest feature, in my opinion. It is the navigation shortcuts that does it for me. You can go anywhere from anywhere with a few clicks - once you get those clicks mentally mapped (I suggest hanging a keyboard shortcut cheat sheet nearby, to learn faster) you'll never look back.

you could try http://emonic.sourceforge.net/ it's mono/.net-eclipse integration project... looks promising

Actually it is that aspect of VB that quite irritates me - stop constantly telling what is wrong, I _know_ it and I am currently in the midst of writing more code that will settle it. Extra alarm clocks are not appreciated.

[quote Miguel P. on May 15, 2007 01:49 PM]
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.
[/quote]

Yes, I believe you....

http://www.sellsbrothers.com/fun/macho.jpg

You should check out C++. You've got includes. You don't NEED to know EVERY SINGLE THING ABOUT OOP to use it.

Fact: The dumb Microsoft Programmers who are programming in C# don't know OOP

Fact: They wouldn't need to if they knew C++

Fact: "Hello World" in C# needs OOP

Fact: I hat C#.

This whole C# versus VB.NET battle is rather amusing.

Especially when the analogy of a battle between Coke and Pepsi is introduced.

If you realise that they're both fizzy soft drinks for children, and the real winner is beer, then how does that make the original comparison look?

>> Thus, any author who relies on automatic, background spell checking in his or her word processor is also "far past the point where their creations are craft by any measure".

>> I think this is an utterly ridiculous argument.

Jeff, this statement is a bit of a straw man. A spell checker doesn't do a heck of a lot for mechanical grammar, nor anything at all to create a great story; it doesn't affect the "craft" of storytelling much. Any arguments that relate the craft of storytelling to reliance on a spell checker will therefore almost certainly fail. On the other hand, most modern compilers check for more than just syntax; such a compiler is hardly the be-all and end-all of good code "crafting", but it does have a significant effect. Thus, arguments relating the craft of coding to reliance on a compiler's error checking MAY be valid.

> when you rely upon the IDE to constantly compile, catching basically idiotic errors (while obviously missing much more insidious errors),

Let's change this to read, "when you rely on the IDE to constantly compile, catching ALL of your errors (when insidious logical errors are obviously being missed),". I think this is maybe more in the spirit of what Dennis meant, and I don't think that you'd have to go any further than the comments on this blog to see that this concept certainly isn't being discouraged. I'd be interested to see how you would refute this revised statement without any self-reference at all, since we're talking about the general case; I'm going to be (justifiably, I think) generous and believe that you don't blindly rely on your tools to tell you when code is well crafted.

It's interesting that you point out a metric like "instructions per man-year" from a source like MMM. Wouldn't "bugs per line" be better? No, wait, old bugs held for backwards compatibility reasons would skew that. Hey, didn't somebody write a book about poor abstract metrics?

Languages: Nemerle.
Compilation tax? Resharper.

@Eric: Some warnings that do make sense is if a compiler allows "backward compatible" code to be compiled and it contains references to deprecated methods/properties/classes/etc. If a compiler became strict then yes, it's an error. An unused variable? That's an error. (That's one that gets me... Clean up your code, dammit!)

@Jim Cooper: He may have changed his color scheme and just edited the error color to match the background...(http://www.codinghorror.com/blog/archives/000682.html) (Just messin with you, Jeff...)

@Jeff: I've made the switch to C# about a year and a half ago. I haven't touched VB since. However... Just today, I started typing in a variable declaration in VB syntax. How dumb is that? I really haven't missed the background compilation, and just type away. Then when I clear my head of all the little things I'm trying to dump out into the code, I then compile. When I was working in VB.NET, I was grateful that 2003 had the option to turn it off. I could work faster, even on a 3.3 GHz/2GB RAM/[add other geek hardware words here] PC. It slowed so bad, just on one instance, and I didn't even have any add-ins installed!

As for all the C# vs. VB vs. [insert any other language here] arguments: a Schwartz is still a Schwartz. It's all a matter of how you use it, and how often. As VB and C# progress, they are coming close to doing the same exact things, just with different syntax. One of the things VB will probably always do is some of the hold over stuff from VB6 (Option Strict/Explicit, anyone?). C# should NEVER follow that path because then it becomes too fragile and would lose the C++/Java converts. Does it sound better when you compare Bud Light to Miller Lite? They are both crappy beers in my opinion. If someone could make the comparison to Beck's vs. Schlitz, then I would most certainly vote for Beck's. (Now I'm thirsty...)

Case sensitivity? Eh. It's pretty much a moot point anymore. Since VB has been case insensitive for so many years, moving it to case sensitive would be a bad thing for the VB4/5/6 converts. As for sloppy programming, it's a matter of paying attention to detail and setting up some coding standards for the shop/project/group/etc. THEN sticking to them. This can go for ANY language. ANY language can have sloppy code created in it. A thing called "DISCIPLINE" will help in making things cleaner and more maintainable in the future.

As for learning "DISCIPLINE", it doesn't come overnight. It takes practice, mistakes, trial and error, and humility. With this, everyone as a developer can go far.

And for everyone who thinks Jeff is saying that he now sees C# as the only .NET language, read again. He's pretending. He still is a VB developer at heart but is trying to embrace the world of another language and all its differences to VB. And he's not finding it easy. As a lot of other developers probably have found out too, myself included. And I'm quite sure he didn't actually mean that C# and VB.NET are the only .NET languages. He just didn't feel the need to mention them since they aren't the current case in point.

Oh, well... maybe someday I'll stop being so snotty in my comments. But, I do mean well...! Thanks for another chance to rant, Jeff! ;)

Or was it VS .NET 1.0? I just remember NOT having a background compile in VS. Oh, well, maybe I was hallucinating...

Coming over from Java, I'm amazed at how slow the .NET development cycle really is. The C# compiler is very fast, but building large solutions becomes quite a time consuming endeavor. Why? All the dependency checking and packaging of IL into DLLs. The Java platform got this right when they came out with loose class files. By having this, you can do quick incremental compiles. The Eclipse compiler uses this feature nicely with its **incremental** compiler (it's nearly the same as if you were coding in a Smalltalk environment). If you're doing a lot of test-driven development, see how fast you work in Java versus .NET. You'll be amazed at the difference, especially in a large, multi-project .NET solution.

As for IDEs, I wish Microsoft would learn something from the refactoring IDEs from the Java world, IntelliJ IDEA and Eclipse being at the forefront (NetBeans is coming along nicely on this front also). VS 2005 lacks any innovation whatsoever. Come on guys, take some ideas from the Java guys and build something that really makes .NET developers productive. I use Resharper 2.5.x in VS 2005, but it's definitely an add-in. It pales in comparison to its sibling IntelliJ IDEA. I want tight, incremental development cycles. I want quick turnaround for unit testing. Give me tools to generate unit tests from classes that I'm writing. Give me smart intentions and templates that speed my development. File templates for "Add New..." don't cut it.

Finally, whatever happened to the once rumored .NET IDE from JetBrains? One of JetBrains salespeople spoke about it some, but nothing ever came from it. I would drop VS 2005 in second for the analog of IntelliJ IDEA for .NET. Microsoft needs some good competition in the .NET space so they feel the need to put some innovation into their tooling. Here's hoping for competition.

We can start with VBScript dying. Well, it's been announced it's reached end of life. Then on to VB.NET. ;)

http://blogs.msdn.com/powershell/archive/2007/05/18/replacing-cmd-exe.aspx

Have a look at F#:

http://www.ffconsultancy.com/dotnet/fsharp/

Read up on F#, thanks for the link.

Talk about a huge step backwards in new language development.

Ok, I couldn't resist...

F#!?!?!?! Ugh!

That has to be a joke.... It's like Python with extra typing! If you can't see the indent, let's mark it!

Ok, so it's not really an indent. But is really annoying. What is the logic behind this syntax? Is there a spec we can read without paying for it?

I like vb.net because I can design difficult date functions in VBA (MS Access) and have the ability to runtime debug and change things at runtime too and then paste it all into vb.net and it works. I would lose this important functionality by using C#, I could keep sliding the yellow line back and changing something.

Ok, just to make sure that this horse is dead...

I just noticed in VS 2005, C# displayed a syntax error to me.

Here's how I got it:

Object[] obj = new Object(); <-- No error indicator.

Object[0] obj = new Object(); <-- Error indicator under the variable name.

So, is that background compilation or what? (No comments about my error, please...)

>>I have to strongly disagree about using Java. I am so sick of getting >>Java interfaces. They are slow, buggy, and resource hogs.
They are? When is the last one you used/built? The Java IDEs are awesome and they "eat their own dog food". You do need to be using a current JVM. I have a C# application that I am switching to Java because there is nothing in the .Net world like Eclipse RCP and Netbeans RCP. In addition, all the libraries and APIs are just too compelling. And to top it off, the C# projects take forever to compile.

>>If someone can come up with a compiler/installer that makes them >>executables when installed,
Those have been around for a while. Try googling. The issue is they take away some of the power of Java. Do you put all your .Net code into and Exe? or do you have DLLs?

>>I can stand it, until then Java should not be used for delivered >>apps.
Good. Less competition for me. While you are compiling or trying to figure out how to pay for third party tools, I'll be getting stuff done can selling products to customers.

About the ASCII v. Unicode thing.

I for one would love it if my IDE replaced ASCII with suitable unicode characters such as &#654; ¬ &#8592; &#8728; &#8730; &#8804; &#8869; &#8743; and other useful stuff.

[quote]
@Damien - I think Jeff is talking about how .NET is done in practice. My experience jives with his.
[/quote]
jibes, not jives

On the "background compilation in C#" topic, my recollection is that when the "parse-only" background stuff went in, it was too expensive (ie took too long) to do the full compilation.

I have heard comments from VB.NET users about their projects getting slow when they get big, and I think that's the same issue showing up on the VB side.

It might be possible to build a compiler that would do a full background compilation within reasonable time constraints. My guess is that that sort of work does not fit in the C# 3.0 schedule, and my language test guy experience makes me less than excited about testing a full replacement compiler.

Eric

Regarding C# compilation tax, what the heck did you do before .net? Did you constantly recompile your c++/pascal/whatever code? Did you have background compilation with older platforms? How many "mistakes" do you make between each compile? When errors are flagged by the compiler is it difficult to double-click them to take you to the source? I am not trying to be petty, I just don't see what the big deal is. Full disclosure: I enjoy your writing and most of the issues you bring up.

jeff

Background compilation is one part of VB that I always disliked.

I write my code in a series of intermediate, often syntactically incorrect, states that only eventually become a properly functioning piece of code. Essentially I pseudocode much of the time, or jump around within my functions fleshing out details. Being "corrected" or worse yet blocked from being able to do what I intend to do by a compiler that thinks it knows what I'm up to better than I do creates a horrid experience.

Coming very late to the party here, oh well.

How about a compromise, faster compilation when you want it in VS2005. This is a manual process, but hey it works for me.

First goto Tools>Options>Projects and Solutions>Build and Run, and select Only build startup projects and dependencies on Run, then I redefine F6 (yes its next to F5) to Build.BuildSelection.

Now once I have finished typing I can check the current assembly with F6, I can test the application with F5 and build all 40 projects with Ctrl-Shift-B.

However what really makes the difference for me is using TestDriven.Net's 'Repeat last test' functionality. Normally that builds and debugs (my last operation is invariably Run in Debugger) much faster that any other way of running the test.

While having the wiggly line would be great, I am more than happy to get into the Ctrl-Shift-F12 cycle following each build. What people often miss is that one simple(!) key combination can cover lots of errors quickly. No need to keep taking your hands off the keyboard to the mouse.

"I fail to see the difference between red-squiggly-underline background spell checking, and red-squiggly-underline background compilation checking. (Well, performance considerations notwithstanding)"

Yeah, me either, which is why I'm wondering why I think that background compilation sounds like a good idea (which, to me, it does).

When I'm setting up a copy of Word, one of the first things I do is make the red squiggly underlines GO AWAY NOW. (ahem) The thing is that when I'm writing, I'm thinking about the concepts I'm trying to convey, and sentence structure, and that sort of thing, and the red squiggles are a distraction from that. It disturbs my train of thought, and my writing suffers, and my enjoyment of the writing definitely suffers. And, besides, it's trivial to go back and do the spell-checking later, once I've written everything.

On the other hand, at first glance, background compilation sounds useful. I suspect there are some legitimate reasons for this: (a) the compiler actually knows if the code is right or not, whereas Word is often just ignorant of real words, (b) in programming, a bug often means I'd have to stop and rethink the larger picture, and (c) maybe it would be implemented in a way that's less distracting.

To which my cynical side replies that (a) is not true when the code's half-finished, (b) only applies when I'm making large mistakes rather than typos, and (c) I'm obviously being an optimist here.

Still, I suspect it would be useful to have even though I probably wouldn't use it all the time.

Hi

Try once to use background compilation with a project > 500'000 loc.
Then you would not like to use it...

cheers

I couldn't agree more with this article. Background compilation is impact analysis on the fly. It's irreplaceable. I love it. I dread the day I'll be forced to use the C# IDE (and it's coming fast). IMPLEMENT THE DAMNED THING ON THE C# IDE!!! Make it **OPTIONAL**!!!!!

Re. F# reference material: see the official homepage at http://research.microsoft.com/fsharp/fsharp.aspx

Anyone who's worked on an insanely large VB.Net solution will tell you where you can stick your background compilation feature. I agree, it SHOULD be a configurable option, for ALL .Net languages. And then I would always configure it to be off.

To the guys dismissing F# - the things that make F# interesting really have very little (to nothing) to do with the syntax (which is admittedly a little odd). F# has things like pattern matching and type inference and it is these features which make it so interesting (and so productive). I'd estimate at least 50% (perhaps a lot more) reduction in code size where I've used it so far. It does help if program in a functional style which can be a bit mind bending if you're not familiar with it. If you end up writing only imperative/OO code then you miss out on a lot of the benefits of F#, I think.

Eric Sink "discovers" background compilation in Eclipse.

http://software.ericsink.com/entries/java_eclipse_3.html
--
Of course I now understand that Eclipse has no build command because it is automatically building all the time. In fact, I've quickly become rather hooked on this feature. I once got it confused, but mostly it Just Works. I make code changes, save the file, and the Problems pane automatically shows all the current warnings and errors. Sweet.

In fact, this morning I fired up Visual Studio 2005 to fix a bug. After making the code change, I saved the file and just stared at the bottom of my screen, waiting for the compile. A few seconds later I realized I had to press Ctrl-Shift-B.
--

Part of the problem is CTRL-SHIFT-B is a pain in the effing ass.

Something like F9 is better on the hands.. and Jeff I know you've used Delphi ;-)

As for case insensitivity... I agree.. I like it.

I had a problem with isNan vs isNaN before..
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Why-Case-Sensitivity-Sucks-Hairy-Bottom

I don't like how some case insensitive code is sloppy looking when some programmers abuse it and type things like Begin bEgin and BEgin but.. life is a compromise.

One should try to be as consistent with case insensitive languages, still. But.. if they happen to make an error like IsNan or isNan or IsNaN or isNaN... as with Javascript... well then... hopefully they are using a case insensitive language because we are humans for creeps sake (especially run time languages without strong/static typing where the bug can go unnoticed, as in javascript)

.Net 3.5 SP1 introduces a background compiler for C#

if (this!=null)
{
}

I'm using Visual Studio 2008 sp1, and background compilation works beautifully in C#.

I don't know which Visual Studio version introduced the feature, but now it just works.

One more point for C# :-)

Hello everyone. Love is, above all else, the gift of oneself.
I am from Niger and , too, and now am writing in English, please tell me right I wrote the following sentence: "Panama - frontier airlines tickets and flight discounts from denver colorado, savings on frontier air line travel reservations flights and airline tickets for frontier."

With love ;-), Oswald.