Each Technology Has Its Place

You would think software engineering is an activity where the decision to use such or such tool is based on pragmatic considerations: short term development costs and long term maintenance costs. In reality there is often a mix of religion (belief that ONE language is better than all others because it’s the language I learnt from an old bold master in a temple somewhere in Tibet) and fashion (technology perceived as cool because its name often appears in blogs and job specs).

Software libraries form a giant, ever-evolving toolset where each tool is optimal only for a narrow range of applications. This is in spite of the massive efforts by standard bodies to build all-purpose languages. No language is truly all-purpose, each one has its preferred applications.

Languages:

• C++ stack: native programming with Win32, STL, Boost… Best for situations where the CPU or the memory usage becomes a bottleneck: embedded systems, server apps handling large volumes of requests. The focus is on execution speed and low memory footprint.
• C# stack: .NET, CLR, Linq, WCF, Windows Forms… Best for situations where the performance bottleneck is in the database or the network. Need for high level of customisation while keeping development costs down: the focus is on ease of development.

GUI toolsets:

• MFC: extremely responsive front-end for consumer-grade applications (as opposed to Enterprise apps). Has been around for ages and is still actively maintained by Microsoft.
• Windows Forms: all-purpose front-end, ideal for Enterprise apps. Plenty of of 3rd party controls available. Very easy to code (when you compare to MFC for instance). Acceptably responsive. Deployment over ClickOnce easy as long as no admin rights are required and the target machines have the right .NET framework.
• WPF: suitable for front-ends with relatively simple functionality, with an accent on good looks or advanced interaction. Feels a little bit overkill for Enterprise apps in terms of ratio between programming effort / result. Model apps for WPF should be those cool-looking interfaces you see in films. You can also do boring-looking Windows apps (with a menu, drop-down lists, trees and grids…, but there is no much point, you might as well use WinForms). Deployment over ClickOnce similar to Windows Forms.
• Silverlight: suitable for extremely simple Enterprise front-ends (think IPhone apps but on the desktop), very easy Enterprise deployment via the web browser. The architecture guarantees that the client-side set of DLLs will be lean: you can’t deploy any 3rd party DLL, only Silverlight classes. Any 3rd party functionality has to run on a server, behind a WCF endpoint. In an enterprise context this type of constraint is actually a good thing because it forces you to leave complexity on servers.
• HTML5/Javascript: web apps with a large reach, required to work on any browser/platform. Would sound like a really tedious choice in a Windows-based Enterprise environment where much better tools are available. However for pure web apps HTML5/Javascript makes more sense than Flash or Silverlight.