Kant's Critique of Judgment, also know as the Third Critique since it follows the first on Reason and the second on Morals, is a masterpiece in the philosophy of aesthetics.  With careful reasoning, Kant examines the experience of aesthetic wonder, The Sublime, and attempts to relate it to the careful delineations he has made in his previous works between the phenomenal and noumenal realms.  He appears to allow in the Third Critique what he denies us in the First: a way to go beyond mere experience in order to perceive a purpose in the world.  Along the way, he passes judgment on things like beauty and genius that left an indelible mark on the Romanticism of the 19th century.

Taste, like the power of judgment in general, consists in disciplining (or training) genius.  It severely clips its wings, and makes it civilized, or polished; but at the same time it gives it guidance as to how far and over what it may spread while still remaining purposive.  It introduces clarity and order into a wealth of thought, and hence makes the ideas durable, fit for approval that is both lasting and universal, and hence fit for being followed by others...

Kant goes on to say that where taste and genius conflict, a sacrifice needs be made on the side of genius.

in his First Critique, Kant discusses the "scandal of philosophy" -- that after thousands of years philosophers still cannot prove what every simple person knows -- that the external world is real.  There are other scandals, too, of course.  There are many questions which, after thousands of years, philosophers continue to argue over and, ergo, for which they have no definitive answers.  There are also the small scandals which give an aspiring philosophy student pause, and make him wonder if the philosophizing discipline isn't a fraud and a sham after all, such as Martin Heidegger's Nazi affiliation.  Here the question isn't why he didn't realize what every simple German should have known, since even the simple Germans were quite taken up with the movement.  What leaves a bad taste, however, is the sense that a great philosopher should have known better.

A minor scandal concerns Immanuel Kant's infamous lack of taste.  When it came to music, he seems to have a particular fondness for martial music, das heist, marching bands with lots of drumming and brass.  He discouraged his students from learning to actually play music because he felt it was too time consuming.   We might say that in his personal life, when his taste and his genius came into conflict, Kant chose to sacrifice his taste.

I think I will, also.  In Rock Band, the drums are notoriously the most difficult instrument to play well.  It is also the faux instrument that most resembles the real thing, and it is claimed by some that if you become a good virtual drummer, you will also in the process become a good real drummer.  I've tried it but I can't get beyond the Intermediate level.  I can sing and play guitar on hard, but the drums have a sublime complexity that exceed my abilities to cope.  With uncanny timing Wired magazine has come out with a walkthrough for the drums in Rock Band (h/t to lifehacker.com).  It mostly concerns working with the kick pedal and two alternative techniques, heel-up and heel-down (wax-on/wax-off?) for working with it.  It involves a bit of geometry and a lot of implicit physics.  I would have liked a little more help with figuring out the various rhythm techniques, but according to wired, I would get the best results by simply learning real drum techniques, either with an instructor or through YouTube. 

I wonder what Kant would say about that.

Can a sequel be better than the original?  With movies this is usually not the case, though we are all holding our breaths for the new installment in the  Indiana Jones franchise.  Technical books, however, are a different matter.  They have to be updated on a regular basis because the technology changes so rapidly.  My bookshelf is full of titles like Learning JAVA 1.3  and Professional Active Server Pages 2.0 which, to be frank, are currently useless.  Worse, they are heavy and take up a lot of room.  I've tried to throw them away, but the trash service refuses to take them due to environmental concerns, and there isn't a technical books collection center in my area.  In Indiana Jones and the Last Crusade (made before the word "Crusade" got a bad rap) there is a comic scene of a book burning in Berlin, and though I am not in favor of book burnings in general -- you'd think we would have learned our lesson after the Library of Alexandria burned down -- still, occasionally, I dream of building a bonfire around COM Programming for Dummies and its ilk.

Scott Hanselman recently posted asking about the great technical books of the past ten years, and one of the titles that came up repeatedly is Bill Wagner's Effective C#: 50 Specific Ways to Improve Your C#.  The book is great for .NET programmers because it goes beyond simply explaining how to write Hello, world! programs, but instead tries to show how one can become a better developer.  The conceit of the book is simple.  For each of his 50 topics, he explains that there are at least two ways to accomplish a given task, and then explains why you should prefer one way to the other.  In the process of going through five or six of these topics, the reader comes to realize that what Bill Wagner is actually doing is explaining what makes for good code, and when both paths are equally good,what makes for elegant code.  This helps the reader to form a certain habit of thinking concerning his own code.  The novice programmer is constantly worried about finding the right way to write code.  The experienced programmer already knows the various right ways to do a given task, and becomes preoccupied with finding the better way.

