Microsoft .Net - Weapon of Choice
"What happens if you delete a null pointer?"
About 10 years ago I was working in C++ and this would be one of our standard interview questions. It's not a particularly nasty question, nor does it require a great deal of thought to get to the answer, but as was ever the case, it did tend to strike raw fear into the hearts of many an interviewee. I've literally seen someone go white when asked this.
Why? Well, C++ is (was?) a very technical language. It is very flexible and in the hands of skilled programmers is able to produce some terrific applications. The trouble is, it is sufficiently low-level to let less able programmers wreak havoc. When I was a junior programmer one of the more hardened developers gave me a piece of advice. He said "Remember two things: Don't make big mistakes and don't address memory that isn't yours". You see, a simple little memory mistake could cause a simple little dll to blow up which could cause a simple little failure in your web site which could cause the whole thing to crash. Frequently. Costing a lot of money.
Fast forward to 2011.
"What kind of design patterns might you expect to see in a invoicing web service?"
Whoa! That doesn't even require you to know anything about syntax, let alone memory addressing! And that's the point. We've moved on us programmers without really noticing where we've come from. How did that happen? Well, for me, in my nice little Microsoft bubble it is down to one thing - .Net
In .Net we have a Common Language Runtime which is not only very, very solid but the core essentials do not require rocket science to understand. It's a lot harder to make big mistakes and for most folk nearly impossible to address memory that isn't theirs. .Net also comes with a massive Base Class Library (BCL) which neatly wraps up nearly everything a programmer needs to do to a machine and leaves them alone to write value-adding business logic. Better still, the functionality in the BCL isn't scattered across the internet in packages with exotic sounding names like boingboing.codetabulous.internet.wicked. No, .Net guys don't get paid to sit around reading about the multitude of available components as might be the case in say, the open source world. And how cool is Common Intermediate Language (CIL)? Seriously, I can potentially take an assembly from a multi-core high end server, drop it onto a windows phone and it will execute! (Ok, constrained by resource dependencies but still...!)
On top of this runtime, we have .Net languages such as C# which are elegant and can be written for a vast array of hardware without too much consideration for how it all actually works. There is such great consistency across functionality in the BCL and associated languages that .Net devs can switch from writing a web service to a desktop application to a web site and now to a phone app or cloud service with ease. What they learn building web sites will almost certainly provide them with some skills transfer when they want to build a phone app.
I should also mention at this point that the environment within which we run our .Net services and components these days also has a major part in our productivity story. Anyone remember writing transactional COM+ components running in MTS way back in the day? Green spinning balls? Well, let's just say it's a bit easier now thanks to great improvements predominantly in Internet Information Services (IIS) and also now moving into the cloud with Windows Azure.
I'm not going to list all the great things I like about Microsoft .Net here - Google them in Bing :-) The point I am trying to make is that as a development platform .Net is productive, established and in my view has contributed massively to enabling development teams to work at a higher level. At a level closer to the business in a language the business understands. It's the place where the money is.
.Net developers don't (ever) worry about whether deleting a null pointer is going to cause a system failure. Half of them won't know what a pointer is in a few years. This is good news for companies as very, very, VERY few of them want to pay developers salaries thinking about memory addressing. Most companies want developers to spend their time thinking about building business systems. I was at DDD9 a few weeks ago and after one of the presentations Jon Skeet was in a discussion about asynchronous programming in C# 5.0 and he said something I was very happy to hear. He said "C# lets programmers concentrate more on the problem at hand".
Exactly.