Hacker News Reader

Comment by InclinedPlane | Hacker News Reader

C# is probably my favorite language, although to be honest I don't have much experience with Ruby, Python, or Coffeescript. However, coding in C# (especially post v3.5) always feels like easy mode. You've got type safety but you've also got enormous flexibility with lambda expressions, extension methods, and so much other good stuff. And then the IDE becomes a real force multiplier instead of just a crutch to keep you from falling down as it can be with Java and other less savory languages, for example.

It'll be exciting to see how this affects the C# ecosystem.

Although it's even more interesting what this says about Microsoft's plans for the future of the CLR. It seems as though MS might be coming to the conclusion that it was a failed experiment, which is interesting given the success of other VM systems such as the JVM. It'll be interesting to see whether or not this move helps advance C# adoption outside of the windows platform.

View on HN

Is it just me who doesn't really like VS.net IDE? I like C#, but I would probably prefer to use something like netbeans or eclipse over VS.net.

Mostly it's just how difficult and annoying it is to fix up a failed build. If you are trying to build something and it's failing because of strange 32bit vs 64bit incompatible libraries or any similar style of technical issues, you're left completely on your own with strange and vague build errors. On the pythin/java/ruby side this stuff is in fairly obvious config files and generally just seems to work. I can't be the only one who has run into this kind of stuff?

Also, the docs/code completion just doesn't seem to work as nicely as in Java where everything has nice big easy to read document blurbs on every function. For example, Bitmap.create<ctrl+shift> and eclipse gives me an awesome popup with all the different versions and a big documentation window from JavaDoc about how exactly to use the function and when/when not to use it.

With VS.net, I'm always having to go read up on MSDN pages in a browser which are poorly written. Just me?

Most developers end up installing ReSharper or VisualAssist.

I'm a junior developer who's been working with C#/.net/VS for about six months with very little guidance, so maybe take this with a grain of salt, but in my experience Visual Studio is regularly an impediment. We had a single with our setup project that took us a week+ of man-hours to resolve, stemming from someone opening a project up in VS 2010 instead of 2008, and then committing the changes. Almost every time I check out a project some of the assembly references are messed up. There are always more errors when I check out code than when I last checked in the project. It regularly takes me about half an hour to go from "Hm, let me fire up this project" to "okay, I'm at the breakpoint". In an environment where I'm working on like five projects, this seems nuts to me.

Coming from python and php, the syntax highlighting is pretty sweet (but then, using the python REPL, I hardly needed it. It's sort of like "look at this problem you didn't have before that we solved!"), and I'm starting to understand why people like static typing, as it reduces certain classes of errors.

I think I want to go back to python and Vim or Notepad++, though.

All abstractions are leaky. Visual Studio and its associated files are meant to act as helpers and thus abstract away several details of the project, what it does with them but there's still a process to it all.

Project files are like build scripts and changing them can cause breaks. Just like wanton changes in a build script can do the same. If you proceed working with VS, I'd suggest familiarizing yourself with project files and how they're set up. All automated processes make assumptions and rely on certain conventions. I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims.

For new developers I generally recommend they review all changes they commit, including project files. Just because its an abstraction or things happen automatically doesn't mean you can just push all changes into the repository. When you open a 2008 project in 2010 you are prompted that changes will take place for example, so it's not like it was a stealth change.

Once they're properly set up project files are pretty maintenance free, but certain behaviors can make them unstable to use.

For example, if you need to support both VS2008 and VS2010, just create duplicates, it's no different than having build scripts that are not backwards compatible, you'll have to keep multiple versions around. Or just keep the VS2010 conversion locally and don't commit that back into the repository.

Anyways, you can go back to a simple text editor and just use msbuild manually, if you prefer keeping track of everything manually. best of luck!

>> I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims.

That's pretty valid. We may be living in an edge case, and I trust that if everyone's experience with VS was as bad as mine, it just wouldn't get used.

Thanks for your thoughts.

There are a substantial amount of developers who don't like VS, NetBeans or Eclipse, even for monolithic projects. Everyone has their own development style, from point and clickers to command line users and everything in between.

I guess it depends on which group you're talking to too, I know more people who can't stand VS than who like it.

I've worked with Java, C#, Ruby, Python and just about everything else at some point. C# is hands-down my favorite. I always describe it as Microsoft stole Java and then fixed all of the nonsense that made Java hard to work with.

For me it is just Delphi with a C like syntax and lots of FP goodness. :)

Nothing about this comment, short of your preference of C# over languages (and non-languages) you don't have any experience with, makes any sense at all. It's wild speculation based on a StackExchange question speculating on something that isn't even implied by a linked job listing.

Microsoft has not, nor will they, come to the conclusion that the CLR was a failed experiment.

As for the actual job listing, it has precious little consequence for anything or anyone, save for possible application speedups for certain use cases on certain architectures a few years down the road.

What exactly is wrong with the CLR? I agree with the first post - Python is my favorite language and I do love a bit of ruby now and again but I have to say that C# is pretty damn awesome when coming from an interpreted language background. Stuff like async/await, function blocks, lambdas and visual studio (which is hands down the best IDE I have used) is really cool.

Where did I write that anything was wrong with it? I was referring to the original comment, which speculates wildly based on nothing and its mother.

> Microsoft has not, nor will they, come to the conclusion that the CLR was a failed experiment.

It's easy to say that now, but time has a funny way of winkling out deeply seated truths that we try to shy away from. Trust me, I like the CLR, I used to work in DevDiv, it's close to my heart.

However, one has to wonder if something is missing or not quite right. The CLR was originally a grand strategic play. It was intended to be everywhere, in Windows, in browsers, in game consoles, in phones, everywhere. And not just present everywhere but also underpinning all of these important products. A lot of the big projects to convert native code to managed code, such as in Windows, foundered and failed. Other than Microsoft.com most of the rest of Microsoft compiles their products to native code. Meanwhile, Windows has released its own "runtime" (WinRT) and windows mobile development is migrating toward native development as well. Not to mention the failure of silverlight to gain traction. The niche the CLR serves today is vastly diminished from the vision even 5 years ago. Also, they've tried to break out of their niche by making sweeping improvements to the CLR such as adding dynamic language support and such-like but they still seem to be stuck in the same rut as ever.

Maybe the CLR will stick around forever, but given the trends it's looking increasingly likely that in, say, 10 years the CLR will be a bit like vb6. Still supported by default in every windows release but no longer fully embraced by the current tool chain.

Difficult to disagree I must admit, but what do you think happens to their web stack in your future?

Reply on news.ycombinator.com