[Me] are basically saying anyone who uses VS2005’s tools to their advantage is a shoddy programmer. It’s elitist crap.
[Dennis Forbes] Speaking for myself, I’m saying no such thing
“I can only envision tools like continuous compilation and edit and continue as…the crutch of hacks.”
Your words, not mine. Everyone who uses background compilation is either a beginner or a hack, according to you. That’s not an elitist statement?!
[Dennis Forbes] Those tiny little plastic spacers that a beginner uses to quickly tile their floor in a good-enough fashion, with limited skill, for instance – no professional tile layer in the world uses those.
Is it because that tool are a hindrance or because they just aren’t useful to someone who is skilled? That’s a pretty broad generalization there. A chef wouldn’t say, “I’m skilled! Get that knife away from me! Only hacks cut things with knives!”
You’ve never shown how using a tool like background compilation “harms craftsmanship”. You simply claim that it can miss other errors. That doesn’t prove it isn’t a useful tool, it just proves that you have no idea how to wield it to your advantage. While you see background compilation as worthless as a plastic spacer, some of us see it as useful as a tape measure.
To that, you’ll probably say, “That you find it so useful is a problem!”, but you’ll also probably never come up with a good reason why it’s a problem other than it annoys you. Bad programmers aren’t bad programmers because they use tools, so I don’t see why good programmers would become bad programmers because they use tools.
There’s a big difference between the subtle way background spell checking is handled, and the way that background compilation is handled. When I’m typing a document, I can still keep my flow going, knowing that I’ll fix the error at a later time. With background compilation, the computer plays second guessing games with me until I’m finished with the program. The statement above that states that background-compilation is more like grammar checking than spell checking is right on target; how does the computer know my intent until I’m through with the program. Personally I’d rather sit with a comfortable editor like vi or emacs and let the computer know what I’m doing when I’m done. I agree there’s value in having auto completion when I’m first learning a language, but I’ve found the nonstandard way that applications handle accepting auto completion to be really annoying. (Wait, was that enter, or CTRL-Enter to accept the completion? Tab, perhaps?). Like any tool, over reliance on the tool, and the inability to turn off the safety/convenience features can make your job much more difficult.
(And yes, I did use Firefox’s background spell check for this post).
There sure are a lot of opinions that go alot of ways. Basically it comes down to personal preferences. Either you have it enabled as default and the user has the option to disable or you don’t have the feature at all.
"So that I could get Word’s continuous spellchecking to work for me. "
a href="http://mozilla.com"http://mozilla.com/a, has built in continuous spell checking for all HTML text boxes. Why doesn’t IE have his? Because Microsoft isn’t one big company, it’s a ton of tiny little companies. All that tying together of the products, you’d think IE could use Words spell checker. Or better yet, that the spell checker would just be a service in the OS.
but on topic before I get too ranty.
Background compilation in VB.NET isn’t as bad as it was in VB6. Hellllooooo, dialog box. Now go away and let me finish typing, I know I need an “End If” statement thankyouverymuch.
All background compilation does is help me out with the missed parens and end statements. Which sometimes, is enough to keep me from banging my head against the desk.
I don’t think it had anything to do with “your editor of choice.” Perhaps you need to not get so defensive.
Don’t need to get defensive? Some people, including the two from the article, are basically saying anyone who uses VS2005’s tools to their advantage is a shoddy programmer. It’s elitist crap.
In your article you state:
“Yes, you could throw emacs and volumes 1-5 of The Art of Programming at your development team. Or you can buy them the best, most advanced development tools on the market. Which approach do you think will be more effective?”
While I am actually abdicating on the issues of background compilation. I have to point out that this statement presents a false dilemma. There is no reason I cannot buy my team the most advanced development tools and 1-5 of The Art of Programming, and I think it would, in theory, be the most effective.
Has this ever happened to you?
You work very horde on a paper for English clash
And then get a very glow raid (like a D or even a D=)
and all because you are the words liverwurst spoiler.
Proofreading your peppers is a matter of the the utmost impotence.
This is a problem that affects manly, manly students.
I myself was such a bed spiller once upon a term
that my English teacher in my sophomoric year,
Mrs. Myth, said I would never get into a good colleague.
And thats all I wanted, just to get into a good colleague.
Not just anal community colleague,
because I wouldnt be happy at anal community colleague.
I needed a place that would offer me intellectual simulation,
I really need to be challenged, challenged dentally.
I know this makes me sound like a stereo,
but I really wanted to go to an ivory legal collegue.
So I needed to improvement
or gone would be my dream of going to Harvard, Jail, or Prison
(in Prison, New Jersey).
So I got myself a spell checker
and figured I was on Sleazy Street.
But there are several missed aches
that a spell chukker cant cant catch catch.
For instant, if you accidentally leave a word
your spell exchequer wont put it in you.
And God for billing purposes only
you should have serial problems with Tori Spelling
your spell Chekhov might replace a word
with one you had absolutely no detention of using.
Because what do you want it to douch?
It only does what you tell it to douche.
Youre the one with your hand on the mouth going clit, clit, clit.
It just goes to show you how embargo
one careless clit of the mouth can be.
Which reminds me of this one time during my Junior Mint.
The teacher read my entire paper on A Sale of Two Titties
out loud to all of my assmates.
Im not joking, Im totally cereal.
It was the most humidifying experience of my life,
being laughed at pubically.
So do yourself a flavor and follow these two Pisces of advice:
One: There is no prostitute for careful editing.
And three: When it comes to proofreading,
the red penis your friend.
What’s “background” about a spell checker? As you enter text, each word you add or change is matched against a dictionary. That’s it! There’s no “background” anything.
I think some peoples problem with background compilation is that it’s more like the grammar check than the spell check. It appears before you’ve really finished and until you fix it the way it wants it to be it just won’t go away (even if you ignore grammar errors in Word they still appear the second you change one character in the sentence).
Of course, unlike the grammar check there isn’t scope for computer error. If it flags it as wrong then the compiler will flag it as an error and it won’t compile. But still, to have it flag things up before you’ve finished tends to even more encourage a bottom-up approach (or is it top-down? I can never remember) as well as Intellisense.
Personally though I love it, it can save a lot of time. But, like some have previously alluded to, it can be very distracting. You’re focussing on one area of code, notice a bug and merrily go wandering off into another area and forget what you were doing before. Again, unlike spellcheck, which is just changing one word, it’s more like grammar check where you often have to restructure whole sentences.
For years I didn’t use a debugger - typically I was working with code that I had written, in Java, that included logging and was (I think) clean and fairly well designed. Since before that I had worked in a C shop, where the debugger (and Purify) was critical, I came to the conclusion that the main reason for having debuggers was to deal with memory errors.
But in my most reason job I am doing a lot more maintenance and extension of existing, rather crunchy, code, and the debugger (IntelliJ Idea - very nice) has been a lifesaver. I don’t have a clean model of the code in my head and part of my job is being able to deal with that - a debugger helps.
So I’m starting to think that - like everything else in life - the usefulness of tools like this is very context-dependent. You learn to use the tools; you learn when to use them; you do your job. Reading the excerpt from Linus you linked to at the start of the post I get the impression that (1) using a debugger in the kernel is, understandably, rather more tricky than in userspace and that (2) he’s not “arguing against” them but simply describing when they are most suitable.
If I mistype a variable name, I want to know NOW, not when I run my code (pythonista here)
If I make a syntax error, I want to know NOW, not later.
You know what, no one is perfect, and we all make mistakes, I think its more productive to find out about mistakes in the context you make them, not at a later stage.
To give a contrived example, you don’t tell your dog he is naughty the day after he does something on your carpet, it is more effective when you scold him straight away.
i wrote this on a brand new keyboard with an unusual layout, (Logitech’s Ultra-flat) and I know i’d be making errors in my code too, if i have the choice to find out straight away, I’d much rather that than finding a syntax (or var name) error when I run my unit tests.
Contrasting syntax and semantic checking (what background compilation does) versus spell-checking is a very disingenuous and self-serving comparison, IMHO.
Spell checking is useful because it alerts you immediately after you’ve finished with a word, and there’s a chance you’re not going to go back to that word. The entire document won’t have to be “spell-checked” (compiled) before execution, so there’s a risk with spell-checking that a bad spelling might sneak into the final product.
With syntax and semantic checking, I could be working on several types simultaneously. Telling me that the whole won’t compile is a pointless distraction, a waste of time. I can find out that after I’m finished with my edits, at which point I’ll invoke a full compile - at it will tell me about all my problems then, and no sooner. There’s no risk of me delivering a product that will throw a “syntax error” exception at runtime - one of the most horrible “features” of VB that I remember from days long past.
Did you read Larry O’Brien response on the subject? He has a great idea, which solves the most common objection I read in your comments:
People talk about background compilation and errors popping up before you’re done with your thought and so forth, but that’s a UI issue, not a technology issue. Don’t show errors until you type “Ctrl-F5” but then show them instantly – that’s okay by me. And I don’t see any reason why you can’t achieve that UI.
I haven’t used VB6 in a new project for years. But there is still code I have to maintain. It’s very easy to turn off the modal error dialogs: just uncheck “Auto Syntax Check” under Options.
These days I’m comfortable writing code in either C# or VB. They both have minor advantages and disadvantages. Most of the real coding uses the .NET Framework classes anyway. I can translate code between the two langauages using just the text editor and do so frequently.
But I have some gripes about SOME C# programmers:
Quit considering your choice of language as a RELIGION. You are acting like Linux and Mac zealots.
Quit inventing your own style of formatting code. Turn on the appropriate options in Visual Studio and follow Microsoft’s standard. I know Visual Basic programmers can be sloppy too, but mostly it’s spacing (which is easy to fix). Visual Studio does the rest for them.
Stop creating variable names that differ only in case from other variables or reserved words. It’s just plain wrong! FxCop flags them for you, pay attention.
Sorry if I repeat what has been said earlier - I regret that I haven’t the time to read all the posts and am probably a poorer person for it (and therefore, if you feel you don’t have the time to read mine, I understand - you may not be a poorer person for it).
Jeff, I think you are comparing apples and oranges when you compare background compilation with background spell check and background grammar checking. The latter are much closer (in their impact on what I am doing and their use of processor cycles) to code highlighting than they are to full-fledged compilation.
I do agree that the model of software development is the infinite monkeys but that doesn’t justify it. An infinite number of monkeys may produce the works of one Willy Shakingspear but it seems more efficient in resources, time and patience to just have Willy do it. With decent training and decent techniques some of the infinite monkeys could perhaps be trained up to be at least a Jack Vance or an L. Ron Hubbard and create at least palatable work.
The difference between writing a novel and writing some fictional blather is having a vision of what one is writing and a plan of how it flows. Developing quality software is the same damn thing. But the infinite monkeys model, handheld with background compilation and interactive debuggers, leads to a world where fictional blather predominates. Design what you are doing, make sure it meets the requirements and THEN write the damned code. You may find that a) you don’t need an infinite number of monkeys and b) you might have a Frank Herbert sitting in one of your cubes whose superlative skills were suppressed by the sound of several score of simpering simians.
“Those tiny little plastic spacers that a beginner uses to quickly tile their floor in a good-enough fashion, with limited skill, for instance – no professional tile layer in the world uses those. I just painted my kitchen, which first necessitated masking off pretty much the entire room. Do you think professional painters do that? Of course they don’t.”
Hell yes they do. They use them much differently though. Instead of laying them down in between the tiles, they stick them up so that they are easier to pull out when the grout is dried. Once you do a row, you don’t need them as much for the vertical layout. Painters, yes they mask off the trim and casement and put drop cloths on the floor and use blades when painting near the wall-ceiling edge. The same way that carpenters wear safety glasses and mechanics don’t wear their Sunday best when working on your car. Stuff happens and it’s better to be safe than sorry. Before the drywallers started applying the texture to our walls during a recent remodel, they taped up plastic all over the place.
Properly preparing your area of work, IDE or someones home, doesn’t imply that you aren’t good at your craft. It’s just the opposite. It shows that you know things can go wrong and that you aren’t invincible. Background compilation, when it doesn’t pull the focus away from your typing, does much the same thing. Protects your area.
I have to say that I’m a little confused on the direction this argument has taken. Most of you seem to act like C# has no design-time checking at all vs. VB’s design-time background compiler.
That seems odd. C# has always had a pretty good design-time parser that flags the majority of common errors you might make as you make them and the display of those errors is nearly identical to how VB displays the background compiler errors.
The only real difference is in the level of checking being done. In C# get feedback about deeper errors only when you ask for them by building the project. In VB you are constantly building the project in the background. Keep in mind that the IDE for C# caches compilations so it doesn’t have to recompile everything each time, making incremental builds pretty fast even in large projects.
There are advantages and disadvantages to both techniques, in terms of usability and performance. The .NET teams have also talked quite a lot over the years about why C# does parsing and VB does background compilation. And quite a lot of their decision seems based on REAL user testing on the populations of C# and VB developers.
Personally, I find that C# catches the “important” issues I want to be notified about right now as I type the code with the parser just fine, but the deeper warnings get saved for later when I’m sure I’m ready to deal with them.
That said, I do use Resharper too. It performs a deeper design-time analysis of my code similar to background compile, but it keeps the warnings off to the side in an unobtrusive way. So I’m not arguing that background compile isn’t potentially useful to C# developers… but if MS ever did put it into the VS IDE I’d want to see it display more like how ReSharper does… off to the side and out of the way until I’m ready to deal with it.
Intentionally choosing not to use better tools because you’re afraid they will become a crutch is, at best, cruel and patronizing.
That’s a pretty loaded statement because you are implying that VS.NET is “better” than Emacs which is entirely subjective. Yes, Emacs may not have background compilation but it has lots of powerful editing features that make VS.NET look like weak in some areas.
I’ve seen lots of debate about rich IDEs vs. more traditional programming editors, but I’ve never seen any evidence that the end product is actually better by using these rich IDEs.
I used the various flavors of Visual Studio for years writing C++ and C# but now I use Emacs to write Python. I don’t think my coding abilities were any better under VS. In fact, I think I’m a better coder now because I use a language that doesn’t get in the way of what I’m trying to do. That has a much higher impact on the quality of my work than some flashy feature like background compilation.
Mike Brooks:
[Dennis Forbes] Those tiny little plastic spacers that a beginner uses to quickly tile their floor in a good-enough fashion, with limited skill, for instance – no professional tile layer in the world uses those.
Is it because that tool are a hindrance or because they just aren’t useful to someone who is skilled? That’s a pretty broad generalization there. A chef wouldn’t say, “I’m skilled! Get that knife away from me! Only hacks cut things with knives!”
Not an apt analogy. A knife is just a knife; it has no training wheels. Better: both a tyro and a chef may use a mandolin. The chef would not bother with the cut guard. The tyro had better use it, lest he lose a finger tip or most of his palm. (I did.)