Last year, I wrote about making Christmas Trees in WPF using FSharp.ViewModule. At the time, I was excited being able to demonstrate how FSharp.ViewModule could make typical MVVM much more functional feeling. This year, for my F# Advent Calendar contribution, I want to demonstrate how Gjallarhorn.Binding can serve as a replacement, and help create a WPF application with a design that is clean, functional, and most importantly, simple.
This post will modernize the Christmas Tree application from last year, improving it, and highlighting the differences between a classic MVVM approach to WPF and a more functional approach. While reading through the post from last year would add context, it’s completely optional.
As my contribution to the F# Advent Calendar this year, I thought I’d write a bit about one approach I often use to create WPF user interfaces in a functional style – mixing MailboxProcessor with FSharp.ViewModule.
This post will illustrate using a pair of MailboxProcessor instances mixed with FSharp.ViewModule to construct a simple application. In the spirit of F# Advent, our application will be a small drawing application that allows us to place and decorate Christmas trees.
I have the privilege of being allowed to write the final post for the F# Advent Calendar in English. To celebrate, I thought I’d skip a technical post and end the year, and the Advent Calendar, with a brief, personal look back on 2014 and the wonderful time I’ve had within the F# community over this past year.
The slides and code from my talk on the new async language features in C# and VB.Net are now available on https://github.com/ReedCopsey/Effective-Async
Typically, I strongly recommend keeping the user interface within an application’s main thread, and using multiple threads to move the actual “work” into background threads. However, there are rare times when creating a separate, dedicated thread for a Window can be beneficial. This is even acknowledged in the MSDN samples, such as the Multiple Windows, Multiple Threads* sample. However, doing this correctly is difficult. Even the referenced MSDN sample has major flaws, and will fail horribly in certain scenarios. To ease this, I wrote a small class that alleviates some of the difficulties involved.
I participated in the Seattle GiveCamp over the weekend, and am entirely impressed. GiveCamp is a great event – I especially like how rewarding it is for everybody involved. I strongly encourage any and all developers to watch for future GiveCamp events, and consider participating, for many reasons…
Version 4.0 of the .NET Framework included a new CLR which is almost entirely backwards compatible with the 2.0 version of the CLR. However, by default, mixed-mode assemblies targeting .NET 3.5sp1 and earlier will fail to load in a .NET 4 application. Fixing this requires setting useLegacyV2RuntimeActivationPolicy in your app.Config for the application. While there are many good reasons for this decision, there are times when this is extremely frustrating, especially when writing a library. As such, there are (rare) times when it would be beneficial to set this in code, at runtime, as well as verify that it’s running correctly prior to receiving a FileLoadException.
Donald Knuth is a fairly amazing guy. I consider him one of the most influential contributors to computer science of all time. Unfortunately, most of the time I hear his name, I cringe. This is because it’s typically somebody quoting a small portion of one of his famous statements on optimization: “premature optimization is the root of all evil.”
I mention that this is only a portion of the entire quote, and, as such, I feel that Knuth is being quoted out of context. Optimization is important. It is a critical part of every software development effort, and should never be ignored. A developer who ignores optimization is not a professional. Every developer should understand optimization – know what to optimize, when to optimize it, and how to think about code in a way that is intelligent and productive from day one. Read more
C# and .NET, overall, really do have fantastic performance in my opinion. That being said, the performance characteristics dramatically differ from native programming, and take some relearning if you’re used to doing performance optimization in most other languages, especially C, C++, and similar. However, there are times when revisiting tricks learned in native code play a critical role in performance optimization in C#.
I recently ran across a nasty scenario that illustrated to me how dangerous following any fixed rules for optimization can be…
The Visual Studio team today released an update to the Visual Studio Async CTP which allows it to be used with Visual Studio SP1. This new CTP includes some very nice new additions over the previous CTP. The main highlights of this release include:
- Compatibility with Visual Studio SP1
- APIs for Windows Phone 7
- Compatibility with non-English installations
- Compatibility with Visual Studio Express Edition
- More efficient Async methods due to a change in the API
- Numerous bug fixes
- New EULA which allows distribution in production environments
Anybody using the Async CTP should consider upgrading to the new version immediately. For details, visit the Visual Studio Asynchronous Programming page on MSDN.