Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Bing Code Search for C#

blogs.msdn.com

Post reply on HN
Print view View original

211–220 of 235 posts

Re: Introducing Bing Code Search for C#

#211

Post by UK-AL »

d0 wrote: post #208
UK-AL wrote: post #198

Earlier quoted context omitted.

WTF? You complain about singletons, then prefer a language where the use of [sharedInstance] is extremely common. Objective-C is singleton hell. Both in third party code, and core libaries. C# is vastly nicer than objective-c, and I'm a iOS developer. I'd rather use C# or Scala with a IoC container to handle the lifetime of objects, rather than using singletons.

Yes exactly that. The difference is that your Objective-C/iOS application doesn't consist of thousands of threads which require synchronised access to these objects. It's a pretty static thing with an event loop. Possible a couple of background worker threads. For a desktop application or even mobile application it's fine but for a massively scalable back-end enterprise system it's a pain in the butt. Singletons are…

"Singletons are not for managing lifetime as well" - No, but you can replace it with something that does. I.E Single Object with application lifetime vs singleton.

Re: Introducing Bing Code Search for C#

#212

Post by pjmlp »

us0r wrote: post #143
blibble wrote: post #38

Earlier quoted context omitted.

don't forget this one: http://en.wikipedia.org/wiki/European_Union_Microsoft_compet...

don't forget to link to Google, Apple and EVERY other Fortune 500 company doing the same shit, different pile.

They won't because this is HN and only Microsoft is bad.

Re: Introducing Bing Code Search for C#

#213

Post by d0 »

josteink wrote: post #206
d0 wrote: post #190

Earlier quoted context omitted.

As a knowledgeable Microsoft basher, you're right. MVC is better but still a long step away from something great. Some of the internals are crazy bad from attribute thread safety to the numerous singleton piles of crud like the ViewEngines collection and route data. Not only that, the tooling really doesn't scale up well either. I can only say after managing a project with 400 controllers that it doesn't scale up to…

So you had an extremely large .NET project and complained it didn't scale. And since you attribute those problems to .NET, your solution is a small project (which incidentally uses another technology). Not dismissing your argument as a whole, but you have to admit you made at least one giant logical fallacy right there.

You're right. 100% right -- I agree with you. Let me break it down into to separate points which are better described.

The problems with the project scaling are primarily down to the infrastructure: MSBuild and the C# compiler are damn slow as is the whole rip up and replace assembly system in .Net. When you have something at the bottom of a dependency chain that is quite deep (with any enterprisey project), you have to recompile all consumers and therefore everything that depends on them and so forth. A single line change means you end up compiling the entire system on top of it. All 200Mb of DLLs need building again. That's a long time. Not only that, when it comes to testing and runtime dev (i.e. using the web front end), reloading assemblies and performing JIT is really expensive and time consuming.

Every time you do something, mount everest is destroyed and recompiled twice: one to IL and once to native. This is expensive and seriously screws productivity. It doesn't scale development-wise. Simple as. This is not specific to my current project - I've consulted at various companies since 2002 and that's exactly what it has ended up for everyone, every time.

Going back to LLVM/XCode. I'm not particularly experienced with the specifics of the abstraction that Apple provide, but I've spent 20 years building monstrous bits of C on top of Unix/Linux with GCC and Sun compiler suite. That's what we're still dealing with but we have LLVM which slings code out much faster than anything we've had before. We also have incremental build support (individual .o files per source file), faster linking and a runtime system that doesn't require recompilation.

I'm not saying it'll realistically turn into anything better at the end of the day but one some points:

1. The Xcode tooling is like lightning, even with a 200,000 line C project I imported from a previous project.

2. The startup time is 487ms compared to the same thing in C# of 2.2s to first output and 10.5s to it actually doing something.

Think I've explained myself better now. Sorry for the initial confusion.

Re: Introducing Bing Code Search for C#

#214

Post by d0 »

thomasz wrote: post #195
d0 wrote: post #190

Earlier quoted context omitted.

As a knowledgeable Microsoft basher, you're right. MVC is better but still a long step away from something great. Some of the internals are crazy bad from attribute thread safety to the numerous singleton piles of crud like the ViewEngines collection and route data. Not only that, the tooling really doesn't scale up well either. I can only say after managing a project with 400 controllers that it doesn't scale up to…

I feel exactly the same way, but we should be aware that the grass is always greener on the other side.

I'd say the grass was less yellow :)

Re: Introducing Bing Code Search for C#

#215

Post by pjmlp »

Touche wrote: post #21
maresca wrote: post #5

C# and .NET get a bad rap for being created by Microsoft. But one thing that can't be ignored is how polished their development tools are. I absolutely love coding in Visual Studio.

But F# is so much better that I can't think of a single reason for choosing C# over it.

> But F# is so much better that I can't think of a single reason for choosing C# over it.

Your co-workers won't learn it unless boss says so.

