To IntelliSense or not to IntelliSense, is that even a question?

UPDATE (tl;dr version):

As it appears people seem not to read the post before commenting. I’m not questioning Intellisense’s value. I’m questioning why .NET developers get panic attack when someone mentions “let’s use X” where there’s no IntelliSense support for X.

As ASP.NET MVC team lately pushes towards third release of their framework including new out of the box view engine, more and more I hear people complaining about the current preview release of it, for one simple reason – it does not have IntelliSense (yet).

This reminds me of similar approach people had for some other view engines like nhaml, NVelocity, BRail both in ASP.NET MVC and Monorail. This can be also extended to not using Boo which is an awesome .NET language that should get everyone excited, but it’s not – because there’s not good tooling story around it Visual Studio (yes, I know about the efforts to bring that to some degree).

So what’s the problem?

I ask you. Ruby community, which seems to be the fastest growing development community at the moment uses what most .NET or Java developers would call “primitive tools”, with hardly even syntax coloring, yet what they seem to be emphasizing the most when they compare Ruby to other platforms is productivity gains.

So is refusal to use something unless it provides IntelliSense just an inner fear in .NET developers? I would envision it to experience children have when they learnt how to ride a bike with additional wheels on each side, and now the additional wheels were taken away.

Isn’t this behavior as irrational?


