January 2008 - Posts
Back in the pre-Facebook era, there was a certain political figure who has accused of suddenly dressing in earth tones on the request of an advisor who thought that these muted colors were reassuring to audiences. This plan, especially after it was revealed, did not have the desired effect.
However, code is by nature easier to dress up than a person. And with the .NET Parallel Extensions, released as an add-on to the 3.5 .NET Framework as a CTP in December, Microsoft is attempting to take the edge off of threads by clothing them in an extra layer of reassuringly subdued abstraction.
This weekend, I attended a session of the SoCal Rock & Roll Code Camp at Cal State Fullerton about these newly released extensions. The presenter, Rinat Shagisultanov, gave a quick overview of what was in the extensions, as well as some working examples. There is a lot in there, so check it out yourself for all the details, but what really stuck out to me was a point Rinat made early in the session. To paraphrase, his point was that Microsoft already gave us the Framework with its threading capabilities and this extension did not change this, rather it gave us some nice building blocks on top of the existing Framework to make writing the code less intimidating.
The curious might ask, like what? The most basic example would be the addition of the Parallel.ForEach construct , which can be used to quickly transform a strictly sequential execution path into a parallel one. This construct gets a little more complicated when you are actively working with shared state, but the basic idea is that the Parallel Extensions spins out a thread for each core and distributes the work between the cores without you having to write the plumbing code. There is also PLINQ (Parallel LINQ) for querying objects in parallel, as well as the Task, Future and TaskManager objects which allow for finer grained control of the distribution of items of work in parallel. (1)
I won't get any further into the details of the API's at this point (although perhaps I will in a later post) because I want to return to the idea these extensions are really less intimated or earth toned threads. Threads could use the help, as they are pretty universally regarded as one of those "hard" topics in programming.
Lots of programmers cringe when they see code in an application that starts spinning out threads. They begin to imagine the nightmares of debugging seemingly random errors and designing the appropriate access schemes for shared memory. It is somewhat a badge of honor to brave the depths of multi-threading and come out with an application that is reasonably stable.
If threads are to be one of the prime mechanisms for parallelism and the importance of parallelism is increasing with multi-core machines, isn't it bad that they are perceived to be so difficult and obtuse? One answer to that question is that they are not really all that hard and most programmers are just stupid. I call this the unintentionally dismissive guru stance; once you've figured something out, you cannot really remember how hard it was for you to do it.
Another answer is that they are hard, but that's OK, because threads are too powerful and dangerous for the average programmer. This is the intentionally dismissive grizzled vet stance; you've earned your stripes working on multi-threaded applications and you don't need some newbie bumbler coming along and fouling things up.
The answer that Microsoft has given with the Parallel Extensions is yes, threads hard and yes that's a problem, so here's some tools that give you a chance to get the parallelism you want (using threads under the covers), but only dive as deep into the intricacies of the threads as you absolutely have to. I call this the populist approach; give something to the masses (even if it's not perfect), at the possible expense of being looked down upon by the elite.
I have not gotten a chance to dig deep into the Parallel Extensions yet, but apparently it is due to be incorporated into the next base distribution of the Framework and what I have seen looks really promising. These extensions, especially when you deal with shared state, will still open up some dangerous traps for the unwary, but they lower the bar for entry and provide some nice base abstractions to work with. In fact, coupled with WCF services, you can see the outline of a .NET grid computing architecture with multi-threaded services distributed across multiple machines pretty easily out of the box. (2) So do yourself a favor and add this CTP to your long list of new parts of the .NET Framework to learn.
(1) Rinat gave a more comprehensive breakdown of what these different API's are and what they could be used for, so any confusion you may experience in reading my description is of my own doing. The slides and code he presented in the session are on his blog at: Code Camp, Fullerton, CA Jan 2008: Concurrent Programming in .NET (Parallel FX)
(2) Some would actually argue that you should not really use multi-threading paradigms anywhere for concurrency; everything should be based on message passing between processes and thereby avoid the problems of accessing shared memory. That is an argument I am not prepared to take on, but for a strong version of the pro-argument see the language Erlang, which is built around the principles of no-shared memory, processes and message passing.
Careful readers of this blog have probably noticed that despite working for a company that specializes in custom software development using Microsoft technologies, I have not posted much about Microsoft or .NET technologies. Instead I have focused on general software development topics, plus a smattering of exploration into non-Microsoft languages, such as Python, Ruby and Erlang.
Python, Ruby and Erlang have all been wonderful to learn about and work with, and I continue to plug away at all of them in various capacities. General topics, such as my last post about versatilists and technicians are fun ways to provoke some debate. And in general, I haven't found there to be a dearth of .NET related blogs to comb through.
Nevertheless, I wanted to venture back into the crowd to talk about what I think .NET does right (despite being too popular and widely used to ever be called "sexy"). Put simply, what .NET does right is to shift the focus away from particular language features and to the environment that the developer works within.
Let's put some meat on those bones. What I'm suggesting is that Microsoft has put a lot of effort into taking away any excuse a developer has for not creating a successful application by surrounding this developer with a vast array of supporting tools.
The first of these tools is the .NET Framework itself, an embodiment of the "batteries included" philosophy, which is composed of a giant number of classes designed to make your life easier as a developer. Than there is Visual Studio, oft criticized for its bulk, which provides you with IntelliSense (to find you way through that big framework), a web designer and a forms designer (to easily create GUI's), an nicely integrated debugger, and with some editions, a profiler, nicely integrated source control, etc. Then there is the documentation, represented officially by MSDN, which is expansive and nicely uniform. Finally, there is the community, which owing to the popularity of .NET is somewhat a self sustaining advantage in that so many people are using .NET and writing about it that a well phrased Google search is a .NET programmer's best friend.
So, as a .NET developer, a lot of the job of programming is done for you. This does not mean that developing applications in .NET is easy or for dummies. It just means that the challenges of programming in .NET usually arise not from algorithm design or harnessing obscure language features, but in finding, understanding and customizing the right set of components and tools for your particular application.
In fairness, this approach is not unique to .NET, but the .NET ecosystems size and structure puts this approach to the front and center. And like all generalizations, this one is not entirely accurate as there is a lot of creative effort being put into the .NET languages themselves. Nevertheless, I think it is accurate to state that .NET is distinguished just by how it is described, as .NET, a full environment for developing applications, not just a specific language.
Joel Spolsky had an excellent post discussing his views on restructuring CS programs in colleges to be more attractive to potential students and produce better programmers. His Bachelor of Fine Arts in Programming curriculum includes more project and software lifecycle work, plus some liberal arts classes, minus some of the more advanced theoretical topics typical to CS programs.
I love the sound of this program as I really enjoyed a similar program at my college where I took liberal arts electives and got to do a decent amount of project work my senior year (and a lot of it in a part time job during my junior and senior years). I did have to take some of the more advanced theory classes and learned from them, just not too much that I've had to apply in my everyday work.
Joel got on this topic by referencing an article in Crosstalk, the Journal of Defense Software Engineering which is revealingly titled Computer Science Education: Where Are the Software Engineers of Tomorrow?
I would sum up the article as follows: the writers use the programming language Ada for projects (presumably military related) where security and reliability are paramount. Large frameworks and external libraries are mostly useless to them in this environment. They cannot find as many recently graduated computer scientists as they would like to fill these jobs because the type of programming involved is very math intensive and low level. What is to blame for this shortage of qualified individuals?
... Java has become the most widely used language in introductory programming courses. We consider this to be a misguided attempt to make programming more fun, perhaps in reaction to the drop in CS enrollments that followed the dot-com bust.
... The result is a student who knows how to put a simple program together, but does not know how to program.
So, the authors make the opposite recommendation of Joel and suggest that CS curricula be modified to include more theory, more math, a lot of C and of course some Ada if possible.
Which one is more persuasive? Actually, they are arguing past each other. They disagree on the fundamental purpose of a CS degree. Joel wants a graduate to have a wide breadth of problem solving skills, including non-technical ones and project experience, and the Crosstalk authors would like a graduate to have a well defined and deep set of technical skills. Or to put it more simply, the argument is about whether a CS major should be a technician or a versatilist.
As a consultant for a company that takes on a wide variety of types of problems, I come down on the versatilist side of the equation. From a popularity standpoint (i.e. attracting students to a major), I also think the versatilist style as embodied by a BFA in Programming is attractive to more students than an even more technically oriented program. However, when it comes down to it, there is no substitute for good technical skills and we'll always need good technicians.
I think Joel is a little loose in his terminology in saying that:
When I said BFA, Bachelor of Fine Arts, I meant it: software development is an art, and the existing Computer Science education, where you're expected to learn a few things about NP completeness and Quicksort is singularly inadequate to training students how to develop software.
While I may not find it too appealing, the projects that the Crosstalk authors refer to definitely involve software development and I can see why they want people with absolutely excellent technical depth to develop systems for the harsh conditions of a military environment. So, I don't expect the standard CS curricula to disappear any time soon, but I hope colleges follow Joel's advice to start offering more versatilist programs to live side by side with the traditional, offering students interested in programming plenty of ways to explore that interest.
Happy New Year! As 2008 starts up, I took a brief look back over what I blogged about in 2007. From music services (still a happy eMusic customer) to Python to Erlang to Apple to lots of operating systems, I covered a diverse swath of the computing world.
While reminiscing about the past year, I identified what I think drew my interest to these topics. As a developer, I am naturally looking for the next best thing in programming languages. As O'Reilly put it in the title of a recent book, I am on the prowl for 'Beautiful Code'. As a consultant, I am looking for the best solutions for my clients. Since we mostly develop custom software applications, I am looking for 'Beautiful Applications'.
'Beautiful Code' is about algorithmic excellence and syntactical elegance. 'Beautiful Applications' are about providing great user experiences that solve the problem at hand. Often we don't have visibility behind the curtain to know if these two go hand in hand, but intuitively we expect that they should.
It is my suspicion that this intuition is wrong and is in fact a deceptive simplification; that since we've all had experience writing code for an application, we mistake this one part of an application for the whole of it. However, a simplification is not the same thing as a falsehood; code obviously has a huge effect on our applications. So while this past year I spent a lot of time looking at beautiful code and beautiful applications separately, hopefully in 2008 I can concentrate a little bit more on exploring the interplay between the two.