June 1, 2007
Dennis Forbes took issue with my recent post on C# and the Compilation Tax, offering this criticism, pointedly titled "Beginners and Hacks":
Sometimes [background compilation and edit and continue] are there to coddle a beginner, carefully keeping them within the painted lines and away from the dangerous electrical sockets along the wall. That would explain why it was a more important feature in VB.NET than C#...not that VB.NET is any more trivial -- it's just a syntactic variant -- but it is the language that beginner programmers are generally guided into.
My experience has been that the best developers naturally start using less and less "helpers", to the extreme where you have incontestably great developers like Linus Torvalds arguing against fundamental helpers like interactive debuggers.
I don't buy the infinite monkeys on an infinite number of keyboards model of software development. I can only envision tools like continuous compilation and edit and continue as the hand-holding of beginners, and the crutch of hacks.
Regardless of whether or not Dennis is buying it, the infinite monkey software development model is what we're stuck with. I'm an advocate of designing practical systems that accommodate what actually happens in the real world-- rather than the way we wish things worked. The present model of software development is clearly monkeys all the way down. And if you're offended to be lumped in with the infinite monkey brigade, I'd say that's incontestable proof that you're one of us.
For every one Linus Torvalds, there are ten thousand programmers who aren't Linus Torvalds. I don't expect this ratio to change any time soon, so any effort directed at helping typical developers with better tooling is a significant advancement in the state of software development. 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?
Ian Griffiths expressed his discontent with background compilation in a completely different way:
I hate VB.NET's continuous bloody interference. I HADN'T FINISHED TYPING YET YOU STUPID COMPILER! CAN'T YOU SEE THAT? DOES IT LOOK TO YOU LIKE I'M DONE TYPING? DID IT NOT OCCUR TO YOU THAT THE REASON YOU'VE FOUND ALL THOSE ERRORS IS BECAUSE I'M NOT FINISHED YET?!! I'LL TELL YOU WHEN I WANT YOU TO CHECK MY WORK, AND NOT BEFORE!
There. I feel better now.
Yes, I'm sure rebuilding my C# applications every other keystroke, as Jeff apparently feels compelled to do, would have a negative effect on my productivity. How could it be otherwise when VB.NET's less than helpful attempts to do that automatically are so very distracting? "It looks like you're writing a program. Would you like help?" Oddly enough, I don't feel the need to disrupt my train of thought continuously. So I would prefer it if VB.NET didn't disrupt me automatically.
I respect the opinions of Dennis and Ian greatly. If you don't have their blogs in your aggregator yet, you should. But I also respectfully disagree with both of them on this topic. If you find background compilation naggy-- or if you think it's strictly for beginners and hacks-- then you must really, really hate background spell checking:
People absolutely adore background spell checking. It's one of those rare "you'll get it from me when you pry it out of my dead, cold hands" features that users will switch applications over. Automatic background red-squiggly-underline spell checking in HTML forms is one of the marquee features of Firefox 2.0. In fact, it's feature number two on the feature page, right under tabbed browsing.
I see very little difference between background spell checking and background compilation. To me, they're no-brainers for the same reasons. I'm actually an excellent speller, to the point that I can (and do) work without a spell checker and rarely make mistakes. But having subtle background underlining effects when I've potentially made a spelling mistake is undeniably helpful to me, a self-professed excellent speller. I can ignore it when I know it's wrong and keep on plowing ahead. But more often than not, I've actually made a typo, and I no longer have to methodically read through my writing several times to find it. With background spell checking, all I need to do is quickly scan through the red squiggly underlined text.
Mike Pope, a professional writer for Microsoft, also defends background spelling and grammar checking:
I use the spell checker and grammar checker in Word all the time. These things are tools for me, ways to help somewhat with the gruntwork of examining every letter of every word of every sentence in all the documents I edit. The spell checker finds words all the time that have been fumbled (often by me as I edit), although it finds many, many more that it thinks are errors but are just fine in context (e.g. lots of technical names). The grammar checker doesn't have as much opportunity to be helpful, but it's good at finding problems like subject-verb agreement when the subject of sentence has been edited but the verb has not.
But these tools are often looked at askance. As I've noted before (I think), professional editors can be snotty about the grammar checker in particularly, focusing on errors that the checker doesn't find, or constructions that confuse the grammar checker and make it believe it's found an error when there is none. Similarly, virtually everyone has examples where the spell checker has missed words. The spell checker is helpless in the face of their-they're-there confusion, for example.
The funny thing about this debate is that I've lived the zero-tooling lifestyle. It sucks. Here's how I've composed every single blog entry I've ever written: in a fixed-size HTML textbox. In fact, I'm writing in it right now.
Despite my spelling prowess, I've posted many spelling mistakes to this blog. Using the most primitive of tools to compose these blog posts isn't a glorious, sweeping validation of my expertise as a writer. If anything, it's an indication of my idiocy, or at least my unwillingness to let better tools help me be a better writer. It's absolutely nothing to be proud of. In fact, I'm a little ashamed to admit how neanderthal my blog tooling really is.
Neither background compilation nor background spell checking are meant to be crutches. Any reasonably competent person knows that tools are never substitutes for critical thinking about what you're writing or coding-- as Mike so aptly points out:
Considering all this, the tools are pretty good at what they do. But no matter how good they are, people need to understand the tools' limitations, or for perhaps more fundamentally, the tools are just tools, and they should never have the last say. Don't let that computer boss you around.
Intentionally choosing not to use better tools because you're afraid they will become a crutch is, at best, cruel and patronizing. And it's usually a bad business decision to boot. Turn off background compilation-- or background spell checking-- if you must, but background spell checking is on by default in Word and Firefox 2.0. Is it a perfect solution to the spelling problem? No. Far from it. But for the average user, it's an easy, automatic, unobtrusive way to see and correct common spelling errors. And background compilation, as in VB.NET, offers the same benefit for common coding errors.
Posted by Jeff Atwood
"Yes, you could throw Notepad.exe 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?"
So subjective, "best" and "advanced" are. Let's just begin by being very clear -- Linus Torvalds does not use notepad, nor do any other top-tier hackers I've ever heard interviewed on this subject. Frankly, I'm sick of this ridiculous, dismissive comment. I hear it over and over again, and I can't understand why.
If somebody chooses not to use a wiz-bang IDE, that does NOT mean they use the most primitive tool imaginable. They typically use a _highly_ advanced development environment that they're comfortable with. They just have a different definition of "best" and "advanced" (as do I).
I use an incredibly advanced tool to write code. It's funny that you mention spell checking, because I can instruct my development tool to check spelling in my programming comments (or symbols, or ...) just like Microsoft Word does. I have integrated compilation across multiple languages. Dynamic macros. Rich abbreviations (dynamic and static). Templates (aka snippets). Registers (my eyes well up when I just think about how much I love registers). Dynamic macros (yes, I know I already mentioned that, you have no idea how amazing they are if you are wondering why I listed them twice). Prefix commands. Massively splittable windows (vertical splits with bounded horizontal scrolling are a thing of beauty). Integrated version control. The list is really endless. And hey, even background compilation if you want it. You know, some really, really advanced stuff.
My tool is so advanced that sometimes I just take my fingers off of the keyboard and shake my head. It gives me power I don't deserve to have.
Peter Norvig, Paul Graham, Dave Thomas, Guido Van Rossum, Tim Bray, Steve Yegge, and yes, Linus Torvalds all use very, very advanced tools [1,2]. In many, if not most cases, it's the _same_ tool.
A background spell check is much more useful than a background compile. You will *always* have to compile, and therefore you will eventually find your mistakes.
However, background spell checking is there to help those who don't run a spell check before sending their document.
Compilation always happens in the process; spell checking is optional.
I really think they should've stopped halfway between what VB6 had and what VB2005 has.
VB6 didn't check the syntax until after you'd moved onto another line (it also doesn't highligh while you're changing the line). Unfortunately, it would tell you about any mistakes with a dialog box. Worse yet, if you'd noticed and had already hit the up-arrow key, when you pressed enter to dismiss the dialog box you would get sent to MSDN (the up-arrow having changed the focus to the Help button).
The spell-check style squiggly line is great compared to this dialog box, and the suggested fixes have saved my butt sometimes. They are especially useful when you know what you want to do in C# or VB6 but the slightly different syntax trips you up. Having a single click "this is what I meant, fill it in for me" is really good.
Throwing a squiggly line at you after having typed only the 'i' in 'if', though, is really annoying. It's as condescending as someone assuming that you've gotten the answer wrong before you start answering it.
(For the record, the grammar check in Word annoys me in a similar fashion, though the spell check is alright)
I turn off "spell check as you type" when I'm really trying to put words on a page. All those squiggles just distract and delay you. Give a href="http://www.hogbaysoftware.com/product/writeroom"WriteRoom/a (or its PC equivalent) a try and I bet your essay writing productivity will go way up.
I think the distinction here is that the primary audience for spell checking is pretty much the whole world, while the audience for background compilation are software developers who are notoriously obsessive compulsive.
For example, I love Resharper which places little yellow warning lines off to the side for lines of code that could be "improved". I find I *have* to fix them. I can't help but notice them, despite how inconspicuous they are.
I think background compilation is fine, but it has to be as inconspicuous as possible. It has a higher bar in being non-intrusive than spell checking. It can't slow my IDE down.
For example, I think a delay in background compilation warnings may actually be a good thing. I notice as I type this that the words aren't spell checked as I type them. It waits till I'm done. And the red dotted line is pretty subtle. As I type, what I'm typing is never slowed by the spell check. That's how bg comp needs to work.
are basically saying anyone who uses VS2005's tools to their advantage is a shoddy programmer. It's elitist crap.
Speaking for myself, I'm saying no such thing, and I think the assumption that I have can only be attributed to defensiveness, with people automatically reading into every statement exactly what their preconceived notion is.
Hi there Jeff. Very interesting post.
Regarding the recurring comparison between spelling and automatic background compilation, I offer up-
Try to wrap your head around that seeming contradiction.
Yet it isn't a contradiction, and the difference between the two is the crux of the whole debate that is missed by quite a few people.
Any time after I needed to do an install of VB6, the first thing I'd do as soon as the MsgBox popped up for the first time was turn off the auto-syntax check. So no big deal or reason to hate VB - it only bothered me when I paired up with other developers and they had left the option on; some of them have actually liked the feature. FWIW I also turn off auto-spellcheck in Word and click F7 when I'm done editing. Oh, I also dislike the auto-capitalize first letter of a sentence in Word, and make sure to turn that off as well.
Back to VS 2005...I'd just like to see both C# and VB.NET with the same option - background compilation and squigglies that can be turned off. Which one is the default shouldn't matter; any good developer before doing any coding will take a few moments after a new install to import his preferred settings file or manually set them up in Options. I'm not going to judge a programmer regarding his own personal preferences, unless he just leaves the default options as is out of the box out of laziness, and has taken no time at all to actually learn the IDE and what options are available.
I agree with you 100% Jeff. I hate not having background compile in C#. That is one of the best features in VB that is not in C#. I mean you can always turn background compile OFF if you don't like it, but why not include it to begin with?
I had ReSharper at my old job (adds background compile to C# among other things) and I do not have it at my new job and the lack of background compile in C# is driving me crazy.
Excuse me but um, am I the only one to notice that background spell-checking is just that -- BACKGROUND, whereas VB used to pop up a DIALOG BOX saying you have typed an incorrect line?
Jeff -- the second guy you quoted expressed frustration at his compiler's OBTRUSIVE notifications of his error, not the INOBTRUSIVE squiggly lines!
I just wonder why a completely ignorable feature forces them to feel such anger. It's not like the editor stops working if the compiler finds an error while you're typing. It's not like it isn't easily hidden.
I also find it arrogant. Griffiths attributes errors VS shows him to be simply because he hasn't finished yet. Wow, so impressed.
I also enjoy the distinction on Forbes's blog that a feature like IntelliSense, which helps you do something right the first time, is "a great bit of functionality", while background compilation, which tells you immediately when you do something wrong, is bad. What's the difference? Is there a huge gap between "This is what you should do" and "This is what you should not have done"?
When we hire people, one of the most important questions/tests is to make sure that someone knows how to use his/her tools properly. I'm not saying it is improper to ignore errors caught in the background, but if someone knows how to use that knowledge to their advantage, if it makes them more efficient and bug free, why is that bad?
Further, I don't buy the argument that it is a beginners-only tool. I'm gonna learn from my mistakes whether the compiler tells me I did something wrong now or later. In fact, I think I'd be more likely to remember the things I did wrong if I'm told of my mistake immediately. Better to fix one error while it is fresh in your mind than 30 after you've written 100 lines of code.
Ironically, Jeff had to email me to point out that I had spelled his surname wrong in the post he references here. :)
But back to the topic at hand...
A few people already nailed it, but since you called me out specifically, just to confirm: yes, I love continuous spell checking and I dislike the grammar checking.
The main reason is simple: continuous spell checking mostly only bugs me after I've made a real mistake. Grammar checking bugs me for no good reason all the time.
That's the thing about spell checking: for a usefully large subset of spelling errors, it is possible to tell immediately and without context that an error has been made. (And I always use styles that enable me to mark something as "not to be spellchecked" when writing technical documents so that it doesn't call out identifiers as errors.)
But the thing about any kind checking of broader syntactic is that context is everything.
That's why spell checking is reasonably unobtrusive, while grammar checks (either by Word or VB) are plain irritating.
And of course I rarley make spelling mistakes.
It may also interest you to know that I do a 'compile' stage on my spell/grammar checking. There's a litle tick/cross thing on Word's status bar that lets you know whether Word is happy with your document. You can click on that to find the first problem if it's a cross. I aim to get a "no warnings" build of a document. Often this consists of overriding Word's ideas about grammar, which (a) don't match UK expectations and (b) don't cope well with some of the bizarre repurposing of words we perform in the software industry.
To be fair to VB, I think part of the reason I got so annoyed by this feature was back in earlier versions of VB, the default behaviour was essentially modal: it would try to prevent you from moving away from the offending line until you had fixed it. By contrast the whole reason squigglies are a good invention is that they got rid of a modal feature. So I got in the habit of turning the feature off in VB in order to get any work done... I've not yet done any serious VB development on VS2005 - the last time I did any real VB.NET coding was in VS2003 - so maybe it's better than it was. Perhaps I now *remember* it as being more annoying than it is.
But if it's as annoying as Word's grammar checking then it still sucks.
FWIW, until fairly recently I also composed my blog posts much as Jeff does. However, I lately built some infrastructure that allows me to use Word to write it all, while keeping the relatively tight style of HTML I like to use. The reason? So that I could get Word's continuous spellchecking to work for me. Despite this, I still don't like using VB on the whole...
Background spell checking only becomes a crutch if you use it without thought. When the background spell checker highlights a word rather then quickly clicking on the word for it to replace it with the correct spelling equivalent, I will edit the word and try to correct it myself. If after several tries I can't get it I will right click the word, see the correct spelling, and then manually edit the word with the correct spelling. This reinforces the correct spelling so that I am less likely to misspell it next time. If one simply clicks and replaces with the right word without thought, they don't really learn and it really does become a crutch.
Its all in the person if they want to use a given crutch to 'get better' or to 'get dependent'.
At the risk of being buried beneath the previous 40+ comments, I'll add my own to the mix.
Do all the background spell check, grammar check, or compilation that your little IDE/editor/tool-chest heart desires. BUT DON'T TELL ME THE RESULTS UNTIL I'M DAMN READY FOR THEM! Ahh, much better.
I want my program parsed and compiled as I code. I want my document to be parsed and checked as I write. But I absolutely, positively, cannot stand those stupid wiggly red lines. They are distracting to the extreme regardless of whether I'm writing prose or code.
So please, dear Sir, do your background checks. Thus, when I ask for the results, you'll have them already in hand. I won't have to wait 10 minutes for you to go get them. But don't interrupt me while I'm writing!
You know, if you didn't use IE, you could have spell check in for your blog entries too... Like this screenshot from Safari shows:
Firefox does this too... but OS X is particularly nice because you can get spell check *in every single standard text entry box in the OS*. The red squiggles are usually disabled for fixed size entry boxes to satiate those that find it annoying, but you can hit cmd-; whenever in doubt.
Also, am I the only one surprised at how poorly Word shrinks? Compare to Apple's Pages at approximately the same size:
(won't let me make it smaller) You've still got double the actual work area! Typical MS toolbar mania.
Is this not almost entirely down to its implementation?
Stephen, absolutely. The way background compilation was implemented in VB6-- as a modal dialog-- made it nearly impossible to use.
Yet [the fact that I applaud background spell checking] isn't a contradiction, and the difference between the two is the crux of the whole debate that is missed by quite a few people.
I think a whole lot of coding is rote and mechanical, precisely the kind of thing that's amenable to spell checking and grammar checking. No, background compilation won't be accurate all the time. But to advocate that background compilation is "the hand-holding of beginners, and the crutch of hacks" is to move us in the wrong direction.
On the other hand, it's fairly common to move away from a line of half-written code while you think "Oh, I want to do this to that variable, meaning it needs to be a Double, not a Float, better change that in the parameter list" or something similar. I'll hardly ever leave a word half-written whilst I think "Ah, I need to change this chapter heading". I'll just spend the extra few milliseconds it takes to type the final few keystrokes. So background spell checking tends to catch spelling errors. Background compilation tends to catch unfinished lines, not errors (in my and, seemingly, Ian's experiences).
I was mildly entertained to find "in particularly" in the Mike Pope quote...
Oh God, not this BS again.
This has nothing to do with some such crap about "background compilation" and the merits of spell checking.
It's about that thing that kills IT folks:
You're comfortable with the stuff you grew up on. Now someone mixes in a feature like "background compilation" and now all the people who thought getting rid of punch cards was a bad idea also think that using something like "background compilation" is akin to being a poser of the first order.
I think there's some subtle "point missing" going on here.
To make soup, you need stock. You can get stock from a box, and some of it is very good. It will never be as good as homemade stock--provided you know how to make stock, and you should.
Not all the work I do can be performed inside the comfortable, cotton-lined Visual Studio. Some of it has to be written on a Solaris box using Pico (because vi and emacs are tools of the Devil), where all that syntactic and pre-compile support isn't available. I have to be as efficient writing in that environment as I am in Visual Studio.
Most of the time I prefer writing in Boxer or CodeWright because VS doesn't support the Brief keyboard command set as well as it might, so I've never been a VS Zombie. I certainly don't write non-ASP websites in VS, because there are better tools.
The funny thing is, I rely on HTML preview when writing web pages. Sounds a lot like precompilation, doesn't it? The difference is, naturally, that it's a lot faster, and only happens when I ask for it.
I would rather control the machine than have the machine control me. I don't need some high-speed idiot telling me when I've made mistakes--I can find those on my own, and I'd often prefer to find them in bulk than be nickeled and dimed to death.
It's about that thing that kills IT folks:
No, Foobar, it isn't at all. You've given me a chuckle, however, given that I had continuous automatic checking in GFA Basic on the Atari ST, circa 1988.
Maybe it's new to you, but it certainly isn't new to me.
Nonetheless, the whole conversation was about the *craft* of software development: If you're a self-avowed code-monkey, then disregard the whole conversation (and yes, Jeff, I will certainly say that I'm not among the infinite-monkeys crew, and the assertion that denying that implied that one was is a bizarre bit of non-logic).
When you're actually dedicated to a craft -- see virtually any craftsman hobby or profession, such as tile-laying, woodworking, whatever -- many of the helpers that allow a beginner to just quickly get the job done are no longer a good idea, either because they end up getting in the way or distracting more than they help, or because they undermine good habits, always helping *just enough* that, if misused, one never improves.
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.
I can't imagine how far this profession has descended if concern for the craft implies elitism.
DISCLAIMER: I read this blog to get a brief refresher into why I don't miss windows, as such, i'd hardly call myself qualified to defend Jeff :)
""Yes, you could throw Notepad.exe 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?""
"So subjective, "best" and "advanced" are. Let's just begin by being very clear -- Linus Torvalds does not use notepad, nor do any other top-tier hackers I've ever heard interviewed on this subject. Frankly, I'm sick of this ridiculous, dismissive comment. I hear it over and over again, and I can't understand why."
I think he was exaggerating the example to get the point across.... I don't think it had anything to do with "your editor of choice." Perhaps you need to not get so defensive. "Looks simple" doesn't actually mean it is simple, you and I both know this, I'm pretty certain Jeff does too.
PS, when i'm not using eclipse i code exclusively in vim
Background checking of spelling and grammar is the first thing I turn off in a new Word installation, so I'm at least consistent in my dislike of background compilation. :)
Many years ago, when I was first teaching my son to use Word to write his school papers, I had to turn off background spelling and grammar checking. Those darn squiggles just flat-out stopped him from getting his thoughts down. Every time one would pop up, he'd stop writing and start correcting. Regardless, I think the comparison to compilers is specious: as another person, above, pointed out, you HAVE to compile to get your program to work. You don't HAVE to run a spell-check to finish a paper.
I can't believe how many people actually want the constant nagging of a back-seat driver.
"I'm actually an excellent speller, to the point that I can (and do) work without a spell checker"
What a low bar to set for oneself.
For those of us who are offended by all those 'code monkeys' that are continuously helping use with our work you can always break out the ol' C++ compiler, or maybe the C compiler or better yet how about the assembler!
Get real, our job is to write software and ANYTHING that helps use do this task with greater ease and shorter delivery time is a welcomed advantage in my book.
Or to put it another way, how many times have you been right at the deadline with some stupid manager that came from marketing or sales breathing down your neck while you are trying to tie up all the little loose ends, sqaush the major bugs, deliver it on time and stay sane?
If you've worked in this industry for ANY length of time probably a whole lot...
Is this not almost entirely down to its implementation? Here are two (real) implementations of a back-ground spell-checker:
1) When a misspelled word is detected format it using the highlighter tool. Oh, and don't wait until the user has finished typing the word. For example if you entered, say, the first three letters of "through" it should say "'thr' isn't a word, I'll highlight that."
2) When I find a misspelled word format it with a wiggly red underline.
The former is in Lotus Word Pro, by the way. It made using the spell checker a grating experience. Word tells you about the probable error but makes it easy to ignore. False-positives are not a painful experience.
My guess is that many developers imagine back-ground compilation to be more like Word Pro than Word. I'd turn a system like that off too!
well, this again. The interesting part of the thread is whether we need IDEs. We don't. The IDE was invented (Borland or M$, too long ago to recall), because DOS was too stupid to make it easy to use the editor/debugger/scc/make of preference; as one could in unix.
I still don't use one. Slickedit for editing (it knows vi/m). Face it, what matters about the IDE is whether it makes editing easier. My fingers only understand vi (other smart people's only emacs; I still respect them even though emacs is a direct path to carpal tunnel). The rest of an IDE is largely irrelevant. Only the debugger matters in the least, and once you get used to one you don't want to learn another. Kind of like your editor. Most IDEs do cvs/svn. Most do ant/make. And so on.
As for the spell checking while posting to your blog, if your blog uses one of the common APIs you can use a client like ecto, which is available for both Windows and OSX (http://ecto.kung-foo.tv/).
On the compiler front, that auto compile in VB.net has saved my sorry ass too many times, it doesn't matter how good I am at it, the feature is useful.
To me, they're no-brainers
Err... maybe that's the problem? ;)
One thing that's coming over from the comments is that the difference between a checker that is insanely irritating and one that's a delight to have around can be as small as whether it waits for you to type a space before doing its thing - a tiny implementation detail, but apparently crucial. Perhaps the user should be able to specify how long the feedback loop's delay should be?
(And of course one should NEVER, EVER, EVER interrupt the user with things like modal dialogue boxes...!)
Interesting. I've never used VB.Net, so I never noticed I've been missing this. I do know that the bug-you-after-every-line nonsense in old-school VB made me so pissed I couldn't speak, but little red squiggles seem like a nice feature.
On the other hand, it might be distracting when I try to fill in larger blocks of code -- I might end up turning it off. But it's a cool idea.
"People love background spell-checking". Ahem:
I HATE BACKGROUND SPELL-CHECKING. I turn it off, and do a manual spell-check when my thoughts are intact "on paper". I'm dyslexic and not a clean typist, and I just find it hard to write coherently when the computer is sticking me with a pin every few seconds. But I think it is a great feature for those who want it. Ditto background compilation.
People absolutely adore background spell checking.
We've had it for years and we're used to it. We know how to ignore it. For *years*, i typed all letters, essays, reports, or anything else non-trivial in a simple text editor *just to avoid spellchecking*. The red squiggly thing was useful during editing, but terribly distracting during writing - every time i'd glance at the screen, i'd lose my train of thought and start thinking about what was misspelled...
So VB.NET's background compilation? It doesn't really help or hurt me, because i just ignore it most of the time. It saves me a single keystroke every few minutes when i'd normally hit Compile, but those are pretty much offset by the extra keystrokes needed to work around VB.NET's annoyingly bad auto-indentation. As someone else mentioned though, it's worlds better than VB6's modal errors - those may have single-handedly kindled in me a life-long hatred of VB.
Still, i'm sure it is incredibly annoying to programmers who lack my zen-like ability to ignore what's on the screen...
I disagree with Dennis.
I made a comment on his blog but it appears that he is carefully choosing which comments he wants to allow.
Here is a copy of the comment I made on his page, in case he denies it from showing up over there:
"And spell checking is a crutch for writers, simply a hand-holding measure for folks who are not able to write.
After all, spell checking sometimes corrects your spelling with the wrong word! A human editing process could never make this mistake.
And what about this keyboard crap? Typos didn't exist before this bane was leashed upon the world! Clearly, this is merely a shortcut for incompetent writers to produce more poorly-written garbage.
God forbid that there is a feature that expedites the process of detecting typographical errors. I know you type perfectly all the time and don't make minor syntax errors.
Oh wait, there is at least one in this very blog entry!
Someone who cannot see the difference between "its" and "it's" are clearly beginners and hacks who do not deserve to write anything.
Furthermore, if you cannot master the syntax and grammar of your own, human, personal language, how can you criticize others for wanting tools that help correct typographical errors in another language?
Dennis, does it get lonely up there on that pedestal?"
Another interesting point, the HTML in your screenshot is not valid! Won't validate (http://validator.w3.org/). Close your p 's man!
If only there was something there to point that out to you with, for example, a red squiggly line? Ahhh... If only...
Hey there TM...I assure that your comment wil be posted, however I'm accessing from a mobile device right now and can't do that until later. The ony comments nix are hater comments, but never just because it's an opposing perspective.
Ian echoed my sentiments very clearly. I can't stand the errors that I get when I'm part way finished with typing something -- they're distractin and annoying.
[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.
The the impotence of proofreading
By Taylor Mali
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.
"Does automatic background spelling and grammer checks make you a leser writer?"
The grammar checker ... [is] good at finding problems like subject-verb agreement when the subject of sentence has been edited but the verb has not.
Obviously not -- it should have flagged "Does" in your example above, not "make."
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.
You just have to be disciplined I guess.
I think the important difference is that background spelling just checks the word (or phrase if grammar checking) while compilation checks the entire application.
Background syntax checking is fine, and would be the equivalent, but background compilation is a laborious process. When it kicks in and your system slows down it's very frustrating.
Just as spell checking only really became a background thing once it could be done seamlessly, I think background compile will become the norm once it doesn't cost so much resource.
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.
I think there are degrees of help:
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:
1. Quit considering your choice of language as a RELIGION. You are acting like Linux and Mac zealots.
2. 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.
3. 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.
Herbert N Swearengen III
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.
[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.)
If you really don't find background compilation as a tool then perhaps you aren't thinking hard enough about what really matters, the architecture or perhaps you are coding an absurdly small project? For me these things are a godsend, especially in larger products where remembering names of classes starts to become quit difficult and you have to guess and wait for it to underline. I don't use VB.NET I user c# but I use resharper and it has a somewhat identical feature to background compilation in C# where it will underline something that it thinks is incorrect, while it's not always right and you have to tell it to ignore it(alt+enter, select ignore) it's very helpful more often than not.
Just my two cents...
I don't like background compiling, because builds take up to one minute or more on my development machine. They also cause significant hard disk accesses, which slows down the accesses that count--to the spellchecking database! I write Java in Netbeans, and it has the squiggle "oh no you made an error" style of correction. It allows me to quickly notice the syntax errors I've made without slowing down code completion and documentation references that occur in the background. By only using compiles when I need to test or clean-builds when I need to look for any far-reaching consequences of changes, I save a lot of time. I like my Netbeans spell check, but I'd never want background compiling.
but you'll also probably never come up with a good reason why it's a problem other than it annoys you
Remarkably, I've never actually criticized the tools themselves. Neither have I said that it, or similar features, "annoy" me.
All of this is really a great study in how defensiveness clouds perception, making people knee-jerk respond to something never said.
What I've *actually* criticized is the -reliance- on the tools, to the point that people feel naked and abandoned without their continuous automatic compilation at their side. After they've used it as their crutch to lean on, suddenly they're left helpless when their random code-dump yields hundreds of errors on a real compile (I'll point back to Jeff's comment that without continuous compilation he's forced the endlessly hit compile, which implies that the code that he's generating has devolved to the point that he needs hand-holding from line to line. I marvel if *anyone* doesn't see how that is a problem).
To go back to the terrible spelling analogy, while many professional writers might occasionally find themselves assisted by squiggly spelling warnings, I find it doubtful that there's a writer out there who depends upon the assistance to ply their craft that we've witnessed here.
Well, I've got mixed feelings about wiggly-I-know-what-you-mean tools. IMO it boils down to: If it serves your purpose, use it.
(This also means if i.e. IntelliSense prevented someone from learning to type properly, because he's switching back to the cursor keys all the time (or worse: the mouse) to scroll down a list of suggestions, burn it!)
Unfortunately I don't know any reliable statistics on how IntelliSense disrupts a proficient programmers train of thought and I myself, don't know any better either.
I've long since been using emacs almost exclusively for coding, although I find emacs to be a crappy editor, but I just love my Escape-Meta-Alt-Control-Shift key-combos and keyboard shortcuts for other editors usually don't support complex multi-key assignments. On the other hand I'd really like to benefit from IntelliSense features when using unknown complex APIs - what should I do?
I'm not yet convinced that background compilation is a good thing. I sort of feel a tendency against it, but there's the one case where I regularly use it:
There is a nice emacs plugin (whizzytex) for writing LaTeX code, which does background compilation and turns LaTeX into a nice realtime WYSIWYG experience. This compilation is usually restricted to the current page or section or subsection, depending on the size of what you're writing. And exactly this is not possible with background compiling i.e. C/C++ code. The process of compiling is in general NP-hard and as such very time consuming and I hate it if your IDE gets slower and more unresponsive by every line you enter.
The Matlab editor has the tendency to notify the programmer of programming constructs Mathworks thinks should be implemented in a different manner.
So I write my code in emacs and if I need to debug something there's no way around using the, for this purpose very powerful, Matlab editor. A couple of times I inspected the *suggestions* Matlab made on my code and found quite a number of them very useful. On some of them I totally disagree and I find myself getting frustrated with the editor if it underlines those constructs.
So my advice is: try it. Learning to handle a new tool has complexity O(1) and if it doesn't fit you, try again later, opinions change.
"I'm actually an excellent speller" who cannot spell "plough".
"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?"
If I had seen that quote in any other context, I would be wondering why two identical choices were being presented as alternatives.
We're not actually talking about development tools here--we're talking specifically about code editors. Development tools have for many decades had the ability to do partial builds and analyze code for errors. This capability is not new--what is new is to have, or even to expect, these analysis capabilities built into your code editor, which therefore makes it distinct from other kinds of text editor.
I don't mind developers who prefer to use analysis-rich editors. What I can't tolerate is developers who can't use any other kind (or, perhaps more precisely, the managers who hire them). This is kind of like hiring cooks who can't chop onions with a knife, but insist that because they can use a cheap plastic onion chopper (like the ones so many of us have gathering dust in our cupboards) is a substitute for basic culinary competency. Chefs spend *years* of their lives doing little more than chopping vegetables. I've often found myself wanting to say (and once or twice, actually saying), "look, if you can't write code in this language without Visual Studio or something else prompting you every third line, I need you to go somewhere else and not bother me until you can."
Feature-rich code editors tend to warp the developers that use them, often in ways they are not aware of. I've known a number of people who were unable to use useful language features simply because they were not supported by their code editor. In C++, you can't look up method names on a function parameter of unknown template argument type in any code editor because the parameter type is unknown--yet, it is precisely *because* the parameter type is unknown that templates are so useful and important in C++. I've seen developers who come across one of these and just go blank because their IDE suddenly stops telling them what the type of every pointer variable is, and they have no other way to cope.
Personally I find syntax checkers and similar code-criticizing tools useless because they are not helping me synthesize code, they are just analyzing its flaws--and all too often, this analysis takes so much CPU and RAM out of the machine that the editor stops being able to keep up with me, which is the point where I stop using the editor at all. This problem is huge on very context-sensitive grammars like C++, where a template declaration in a header file you've never heard of can subtly change the meaning of statements throughout your entire program. vi, for all its flaws, never has that problem--it never gets an order of magnitude slower because a single line was added to a different file.
If an editor is going to help me, it's going to fill in automatically the close parentheses, the "else" branch of the "if" statement, the names of the arguments of the function whose name I just typed, the set of identifier names whose prefix I typed before pressing TAB, in the context of a partially typed expression around the mouse cursor. At least those operations don't use system resources until I explicitly ask for them, or save my poor tendons from some typing.
A helpful editor won't sit there saying "nope, the function's not named f...nope, the function's not named fo...ok, the function's named foo, but something's missing...you're missing a close parenthesis...you're still missing a close parenthesis...". That's just replacing the Clippy The Paperclip with Gilles The Digital Git.
I turn off syntax highlighting in VI cause it's distracting,
yet I loved using 'ddd' for debugging way back when. The nuance is how frequently the background process updates the page (and how MUCH of the page gets updated). Give a 2-3 second delay and I think a happy medium could be struck.
Meanwhile, I find 'perl -d' cumbersome, mainly because it's not GUI
enough.... but I hear there are products out there that let me see into a running script pretty easily. Being able to glance at a runtime variable value without having to insert a print statement actually does go a long way to increasing my productivity.
"Remarkably, I've never actually criticized the tools themselves. Neither have I said that it, or similar features, "annoy" me."
So you can only envision these tools as "the hand-holding of beginners, and the crutch of hacks," yet you have no criticisms of them? Interesting.
I don't think your comparison holds true. If you were writing a novel, would you want Word constantly telling you "that character doesn't exist" or "this character doesn't own a car"? Spell check only checks if a particular string happens to occur in its table of known words. It doesn't check your entire document for self-consistency. Nor does grammar check. I'm perfectly fine getting every little bit of help I can from the compiler (that's one reason I love the const keyword), but when I've been forced to use VB, I found the constant reformatting and "checking" of my code a hindrance, rather than any help. I don't mind if other people like it, just let me turn it off so it doesn't hinder me.
Also, regarding the monkeys, I really dislike the idea that one would simply accept that he is a monkey and not aspire to Linus like greatness.
All these people against background compilation, let me ask you if you also believe:
All shoes should be handcrafted like 150 years ago;
The automobile assembly line is a bad idea;
Using matches/lighters to make fire is for wimps;
If you are skilled and knowledgeable programming tools will NOT harm you. There is a reason programming has evolved the way it has. Get with the program.
I just use Zeus - http://www.zeusedit.com
It does Brief emulation, has many IDE like features, but still feels like an editor.
I think that hardware is definitely relevant here. Back in my VB3 days (1994-1995), I avoided auto-completion because as soon as I pressed Alt+Space my whole PC would freeze up for a few seconds, grinding away to figure out what the rest of the word should be. By contrast, background compilation has negligible impact on my current computer, so it's not actually slowing me down.
It can be annoying at times, e.g. if I declare a variable and then I immediately get a warning message because I haven't used it yet. However, the situation where I've found it most useful is when I've converted old VB6 programs into VB.NET; it's not so much that it instantly detects errors, but rather that it instantly detects corrections. It's a happy time when the number of outstanding errors drops below 102, so that I can actually see everything that's left!
Are you sure about the popularity of background spellchecking? It's the feature I always turn off and the reason I don't use Firefox any more. I've always been a good speller, though, so I could be in the minority here. (Also, my name is never recognized by those damn things, and I know I'm in the minority there.)
You stopped using Firefox because, what, unchecking "Check my spelling as I type" was too difficult for you?
The lengths people will go to to avoid certain things baffles me.
Ken, the reason why I (and others) don't like background compilation is because it interrupts me when I am trying to code - especially when the project is large and takes over a minute to fully compile. When I am ready to compile I do so by pressing the compile button. I don't work on an assembly line, nor do I wish to.
There is a simple difference. Background compilers like in VB generate a lot more false negatives the a spell checker.
For a spell checker a word is a complete thought, and it can check the last word you typed as you enter the next word.
For code the whole line (or two, or three) is a single thought when taken as anything but a whole will fail. If you try to background compile as I type you will be distracting me with noise that is USELESS until I finish the line of code.
The different is the scope of the problem and how it's handled. The noise is the problem, which is something that a spell checker doesn't worry about. A word is correct or not, code isn't so forgiving.
Just to inject a little humor into all this:
I have a spelling checker It came with my PC; It plainly marks four my revue Mistakes I cannot sea. I've run this poem threw it, I'm sure your pleased too no, Its letter perfect in it's weigh, My checker tolled me sew. - Janet Minor
Spell check all you want, but sometimes it will come back to bite you.
As someone who's never used Visual Anything, my biggest take-away is that subtle UI differences make a huge difference. I mainly use Eclipse (with a smattering of vi, plus jEdit as an Emacs-replacement.)
In Eclipse, there's a configurable half-second delay after you stop typing and before it marks any errors. I rarely have a half-second hesitation unless I've finished a line of code. And most of the time it knows the right fix for the problem.
I haven't experienced slowdown due to compiling a big project, although there are occasional annoying pauses for garbage collection.
Arg, automatic spell-checkers bother me to no end. Their vocabulary sucks, their grammar sucks, the wiggly red lines look stupid. THEY ARE FOR STUPID PEOPLE AND PISS ME OFF
Feature-rich code editors tend to warp the developers that use them, often in ways they are not aware of. ... I've seen developers who come across one of these and just go blank because their IDE suddenly stops telling them what the type of every pointer variable is, and they have no other way to cope.
THE crux of the issue. We're happily turning ourselves into Framework Programmers. Hirers now want to know which, and insist that one use, particular IDE/framework one is currently using. In a sense (not a good one in my estimation), we've raised the semantic level of low-ish level java and .net, but by default without thinking too much about it. Sad. Especially for java, which coulda been a contenda.
"2. 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."
This is why I don't use background compilation, I want to use a formatting style that is clear to me? Not one chosen by Microsoft?
I agree with most of the above
a background spell checker tells me about minor errors I can correct now,
a grammar checker tells me about errors that are mainly not errors just incomplete sentences (and so is annoying),
background syntax checking, (and autocompletion) tells me about things I can correct now,
background compilation tells me about things that are mostly incomplete code (and so is annoying)
In the last post I mentioned C# having rudimentary background compilation. I wasn't knocking it. It helps. I'll use it AND spell check everyday!
I just hated the popups in VB6. Turned those suckers off right away...
I wanted to bring my two sense on the matter, since I hadn't read anything like it in the first 30 comments or so: intellisense, background spell checking, background compilation, and their ilk are excellent learning tools. Like a good teacher, they take your incorrect work and mark it up with red lines, and unlike a bad teacher will actually help you correct it.
Now I am not a programmer by trade, and programming is certainly not in my job description, but I do use VB.NET Express when something needs to be done programmatically. I learned C when I was in college (before I realized that studying Comp Sci was a mistake for me) and started off using the friendly Visual C++ 6.0 compiler. I started off relying on intellisense to help me out with keywords and function names and the like, but after a while I found myself using the popups less and less. I was actually suprised when, a year later and after not touching C since, I was able to write out a relatively simple C program with a minimum of bugs in vim, without having to review pages of documentation. The only things I had to look up were a few Linux-specific procedures.
I guess what I'm trying to say is that intellisense et al are a pox if they are used passively. But if you use them actively, as examples with which to learn by, then intellisense can be a wonderful learning tool. Not to mention that intellisense, combined with the Object Explorer and your F1 key, can be an excellent way to explore new components.
How can you call yourself a programmer when you don't even close your p tags?
You never did "creative writing", I mean, writing a novel or the like, did you?
My sister does, and she turns off any check while she's writing. Once you got "inspiration", you don't need someone behind your back to tell you, "hey, you mispelled supercalifragilisticexpialidocious" continuosly.
You just need to write down what's in your mind before the magic moment goes away. You don't need to be distracted by red lines or the like just because two letter were exchanged. You will take care of that *later*, when revising and polishing what you've written.
The same sometimes applies to programming. In the middle of coding a complex algorithm I need to focus on logic, not if the code compiles or not - I could check it later.
To all the readers that complain about the unclosed tags: closing the paragraph tag is optional in HTML. Really. Go and read the standard documents. That's not the case for XHTML, tough.
Mashing these two problems together, we added background spell checking to Visual Studio with the TestMatrix extension. The idea being that misspellings are very much like bugs, and you want to know about it sooner than later.
Some people loved it, some people hated it. Turns out, what they hate is the spell checker telling them their variables are misspelled.
Actually background spell checking annoys me to no end. The trouble is that the red lines will munge the bottom of the letters that you're writing, which makes it impossible to see, for example, the difference between a "," and a "." When writing stuff that will be guaranteed to have lots of "typos", like some technical documents, I disable it and use normal spell check at the end.
Just because it's feature #2 in Firefox, doesn't mean it's great. I hate tabbed browsing too, since it takes up valuable screen real estate, but Firefox is so convinced you'll love it, that it doesn't let you disable it, especially off the context menu for hyperlinks, meaning that about 10% of the time I misclick "open in new window" to "open in new tab", which is very annoying. Fortunately I'm not alone in my hatred of tabs (who thought that having two taskbars in different locations was a good idea?), and someone wrote an extension (tab killer) which gets rid of tabs from Firefox once and for all.
Moral of the story: Don't fall so I love with your code that you can't realize that some people will find it very annoying, and want to disable it.
Those issues are not essential ones, but mostly implementation problems.
God knows I hate type errors when there need not be one, yet I believe this makes sense.
Just a smarter way of doing it will close the debate.
If background spelling checked stopped my ability to type, I'd have a problem with it. VB.Net's "background" compilation can keep you
for typing for twenty seconds on a big enough project.
Why do some people insist on turning a perfectly normal discussion into sending personal insults to those with differing opinions? The worst part is that the degrading sarcasm and insult barrage is premeditated. At least emotions in a real life heated debate may cause nasty (and irrelevant) comments to leak out of those with lesser intellect, but to read a blog and then sit down and type out hateful comments and click "Post" with the intention of belittling someone for an opposing view is beyond asinine. And yet the victims --namely Forbes, Griffiths and Atwood-- respond calm, cool and collected. The distinction between which writers are the more informed is clear and I appreciate the professional nature of the mentioned victims.
Why can't a debate such as this stay in the theoretical arena with a few examples to make ideas clear? Why do authors need to labeled as "arrogant" or "on a pedestal?" What does talking about your ill informed idea of someone's character have to do with background compiling?
That said, I can agree that VB relentlessly suspending the entire IDE indefinitely just because I haven't finished typing my line of code is certainly NOT useful to me, and obviously others as well. This doesn't make me (or Griffiths for that matter, as Mike Brooks tried to imply) arrogant, it just means I don't care for that kind of invasive "help" from an IDE. (What would make me arrogant, perhaps, would be to state that absolutely 100% of ALL errors flagged by VB in my code are due to unfinished lines, and other than that I NEVER make any mistakes of any kind whatsoever. Forevermore. Period.)
I can also say that background compiling could possibly be used as a tool for an experienced programmer, as well as it could become a crutch for an abuser of such a tool. Clearly a guiding tool might be useful to some, while a hindering tool is not useful to many.
As you pasted the screenshot of what you're typing i noticed that you're not closing your p tags!!!
The people who are arguing against background compilation, spell checker, and all sorts of other tools sound like the people who weren't sure about GUI's.
On a side note, the style of this entry sounds a lot like you, Mr. Forbes, and Mr. Griffiths need to just start a forum thread and get it over with.
Actually, I see it the other way around, mostly. I love background compilation in Eclipse, but I generally disable spell checkers. Because while the former is actually highlighting problems with my work, the latter is more commonly showing nothing more than it's own limited vocabulary.