Last night I attended a BCS talk for the Advanced Programming Specialist Group by Don Syme of Microsoft Research about F#, a new language addition to the Visual Studio family as of VS2010, but also available as a separate download for VS2008. F# is a Functional Programming language at heart, but also has the ability to support both OO and traditional imperative styles as well, which is hugely important for interop with the other .Net languages. Don is the designer of F#, and although I went to Oliver Sturm's ACCU 2009 conference session Functional Programming in F#, I felt getting the lowdown on F# straight from the horses mouth was too good to miss. Oh yeah and a trip to the pub after to chat with fellow BCS members is always a worthy pursuit.
Don's talk lasted just under 90 mins and started by covering the background, such as the design goals; Simplicity, Economy & Programmer Productivity. The former allowed him to compare some verbose C# code and the equivalently succinct F# version. With it being a .Net language the JIT compiler should allow for efficient code generation, and the static typing also helps the IDE to use IntelliSense. Don pretty much skipped over any discussion of syntax and headed straight for the meat to show how you can write using different paradigms, giving some nice demonstrations such as graph plotting and web crawling. These also gave him a good opportunity to show how easily it interops with the rest of the .Net class libraries.
The reason I was aware of F# was because I had read an article about it in MSDN Magazine , and the pipelining and parallel processing aspects really caught my eye. Don had just enough time to take the original single-threaded web crawler example and show how it could be changed to use an asynchronous style, but without making the code unreadable, in fact there were hardly any changes at all.
I've never studied or done any Functional Programming, but this was a key theme at last years ACCU Conference [2008], and the change in hardware due to multiple-cores and NUMA architectures has prompted quite a bit of discussion around the mutability of data and it's effects on scalability. Also in this months C Vu magazine [ACCU], Andrei Alexandrescu in his article "The Case for D", touches quite a bit on this subject and explains the FP aspects of D which look very interesting. It looks like I can't ignore this area of Computer Science any longer.
Thursday, 28 May 2009
Monday, 18 May 2009
A Potted History of My Windows Framework
I thought that before leaping into a few posts about my experiences porting my Windows Framework to 64-bit Windows and GCC that I would spend a few minutes explaining how it has come to be the way it is. If you've looked at the source code to my various libraries you'll see a mixture of Hungarian & Java'ish notations, plus some MFC'isms and two different comment styles. Some parts of the framework are very old and as I only spend part of my free time on it, it is in a way, treated very similarly to commercial code - new features often come first and consequently it has accrued a significant level of Technical Debt.
The oldest parts of the code actually date back 15 years or so to my first framework which was written in C as I started my professional career writing Windows 3.x applications in C. This was the Petzold era and the code was pretty much adapted straight from his famous book - Programming Windows.
However, this version didn't last very long as I soon got back into C++ again at work and discovered the late Paul Dilascia's book Windows++. Instead of starting from scratch though, I refactored most of the C library, which was written in an OO'ish style, into classes. The code also followed the house style of their C++ framework as I was used to it.
It was still just a framework without a purpose though until I went freelancing and got my first contract. I now had a need for an application to track my hours for billing and so Task Tracker was born. The contract involved maintenance on an MFC based application and during this time I realised that it would be beneficial if I could reuse code from my framework and potential applications in my professional work. I didn't want to be tied to the real MFC framework tough - after all the point of re-inventing the wheel was to learn, so I decided to refactor my core framework to be more like MFC in style so that moving code between work and home would be easier.
It turned out to be a good move as I continued to work on MFC based code for the next 10 years and I got to reuse some of my classes like CIniFile & CPath quite a lot. During that time I read the classic Design Patterns book and tried to apply some of it to my own MVC like framework as that was the one area of code that I wasn't going to reuse outside my own apps. I also went through an "everything should be a reference" phase as I couldn't decide on how best to deal with object lifetimes.
The main thing missing from my codebase though was use of the STL which was largely down to the fact that MFC doesn't use it and so it doesn't tend to be the default choice. Also I had written my own containers because Visual C++ 1.5 had no template support (and frankly I wouldn't have known what to do with it then anyway :-) and that had created a large body of legacy code to refactor.
My last contract, which although heavily COM/ATL based, was an entirely different beast however. They used STL extensively and was beginning to use Boost for more than just shared_ptr. They also used STLport instead of the Dinkumware offering and there was little to no use of Hungarian Notation. And there was not a line of MFC code in sight! However the biggest factor was the large number of ACCU members that worked there...
After joining the ACCU, I almost went back to basics and began to discuss quite fundamental issues, like style, testing, C++ conformance, tools etc and I began to realise that my personal codebase was somewhat of an embarrassment. So I decided it was time to try and modernise it by deprecating my own containers, switching to the more lightweight Doxygen style comments, using size_t consistently, etc. The most important change though was dropping my own variation of Hungarian Notation and using the more common camelCase convention.
Structurally I have started to split off parts of the Windows C++ Library into a new base class library called Core which I hope to make reasonably platform independent. The single biggest effect of this is that std::string has now become the default string class instead of my own MFC-like CString. My new XML library is the first to take advantage of this and I hope to ensure both libraries compile with GCC as well as Visual C++.
The changes are not just in the code, but also in the way I develop it. I have written my own simple Unit Testing framework which loosely follows the xUnit style and have adopted TDD when possible whilst making changes to all the libraries. Core has the most test coverage as it is the newest and was created using TDD from the start. The other libraries are gaining coverage as and when I make changes.
So, is it worth it? I've always viewed my framework as a playground - somewhere outside of work to play around and make mistakes - but more importantly to try out new things that I hope can then be fed back into my professional career to make me more valuable to a potential employer. I'm still learning heaps every time I refactor, so I guess it is :-)
The oldest parts of the code actually date back 15 years or so to my first framework which was written in C as I started my professional career writing Windows 3.x applications in C. This was the Petzold era and the code was pretty much adapted straight from his famous book - Programming Windows.
However, this version didn't last very long as I soon got back into C++ again at work and discovered the late Paul Dilascia's book Windows++. Instead of starting from scratch though, I refactored most of the C library, which was written in an OO'ish style, into classes. The code also followed the house style of their C++ framework as I was used to it.
It was still just a framework without a purpose though until I went freelancing and got my first contract. I now had a need for an application to track my hours for billing and so Task Tracker was born. The contract involved maintenance on an MFC based application and during this time I realised that it would be beneficial if I could reuse code from my framework and potential applications in my professional work. I didn't want to be tied to the real MFC framework tough - after all the point of re-inventing the wheel was to learn, so I decided to refactor my core framework to be more like MFC in style so that moving code between work and home would be easier.
It turned out to be a good move as I continued to work on MFC based code for the next 10 years and I got to reuse some of my classes like CIniFile & CPath quite a lot. During that time I read the classic Design Patterns book and tried to apply some of it to my own MVC like framework as that was the one area of code that I wasn't going to reuse outside my own apps. I also went through an "everything should be a reference" phase as I couldn't decide on how best to deal with object lifetimes.
The main thing missing from my codebase though was use of the STL which was largely down to the fact that MFC doesn't use it and so it doesn't tend to be the default choice. Also I had written my own containers because Visual C++ 1.5 had no template support (and frankly I wouldn't have known what to do with it then anyway :-) and that had created a large body of legacy code to refactor.
My last contract, which although heavily COM/ATL based, was an entirely different beast however. They used STL extensively and was beginning to use Boost for more than just shared_ptr. They also used STLport instead of the Dinkumware offering and there was little to no use of Hungarian Notation. And there was not a line of MFC code in sight! However the biggest factor was the large number of ACCU members that worked there...
After joining the ACCU, I almost went back to basics and began to discuss quite fundamental issues, like style, testing, C++ conformance, tools etc and I began to realise that my personal codebase was somewhat of an embarrassment. So I decided it was time to try and modernise it by deprecating my own containers, switching to the more lightweight Doxygen style comments, using size_t consistently, etc. The most important change though was dropping my own variation of Hungarian Notation and using the more common camelCase convention.
Structurally I have started to split off parts of the Windows C++ Library into a new base class library called Core which I hope to make reasonably platform independent. The single biggest effect of this is that std::string has now become the default string class instead of my own MFC-like CString. My new XML library is the first to take advantage of this and I hope to ensure both libraries compile with GCC as well as Visual C++.
The changes are not just in the code, but also in the way I develop it. I have written my own simple Unit Testing framework which loosely follows the xUnit style and have adopted TDD when possible whilst making changes to all the libraries. Core has the most test coverage as it is the newest and was created using TDD from the start. The other libraries are gaining coverage as and when I make changes.
So, is it worth it? I've always viewed my framework as a playground - somewhere outside of work to play around and make mistakes - but more importantly to try out new things that I hope can then be fed back into my professional career to make me more valuable to a potential employer. I'm still learning heaps every time I refactor, so I guess it is :-)
Friday, 1 May 2009
Who is the ACCU?
Some diligent readers may have noticed that I described Matthew Wilson as "a fellow ACCU member" and are wandering what the ACCU is. Well it's not some kind of secret religious cult - on the contrary they also allow mere mortals like me and you to join! Rather than screw up the possibility of recruiting new members by trying to succinctly describe what the ACCU is about I'll leave it to the front page of the ACCU website (http://accu.org/):-
"ACCU is an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming."
Once upon a time the "CC" in ACCU stood for C/C++, but these days it is far more diverse. In one of the Lightning Talks at this years ACCU conference (http://accu.org/index.php/conferences/accu_conference_2009) there was a straw poll on the primary language used by the attendees and there was a considerable show of hands for Java and C#. Python also features quite regularly on "ACCU-General" which is the organisations main mailing list.
I'm a relative newcomer to ACCU (I only joined in 2006) and came to find out about it by working at one of the major investment banks that has quite a few members in its ranks. I was lamenting the loss of CUJ (The C/C++ Users Journal) and asked on the internal chat system where I was going to get my [printed] fix of C++. I was told that the ACCU publishes two journals, C Vu and Overload which are packed with top quality articles about all aspects of software engineering amongst other benefits. I thought I'd try it for a year and see how it pans out. I only wish I'd known about it when I started my career back in the early 90's!
At £35 per year, membership is cheaper than a subscription to CUJ, MSDN Magazine, TechNet etc. and in return you get a journal per month of quality articles, but more importantly, you get access via the mailing lists to some really smart cookies.
The highlight of the year is probably the ACCU conference, which is held in Oxford during April. This is 4 days of high-bandwidth communication with such luminaries as Andrei Alexandrescu, Nicolai Josuttis, Robert Martin, Kevlin Henney etc. During the day you listen to various speakers talking about all sorts of aspects of software engineering, but more importantly, during the evening (and most of the night :-) you get to speak to many of them one-to-one over a pint or two in the bar. Of course you also get to meet a whole bunch of other like minded souls and share experiences with them as well.
If you're still unsure that your £35 buys you excellent value for money, you can view back issues of Overload online here - http://accu.org/index.php/overloadonline.
See you soon on "accu-general"...
"ACCU is an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming."
Once upon a time the "CC" in ACCU stood for C/C++, but these days it is far more diverse. In one of the Lightning Talks at this years ACCU conference (http://accu.org/index.php/conferences/accu_conference_2009) there was a straw poll on the primary language used by the attendees and there was a considerable show of hands for Java and C#. Python also features quite regularly on "ACCU-General" which is the organisations main mailing list.
I'm a relative newcomer to ACCU (I only joined in 2006) and came to find out about it by working at one of the major investment banks that has quite a few members in its ranks. I was lamenting the loss of CUJ (The C/C++ Users Journal) and asked on the internal chat system where I was going to get my [printed] fix of C++. I was told that the ACCU publishes two journals, C Vu and Overload which are packed with top quality articles about all aspects of software engineering amongst other benefits. I thought I'd try it for a year and see how it pans out. I only wish I'd known about it when I started my career back in the early 90's!
At £35 per year, membership is cheaper than a subscription to CUJ, MSDN Magazine, TechNet etc. and in return you get a journal per month of quality articles, but more importantly, you get access via the mailing lists to some really smart cookies.
The highlight of the year is probably the ACCU conference, which is held in Oxford during April. This is 4 days of high-bandwidth communication with such luminaries as Andrei Alexandrescu, Nicolai Josuttis, Robert Martin, Kevlin Henney etc. During the day you listen to various speakers talking about all sorts of aspects of software engineering, but more importantly, during the evening (and most of the night :-) you get to speak to many of them one-to-one over a pint or two in the bar. Of course you also get to meet a whole bunch of other like minded souls and share experiences with them as well.
If you're still unsure that your £35 buys you excellent value for money, you can view back issues of Overload online here - http://accu.org/index.php/overloadonline.
See you soon on "accu-general"...
Subscribe to:
Posts (Atom)
