So here’s my quick review: it’s about as quiet as a baby seal being clubbed to death. No joke, it makes a loud screaming noise when the churning gets tough. Eerie. It takes up a lot of counter space, and it’s not the most aesthetically pleasing device, nor is it the most well made. The freezing unit looks pretty solid, but the motor arm, and mixing paddle are made from plastic. That said the only other device I’d consider purchasing, the Lello Musso Lussino Ice Cream Maker 4080, costs significantly more than the Cuisinart. When this one burns out I’ll probably replace it with the Lello though.

Having said all that, I would, without hesitation, recommend the 50BCC to anyone. There’s a markedly clear division in my life: there’s my life as it was prior to owning an ice cream maker, and there’s my life as it is now. It’s hard to describe what it’s like, but the best I can come up with is this: it’s like having a garden, only instead of the garden being made of dirt it’s a metal cube, and instead of growing plants, the end result is a sweet, creamy, cold, nectar of the gods, set to the tune of whatever your brain and tastebuds can come up with. Honestly now I look at every ingredient and wonder about its suitability for inclusion into an ice cream. Pickles: considered it, rejected it. Cayenne pepper: considered it, have a plan for it. Peas: considered it, unsure about it.

And similar to having a garden, with each mouthful of god nectar you can smile in the smug satisfaction of being able to stick some xantham gum up the ass of some douchebag corporate foodie in one of the many tiny pointless towns called Exploitedville, USA. Go ahead, club a baby seal. Not only will you not hear it because your 50BCC will be screaming like a banshee, but you’ll have plenty of good food karma to spare. I wonder: baby seal ice cream? Wrong, just wrong.

Have you ever taken a close look at what happens when grocery store ice cream melts? Have you ever wondered why ice cream from the store is kind of “fluffy?” Let me assure you that the weird liquid separation you see when it melts, and the fluffy texture are in no way natural. Modern ice cream barely qualifies as ice cream at all. In fact, most commercial ice creams are solidified through the use of various viscous compounds. The most common is Xantham gum, which if produced in North America, is almost certainly derived from corn. Even “all natural” ice creams will often include guar gum, or “natural tara gum”. Yes tara gum is made from a plant, but no it’s not natural. It’s also used for killing insects and in creating leather for furniture. So when buying ice cream it’s your choice: corn or insect free leather. Mmmm… tasty couch!

The only exception I’ve been able to find is good ‘ol Häagen-Dazs. The downfall to the Dazs, as I can attest to, is it comes in small packages and is quite expensive. Not only that but the flavor selection is a bit limited.

And, now that I have an ice cream maker, I can say that Dazs isn’t even that good. Even some of my “failed” creations are leaps and bounds ahead of Dasz in terms of both texture, and flavor. Did you know that real French Vanilla ice cream is made with custard? I do now, because I’ve made it, and although it’s quite a bit different than the so called “French Vanilla” you can buy in the store, it’s also much, much, better. Seriously they put some egg ingredients in there, along with some yellow colouring, and call it French Vanilla.

I should also give a warning: I used to pretend this blog was mostly devoted to technology and computer science related topics, but likely for the next while it will be devoted mostly to ice cream recipes .

On that note I’ll end with a killer recipe I came up with today. I previously made a Peanut Butter and Banana ice cream, but today I made two batches, one of peanut butter, and another of banana. They both turned out awesome, but the PB was the star for me. Of course they compliment each other well. But anyway, here’s the Peanut Butter:

Ingredients:

1/4 to 1/2 cup Peanut Butter to taste (choose your favorite kind, I used a creamy variety because I like creamy ice cream)
1 cup heavy cream
1 cup table cream
1 cup whole milk
1/2 cup organic granulated sugar

Directions:

Put the sugar, peanut butter, and milk in a sauce pan and slowly heat the mixture until the peanut butter is dissolved. Transfer it to a mixing bowl and whisk it until the sugar is dissolved (if it isn’t already), put it in the freezer and wait for it to be cold again. Mix in the creams, and you’re good to go!

The hardest part is getting the PB ratio correct. The taste changes a bit during the freezing process, it gets a little less potent, so keep that in mind. I started with ~1/4 cup but when I added in the creams I realized it wasn’t going to have the punch I wanted, so I added in another few spoon fulls. I was too lazy to reheat the mixture, so the newly added PB gave the ice cream some interesting flaky bits which I actually kind of like. I might make it like that on purpose again next time.

