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

221–230 of 235 posts

Re: Introducing Bing Code Search for C#

#221

Post by 300bps »

d0 wrote: post #213
josteink wrote: post #206

Earlier quoted context omitted.

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…

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.

This just isn't true at all. Even in COM days it wasn't true. With COM, if you preserved binary compatibility you didn't need to re-compile a client if you compiled a new version of a DLL it calls. In .NET it's even more forgiving. Sure, if you change something major like delete a bunch of properties that are used in the client then you have to recompile the client. But in many cases you don't.

Beyond this, if your architecture has 200 DLLs, it might be completely appropriate but it is a suspect architecture. I manage a .NET project that trades $4 billion of fixed income instruments per day, interfaces to three trading platforms, interfaces to 13 custodial systems and 7 different data providers. It uses about 25 DLLs and is quite manageable.

Finally, how often do you recompile a DLL that is "quite deep" in the dependency chain? Generally, such low-level DLLs should do very little. For example, maybe it's appropriate to change them if you change from Oracle to SQL Server but how often would that happen?

Re: Introducing Bing Code Search for C#

#222

Post by mallamanis »

"Programming by example" is becoming an interesting trend these days. VS seems to be the first to implement widely such a feature. This of course, suggests that this small-scale reuse is very common. But could it be a "problem" of modern languages like Java and C#?

Re: Introducing Bing Code Search for C#

#223

Post by mercurial »

alkonaut wrote: post #197
mattmanser wrote: post #193

Earlier quoted context omitted.

I've tried it a few times now, and never stuck with it. I think it's because I find the VS interface incredibly cluttered anyway, and Resharper just makes it worse. The right click menus are already 10 miles long filled with useless clutter and when it starts mucking around with the already edging towards overwhelming intellisense pop-ups it just annoyed me one too many time. After 2 weeks of trialling it then only t…

I agree the slowness of find (Ctrl+F) and the slowness of the xml/html parsers is still the worse thing about it. I can see how tag soup is hard to parse, but well formed xml should parse in milliseconds. On the bright side, with a good go-to-symbol, go-to-file, go-to-type etc., I search much less for free text. The text editor is only a tiny part of an IDE, the bits that are added are quite important. Integrated deb…

> Integrated debugging (with edit+continue while debugging)

That's the main reason to use an IDE, in my mind, along with the ability to display the call sites of a function.

> integrated version control interface,

Never noticed any advantage compared to a shell with git or git-svn, personally.

> integrated build system

Depends what you mean by that. What's precious is the ability to detect errors before doing a build or testing anything. "Integrated build systems" in general I find often fall flat on their face when something outside of the IDE touches the files.

Re: Introducing Bing Code Search for C#

#224

Post by mattmanser »

alkonaut wrote: post #197
mattmanser wrote: post #193

Earlier quoted context omitted.

I've tried it a few times now, and never stuck with it. I think it's because I find the VS interface incredibly cluttered anyway, and Resharper just makes it worse. The right click menus are already 10 miles long filled with useless clutter and when it starts mucking around with the already edging towards overwhelming intellisense pop-ups it just annoyed me one too many time. After 2 weeks of trialling it then only t…

I agree the slowness of find (Ctrl+F) and the slowness of the xml/html parsers is still the worse thing about it. I can see how tag soup is hard to parse, but well formed xml should parse in milliseconds. On the bright side, with a good go-to-symbol, go-to-file, go-to-type etc., I search much less for free text. The text editor is only a tiny part of an IDE, the bits that are added are quite important. Integrated deb…

The text editor is by and far the most important part of the IDE and is the only part everyone will use.

It's also the thing that's most important to flow, to producing, not navigating or testing.

That it can pause and stutter when you're just trying to do a simple edit is pretty silly.

I love VS and it's one of the things I always miss whenever using something else, but there's a lot of annoyances and a lot of sub-par features and some you should never use features.

I notice you said "integrated version control interface", if you're talking about TFS, it's terrible. Stop using it. The interface is terrible, all generic tables that you can't tell apart. It's a massive effort to see file changes. And worse than all of that, the actual version control system is shockingly bad, even compared to SVN, let alone Git. You're a madman to be using TFS, it's so bad.

Re: Introducing Bing Code Search for C#

#225

Post by d0 »

