Introducing Bing Code Search for C#
blogs.msdn.com
blogs.msdn.com
To many young developers these days, and IIS server is the thing your company keeps in the closet to some sluggish legacy monstrosity which has been replaced for years with a better open source solution, but can't be put out of it's misery because it still holds some data that might be useful sometime.
Is any of this true? I have no idea. I'm just letting you know the rap it has, and the perceived reasons for that rap.
Deploying everything can be one-click. VS even has git integration now.
The old IIS is like you describe. But, the latest IIS is fast and easy.
In all honesty this is what I find from most unknowledgeable Microsoft bashers. They tried out the MS development stack with Classic ASP, Visual Basic 6 and SourceSafe 15 years ago. Then in their head they're contrasting that to the latest RoR tools with github. Many are not even aware of ASP.NET MVC and how different it is from ASP.NET.
Now, this isn't to say there aren't knowledgeable Microsoft bashers but this is what I find from many of them that aren't knowledgeable.
I can only say after managing a project with 400 controllers that it doesn't scale up to complex UI or even medium sized projects well. Also we're reaching 5 minute edit, compile, run cycles (on E5 Xeons!). Also production debugging (which is inevitable one day) is a PITA on CLR based projects.
It has become the opposite of all promises. It's like wading through tar.
To be honest after over a decade of .Net experience and over a decade of Win32/COM etc before that, I'm tired of it all.
I wrote my first Objective C+Cocoa application last week (an RPN calculator) and it's where I'd rather be. It was fun and frustration free. I tried to do exactly the same with WPF/C# a few weeks ago and it was horrible.
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.
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 not for managing lifetime as well. They are a container for an object -- nothing else. Lifetime should be managed separately i.e using a container/service locator or something. Everything I've seen Cocoa-wise is pretty decoupled so far. There are some crimes but only inexperience seems to require them.
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.
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.
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?
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!
What are the features of Resharper that make you say VS isn't complete without it?
Next big thing is navigation. Go to type, go to symbol and go to file are super quick and means I never go to the source tree to navigate the solution.
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.
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 thing I was really using was the "go to implementation..." but I've long since given up on the ridiculousness of making everything mockable anyway so it's only occasionally useful.
The worst thing about VS is how slow it can be sometimes, even on incredibly powerful machines. In the end it's a glorified text editor and everything should be secondary to that.
There's nothing more annoying than pressing ctrl-f (find) and then have it pause for 1/2 a second because it's trying to parse a massive html tree for intellisense you don't even need because you're just trying to delete a single node you know the name of.
The text editor is only a tiny part of an IDE, the bits that are added are quite important. Integrated debugging (with edit+continue while debugging), integrated version control interface, integrated build system, integrated profiler and much more makes it so much more productive than having to e.g. do debugging with recompile/restart turnaround times.
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.
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.
I haven't lived with it long enough to find out if it's as easy to break as Eclipse when you install the wrong combination of plugins, though. Oddly enough, its vim emulator plugin is much better than what I found for Eclipse, which I find quite ironic.
One problem I'm running into at the moment is I'm trying to port a vendor's reference SOAP Service over to Mono/Linux and their provided secret sauce DLL is blowing up when calling their objects' constructors. I'm yet to pin it on Linux or Mono. Here's hoping the vendor is Mono friendly and willing to debug it. If not we're going to have one oddball Windows server in a sea of Ubuntu EC2 instances.
Ironically, we have some large-ish C# code-bases that run on everything but Windows.
The memory model is, IMHO, where Microsoft is pushing the limits of the existing C# language.
What has Microsoft changed in the .NET memory model that makes you think they're pushing the limits?
From what I can tell, the .NET memory model is one of the things that has changed the least. The languages have changed a lot faster than the memory model.
.NET seems to be well worth the cost of running Windows, but the consequent platform and vendor lock-in is still a concern for us.
Maybe you should contribute a better one. ;)
Getting a web app built on .NET/MVC4/IIS running on mono isn't a trivial endeavor, and the open source implementations rightfully tend to lag behind the closed implementations.
[1]: https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammer...
While developing with MS technologies, you must accompany any code, tests and documentation with a "My License" folder with "licensing.cs" files to calculate, the implied licensing costs of each piece of code you develop along with all required MS components down to the metal. Finally, you must make sure the relevant "My License/licXX.cs" gets updated with changing licensing policies.
Next to your developers, designers you must staff an MS certified licensing specialist, or for larger projects a License team with a director level position to analyze, plan, design, test, negotiate and pay licensing costs.
I don't get all the hate?
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 operation is taking too long."
- Misclicks spinning off long background tasks that stall the IDE.
- Automatic refactoring/code analysis that will stall the IDE.
- Incredibly aggressive automatic reformatting.
- The Microsoft Account agenda. VS2013 wants me to sign-in with my Microsoft account on so many different occasions: settings sync, Azure, Windows Developer account registration, auth refresh, etc... which wouldn't be so bad, but I'm signed in via Windows 8 already, adding insult to injury.- Nor misclicks stall IDE
- Nor automatic refactoring analysis stall IDE
- Automatic reformatting is a once click option to disable and is not terribly aggressive in VS 2010 up.
- wants you to. Not forces. So, by the way, do JetBrains, NetBeans, Oracle ...
That said, my experiences with Visual Studio only serve to underscore the point that my peers would prefer to avoid running a Windows VM altogether if there are open-source alternatives that are good enough.
As far as virtualization, why are you working in a virtual environment? What are your machine specs? What is the emulator? I'm genuinely curious, because I haven't encountered any of those issues.
Virtualization is kind of a red herring here, because as mentioned before, this happens on an array of workstation-level hardware (quad-core Xeon/i7, 16-32GB configurations, SSD).
The point is that virtualization makes these already-painful existing issues much more pronounced, such that my peers actively want to avoid spinning up a Windows VM for a project. These experiences, whether agreed with or not, were largely responsible for the immediate revulsion my team felt to Windows-based solutions. I can't begin to explain how excited people were at the prospect of not having to use Visual Studio anymore when ServiceStack rolled out at my prior company.
My use case for virtualization is mobile development spanning iOS, Android, Windows 8 and Azure-backed services. The last few companies I've been on-site at outfit their employees with high-end MacBooks, with developers occasionally using virtualized Windows under protest.
If you have to work with the tools daily, then take the time to learn them. You'll thank yourself.
Converting off of STA in legacy code is extremely difficult due to the transitive nature of it as well as the fact you likely have very large and complex types which were never written to be thread-safe because the STA protected them from that (let's not talk about re-entrancy though :)).
It is getting better since managed code has MTA semantics by default, but even with async code all it takes is one person calling Wait on a Task on the UI thread...
A huge sync API surface that is publicly callable also doesn't help. Even if you want to make things async under the covers you generally can't since callers are expecting synchronous semantics and there is no (good) way to make work async, present a sync calling surface to callers, and not block the UI thread (if you say nested message pump, you lose :P)
I'd be inclined to agree with you if it were just me or one machine, but these are characteristics that I'd use to describe Visual Studio across a number of machines, projects and teams over several years.
I find a 100project C# solution (200mb deploy) to be perfectly snappy when using & fast to build. There are and have been zillions of annoyances with VS but perf hasn't been one since I set my machine up properly (in the office most of the developers complaining about build perf could cut 75% or more just by excluding certain dirs from AV scan).
I'd be as upset by a group policy demanding I scan my VS intermediate dirs on access as I would be by a no-chairs policy at the office. It's a dealbreaker.
I'm not talking amazing hardware either, just a computer I put together myself.
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 be able to compile things from the command-line first and use the IDE to edit the code. The way this happens makes it much harder to use other tools I like such as Jenkins. I can't ssh to a windows server.
On the other hand I can see where somebody might be frustrated that they' can't remote desktop into a linux server or had to learn a new config language instead of having a GUI.
IIS is another beast altogether. I've had to help customers set up their servers and the instructions are a set of screenshots that are hard to follow and easy to skip. Most apache/nginx configs clients can copy/paste fragments into their configs to get things working.
I could have 1000's linux servers up by lunch, but it would probably take me all day to configure one windows server. You probably have a better solution for this, but I've not come across it.
For me VS C# probably wouldn't be too bad if it didn't require running windows.
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 admin could have 1000's Windows servers up by lunch too. They'd probably take all day to get a Linux server up though.
Err, no - MSBuild, is basically a clone of Ant, except that it is meant to be generated by Visual Studio. This is completely backwards from what happens in say Java/Scala with Maven, SBT or Gradle.
The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
MSBuild does not require Visual Studio
> The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
The equivalent of plugins for MSBuild is Tasks
> Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
Yes it does via NuGet, and again NuGet has no dependency on the IDE
> And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Yes I have, what's your point?
> Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
Thanks for the personal and professional attack at the end there, nice touch
I remember looking into MSBuild, but I couldn't get it to work. I must have had some path set wrong or something.
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-...
Where would you suggest I go to find the best way to handle this?
You want a text editor, not an IDE.
I want to be able to access the compiler external from the IDE so I can automate builds/deployments easily.
Now I want both types of builds to happen in as close to the same manner as possible so they're consistent, but both are important.
fortunately those days are over and they've become mostly irrelevant, but everyone knows that given half a chance they'd do it again...
Everyone I know for the most part types their documents in Microsoft Word on Windows computers. Sure, they got smartphones and tablets for the media consumption and facebook, but they don't even know an alternative "big boy" OS exists. They think Windows == computers. Which I think means MS is anything but irrelevant (no matter how hard I try to stuff opensuse down everyones throat).
MS Office is the defacto file format for office work, and MS Office on non-Windows platforms (ie. Mac) is so bad as to appear intentionally crippled.
Microsoft makes most of its money with its business products, so it's not cheap. Some companies just simply don't want to pay the Microsoft premium.
I also should have mentioned Mono, but that's a different topic.
http://visualstudiogallery.msdn.microsoft.com/0e53eaf6-b031-...
Contrast that to your scenario. First, I need Windows, which is fine for most, but not me. Then, my prod setup has to be Microsoft based. I've yet to find a $5/month IIS-based host with SQL Server (apathetically, I haven't looked much). Oh, and Visual Studio. I can probably get by with Express, but at some point I expect I'll find a wall that forces an upgrade.
Microsoft has come a long way, but when I started years ago, I couldn't swing a Microsoft-based environment. VS was prohibitively expensive, and my parents' crappy computer couldn't run it. But I could learn PHP for free, run it locally through XAMPP, and be off to the races. Microsoft's never won me back, and your CMS is paying that price.
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.
They're free, period. You don't need Visual Studio Pro -- you just need to install the isolated shell.
If you have problems selling due to the platform, I think the main issue is your target market, and not .Net in itself.
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 better sense of the IL that a given C# program will generate. This is both because I am a C# compiler dev and because C# is closer in form to the .NET IL than F#.
2) I have a better sense of the actual machine code that will be generated for C# code by the JIT. This is almost entirely because I am a dev on the C# compiler.
3) The language/framework teams are very data driven. The population of F# developers and F# code in comparison with C# developers and C# code is like a drop in the bucket. There are hundreds if not thousands of C# developers for every F# dev. It is almost a statistical certainty that C# JIT hot spots will get optimized before F#.
4) The fastest F# is usually very imperative and is essentially the same as the C# code.
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 "essentially the same", code, but with 1/20th the type annotations. It adds up.
I've not found a case where there'd be an excellent C# programmer not capable of using F#. Sure, if it's a little project and it's required that "random" C# programmers be capable of working on the codebase, fine, OK. Otherwise, the benefits of the language outpace the minor learning curve.
Your co-workers won't learn it unless boss says so.
This tool definitely helps with C#.
One thing I like about Apple developer docs (on developer.apple.com) that MSDN doesn't have (at least didn't last time I looked) is the ability to get a PDF covering specific topics. These are useful when I would rather have not deal with a browser while developing.
http://msdn.microsoft.com/en-us/library/export/help/?returnU...
If I do the following google search "developer.apple.com keychain", it gives me a web browsable version with a pdf link in the upper right. If I click the PDF link, I get the content for "every page" which means, in this case, the "keychain services programming guide".
I have yet to be able to do the same under msdn.
You can even throw whatever you download on a network, and anyone can access it from there rather than individually needing to download it. That requires setting something in the registry though to access from the network (let me know if you want to know though).
Visual Studio still has an option to install all MSDN content on your hard drive, for offline access. It's the traditional Help Viewer model.
This only covers language and SDK documentation -- not the magazine articles and other random stuff.
The one thing that bugs me when these types of threads start is the hatefulness of others to bash MS for trying to make a profit and lock in when everyone else here is trying to earn a profit on their must have technology.
Why single MS out on this? Isn’t this what your trying to do?
For example, I am used to having a class information(methods, variables, etc) or similarly Javascript function information in Structure window updated whenever my cursor moves in the code window.
In Visual Studio this apparently is not possible automatically, and you have to make a custom hotkey to force this behaviour.
http://stackoverflow.com/questions/546113/visual-studio-auto...
How do people work through someone's else's code in VS? Do they really read every single line or use Object Browser?
I understand that Jetbrains Resharper fixes many of these issues, but that is not vanilla VS then.
Have you considered perhaps including more data sources ? I'd imagine for example a public code repository like Github or Codeplex will extend the range of possible "How Do I" questions that can be answered.
On an unrelated note, I have almost always been disappointed by the search-quality of Github. I know they have a lot of public code but they don't do a good job of surfacing relevant code results. Imagine for example, how cool it will be being able to type into Github, "How to compute MD5, C++" and seeing the relevant code.
Actually, thinking about it, there is nothing preventing Microsoft Research from taking this tech, and turning it into a natural language web code search service. Now that would be awesome !
And, agreed, MSR does some cool stuff :)
As you mention, GitHub doesn't fare that well: "We couldn't find any repositories matching 'How to compute MD5, C++'"
PTVS: http://pytools.codeplex.com NTVS: http://nodejstools.codeplex.com
disclaimer: msft employee.
Now i have to [ctrl] + [space], click on how do i, then search. Is there an easier keyboard only way like your web example?
using (var file2 = new StreamReader(file))
{
while ((line = file2.ReadLine()) != null)
Console.WriteLine(line);
}
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
[Citation needed]
Then what's the point of having a 'using + catch' instead of a 'try catch finally' ?
Personally, I think this new feature is cool, but I've come to realise that my visual studio freezes way more then initially, I think this might be because I've got a few addons installed (ex: Demon, Resharper ...etc) I wonder what will be the overall performance impact of this.
It is at least a really useful add-on...
http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky
> The Qeng Ho's computer and timekeeping systems feature the advent of "programmer archaeologists":[2] the Qeng Ho are packrats of computer programs and systems, retaining them over millennia, even as far back to the era of Unix programs (as implied by one passage mentioning that the fundamental time-keeping system is the Unix epoch:
> Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.
> This massive accumulation of data implies that almost any useful program one could want already exists in the Qeng Ho fleet library, hence the need for computer archaeologists to dig up needed programs, work around their peculiarities and bugs, and assemble them into useful constructs.
And Vinge is an excellent storyteller.
There's actually a third title in the series out, now, that I also quite enjoyed. But the first two, and especially "A Deepness in the Sky", really got my attention.
vim howdoi plugin [2]
one of the few emacs plugins [3]
not sure if there are any other plugins, but that should cover a decent portion of interest here.
[1] https://github.com/gleitz/howdoi
[2] https://github.com/laurentgoudet/vim-howdoi
[3] https://github.com/arthurnn/howdoi-emacs
EDIT: sublime version https://github.com/azac/sublime-howdoi-direct-paste
Fred Wilson posted on this very topic this morning. http://www.avc.com/a_vc/2014/02/inspired-by-github.html
From his post:
"I was at a hackathon up at Columbia University last weekend and one of the hacks was a development environment that automatically queried StackOverflow and GitHub as you are writing code so that you always have in front of you the answers to the questions you are most likely to ask. The developer who did the hack introduced it by saying something like "programming these days is more about searching than anything else". That reflects how collaborative the sharing of knowledge has become in the world of software development as a result of these cloud based tools for developers."
Most other experiences base their search algorithms on search engines / textual matching / rely on the host web site's search accuracy, where as we combine search engine smarts with semantic and contextual analysis.
You get those types no matter what role they hide in. Today I spent an hour with a candidate that looked really promising on paper dodge every question and switch from being "mainly backend" to "mainly frontend" when they couldn't tell me the difference between an interface and an abstract class....
I do wonder if there's something about .NET and a business environment that encourages this kind of behavior. When the organization's values are in their business rather than mentoring programmers, when they tell their programmers to "just get it done," you end up with IntelliSyn...Sense programmers? I've worked in various different programmer ecosystems, and I've never seen this pattern so strongly. There are of course excellent .NET programmers, I don't mean to say otherwise. And I got the feeling that several of the people we interviewed had basic talent, they'd just been trained, intentionally or not, towards this kind of behavior.
We started putting VS in front of candidates precisely to deal with the kind of fuzziness you mention. We started with whiteboarding code, but a lot of candidates would have a wrong design, then add a line of pseudo-code that they claimed magically made it work. By having them write actual code, it forced them to be explicit and to deal with unexpected outcomes.
I use dynamic languages and have never touched an IDE, but I still do this.
If I find out I need some feature provided by libfoo to accomplish a task, then, before I even look up the libfoo docs, I try this, or an equivalent:
require 'libfoo'
LibFoo.constants
(LibFoo::Foo.new.methods - Object.methods).sort.grep /bar/IntelliSense is like GPS for programming. When driving, do you prefer to plan your trip using a map or use the GPS instead? I guess there are still people in the former camp, but most younger people are in the latter.
> Instead of stepping back and thinking about the problem generally, they'd try to solve it by stringing together IntelliSync suggestions, like stepping stones across a pond.
And are they less efficient for diving in right away and using their tools vs. waterfall planning up-front?
Kids these days...
Don't get me wrong, I love IntelliSense. It digests a huge amount of information for you without forcing you to switch context, like having to look up library documentation or how a particular module was written. But it's only part of the puzzle. What I was seeing in our candidates was that they'd come to rely too heavily on IntelliSense and forgotten how to design. You need both.
> What I was seeing in our candidates was that they'd come to rely too heavily on IntelliSense and forgotten how to design. You need both.
I think kids these days have evolved different ways of working given the tools they grew up with. IntelliSense (and code completion) wasn't even a thing before 1997, and many of us developed our core programming habits before that. The question is: are we biased against the process we are observing because it is so unlike our own, and are they arriving at the correct answer as or more efficiently than we would with older ways of doing it?
Design is quite orthogonal to API selection; if they aren't designing, then they should be succeeding on the problem UNLESS you gave them one that required little or no design; like writing some basic boilerplate code. You didn't specify if the candidates were failing on outcomes or not.
Now aircraft control systems or MRI machines...you probably want very clean code.
The kind of "commitment" that you refer to is one that results in perhaps wider acceptance (perhaps not), but /definitely/ will annihilate their existing strategy (lock-in).
http://gkoberger.github.io/stacksort/
A lot of programming can involve Searching, but it doesn't have to involve searching with plain-text. One would have thought Google would work on this, but they closed down their code search and haven't offered anything else.
Google search reliably produces an answer each time, regardless of what the question or problem is
This is why search is very sticky (and habit forming). MSDN (and even Stackoverflow or Github) suffer from this problem because they only have a subset of content that developers want/need. Google brings all these sources together into a single search.
This extension doesn't “spoil” programmers any more than Google does. And if you hire this kind of programmers, this is very likely a problem of yours.
I honestly can't imagine going back to the dismal experience that was the ecosystem I used in undergrad - Linux/Unix + Java/Ruby/Python/C/C++. The only one of those I actually still enjoy working in is Python, and I can do that on .NET in VS as well. Ruby/Rails isn't really that bad TBH, but these days it just feels like a second rate dynamic version of MVC.
JS is hard to analyze, but we're working hard on getting better--and the analysis code is open source[1].
https://sourcegraph.com/github.com/joyent/node
https://sourcegraph.com/github.com/jashkenas/underscore
I could even see it being used to search for CSS framework usage examples.
I always had a chuckle when the first result for a simple C# concept and the result isn't a MSDN site. I also chuckle when the result is a forum post from 2005 that drops me into a link loop.
Thankfully I won't have to write C# for a long while. I can't say I will miss the MVC stack or the legacy burden you get with forms.