May 11, 2007
Over the last four years, I've basically given up on the idea that .NET is a multiple language runtime.
- The so-called choice between the two most popular languages, C# and VB.NET, is no more meaningful than the choice between Coke and Pepsi. Yes, IronPython and IronRuby are meaningfully different dynamic languages, but they're somewhere on the horizon and far from first-class IDE citizens.
- There's simply too much cognitive friction when translating back and forth between these two very, very similar languages. Semicolons or underscores? Case sensitivity or case insensitivity? Parens or brackets? Arrays that begin at one, or arrays that begin at zero? To-may-to or to-mah-to? It's just not worth the mental effort it costs to keep track of all these nitpicky little differences that can bite you so easily.
- Mixing source code in different languages is awkward at best. You have to segregate each language into its own compilable project. Separate-- but equal. Sort of. Well, mostly.
- Most of the community has settled on C# as the de-facto standard, so you're in for a rough slog of code translation if you want to stick with VB and cleanly integrate commonly available source code libraries into your codebase. And if you want to understand the code you're absorbing into your application (note: this isn't really optional in my experience), you better learn how to read it without a bunch of mental translation gymnastics. And once you've learned how to read and write the language well enough to integrate it, you've come full circle. Like me, you'll be left wondering why you didn't just cut out the translation penalty entirely and stick with one language in the first place.
This is not to say that you can't do multiple language development in .NET. But most of the time, it isn't worth the hassle. It's less painful to move with the herd and choose C# like everyone else does. For the most part, I've learned to suck it up and pretend C# is the only .NET language. I'll even grudgingly admit that explicitly ending lines with semicolons is way better than the mish-mash of carriage returns and underscores we have in VB.NET. But there are still two things that drive me nuts about C#.
The first is the evil of case sensitivity. As an advocate for people over machines, I have to go on record stating that case sensitivity in a programming language is wrong, and will always be wrong. I know the decision is written in stone at this point, and it's never going to change, so I'll leave it at that. It's a religious issue, and we software developers are nothing if not religious. Let's move on.
The second is the C# compilation tax. When working in C#, I'm constantly compiling the solution to ensure that I haven't broken anything. It's a ridiculous productivity tax in an endless loop: Write some code. Compile. Write a little more code. Compile. Change a function. Compile. Rename a variable. Compile. Refactor some methods. Compile. Then compile again, just to be sure. Wait a second.. did I compile this yet? Compile!
Notice a pattern here? I'm going to prematurely wear out my CTRL, SHIFT, and B keys. When coding in C#, I feel like a monkey in a cage that dispenses food pellets when I press CTRL+SHIFT+B. It's a complete waste of time, but you're compelled to do it through perverse incentives in the IDE.
What's particularly sad about this is that, in my experience, most C# developers think manually compiling all the time is a natural state of affairs. Well, it isn't. In VB.NET we have this clever little technology we call background compilation. Background compilation saves you the effort of all that meaningless, repetitive, mind-numbing manual compilation. It's very simple: as you type, imagine all that CTRL+SHIFT+B-ing happening automagically in the background for you.
With background compilation, I know immediately when I've made a mistake. I don't have to wait until the next time I manually invoke the compiler. Let's say I was to type in the following C# code:
s = 1;
Well, that code looks fine in the editor. Until I compile. Contrast that with the VB.NET equivalent:
Dim s As String
s = 1
The second I finish typing the assignment (e.g., move my cursor off the second line), the statement is flagged as an invalid assignment. No compilation necessary; it automatically appears as an ambient squiggly underline in the background.
This is an admittedly trivial example, but background compilation makes my life so much easier in VB.NET. It reduces the turnaround time between mistake and fix to virtually nothing. And you can do other clever things with it, such as quickly renaming a function or variable to get an idea of where it's being referenced via the stack of compiler errors that appear. If nothing else, it's one less thing I have to remember to do: oh yeah, the C# IDE shows me basic syntax problems, but I gotta compile my C# to see what's really broken. Doesn't that seem like unnecessary work to you? It sure does to me.
Background compilation is something that, unlike case sensitivity, is not written in stone, and possibly could be fixed. It's an IDE feature, not a language feature. Here's hoping the C# team eventually recognizes the massive productivity drain of the C# compilation tax for the average developer. If some developers are masochists who hate productivity, then make background compilation a configurable option they can turn off. They can march off in lockstep, back to their wheel of never-ending CTRL+SHIFT+B pain. More power to 'em.
Personally, I'd rather let the computer do the grunt work of compiling in the background. Freed from the onerous compilation tax, no longer compulsively invoking the compiler every few minutes, I can spend more time concentrating on my code.
I may have accepted the C# penance, but I wish the saints at Microsoft would see fit to grant this one small wish to a converted VB.NET sinner.
Posted by Jeff Atwood
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.
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.
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 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?
Just a heads-up: Arrays are 0-based in VB.Net.
Yeah, but in VB you may find your Arrays have an unexpected size:
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#
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.
Wow, Jeff, you've gone viral.
Good article by the way.
"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.
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."
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."
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.. ;)
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?
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).
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.
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.
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 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.
Plus you can prevent pigeon holing yourself at least a little.
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",
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.
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.
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.
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.
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 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#.
@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...
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?
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.
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?
Compilation tax? Resharper.
Read up on F#, thanks for the link.
Talk about a huge step backwards in new language development.
Ok, I couldn't resist...
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 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.
@Damien - I think Jeff is talking about how .NET is done in practice. My experience jives with his.
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.
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.
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.
"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.
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 ToolsOptionsProjects and SolutionsBuild 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.
Try once to use background compilation with a project 500'000 loc.
Then you would not like to use it...
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**!!!!!
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.
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..
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.
.Net 3.5 SP1 introduces a background compiler for C#
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.
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?
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.
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".
+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.
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?
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).
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.
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.
Yes, I believe you....
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.