Karl Seguin

August 2007 - Posts

• Good Programmers Micro Optimize

  Programming is too delicate a task to heavily rely on generalisms. Even at the relatively high level of programming we do, what works in one situation isn’t guaranteed to work in another. As developers we typically lack the imagination necessary to foresee even a fraction of how real users will use our systems. This combination makes it dangerous to rely on anything but firsthand experience. Good developers must pursue their intuition and satisfy their curiosity by means of continuous experimentation. Sadly, too many developers look down on micro optimization, ensuring that curious developers never ask their performance question for fear of being ridiculed (I found a couple of newsgroup posts from years ago where someone asked about string to integer conversion and I arrogantly shot them down for asking such an insignificant question). It’s rather silly that on the one hand we fear leaky abstractions is getting the best of our community, and on the other we look down at attempts to gain greater understanding. The most cited reason against micro optimization is that clarity/maintainability/readability should trump any minor performance gains. That implies that the two concepts are mutually exclusive – which may be true in some cases, but in other cases isn’t at all (such as generics). And, much like you can’t know if something is a micro (or a macro) optimization until you try, there’s a good chance you can’t really tell the impact on maintainability until you let your creativity loose. Back to my point about generalities, and we can see how easy it is for someone not to have to try it out for themselves. There are countless blogs that praise StringBuilders as the fastest way to concatenate a string – which is true except for when it isn’t – and even more blogs that praise the superior performance of stored procedures – which is also true except when it isn’t. Blogs and bloggers aren’t to blame though. In the end, developers who sheepishly follow, perhaps because others have shamed them into not asking, are responsible for their own enlightenment. I also want to point out that when it comes to both micro optimization and premature optimization, unit tests should play a significant role in your experimentations. Properly written unit tests will ensure that an optimized version works within the same parameters as the original. TDD should embrace an addition to their red/green/refactor motto --> red/green/optimize/refactor. If you don’t optimize early and often, you’ll never understand the value and cost of those optimizations. All you’ll have to go by are general statements made by others, rather than an actual understanding of what’s happening beneath the compiler. While the Alpha Geeks are off mastering Ruby, I think I might spend some spare cycles trying to familiarize myself with MSIL.   Posted Aug 09 2007, 11:23 PM by karl with 9 comment(s)

• 4 quotes + 1 paraphrase on failure

  Success consists of going from failure to failure without loss of enthusiasm     Winston Churchill My great concern is not whether you have failed, but whether you are content with your failure     Abraham Lincoln There are no secrets to success. It is the result of preparation, hard work, and learning from failure.     Colin Powell I have missed more than 9,000 shots in my career. I have lost almost 300 games. On 26 occasions I have been entrusted to take the game winning shot, and I missed. And I have failed over and over and over again in my life. And that is precisely why I succeed.     Michael Jordan The point is, ladies and gentlemen, that failure—for lack of a better word—is good. Failure is right. Failure works. Failure clarifies, cuts through, and captures the essence of the evolutionary spirit. Failure, in all of its forms—failure for life, for money, for love, knowledge—has marked the upward surge of mankind.     Gordon Gecko (/greed/failure)   Posted Aug 03 2007, 10:11 AM by karl with 4 comment(s)

• Longest Type Name in .NET?

  This is as useless as useless posts go but.... I happen to be on MSDN the other day (via Google) and landed on a page for a type that had a mighty long name. Naturally it made me wonder: what's the longest type name in .NET? Turns out that Rob Chartier looked at this back in early 2004. But since then we've seen 3 releases of the .NET framework. For the curious (and the lazy), the longest private type in 1.1 was 86 characters long, the longest public type was 46 characters long, and the shortest public type was 2 characters long. Fast forward to 2007 and.... The longest type name is 148 characters: MessageSecurityVersion+WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10MessageSecurityVersion  The longest public type FULL name (w/namespace) is 89 characters: System.ServiceModel.Install.Configuration.ServiceModelConfigurationSectionGroupCollection The longest public type name is 53 characters: ListViewVirtualItemsSelectionRangeChangedEventHandler Much like in 1.1, the shortest public type name is still SR (found in various namespaces), and the short private type is  a single letter (I found "U" but there are doubtless others). Interestingly, the shortest public type full name was....System.Uri For the curious, I limited my search to: Directory.GetFiles("c:\\windows\\assembly\\GAC_MSIL\\", "System*.dll"     Posted Aug 01 2007, 08:18 PM by karl with 4 comment(s)