C# and the Compilation Tax

blog
101

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.

102

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.

103

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

104

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

105

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.

106

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 SHIFTs 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?

107

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…

108

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

109

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

110

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#

111

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.

112

Wow, Jeff, you’ve gone viral.

Good article by the way.

113

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

114

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.

115

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.

116

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

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!

117

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.

118

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?

119

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.

120

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