Hacker News new | past | comments | ask | show | jobs | submit login

Writing C# code in Visual Studio feels almost like telepathy. Intellisense is so good that, it nearly writes 30-40% of total code.

I couldn't agree more. In fact, that is my single biggest problem with being a C# developer. Sounds counter-intuitive, right?

Each time I dive into another language, I feel handcuffed because I don't have the features and options that I get from Visual Studio. Once the "new language smell" has worn off, I find myself wishing for faster ways to develop sections of code. I miss instant code compilation and validation. The ability to hop around sections of code, immediately find all references, or catch compile errors at a glance are all things I take for granted until they aren't there. And don't even get me started on ReSharper. Those guys at JetBrains are glorified drug dealers and I am one very hooked addict.

All that said, it makes it very difficult for other languages to gain traction with me. At times, the software adventurer in me gets frustrated about this, but the pragmatic side of my personality (the one that likes food and a house) prevents me from giving up all those benefits.

Amen, I almost totally jumped ship when MVC was a 'new' thing, if they hadn't brought out ASP.Net MVC when they did I would have left.

The only thing I hate about C# is the 'magic' they keep trying introducing to the frameworks. ASP.Net was bloody awful but if you haven't checked out MVC 4, this is truly WTF were you thinking MS:


GetAllProducts magically maps to api/products/

GetProductById magically maps to api/products/{id].

Fucking retards, just give me the tools, not the magic. It's so focused on incompetent idiots. It's even worse than the stupid and almost but not quite utterly useless user membership crap they infect your code and database with. That's what's pushing me away from C# more than anything else, the random magic that will suddenly kill your application.

I'm guessing you're being downvoted because you're calling people retards because of what you perceive to be a poor design, when in reality they've done exactly what you've said, you just don't realise it. Which makes your "incompetent idiots" remark rather ironic and gave me a good chuckle. For the competent, or consciously incompetent:

1. ASP.NET MVC implements customizable routing, like pretty much every other modern web MVC framework these days. The routing library can actually be used in old school ASP.NET Web Forms applications or your own raw ASP.NET application, if you like; it is not ASP.NET MVC specific.

2. The default route in the code generated as part of the "ASP.NET MVC Web Application" template project in Visual Studio maps routes as follows: /{controller}/{action method}/{id parameter}. There's nothing stopping you from (a) changing this in the generated source code (Global.asax.cs) or (b) generating an EMPTY default web application without the code at all and zero routes pre-defined.

I found the magic just got in my way when I first got into ASP.NET MVC. I needed to use Firebird with Entity Framework but I didn't want to use that horrible feature which connects to the database and maps it automatically for you using a GUI. Mapping my model to the database is just something I'd rather do manually, and eventually I figured out how to do it and it's awesome.

I don't use membership so it doesn't infect my db.


Sorry, wait - how is this different than the RoR magic. Where you can do stuff like MyObject.findByArbitraryProperty and it just works? That's PFM if you ask me. Django, RoR, and Node all have lots of magic bits. You don't have to use any of the magic, which also goes for MVC.

(I do agree with you though - just because other frameworks have magic bits doesn't mean I like it in MVC. I would also prefer it not be there. I just don't think you can really pick on MS in this case.)

It doesn't fit the language and the environment.

ASP.NET MVC is way too much of a RoR clone than is good for them. C# programmers aren't used to magic: they're used to compilers telling them about typos. Convention over configuration is nice, but it's essentially the concept of dynamic typing translated to frameworks. It fits badly in a statically typed language.

I'd have much preferred ASP.NET MVC to have less magic and, for instance, decent, controllable, IDE-supported and compiler-guarded routing.