Re: Introducing Bing Code Search for C#

#216

Post by chrislomax »

eddieroger wrote: post #162
chrislomax wrote: post #12

Earlier quoted context omitted.

It pains me if I am honest. Our CMS is built on .NET and it's like an uphill battle selling it as it's on IIS and it's .NET. I have played around with the idea of reworking it into an open source language and open source database but I would miss Visual Studio and the language a lot. I don't get all the hate?

Not so much hate for me, but apathy. For your one CMS, there are dozens based in Rails, Django, Node based ones I've not even heard of, and same for Go. For any of those, I just need Sublime and a server of my choosing. Furthermore, I can do dev on my box (a Mac) with very little spin up time. Contrast that to your scenario. First, I need Windows, which is fine for most, but not me. Then, my prod setup has to be Micr…

The problem does ultimately lie with the tie in, I can appreciate that. I suppose my question was almost rhetorical as I know where the problems lie.

I wanted to redevelop our CMS in MVC (we missed the MVC train by about 2 months so it's Web Forms) as I like how much more lightweight it is but to be honest, I would rather completely redevelop in another language as it would help our adoption rate with our clients.

The painful thing is, I know how powerful our CMS is (to our clients at least) but it's such a hard sell.

We normally deploy onto our own cluster BTW as we roll out core updates through our own servers so everyone feels the benefits of new modules and admin updates etc so the hosting is generally taken care of.

Re: Introducing Bing Code Search for C#

#217

Post by d0 »

UK-AL wrote: post #211
d0 wrote: post #208

Earlier quoted context omitted.

Yes exactly that. The difference is that your Objective-C/iOS application doesn't consist of thousands of threads which require synchronised access to these objects. It's a pretty static thing with an event loop. Possible a couple of background worker threads. For a desktop application or even mobile application it's fine but for a massively scalable back-end enterprise system it's a pain in the butt. Singletons are…

"Singletons are not for managing lifetime as well" - No, but you can replace it with something that does. I.E Single Object with application lifetime vs singleton.

Or a singleton that exposes a service locator (which is the pattern I've been using in Cocoa).

Re: Introducing Bing Code Search for C#

#218

Post by pjmlp »

MichaelGG wrote: post #179
Locke1689 wrote: post #116

Earlier quoted context omitted.

I agree that F# is a great language, but there are a couple projects in which I favor C#. One reason to favor C# is that it just has better IDE support, hands down. In addition, if I'm working with C# devs it's just nicer to use something everyone already knows. As far as the language goes, though, perf sensitive stuff often makes more sense for me to do in C#. This is a combination of reasons: 1) I generally have a…

I've found that with F#'s inlining, you can get significantly better code generated. The C# team has seemed hostile to the concept of implementing many compiler optimizations, and the JIT still does a poor job inlining. (And still no SIMD...) Even in C#, imperative style will be faster. Without better type systems and much better compilers, that won't change (but F# could implement fusion a la Haskell). It may be "es…

RyuJIT and ProjectN are supposed to tackle the quality of native code generation.

Re: Introducing Bing Code Search for C#

#219

Post by baha_man »

sequence7 wrote: post #58
Tobani wrote: post #48

Earlier quoted context omitted.

I have done a lot of Java, Scala, etc. IntelliJ & Eclipse are both wonderful IDEs in their own right. A lot of things like ReSharper were in those IDEs before Jetbrains (maker of IntelliJ) made the plugin for VS. After trying VS for a couple of projects I found it completely baffling and backwards. And I don't think this is because VS is bad, but because the way I approach software is completely different. I want to…

It sounds like you just don't know Windows/VS/IIS as well as you know the other stacks which is entirely understandable since I'm guessing you don't work with them very often. For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does. As far as IIS is concerned you can maintain all it's configuration via config files so an experienced Windows admi…

"For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does."

Not necessarily true, I believe some versions of Visual Studio have their own compiler which is different to the one used by MSBuild:

http://blogs.msdn.com/b/ed_maurer/archive/2008/06/11/a-tale-...

Re: Introducing Bing Code Search for C#

#220

Post by ifross »

bluefinity wrote: post #204
jmnicolas wrote: post #189

Earlier quoted context omitted.

But with a 'using' you can't catch an exception. So in production I end up using ( ;-) ) try catch finally.

The using block compiles to the equivalent of a try-finally block. If you want to catch an exception you can do it inside or outside the using block.

There are known issues with using "using". If the Dispose() call throws an exception in the finally block, then any exception that occurred in the within the using block is masked.

The easy solution is to make sure that your Dispose() calls don't throw exceptions, unfortunately some of Microsoft's classes don't conform to this (e.g. WCF clients).

The following MSDN article shows a case where they do not recommend using "using", and instead suggest explicitly using try-catch-finally: http://msdn.microsoft.com/en-us/library/aa355056.aspx

Post reply on HN