[#Beginning of Shooting Data Section]
Nikon D2Xs
2009/07/03 11:30:57.3
Tiff-RGB (8-bit)
Image Size: Large (4288 x 2848)
Lens: 24-70 mm F/2.8 G
Focal Length: 58 mm
Exposure Mode: Manual
Metering Mode: Multi-Pattern
1/180 s - F/11
Exposure Comp.: 0 EV
Sensitivity: ISO 100
Optimize Image:
White Balance: Color Temp. (4800K)
Focus Mode: AF-S
VR Control: OFF
Long Exposure NR: OFF
High ISO NR: Off
Color Mode: Mode II (Adobe RGB)
Tone Comp.: Normal
Hue Adjustment: 0¡
Saturation: Normal
Sharpening: Medium high
Flash Mode:  
Flash Exposure Comp.:  
Flash Sync Mode:  
Image Authentication: OFF
Image Comment: (C)2008 HALL IMAGE PHOTOGRAPHY      
[#End of Shooting Data Section]


Moutasem Al-awa says:

Well i read in older posts that instead of having intellisense a spell checker would be more than enough, because we are actually writing verbs and actions.
But at least lets have a tool to check our syntax and help us instead of stuck into the monitor for hours trying to figure out what did you miss in the syntax.

Nope, it isn’t.

IMHO, comparing a dynamic typed languge w/o "intellisensed" IDEs, with a – usually – statically typed (thus can be more successfully) "intellisensed" environment does not makes sense.

What about fluent interfaces? W/o intellisense, how would you use them?
I don’t want to memorize APIs. I want to discover them.

Keith Dahlby says:

If a user’s going to accept the constraints of a statically-typed language, I can understand wanting to get as many benefits from it as possible. A crutch perhaps, but if you’re going to use a crutch you might as well lean on it.

IntelliSense is not a crutch, or training wheels, it’s just a helpful tool. The entire purpose of an IDE is to help you interact with your code.

> I don’t want to memorize APIs. I want to discover them.

That’s exactly my reasoning for using C#. We’re constantly working with different languages, different APIs, and different libraries — a lot of the time, you’re going to be using something new, so it’s nice to see all of your syntactic options.

And beyond that, if you’re using a static language like C# or Java, you’re dealing with some crazy verbose code. If you can type the first few letters, hit enter and have it autocomplete RegisterForFullGCNotification or some other long-named thing, then you end up saving yourself a lot of typing time.

As someone who uses Boo, I enjoy Boo’s syntactic conciseness, but it still has to contend with the .NET API, which makes the lack of IntelliSense really unattractive. I even studied some of the MonoDevelop Boo add-in source to see what it would take for IntelliSense.

I enjoy Ruby, too, but I find myself having to break my concentration to look up the docs for a class or method far too often.

Steve Bohlen says:

I think that we also have to ask the question: "What came first? Did intellisense *facilitate* the ridiculous (over-)growth of the .NET fwk or is intellisense *needed* b/c the fwk is now so big?"

In a real sense, I think that the answer is that each of these two things co-enable each other. I cannot (exactly) recall where I read it, but when .NET 3.0 was released I recall reading that the public surface area of just the WPF API alone was itself greater than the *entire* .NET 2.0 framework. With that kind of exponential growth in the size of the APIs that need to be ‘mastered’ in order to work (efficiently) with the framework, I don’t actually think that "hit F1 and search the framework docs" would enable anyone to get any (efficient) work done. A "discoverable" API is almost a necessity.

When we compare something like Ruby (which as you point out is clearly usable by folks without quite so feature-rich tooling), its probably important to compare the relative size of the API in .NET vs that of Ruby (by which we, of course, take to mean "Rails" rather than ruby in this and most contexts).

I suspect that as (over time) the Rails APIs continue to grow in scope/scale that you will find that "knowing all of Rails" will become similarly impossible and that the need for richer tooling will probably increase. That curve is shallower for Rail b/c its (of course) only an mvc framework for Ruby and so doesn’t have quite as many masters to serve as .NET, but the trend towards more (and more complex) APIs is (I think) inevitable.

IMO its the size of the API surface that (minus tooling) everyone would have to become intimately familiar with rather than static vs. dynamic languages, etc. that most seriously impact the need for *something* like the ‘training wheels’ you point out here.

Yes, its a crutch/stand-in for "knowing all of .NET intimately, but I think the ship has sailed in re: anyone actually being *able* to know all of .NET intimately. Ruby (Rails, really) is still so comparatively small that I don’t (yet) think the same can be said of it.

I do agree, however, that as you say for smaller "add-in" technologies (Boo, NVelocity, etc.) that actually are by themselves entirely "knowable" that entirely too many developers do indeed "avoid" such thing unless/until they get "intellisense support" in VS. This is a common tooling tax that VS adopters suffer through but I would suggest that its not entirely unique to VS…after so many years of popularity, the same prejudices are evolving against tools with "less than stellar" Eclipse integration for users of that platform.

Just my thoughts…hopefully more or less on-topic 🙂

-Steve B.

> I’m not questioning Intellisense’s value. I’m questioning why .NET developers get panic attack when someone mentions “let’s use X” where there’s no IntelliSense support for X.

I don’t think that IntelliSense addiction is /really/ the culprit in those cases. Remember that developers will always refuse to use something unfamiliar; they’ll just pick the most rational excuse to defend their position. For a C# user, that’s probably IntelliSense.

And even if the developer *is* willing to use something unfamiliar, what would be the most valuable tool for them to have so they can get up to speed quickly? IntelliSense!

Also, I think the way you are downplaying IntelliSense as just a .NET crutch is dangerous. There is already a perception in alternative communities that C# is "easy mode" and "real developers" don’t care about things like IntelliSense. So when a Boo developer thinks "What is the best way to add value to Boo?", IntelliSense is way at the bottom. Even though I’m sure that IntelliSense would capture infinitely more new users than implementing yet another undocumented way of doing AST macros.

The interesting thing is, developers are radically aware of the effects of accessibility. If code is confusing, unclear, or misleading, it’s likely to get thrown out. If a UI is unintuitive, sluggish, or dense, users are likely to avoid it. If a tool is powerful, but hard to use, people will do it by hand. But when it comes to development environments, we’re willing to look the other way for the sake of ego. I can brag about using vim when I’m talking to my .NET-only friends. They can’t really brag about using Visual Studio. Why?

RhysC says:

Without reading in depth the other comments IMO the need for intellisense is is just the need for feedback. If code was compiled and tested super fast then the intellisense crutch would be lessened. This is the effect you get when using a dynamic language with backgorund test runner constanting giving you that feedback (eg my experience with ruby and autotest).
One of the major problems is (IMO) that .netters by and large do not do TDD, so lean heavily on intellisense. Testing is still an afterthought in all but the smallest of our population. Techniques like Fluent Interfaces if well constructed may help encourage the use of intellisense, but that (again IMO) is not the reason for using a fluent interface, FIs are for READABILITY not writablity.

my $0.02