Up until the 4.0 release I had become an avid KDE user. Like most people, however, I was pretty dismayed at their choice to tag a feature incomplete, and horribly buggy release as 4.0. Yes they did come out and say it wasn’t ready for mass consumption yet, but they pretty much blew it by tagging it as 4.0, when really it was an early, early beta, or perhaps an alpha release — I won’t go on about since it’s already been discussed to death. KDE 3.5 held up fairly well for a while, but eventually Gnome surpassed it in terms of features, stability, and it remained lightweight yet had nice integration with Compiz, meaning I could still appease my inherent fascination with shiny things. So, I begrudgingly left KDE behind.

And now, KDE 4.2 is here, which is being touted as “The Answer” to all the critics. So is it?

First let me say that it really is a great release. It’s what a 4.0 beta should have been. It’s [mostly] stable, and [mostly] feature complete in comparison to 3.5. The new API changes are awesome — it’s an absolute joy to develop for. It’s got a solid foundation, and what they’ve built from it really is a technical achievement — they should be proud of their efforts. All the KDE4 applications have a consistent UI feel, and they all work in exactly the way you’d expect with regards to things like some of the more advanced drag ‘n drop features that OS X has supported for years (and that Microsoft still hasn’t caught on to).

My favorite thing: its window management is absolutely top notch. I thought nothing could beat Compiz, but the new KWin is pretty much perfect. It strikes a great balance between configurability and simplicity. The average user will never know 90% of the things it can do, but for those picky people among us it offers things like: an excellent focus-follows-mouse implementation, the ability to be able to easily set individual windows as on-top or below-others, and the ability to disable or enable window decorations on case by case basis, and that’s just for starters. KWin does everything I want, and more, yet it doesn’t suffer from the insane configuration and menu nightmare that is the Compiz configuration tool.

All that being said, my answer to the question is still a definitive “no”. KDE 4.2 is not The Answer. I am back in Gnome right now due to bugs. I really like konsole but the toggle that disables the menubar does not work, nor does the toggle that disables blinking text. There’s still no native network manager for those with wireless connections. The list of, admittedly minor, complaints goes on at length, and while none of them are a really big deal on their own, as a whole they leave me with a bad aftertaste in mouth… a taste that is reminiscent of an x.0 beta release, and not a .2 release.

However, this release does at least give me hope. I have faith in the KDE developers, and believe that their cause is a good one and a worthy one. They’re creating an excellent new foundation for what should become a consistent and unified interface experience — something Linux has sorely been lacking since the great KDE and Gnome divide began.

Prior to a couple weeks ago I had never played with Qt, and I actually had sort of a negative opinion of it. I had known that it required this extra compilation step where it preprocessed C++ source files for some reason… but I’ll back get to that soon — for now I’ll just say I thought it was silly because I didn’t understand it. The other thing I thought was that Qt was just a widget toolkit for building GUI applications.

I was wrong. On both accounts. First of all Qt is so much more than just a GUI API. It’s an amazingly well designed collection of classes for building robust cross-platform apps. Example, the QString class is so much more useful than std::string. It has built in support for all types of unicode strings, and has a ton of handy functions and operators available. Memory management is also really well done in Qt — you can often “new and forget”. It has a high performance computing API that includes out of the box support for things like Map-Reduce, job scheduling, futures, etc. I could go on and on, but suffice to say, Qt is another tool I’m really glad to put into my toolbox right next to Boost.

As a quick aside, before getting to my actual point, I’d like to mention Nokia’s recent acquisition of Trolltech (the company responsible for Qt), and their decision to LGPL the library. I think that this is probably the greatest thing that has happened to Linux, since the Linux kernel itself, and perhaps the GNU tool collection. I honestly can’t see why any developer would continue to support and use Gnome now that Qt is LGPL’ed, and you can use it to write cross-platform apps that use native widgets on Mac, Windows, and Linux. Competition is usually good, but not when it comes to competing desktop widget sets.

Alright, my actual point, and the thing that inspired me to post about Qt in the first place: the MOC. Qt’s Meta Object compiler. What it does is preprocess a C++ header and build another header out of it that you then include into your source file along side the original header. This preprocessing step gleans all of the information from your class(es) and puts it into a format digestible at runtime. Qt has kindly wrapped this up into a nice meta object system that stems from the QMetaObject.

Essentially what they’ve done is given reflection to C++. If you’ve ever programmed in languages like Python, Ruby, Objective-C, C#, or Java, and friends, you know how awesome and useful reflection is. With Qt’s MOC system you can do many of the neat things in C++ that you can in dynamically bound languages. You can enumerate all the methods of a class, and then invoke them via a string representation of their function name. You can dynamically cast to and from super-classes (again, via a string), or iterate over an object’s class hierarchy — all at runtime! It’s awesome. Really awesome.

