C# revisited
19 November 2013I first used C#.NET about a decade ago in a job that was an experience better mostly forgotten, and for various reasons the software platform is one that I started to take semi-seriously again around six months ago. This was partly driven based on anecdotal information I knew about the New Zealand job-market and some of the remarks below about it were written while I was still out there, but my current interest is for somewhat very different reasons.
Rekindled interest
My interest in C# back I New Zealand was partly due to it being the one language that I could claim legitimate commercial experience with, yet the passage of time meant that I would be far from hitting the ground running. In other words the one language where I could conceivably make it to interview on the back of having used it commercially, but not be sufficiently up to speed on to wing it on technical questions. As it happened, I ended up in a job that involved neither C# or .NET, but I still felt that C# was a better bet than C or C++ as a future direction. Suppose it is because I already know C inside-out, and C++ always leaves me thinking why? due to its bloated nature. And I hate Java.Current interest
Since stating my current job, my interest in .NET is that it is significantly different from the Linux-orientated development I do professionally, which in part may well be down to the task-orientated nature of the work. This does not involve the hands-on down-to-you approach of my previous company, which although a lot less stressful, also leads to easy detachment. One way or another, I wanted something most definitely not related to my salary-paying programming, and ideally not related to my previous job either. As much as the likes of Haskell still have their appeal, most languages I have not at least tried to use commercially are ones that I would be rusty at best with. 4-5 years ago I consolidated on C & Python, and I still see no reason to diverge from keeping to a small set of languages, even for personal projects. So C# and Python it is.Development systems
There is several choices of development environments for C# development, and perhaps predictably they are all geared towards creation of GUI-orientated programs. I've tried three so far, and although none fits my ideals perfectly, any should do if your plan is to learn C# itself.- Visual Studio Express
- I am not exactly sure what the premium editions of Visual Studio provide that cannot be achieved by the free express editions, but the latter is more than enough for the solo programmer. However like may others I hate the re-themeing the Windows8-like 2012 edition of Visual Studio has had compared to the 2003-2008 editions, and sometimes getting certain non-coding things done can be a bit long-winded. You need to register to get a licence key, which is bit of a pain as I do not know how many you are allowed, and in any case am always jumpy about some of the information you have to give, even they clearly do not check it. On the plus side it is C#.NET how Microsoft intended it, which has currency with some people, and Visual Studio is very polished as far as IDEs go.
- MonoDevelop
- I have tended to find GTK heavy going, and GTK# is bit of a second class citizen as far as documentation does, so Mono's learning curve is steeper than it needs to be, and it left a bit of a negative first impression. I get the distinct impression that it is a bit too focused on GTK, so if like me you prefer wxWidgets, the only thing it really offers is the debugger. To be fair being Linux-orientated much of the target audience are people who tend to gravitate away from IDEs. On the plus side it is the way to go if you are biased towards C# on Linux rather than C#.NET, which is a major plus point if like me you do not use Windows day-to-day, and it leaves out stuff that is likely going to be a portability problem.
- SharpDevelop
- From what I have read, SharpDevelop and MonoDevelop have common roots, but they clearly have different agendas. Whereas MonoDevelop is built to be completely independent of Microsoft, SharpDevelop uses the command-line tools that ship with the .NET runtime. In terms of appearance SharpDevelop feels much like how Visual Studio used to look like, which is what made me like it almost immediately. It also has a few tricks such as auto-generating classes for accessing resources, and doing it in a way I find more intuitive than Visual Studio. It even uses Visual Studio's project file format to boot. Although in principle there is in theory nothing stopping it working under Mono on Linux, in practice this is not a priority target audience. Once nice feature, although not sure how reliable it is, it has the ability to convert the language a project uses.
Legal issues & Oracle
While C# is an ECMA/ISO standard language, this does not extend to either C# versions 3 onwards, or the .NET runtime that practically all C# programs depend on, and there are still memories of some of the dirtier tricks Microsoft has pulled in the past. Ultimately Microsoft's longer-term aim is to see Java displaced by C#, and there are those out there who think Microsoft are playing it long and have not genuinely put Halloween-era behaviour behind it. Microsoft have improved interoperability, but that is mostly being driven by the European Commission, and even then there are doubts about how far it has actually gone.On the flip side after some of Oracle's recent(ish) actions following their takeover of Sun, in particular suing Google over Android, anyone concerned over the control of C# will also be concerned over the control of Java. Concerns over Oracle's control of MySQL was regarded as bad news, and it does not help that post-takeover Sun has had an exodus of significant people such as James Gosling, which in itself is cause for concern from a technical steering perspective. General feedback I have got is that Oracle is a company that others want to avoid dependence on, so those concerned about vendor lock-in are gravitating to the likes of Python.
Windows Forms
The Windows Forms designer in Visual Studio is very nice to use, but I found that more often than not I ended up using the generated code as a template rather than using as-is. To be fair this is because interface designer programs in general only really work with a static set of GUI controls, and programs I've written required dynamically-generated interfaces. Although Windows Forms allows for nesting of panels & controls in order to facilitate resizing, the designer itself invariably uses fixed coordinates everywhere in the generated code. I suspect this is a throwback to the days when Windows did not have the extensive theme support it now has, so it was safer to make assumptions about control sizes. I would not be surprised if the form designer in Visual Studio was mostly implemented well over 10 years ago, and to be fair ther interface designers that output source code usually suffer much the same problems.What surprised me is the extent that Mono supports Windows Forms, with problems only really arising if a C# program drills down and makes use of the underlying Win32 window handles. Earlier versions of C#.NET, at least from my experience with the Compact Framework for PDAs, were so bad that drilling down was basically required and at times I wondered whether I would be better off simply writing entire components in native language then importing them. However much has moved on since then, and what attracts me towards it all these years later is how similar it is to the Win32 and WinCE user interface APIs I have used quite a lot the last 3 or so years.
The down-side is that Windows Forms, like C & Win32 API programming, seems to be much in decline. These days the trend is towards XML-based systems such as Glade and WPF, which introduces a logical separation of appearance and program code. The problem is that these are geared towards large-scale programs with several different windows & dialogs, and not the small-scale and tightly-coupled things I can foresee myself writing in the near future.