The way I formulated that last thought is a bit awkward.  I think I could have written it better.  A semicolon is probably in order, and the sentences should be shorter.  Perhaps

The novice programmer is preoccupied with finding the right way to perform a task; the experienced programmer knows that there are various right ways, and is more concerned with finding the most elegant way.

or maybe

The novice is preoccupied with finding the right way to get something done; the expert is aware that in programming there are always many paths, and his objective is to find the most elegant one.

Alas I am no Le Rochefoucauld, but you get the idea.  This is something that prose writers have always considered a part of their craft.  Raymond Queneau once wrote an amazing book that simply takes the same scene on a bus and reformulates it some fifty times.  Perhaps Amazon can pair up Bill Wagner's Effective C# with Queneau's Exercises in Style in one of their "...or buy both for only..." deals, since they effectively reinforce the same point in two different genres, to wit: there is no best way to write, but there is always a better way.

If you do get on a Queneau kick, moreover, then I highly recommend this book, a pulp novel about Irish terrorists, which has a remarkably un-PC title, and for which reason I am not printing it here.  I assure you, the contents are better than the title.

The only shortcoming of Bill Wagner's book is that it was written for C# 1.0, while we are currently at iteration 3.0.  It is still a remarkably useful book that has aged well -- but alas, it has aged.  It was with great excitement, then, that I read on Bill's blog that he is currently working on a title called More Effective C# available for pre-order on Amazon and as a Rough Cut on SafariBooksOnline. 