But, does this extra MOC step require some insane build system? Well, fortunately no! Thanks to the KDE project having adopted CMake as their build system they’ve created all the necessary build scripts for using Qt in your project. You just do your build setup like you normally would with CMake, include the Qt CMake module, which automatically detects the Qt libraries, and sets up support for automoc’ing your source files.

And while I’m on the topic I might as well say a few words about Qt as a GUI library. I’ve use quite a few GUI APIs in my day: everything from raw WIN32, to MFC, and .net’s WPF (Windows Forms), Cocoa and Carbon, WxWidgets, GTK, TK, AWT, Swing, and there’s probably a few others in there that I’ve [likely thankfully] forgotten [or repressed].

In the past, I’ve never really been impressed by a GUI API before. Cocoa is the one I’ve used the least, but I was definitely impressed by it — that being said it’s sort of wrapped up in the Objective-C way of doing things, which isn’t necessarily bad, but it’s a bit more difficult to evaluate on its own because of that fact. Windows Forms is also relatively well done, but nothing to write home about. And the rest are just plain awful. With the shining star being Qt.

When I created my first Qt GUI (through the help of Qt’s excellent GUI designer) I was extremely happy. I’ll be the first to admit that I hate GUI programming, but let’s face it, every once in a while you do need an app with a GUI, and Qt takes all the crap work out of GUI programming. There’s almost never a need to write code that resizes widgets when you resize your application’s window (they have a well thought out Layout system), and the whole process of designing a GUI and including it in your app is very well done.

The GUI designer creates a nice human readable XML file that you can either have your CMake build system auto-process for you and produce C++ code that you merely include into your project, or you can use the Qt library to dynamically load and process the UI XML files at runtime. Who doesn’t want their users to be able to change your GUI around in whatever twisted ways they want? Well okay, probably a lot of people, but at least the option is there!

All in all I give Qt a resounding thumbs up. I will probably use it in every spare-time project I do from now on, even non-graphical ones, just because I think the API is that good — Qt really has given C++ a gift with their meta-object system. And now with Nokia’s support and LGPL goodness, there’s finally no reason not to use Qt.

First of all the good: the bottom line is, D is a great little language, and I say little because in many ways it’s a lot simpler, and less complicated than any of the other system level object-oriented languages that it competes with (C++). This doesn’t mean that D is any less valuable though — in fact much the opposite. D’s inherent simplicity is by design. It’s pretty clear by looking at the language spec that the idea was to take the best elements of some languages, throw out the rest, and add some of the missing features that we all wish we had (built in strings, optional garbage collection, modern language features, etc).

And by modern language features, this is the kind of stuff I’m talking about: mixins, lambdas, variadic templates, lazy evaluation, delegates, nested functions, anonymous unions, array slicing, contract programming, handy statements. Basically, much of C++0x’s upcoming feature set, and more.

So does D deliver? The answer yes, a resounding yes in fact. In terms of core language design and features, D provides exactly what many of us have been yearning for for years — a system level language that is on par with (or better than) modern scripting languages (such as Python, and Ruby) in terms of development speed, provides the language features we all should have by now, yet compiles to native code that can be as efficient as C++.

The panacea of programming languages? Well… no, not quite. Unfortunately the story doesn’t end there.

The first problem is a major one, and I don’t want to downplay it because as it stands it’s enough of an issue that no development house could even consider D as a prospective language, but fortunately it’s something that should get better over time. The issue: compiler bugs, and plenty of them. Some of them are small, some of them are huge, but there’s enough that they add up to a serious problem.

The bugs I ran into ranged from little things like floating point printing errors, all the way to compiler segfaults. Being that D is so young and the compilers aren’t close to maturity yet, any project complex enough is basically guaranteed to run into problems with either of the existing compilers, and my thesis project was no exception. Fortunately there are two major compilers that use separate optimization paths (a frequent culprit in the official digitalmars compiler) so one at least has a contingency option, but unfortunately, they share the same front-end, so they tend to exhibit some of the same bugs as well.

There’s also some serious performance issues with both compilers. For example, if you look at the assembler output of either of the compilers you can see them doing the same wasteful, redundant memory copies when doing something simple like returning a struct from a function. The only work around to this compiler bug is to do ugly things like return values from functions using by-reference function parameters.