300bps wrote: post #221
d0 wrote: post #213

Earlier quoted context omitted.

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…

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. This just isn't true at all. Even in COM days it wasn't true. With COM, if you preserved binary compatibility you didn't need to re-c…

COM is different. The interfaces are well defined between components and processes.

In .Net, any contracts that break between layers in your dependency chain force a rebuild of all layers above it. This is not unusual in .Net projects as the components are bound at runtime.

There are not 200 DLLs - there are 200Mb of DLLs. Total count is 122 DLLs.

This particular beast handles integrations with over 100 systems using vastly different non COTS integration methods, has over 2500 tables, 950 domain objects, 400 controllers, 45 databases, 200 API endpoints, async background processing and piles of MSMQ queues. Data volume is terabytes. It's a behemoth and it's been around for 33 years in various forms.

If you, as we do, change architectural components and APIs, dependencies are broken. The main case for this is when we version our API. We have up to 3 API versions in production. When someone introduces a new API version, the oldest is deprecated and all the historic versions are ported to the newest internal API. This is where it becomes dependency hell.

However it's a fine way to avoid technical debt!

Re: Introducing Bing Code Search for C#

#226

Post by ryaniscool »

gisenberg wrote: post #52
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?

I think it's less about not wanting to use Visual Studio and more about not wanting to have a Windows VM thrashing resources. I've worked with teams that have migrated to ServiceStack just to avoid running Windows. Assuming that running Windows is a non-issue, the parts that really, really bug me are: - Background operations suddenly become foreground operations that stall the IDE with a dialog saying "A background o…

I've run VS2013 natively and on a Virtual Machine with no problems at all. Certainly not what you're describing.

I'm not talking amazing hardware either, just a computer I put together myself.

Re: Introducing Bing Code Search for C#

#227

Post by codelap »

gisenberg wrote: post #131
codelap wrote: post #123

Earlier quoted context omitted.

The most annoying issue to you, is that you click the wrong button, and it does what it's supposed to do?

Interruptions to flow are indeed high on my list of annoying issues. Blocking the UI unexpectedly to poll an external service for an indeterminate amount of time is frustrating and worthy of resolution.

Okay, for starters, you hit the wrong button. Secondly, pretty much everything is customizable, so edit your toolbars or menus to move those to a slow running menu. The others about code formatting and auto refactoring are easily disabled. Learn your tools.

Re: Introducing Bing Code Search for C#

#229

Post by breischl »

alkonaut wrote: post #186
breischl wrote: post #135

Earlier quoted context omitted.

I tried out Resharper for the entire evaluation period and then dropped it. There were a few nice things, but nothing that was just leaps and bounds better than built in VS features. But everyone says it's necessary, so I keep wondering if I somehow missed the killer features. What are the features of Resharper that make you say VS isn't complete without it?

One of the big ones to me is "move class to its own file". Means when you are sketching up some multi-class API or something you can just type away in a single source file, and as soon as something looks half-finihshed I just alt enter and it creates a new file with the correct name and moves the type to that file including adding the necessary imports to the header. A lot of context-switch time gained. Next big thin…

I didn't find the "move class" feature while I was trialing, but it does sound pretty handy.

Symbol search is incredibly useful, that was a revelation when somebody told me about it. But Visual Studio has had that since at least 2010, I think maybe 2008. Resharper's is a bit more complete, but I think the VS built-in one is a bit faster. The VS native implementation is Edit -> Navigate To, the default key combo is ctrl-comma, but I think Resharper takes that combo for its own purposes.

Re: Introducing Bing Code Search for C#

#230

Post by Tobani »

codygman wrote: post #174
Tobani wrote: post #158

Earlier quoted context omitted.

Not true. I want still want the IDE compile, type check, and add type-safe completions (When using statically typed languages). I want the IDE to assist me in writing the code. I want my IDE to launch/attach to processes for debugging. Generally, I want the IDE to produce binaries yes, but mostly for my own consumption. I want to be able to access the compiler external from the IDE so I can automate builds/deployment…

I get compile, type check, and add type-safe completions with emacs writing Haskell through haskell-mode, auto-complete, and flycheck.

There is certainly a debate on where a text-editor ends and IDE begins. I think we can all agree we'd rather not use notepad or pico for most things.
Post reply on HN