The current coy subtitle is (#TBD) Specific Ways to Improve Your C#. To fulfill the promise implicit in the book's title, More Effective C#, doesn't the final #TBD number of Specific Ways have to be at least 51?

I recently came across some interesting code in Juval Löwy's Programming WCF Services and wanted to share.  It's simply something I had never run across before:

            IMyContract proxy = new MyContractClient();

            using (proxy as IDisposable)

            {

                proxy.MyMethod();

            }

The first thing to notice is that the proxy object is instantiated outside of the using block.  I don't think I've ever actually tried this, but it is perfectly permissible (if not recommended).  I used a dissembler to look at the IL this generates, and it is pretty much the same as instantiating the proxy object inside of the using brackets.  The main difference is that in this case, the scope of the proxy object extends beyond the using block.

Within the using brackets, this code casts the proxy object to the IDisposable interface so the Dispose method will be available.  Since a Using Block is basically syntactic sugar for a try-catch-finally structure that calls an object's Dispose method in the finally block, the equivalent try-catch-finally block would look like this:

            IMyContract proxy = new MyContractClient();

            try

            {

                proxy.MyMethod();

            }

            finally

            {

                ((IDisposable)proxy).Dispose();

            }

However, Juval's using statement does one additional thing.  It also checks to see if the proxy object even implements the IDisposable interface.  If it does, then the Dispose method is called on it.  If it does not, then nothing happens in the finally block.  The equivalent full blown code, then, would actually look something like this:

            IMyContract proxy = new MyContractClient();

            try

            {

                proxy.MyMethod();

            }

            finally

            {

                IDisposable disposable = proxy as IDisposable;

                if (disposable != null)

                {

                    disposable.Dispose();

                }

 

            }

... and we've condensed it to this ...

            IMyContract proxy = new MyContractClient();

            using (proxy as IDisposable)

            {

                proxy.MyMethod();

            }

It's probably not something that will come up too often, but if you have a situation in which you do not know whether an object implements IDisposable or not, but still want to implement a using block for readability and good coding practice, this is how you would go about doing it.  

Besides Juval's proxy example, I can imagine it coming in handy when dealing with collections in which you don't necessarily know whether all of the members of the collection implement IDisposable, for instance:

            foreach(IDog dog in myDogsCollection)

            {

                using (dog as IDisposable)

                {

                    dog.Bark();

                }

            }

It also just looks really cool.  h/t to Bill Ryan for pointing this out to me.

The seventh day of any project should always be devoted to rest and reflection.

There is a passage from James Watson's account about discovering the structure of DNA, The Double Helix, in which Watson decides that he wants to study X-ray crystallography (the technique that eventually leads to the discovery of the double helix structure).  He is told by an authority that because the field is so new, there are only five papers on the subject worth reading -- five papers to read in order to master an entire field of science!

This is also the current state of Silverlight development.  The final framework is not yet out, the books are still being written as authors hedge their bets on what will be included in the RTM of Silverlight 2.0, and there are no best practices.  Moreover, Silverlight development is so different from what has gone before that no one has a particular leg up on anyone else.  The seasoned ASP.NET developer and the kid fresh out of college are in the same position: either one can become a master of Silverlight, or simply let it slide by and work on other things instead.

So is Silverlight worth learning?  It basically fills in two pre-existing development domains.  One is Flash, and the other is ajax web sites.  It can improve on ajax web sites by simply having a simpler programming model, and by not being dependent on Javascript (as of the 2.0 beta realease) which tends to be brittle.  The update panel in ASP.NET Ajax and the Ajax Control Toolkit have made component based programming of ajax web sites easier, but if you ever read the Microsoft Ajax web forums, you'll quickly see that it still isn't easy enough, and people supporting sites that have been up for a year are starting to come forward with their maintenance nightmares.  The introduction of the Microsoft MVC framework raises further questions about whether the webform techniques that so many Microsoft-centric web developers have been working with will continue to be useful in the future. 

Silverlight, in some sense, competes with Flash, since it is a web based vector graphics rendering framework.  It is more convenient than Flash, for many developers, since it can be programmed in .NET languages like C# and VB, rather than requiring a proprietary language like ActionScript.  Even better, it does something that Flash does not do easily.  Silverlight talks to data, and it does so without requiring an expensive server to make this possible. 

When you are thinking about Silverlight, then, it is appropriate to think of a business application with a Flash-like front-end.  This is what it promises, and the technology's success will rise or fall on its ability to make this happen.

So if you believe in this promise with, say, 65% to 75% conviction, then you will want to learn Silverlight.  There are currently about 5 articles worth reading about it, and they can all be found here.  Most other tutorials you will find on the Internet simply deal with bits and pieces of this information, or else try to pull those bits and pieces together to write cool applications.

But after that, what?  The best thing to do is to start writing applications of your own.  No company is likely to give you a mandate to do this, so you will need to come up with your own project and start chipping away at it.  The easiest path is to do try to copy things that have gone before, but with Silverlight, to see if it can be done.  Many people are currently trying to write games that have already been written better in Flash.  This is a great exercise, and an excellent way to get to know the storyboard element in XAML.  It doesn't really demonstrate any particular Silverlight capabilities, however.  It's pretty much just an "I can do it, too" sort of exercise. 

A different route can be taken by rewriting an data aware application that is currently done in Winforms or ASP.NET AJAX, and seeing what happens when you do it in Silverlight instead.  Not as cool as writing games, of course, but it has a bigger wallop in the long run.  This will involve getting to know the various controls that are available for Silverlight and figuring out how to get data-binding working.  (Personally, I'm going to start playing with various interactive fiction frameworks and see how far I can get with that.  It's a nice project for me in that it brings together both games programming (without fancy graphics) and data-aware applications.)

Finally, after getting through the various Microsoft materials and reading the various books from APress and Wrox and others that will come out shortly, where does one go to keep up with Silverlight techniques and best practices?

• Brad Abrams is blogging about it
• As is Jesse Liberty
• As is Scott Guthrie
• As is Scott Hanselman
• Method ~ of ~ failed by Tim Heuer is a great site for Silverlight apps and tutorials
• And so is http://www.adoguy.com/ by Shawn Wildermuth
• You also can't go wrong checking out something called Silverlight Games 101

Warning: there is a bit of profanity.  I'm warning you because profanity is obviously worse than being compared to Adolf Hitler.  On the other hand, sometimes dirty words can be as funny as logical fallacies -- and so can Hitler.