Take a moment to think about the case where you can’t return values from functions — design goes out the window, along with readability and maintainability, not to mention ease of porting to other languages (should the desire arise). It extends further than that though — it means, for example, using custom foreach iterators to do a simple iteration over a collection of stack allocated structs becomes so inefficient that you end up having to put regular for loops in places where they really shouldn’t be.

Basically these “little” compiler issues make it difficult to consistently employ OO design principles, and use all of the nice modern language features that made the language so attractive in the first place. And after discovering these issues, along with their associated workarounds (wasting time discovering that your program’s poor performance is due to the compiler and not your code), you’re basically left with either a slow, inefficient executable, or ugly, unmaintainable code written in a language that was specifically designed to produce clear, concise, elegant code.

It’s a terrible shame to have a few minor problems result in such broad consequences, but these issues are all things that can be fixed, and they’re not nearly as prevalent as this post makes them seem. In fairness, given how new D is, the overall stability and quality of the available compilers is actually quite impressive. The language itself shouldn’t be judged on these compiler issues, but it’s important that people who may be considering adopting D be aware that there are problems with the compilers before forging ahead.

The next big issue isn’t technically related to the language itself, but is still a problem because it’s one of the root causes of much of what’s stopping D from living up to its potential. The heart of the matter is that D is currently going through some growing pains, and project leadership isn’t keeping up with the community.

Right now the D community is split between two incompatible standard libraries (Tango, and Phobos) that offer up different design philosophies, and although the majority of the community uses one library (Tango), it’s not the official standard library. This tends to create confusion for new users, and forces people to adopt one library or another, or library designers to write and maintain two sets of sources — neither being optimal solutions.

To come back to the issue of the compiler bugs — in other projects such a situation might not be as much of an issue, but many of the compiler bugs have been sitting idle in the D bug tracker for many months, and many releases. It appears as though the project is transitioning between a small niche language, to something that might even be getting close to being considered mainstream (D is currently 12^th on the programming language popularity list, and still moving up), so it’s understandable that some project leadership issues might crop up along the way.

Regardless of how understandable these growing pains may be, it’s still something that the project maintainers, and the D user community, are going to have to deal with before the language can really take the next step in terms of public acceptance.

There’s also one final problem with the language, or rather, the upcoming D2 language spec, and as big as all the other issues are this is actually the biggest thing that’s keeping me from continuing to use D on future projects. We all know that multi-core systems are the defacto standard these days, and although we’re starting to get a handle on developing tools to help programmers deal with the almost always non-trivial task of writing parallel code, we’ve barely even scratched the surface of what compilers and runtimes can do to help regular joe-six-pack-programmer effectively, and easily, design algorithms that take advantage of today’s processors.

Given the current state of affairs in terms of SMP and distributed development, and that there’s a new revision of the D language in the works, D has a great opportunity to assert its intent to be a player in the upcoming multiprogramming language war. But nothing is in the works. The D team isn’t actively working on providing any inclusion of a modern parallel programming paradigm for D2, which means it will likely be pushed back to some future release of D. This is unfortunate, because I know a great many developers are waiting for tools to help them deal with parallel programming (even if they don’t know they are).

Aside from Erlang and other more obscure functional languages, right now C++ is still one of the best choices around for parallel development. With the resounding success OpenMP has seen in the last few years, and with C++0x on the horizon and the new OpenMP 3 being recently released it looks like C++ is going to continue to be the language of choice for most system level and computationally expensive tasks.

Neither D, nor the upcoming D2 spec, give developers anything beyond raw threading (plus some critical section synchronization and resource locking type mechanisms, along with a controversial const system), but definitely nothing in the way of a modern parallel programming methodology. It’s another unfortunate oversight that takes a language that should be an ultramodern successor to nearly all current languages in its class and puts it years behind C++, and even Fortran (both of which have OpenMP at their disposal), and let’s not even try to make a comparison to other languages like Erlang, JoCaml, Parallel Haskell, and friends.

I really wish I could recommend D as a natural successor to C++, but given all the issues it’s currently facing, I just can’t. It’s simply not there yet, and I fear, given it’s current direction, that it never will be. I still think it’s a great project, and I hope that it works out because I’d like very much to see it succeed, because I think a strong competitor to the multi-paradigm system-level language would be a great boon to the software development and computer science communities.

I’ll definitely keep watching D to see what happens in the future, but I likely won’t be using it for any more projects until they can iron out the compiler stability and efficiency issues, and implement some reasonable multiprogramming method.