Example: in an action method, parameter names are mapped to URL parameters. This is horrible, I should be able to change the parameter name in any method without calling code being affected. Or, when this is not the case (e.g. when C# 4's named arguments feature is used in calling code), I want a compiler error saying that calling code can't find the parameter anymore.

In ASP.NET MVC, I get neither of those things. I might have as well gone Ruby all the way, then.

In short, it's brittle.

Compiled languages have pros and cons, but if you're compiling anyway, please use all the pros to the max. APS.NET MVC doesn't, and that's a shame.

It's still a nice enough framework, but it screams "missed opportunity", much like all those Java libraries that were ported over to C# back when .NET was new.

Binding between a request and a controller method is entirely customisable. The framework uses a completely customisable number of parameter sources (query string parameters, POST parameters, session variables, you can customise this to e.g. query LDAP if you want) and binds those to the parameters of your method in a completely customisable way. See, for example http://odetocode.com/blogs/scott/archive/2009/04/27/6-tips-f... .

That being said there is definitely a deficiency in strong typing in ASP.NET MVC as-is. That's why I use T4MVC (http://mvccontrib.codeplex.com/wikipage?title=T4MVC_doc&...). I'm not too sure how the MVC team have done things much differently, though, without overcomplicating the framework... you'll note the T4MVC approach is based on code generation that inspects your source tree.

Wow, cool stuff!

I think code generation from inspecting source trees really is the future for compiled languages.

I used to think that the only reason to generate code (instead of using reflection or interpreting some DSL) was speed. I missed how code generation gives you excellent additional features, such as more compile-time safety and, most importantly, excellent IDE support. Once my code is generated, I can talk to it from other code like it was a hand-written library including all the IDE goodness (API discovery through autocompletion, etc) that it comes with.

I really hope they'll keep making T4 even more awesome than it already is. Combined with Roslyn, I think we'll get some pretty cool tools ahead that we can't even fathom now.

.NET magic is generally limiting things down so that happy path works and edge cases are expensive. Other platforms do a much better job of this because they start on an edge and make that run through happy path by convention. I can't speak to it being language limitations or just the way Microsoft works, but they almost always seem to get this part wrong.

See ASP.NET MVC Routing as a example (kinda related to the above).

If code can be written by auto completion, it's by definition redundant and IMHO shouldn't be necessary in the first place.

No, it's more like the IDE is augmenting your brain and fingers. The code comes out readable, but you only have to type a fraction of the characters. It's a code-writing assistant robot.

Also, it makes APIs incredibly discoverable. Not sure what a `IQueryable` provides?

    IQueryable iq = null; iq.
and scroll through the popup. Instant one-line descriptions are available in the tooltips, and you can get full documentation with F1. you've ever experienced this, it's REALLY hard to go back to Emacs. It's incredibly well done.

(edit: formatting)

Agree on the discovery part, this is the biggest reason why I stay away from vim.

That doesn't sound all that good to me. My steps to finding what IQueryable provides:

* Cmd+Tab to Chrome

* Cmd+L for location focus

* \IQueryable searches DuckDuckGo for IQueryable and takes me to first result

I get to use the editor I want (hint, not visual studio), and I know a lot more about IQueryable anyway and can continue poking around in the docs to learn more about the 'nearby' bits of the API.

I don't really want my editor to write code for me after only a fraction of the characters. I like writing code. I agree with Inufu, I feel like completion of more than, say, IQu[tab] is starting to show redundancy I'd prefer not to have in the first place.

"Here's how to instantly find documentation on something."

"That doesn't sound all that good to me. Here's how I do it in multiple steps, in a different window!"

Do you see the problem here?

Yea, I really don't. What's wrong with different windows? I prefer to read documentation in a tool that is good for reading documentation (don't understand the IQueryable crap? Just jump over to StackOverflow in a couple keystrokes).

The description I was replying to had you hovering over little thingies for tooltips. The whole time you're writing code little popups and widgets are flying all over the place. That is distracting. Give me an environment that edits text please.

Stockholm syndrome.

Try Visual Studio for a month. At first you'll be like "get out of my way stupid intellisense popup" and then you'll be like "holy crap that just saved me 60 seconds... for the 60th time today." And then you go home early and use that free time to have sex with your wife.

Point being, it'll change your life for the better.

I was forced to use Visual Studio in school, I hated it throughout and took every chance I could get to use Python or Ruby or something else with a unix-y stack.

Trying it again now would be pretty far out of my way just to reaffirm what I already know, since of course I've long since left Windows entirely.

Visual studio has changed a lot since 2008. VS2010 is actually surprisingly good. Personally I prefer it over any other IDE I've ever used, such as eclipse.

As you said, since you don't use windows, there's no point in you using it. But let me just say that it certainly sucked at one point, but it is now one of Microsoft's best products, IMO. They've definitely done a LOT of work to improve it.

Most of the time you don't even need the documentation, as methods are named well enough that they describe their behavior. This is simply much faster than opening another window and doing a google search. The times you do need the docs, a hotkey will open a full window for it.

I'm with you on the crap flying around on every other keypress though. Feels like I'm programming with an extreme case of ADD.

No, I don't. He's using different tools for different jobs, which is the way it should be. Not an integrated mess of a thousand and one things that should be stand-alone programs with intercommunication ability.

Those who don't understand UNIX are forever doomed to re-implement it - poorly. Which is the story of every IDE ever.

As if the goal or intention were to approach UNIX's philosophy. UNIX is practically by definition decoupled. Integrated Development Environments are by definition integrated.

I spent years hating Java and embracing vim, but as I tried to shape my environment more, I grew increasingly frustrated. Finally, I was forced by necessity to use Eclipse and Maven with Java, and the lightbulb turned on for me.

Any language that takes 30-40% less code to do something for you is taking away some freedom. They're making convention easy but can make escaping it to be hard, or may slow down because of more dynamic-ness, or some other tradeoff. And there are many good tradeoffs to be had when creating programming languages, of course.

The deal with Java is that it is the pedant of languages. Half-answers and hand-waving to how objects interact (i.e. duck-typing) aren't good enough for it. This makes libraries or APIs very, very easy to reason about, because if it doesn't access to that information then that means that the library or API is broken or intentionally hiding those details from you. But on the other hand, it enforces a kind of light, but still present, agreement between classes on their relationships to each other.

The point at which your thoughts on IDE come into this is that because Java has a very rigid structure, it can make sweeping code changes at massive scale. This is something that, with shallower insight into the language, or without insight into the flow of code through a method (i.e. checking for dead code or invalid assignments), and so on, would take a massive number of man-hours to duplicate, or make use of the exact same code the IDEs themselves have written for the purpose (i.e. emacs and vim are capable of delegating certain functions to eclipse). Decoupling it in the UNIX way doesn't really make a whole lot of sense when everything is very interrelated in nature.

As well as generate, but given that some people think that if code can be generated, it should be done at runtime by the language instead, I don't want to argue this too hard in this reply. They're not wrong but they sure aren't right.

That is not true. Autocompletion is a decision with user override enabled. It is, at the very least, a visible decision. That does not imply that it is totally automatable.

What about sensible defaults? If the libraries you use are designed with reasonable defaults that have already anticipated your needs there should not be any need for anything but the most basic syntactic autocomplete functionality (closing brackets for example) because any code at that point is customization for your specific project which is not easily generalized (otherwise it would be a default in the library).

Just hide the default behaviour and make the overrides optional.

If you haven't already, you owe it to yourself to try ReSharper. The automated refactoring and static analysis tools are best described as "pair programming with a genius robot".

I felt like I was more of a configuration engineer than software developer when I was working in VS. If I got stuck I would just start typing and then hit ctrl+space and scroll through intellisense to get the options that seemed to fit.

I get that feeling with all modern software engineering. Intellisense and similar environments at least try to make it bearable.

How I long for the day of starting your project with only a blank document.

I guess that's why I gravitate towards JavaScript, still kinda the Wild West where we can still write things from scratch.

if your IDE writes 30-40% of code for you it just means your language needs at least 30-40% more code than it should to cleanly describe the algorihtm. (not dissing C# here, just all IDE-aised languages)

If my IDE writes 40% of my code it means i can call my functions ConnectToDatabaseCheckUserNameAndCountPosts() instead of ConDBusrCnt() just to save a few taps on the keyboard.

Though arguably that should be three different functions:


Obviously that's not taken from any real code but just the most obscure function name that still makes sense that i could make up in my head while writing the reply.

...But even after splitting it into three functions you would still save 60% of your keystrokes by using auto completion ;)


Which doesn't mean that you can get GetCellLocatuonById into Get CellLocation ById

Sorry for the formatting, the reply box on Android is malfunctioning.

Vim doesn't write any code for me yet I can still have long function names because of the cutting edge magic of auto-completion.

Autocompletion is writing code for you. That's what we're talking about here, in large part.


ConnectToDatabaseCheckUserNameAndCountPosts() should be 3 functions, not one.

not entirely true. some languages are very-IDE-aidable but verbose (java and c# come to mind), some are not very IDE-aidable but less verbose (ruby and python come to mind, various LISP variants also fit here I guess).

but that is not hard rule as, for instance, haskell is potentially-very-IDE-aidable AND less verbose.

now only the haskell IDEs need to mature :) but this is a mater of time.

Yes, but with Ruby or Python 60% of that code wouldn't even need to be written.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact