NullPointerFactory

Still at NFJS, and even when I go home, I keep thinking about Neal Ford’s keynote that I railed about a couple of days ago. So maybe complexity, or at least complexity that is not related to problems we’re trying to solve (”ceremonial” complexity, as Neal calls it), isn’t costing us jobs. But is it costing us sleep? nerves? I don’t think I, or anyone else, could disagree that “ceremonial complexity” is the enemy… and then I think back to another talk by Neal Ford during the conference, and his mention that the “new languages” are not about static typing vs. dynamic typing… it’s “ceremony vs. essence”. Neal uses Scala as an example (one that is, sadly, unfamiliar to me) of a static language that provides power without ceremony. This I can live with - static typing isn’t the enemy. Ceremonial complexity is.

So the question is, do we need to brush aside static typing, simply because its greatest harbinger, Java, appears to many to be beyond saving? For me personally, it’s just too great a feature to sacrifice. And more importantly, there’s no need to. There are currently several different proposoals for closures in Java, and reasonable hope to see them someday. C#’s delegates already offer something in that spirit, albeit in a slightly more verbose incarnation. C# 3.0’s lambda expressions go a long way in trimming the fat.

There are other features of C# that resemble those of popular dynamic languages. C# 3.0’s extension methods let you add methods to existing classes, even if they’re final. C# good old features, such as indexers and property go a long way in making the language less like Java and more like Groovy. But there is still more that can be done. Why not add a compiler trick where invocation of an unexistant method will call MethodMissing(string invokedMethodName, object[] arguments)… Have MethodMissing be an event on System.Object - if there’s a handler for it, with the above signature, use it! If not, puke! Let the user choose whether to puke at compile time or at runtime with a compiler switch.

There are probably holes somewhere in the preceding paragraph - I’m designing out of my a** here. But my point is, we should not give up on static languages… I know, I won’t. Having gone from Java to C#, I have seen how much can be accomplished if the driving force behind the language isn’t mired in bureaucracy.

There is probably more ranting on “ceremonial complexity” left to be done, an inquiry into how the hunt for flexibility can bring about bloat (see WebSphere) or freedom (see any language with closures). The important thing for now is that, having found a common enemy, dynamic people and static people can at last be friends.

Back from day 1 of the conference. Here’s the raw, unedited, and uncensored rant.

First the good: all the speakers I heard today were very strong. This is not to say that I agree with all of them on all counts (more on this in a bit), but rather that their delivery was effective, and their material - enlightening and/or thought-provoking. Jared Richardson’s talk titled “Build Teams, not Products,” in particular, was one of the best presentations I’ve ever witnessed. It was just one of those talks where all the points seem tautological and obvious, until you consider how many (or rather, how few) you apply to your own work. I couldn’t come close to doing the talk justice by summarizing it here - if you can, hear it for yourself.

Another striking highlight was the manner and style of Neal Ford’s keynote. Very stirring, very effective. Mr. Ford clearly graduated the Steve Jobs school of presentations with the highest honors.

Ok, that’s enough ra-ra’s for one day. The time for complaining is nigh… Mr. Ford’s keynote, since we’re already on the subject, although excellently crafted and delivered, raises questions at best. Although entitled “Ancient Philosophers and Blowhard Jamborees“, the talk can be summarized in a sentence as “WebSphere and Rational ClearCase are causing our jobs to be outsourced to Chindia… permanently”. Our industry, as Mr. Ford, would have it, is crippled by the Svengali vendors of gargantuan and deleterious middleware, that renders us unable to compete with the likes of India and China. Really, Neal, WebSphere? Is WebSphere responsible for the 32% decline in the number of Comp. Sci majors in the U.S. from 2000 to 2004? Is WebSphere the reason why Bill Gates begged Congress to increase the number of work visas to the states? Or maybe SOAP is responsible for the war in Iraq? Perhaps CORBA brought about the current recession?

Don’t get me wrong - I’m no fan of WebSphere, and I loathe ClearCase with a burning passion (ask my manager!) Yet it seems obvious to me that there are far greater factors to explain our shrinking I.T. industry than its subservience to the mean, ugly middleware vendors. Is there vendor-induced inefficiency in I.T? Sure. But no argument in Neal’s keynote demonstrates that (A) this inefficiency does not exist in “Chindia”, and (B) when the “Chindian” companies start posing a threat to their American competitors due some gap in IT efficiency, that American business won’t rise to occasion. And for heaven’s sake, if you’re going to show a cruise ship to characterize a bloated piece of architecture, use the Freedom of the Seas, not the Carnival Conquest, which is lighter by about 40,000 tons and fits about 1500 fewer passengers. Hey, I’m a cruise ship fanatic, I couldn’t help myself.

The talk on meta-programming in Groovy with Jeff Brown was quite well done, but left one major unanswered question: all these closure delegates and meta-classes - if one is not building or using an internal DSL, what do they offer that a static language does not? The ability to stick a parameter into a method name instead of an argument? Don’t get me wrong - I really like Groovy, including the metaprogramming features. What angers me is seeing a couple of features that are useful within one specific domain (DSLs) touted as the death knell for Java, C# and the like… with a few compiler tricks and reflection/emission constructs, a static language could satisfy most meta-programming needs. C# 3.0 is well on the right path.

But just so I don’t end on a negative note, there’s one more thing that really impressed me today: the dessert selection at dinner featured these incredible soft brown pastries that I have so far seen in only three palces: Russia, Russian stores in the U.S., and on the M/S Noordam. Sampling them again today was a true pleasure.

To be continued…

It’s no secret that fewer Americans these days are going into math/science professions. Sure, we can blame, at least in part, off-shoring. But perhaps, and to a greater extent, we can blame the media-propagated “geek” imagery - the skinny, socially inadequate males who spend friday nights alone reading the code to the Linux kernel or something… Just for once I’d like to turn on the TV (if I had one) and see a computer geek shaped like Brad Pitt, or better yet - Angelina Jolie, shouting technobabble while riding the latest sports car with two highly appealing representatives of the opposite sex under each arm.

Instead, all we get is more of this:

I had this unpleasant situation a few days ago: a colleague, in process of making a fix, decided to rename some utility methods to better reflect their behavior. An admirable intention, but in the process, he had to modify around thirty different classes to reflect the naming change and broke every branch and local checkout that existed. He believes he did nothing wrong. I disagree. His mistake, as I consider it, is indicative of a tempting but fallacious notion of “our code” or “internal code”.

Look at it this way: If you were making a public API, say an XML parser, that was used by multiple third parties, would you make non-backward compatible changes to it and expect your users to accomodate? Would you rename public methods/fields/properties? Would you substantially alter their purpose or behavior?

Within just about any non-trivial code base, especially an object-oriented one, similar pieces of code soon emerge, even if they are not visible to third parties. Common data structures, utilities, even plain old beans that store configuration information - all of these things are examples of “Internal APIs”. An internal API is any piece of code that gets used in more than one nugget of functionality. Like their public counterparts, internal APIs require thorough design and dillidgent change management. If a member needs to be renamed, it is not enough to change the name - the deprecated name (clearly marked and documented as such) still has to be supported.

Changing behavior of members is tricker still… if a change introduces materially new behavior (rather than fixing bugs/quirks on existing behavior), the new behavior needs to come under a new name that clearly describes it… I would argue that even when all references to old behavior now merit the use of the new behavior, the new behavior needs to be a separate member unto itself - the act of updating all the code and tests that exercise the old behavior becomes the act of explicit confirmation that no assumptions of old behavior are present. Any invocation of an API member (internal or external) introduces coupling by assumption where the calling code makes an assumption of what the API call will provide. If the API behavior changes, the name has to change too, so that these old assumptions are forcibly and explicitly disclaimed.

Microsoft has announced it’s giving away Windows Server, Visual Studio, and a bunch of other development tools to all students for free. Big news, right? Naaaaahhhh. Guess what, Microsoft has been giving students software for free for ages. Except they didn’t call it “DreamSpark”, they called it “Piracy”. A student who wanted to learn visual studio, or play with the latest server OS could easily download it through a university’s broadband network or borrow a disk from a techie dormmate. But Microsoft & company never went after disk-swapping students with the bloodhungry zeal often observed with RIAA or MPAA… No… Microsoft counted on them. It always stood to benefit from a “get’em while they’re young approach”- if they get used to developing on and for Windows in school, they’ll seek out jobs that will utilize and expand these competencies. (more…)