Friday, September 28, 2007

Code Te Ching - Verse 35

If you wish to strengthen it,
    You must certainly break it.
If you wish to sophisticate it,
    You must certainly shrink it.
If you wish to quicken it,
    You must certainly dismantle it.

Improvement is always destructive.

Thursday, September 27, 2007

Sorry for This

I don't like blogging about blogs or bloggers - the whole enterprise smacks of, oh I don't know, a chain letter. "I blog about you, you blog about me, pass it on to 10 people and you will get traffic! If you don't you'll be relegated to obscurity." You know - lots of text, no substance.

That said - I can't let gold like this pass. Bravo.

Maven Doesn't Suck, You Suck (And Maven Sucks)

There's been a lot of chatter going on the Maven user list about Maven being too hard. To some extent this is true.

As per usual, it is largely filled with whining about a particular user's difficulty with Maven, and how that is somehow reflective of the technology or philosophy. Normally I wouldn't give these bouts much credence, were it not for the fact that the same discussion has surfaced, oh, about 10 times prior with nary a resolution. Every couple months ago the same points get brought up:

  • Maven docs suck

  • Maven makes mundane tasks too complex (ie. is cumbersome)

  • Maven is only suitable for large projects

  • Maven is only suitable for small projects

Maven docs suck

True, sort of. The Maven website sucks out loud. It is cumbersome to navigate, and doesn't feel so much as being led gently through Maven the Beautiful City, as "wrassled" and "hogtied" to the back of a pickup and drug through Maven the Scattered Trash-Heap. I made a few suggestions on the list, mostly pointing out websites which are easy to navigate (Rails, Spring, Wicket) and then Maven's site. QED, methinks.

If I hear "cookbook" or "taxonomy" as the answer to Maven's documentation problems one more time I'm going to punch the first kitten I see. Set up a goddamn wiki and let people populate it with their own best practices. Stop using Confluence, because it's a pile of steaming elephant shit (A wiki with tight security and roles? No thanks). I guarantee if the front page had a giant link to a MediaWiki installation with bold letters: USER CONTRIBUTED DOCS, people would use it. Hell, I'll even do the first post.

In short my feeling is this: Maven documentation is fine, it's just freaking impossible to navigate. Most plugins are documented well, if you can find them (psst... they're here and here). Or better yet, make them searchable. When I hear "Maven docs suck!" I know what they really mean: "I Googled it and the answer wasn't on the front page!". Moreover, make a good wiki for anyone to post their problems and solutions. Finally, stop using Nabble - because it kills Google.

Maven makes mundane tasks too complex (ie. is cumbersome)

Again, this is true, sort of. These are the same complaints I heard about C from ASM users, and C++ from C users, and Java from C++ users, and now, Maven from Ant users. I can do anything I want in Maven... for course, that's because I know the core and most of the plugins fairly well. If I don't know the answer, I know where to find the docs, and finally, check out source code if I really need to know. So to this I can say - it's not Maven that sucks, it's you.

However, this is a terrible attitude to take, and I apologize for whoever wrote the previous paragraph. Because most people just want to get their milk, not buy the whole cow. That is one of Maven's problems. It is not just the documentation that sucks about Maven, it is its usability.

How do you get help from the command-line? mvn -help is nearly useless, and the help plugin is nigh-unusable (though, thanks to me, the new "-Dmedium" flag has gone a long way to making it easier). Of course, that is only meaningful if the plugin/goals are commented well, which they often ain't.

How do you write a POM? XML by hand? No way, says I - I write mine in yaml. But more to the point, there is a distinct lack of IDE support. Someone once said about Maven: "working in the command-line is like working in the Stone Age". I can't wholly agree, however, your average user would be fine with a few wizards, or at least, command-line editors (pomtools was a good idea, but kind of died). It's been over 2 years now since the release of Maven 2, and we are just now getting to the point where IDE support is getting decent. Decent, but still a ways to go. Maybe in another 6 months? Stay tuned.

How do you copy a file from point A to point B? This question gets asked probably more than any other. It wouldn't be so funny if it weren't the case that there are nearly a dozen ways to do it. But in this case, it is both a Maven and user problem. A Maven problem because such frequently asked questions should have an easily findable answer. A user problem because these kinds of questions always come from people who don't understand the fundamental shift of Maven in thinking. There are a dozen ways to move a file, because there are a dozen different reasons to move a file. Moving the web.xml file to the packaging directory is done by the war plugin, because it makes sense when creating a war. But it is not done when creating a jar, by default, so it will just sit in your project. If you want to make it move, add it into your src/main/resources directory and viola, it'll get packaged up too. If you want more control, then use the antrun plugin. If you don't like Ant, use jruby or groovy or write some Java code to do it.

One of the problems with Maven is it's run by a bunch of purists, who won't make mvn -help just execute a "help" goal. Or refuse to wave good-bye to the stone-ages and insist on keeping with XML-based configurations. Drools 2 sucks, Drools 3 rocks... why? Because 3 dropped the XML, making the syntax nice and terse. Maven should learn this lesson.

Maven is only suitable for large/small projects

These aren't really fair complaints, but I hear them often. I use Maven for both large and small projects without much problem, I don't even think about it. Both of these complaints can really be chalked up to user misunderstanding, which then can be chalked up to poor documentation and usability. Which brings us right back to where we started.

This was a fun exercise, but where does that lead us? Back to the same old answers: wait for IDE support, documentation is slowly improving, we need more community support. Finally, may I make a small request? There are at least two commercial companies selling Maven support - can one of you, please, hire a goddamn graphic designer to revamp the homepage? Pleeeeeaaaassseeeee??? It's really, really ugly. This coming from a guy with a plain-white blog.

Tuesday, September 25, 2007

Code Te Ching - Verse 34

Defined process is inflexible
    Stifles results.
Empirical process is flexible
    Emergent results.

Too many colors blind the eye.
Too many noises deafen the ear.
Too many flavors deaden the palate.
Too many variables destroy the definition.

Empirical process is indefinable.

So Lao Tzu said:
    Look – you won’t see it.
    Listen – you won’t hear it.
    Use it – you will never use it up.

Monday, September 24, 2007

Let's Keep in Touch

I've been lax on the updates lately since spending the end of last week in Montréal, QC, doing some Maven training. Gorgeous city - I love French Canadians. Also, apparently, quite a little hotbed for hookers.

I spent the weekend working on a new Rail project; something to support the open source community, as well as leverage my newly found Rails skills. This project is something akin to an amalgam of: a catalog of code snippets, a link farm, and a collection of online quizzes. Seriously - it'll make more sense when you see it.

Until then - I suggest you add my blog to your iGoogle account (though it makes me cringe to type that marketing gobbledygook... i-G-o-o-g-l-e.... *shudder*). Here's the link.

Saturday, September 22, 2007

Code Te Ching - Verse 33

A coder's true worth is the deeds he has done:
Not the words he has to say.

Be wary of false knowledge.
It disguises itself well with much talking.

Thursday, September 20, 2007

Code Te Ching - Verse 32

“Mankind” does not exist.
“Time” does not exist.

“Man-hours” doubly do not exist.

They are a delusion of the mind, that is all.

The foolish man answers:
One coder? It will take two days.
Two coders? It will take one day.

Silly! Folly! Foolishness!

The great clock of the universe is not so precise,
How much less the minds of men?

The wise man answers:
One coder? It has taken two days before.
Two coders? I do not know!

Any time given is a guess.
How long is too long, then?
The wise man is not confused.
He says simply:
    I shall know it when I see it.

Wednesday, September 19, 2007

Evil Ruby in Practice

Evil Ruby is more than just a hacker's wet dream with a rock-n-roll name. When I first learned of it I presumed there was little practical use for its dark magic - yet I find myself now utilizing it more than expected.

One of the radder (more rad?) incantations of Evil is as_module. This innocuously sounding method attached to Class is insidious enough to make Satan blush. In short - it converts a Class to a Module. Why? Imagine the glory of using a class as a mixin - as seen in the little configuration system below (via include Array.as_module):

I want CompositeConf to contain all of the Array methods, yet want the inheritance hierarchy to specialize from Conf (that way a CompositeConf can be used like any other configuration - without needing to know it is a composite).

Let us play in the resulting blood bath by creating a composite configuration containing a few Configs.

Just to ensure it is working as planned - ask for the value of the key :water.

Which should output:
"wet"
But so what? We want to use Array's methods. So - let's add a nil into the CompositeConf and then compact it (Array.compact removes nil values from an array).

The first output is the CompositeConf containing the nil - the second is the compacted version.
[#<Conf:0x1050158 @hash={:sky=>"blue", :water=>"wet"}>, #<Conf:0x105011c @hash={:women=>"???"}>, nil]
[#<Conf:0x1050158 @hash={:sky=>"blue", :water=>"wet"}>, #<Conf:0x105011c @hash={:women=>"???"}>]
If that's not evil, well, then maybe I'm in the wrong industry - perhaps I should make a career change right now.

Tuesday, September 18, 2007

Code Te Ching - Verse 31

Close your mind and click away?
The elite does not debug this way.

To debug requires the focus of new development
More even,
    for options are limited,
    and the work: tedious.

The wise man does not fear bugs
He treats them all with dispassionate concern.

Monday, September 17, 2007

Maven is still Fugly

I know, I know I've said it before, and even came up with an alternative. I shan't rant on the topic a third time.

It's just that, well, I had done a cartoon a while back for the first post - and since I just purchased the glorious Adobe Fireworks CS3 this weekend (a superior platform for web-image development than Photoshop, I claim, and yes will challenge fisticuffs to any who doubt it) and needed an image to play with - outlining my belief that "tooling" can somehow remove the need for a POM with a prettier syntax.


Yes late, but never never.

Friday, September 14, 2007

Cheap Tricks IX - Spying on Ruby

St. Louis was fun. They have a very active Java user community and met loads of nice folks. Other than that, not much new or exciting today. Crashed on a friend's couch last night so brain not function so good.

But... here is some fun Ruby-spying techniques to help round out the week. The first one attaches a trace to "require" and prints out the file and line that is making the first call to "require":

Here is a way to trace every line that creates a new object.

A little more generalized, here we trace calls to specific methods for a given class that "requests" to be traced:

And here is how any class can request it's methods be traced:

Finally, you can add a little extra zing by cleaning up the output of the "caller.shift" file location like so:

Wednesday, September 12, 2007

Little Known Development Drivers

Most of us are familiar with multiple development concepts. Examples such as Test Driven Development (TDD) or Behavior Driven Development (BDD) are fine methods to write code under, but are far from the only drivers of development. I would like to go over a few of my favorite methods for pushing software development in an organization - equally as valid, if not slightly esoteric.

Resume Driven Development

RDD is not a term I coined - but if you want to credit me I shan't argue (it'll be our little secret). This is the style of development that is best represented by flowchart:


This kind of development is overly represented by technical consultants - especially the kind that travel. Perhaps this is due to the position in which they are placed: singular technical experts surrounded by non-technical clients. This is a recipe for minor abuse, if not outright exploitation.

However, despite the obvious drawbacks of such unmitigated trust (the most glaring: the technology suggested may not necessarily be the best for solving the business problem at hand), there are places where such development style is not so bad. I've seen this actually work in larger companies where innovation moves at the speed that fingernails grow, it helps to have someone who always wants to push to the newest technology - someone eager, interested and alert (even if only to thicken up a balding resume). The pestle of corporate politics will eventually grind this person down - but for the short term, some sliver of vicissitude might just make it out of the mortar unscathed.

Annoyance Driven Development

ADD is aptly acronymic
This only works if your developers actually get annoyed - the higher-strung the better. I've known people who are so tight they fart in octaves once reserved for calling dogs and shattering wine-flutes, and are perfect specimens of ADD. It works well for people who are kept up at night worrying that your XML-based configuration is substandard and could be more easily managed if replaced by YAML. Or cannot take a shower without imagining how cool their company's perfectly working system of web services would be replaced by CXF+Camel+Terracotta on EC2.

This is my style, and the style of most developers I call friends. When it works, it kicks ass - with only slight social drawbacks. But when it does not work it is disastrous... some people just plain don't care.

Contract Driven Development

Features or technology chosen because they prolong the life of a contract. Someone I know works for a (major, yet unnamed) consulting company. They charge an arm and a leg (then steal an ear and your nose while you sleep) before they are done with most contracts. It's a murky world where they reside, secretly ramping up the cost of healthcare in unseen ways, for example, convincing a hospital board that they need bed-side game consoles that must interact with the rest of the hospital system. Why? Because it would take forever to develop (who knows what they tell their clients) - and there is a good chance it will never be delivered anyway. However, the client won't know that until it has wasted hundreds of thousands of dollars in the attempt. Caveat emptor, I guess. Except the client will never tell anyone that they wasted money - leaving the consulting company free to hunt for their next contract. I doubt this is what Adam Smith had in mind.

I really cannot find anything positive to say about this kind of development. Hiring consultants is always a crap-shoot. Except for Amentra - these guys rule (I swear, I don't get kickbacks :) - they are bloodhounds for finding really smart people).

Tuesday, September 11, 2007

Cheap Tricks VIII - Blogger hCard

hCard is a plain old semantic html (POSH) microformat of a vCard. If you look on the right-hand side you will see my hCard.

All it is is a vCard, just using plain old HTML. What's the big deal, then? Because microformats are going to be added into the next generation of browsers (already slated for FireFox 3). They are just little snippets of HTML that, if the browser finds, it can take action on. If you are viewing this post in FF3 you will be able to add me to your address book... you are also from the future.

If you use Blogger, fill out this form and submit. It will create an hCard page element for you.

Bon Appetite

Change of Plans

After much soul-searching, I have decided to bow out of this years Apache Con US - I just didn't see the point. Jesse McConnell from DevZuz has been cool enough to step forward and take my place. Anyone who was interested in my talk over utilizing Apache Maven for managing J2EE projects can now look forward to Jesse's talk - however - it may not necessarily be around J2EE. Since he is scheduled right after Brett Porter's Maven presentation, I would anticipate that they will fit together well.

Again, sorry.

However - I am still going to be at the St. Louis JUG this Thursday @ 6:30, so stop on by to hear about Maven.

Monday, September 10, 2007

The Curve is a Circle

Jim and I have talked about this at length, and considering our obsession with meme-fabrication, this is one we both felt the need to discuss.

The phrase "the curve is a circle" is one we concocted to deal with the inadequacy of the illustrative ability of the term "learning curve" to describe the movement from beginner to expert. Such a viewpoint cannot appreciate the actions of one who has surpassed such sophomoric phases and ascended to the ranks of utter simplicity. Such states are almost Zen-like - moving along the circle only to discover there is no active difference - only an epistemic one. Sometimes the beginner and expert find themselves in agreement, where the intermediate believes himself superior to both. Consider the example JW gives: moving from plain text editor, to fancier IDEs, eventually venturing back to plain text editors. Corinthians 13:11 didn't quite have it right - sometimes being a man requires embracing childish things.



So how can one tell what side of the circle someone, or yourself, is on? That's the bad news. Unless you are on the other side it's damn near impossible to effectively argue a point to one on a different cycle. And believe me - it doesn't do well for an argument to declare, "you just don't understand the situation - I'm so far ahead I've lapped you." It's a good way to get punched in the face.

It's not new or a leap to say that the very language of a discussion has a different meaning depending on your point of view. This really makes communication difficult between an expert and sophomore - a little knowledge is a dangerous thing.

Here is an illustration of a conversation between me as a beginner and you as someone with intermediate knowledge on static versus dynamic typing.

You: Static typing is awesome!
Me: Dynamic typing is better.
You: How do you figure? Static typing gives compile-time checks.
Me: But, dynamic type is easier to code in.
You: Static typing is safer for large development teams.
Me: Yeah, but uh, dynamic is easier?
... ad infinitum ...

Now, let's say you make a claim as an expert - and I make a counter-claim as an intermediate fan of static typing.

You: Dynamic typing is awesome.
Me: No, static typing is the best. You are a n00b.
You: I like dynamic-typing because it makes it faster to develop and manage code. Once the use-cases are satisfied, you'll find a lot of unnecessary time that would have been spent on static-type frameworks has been saved.
Me: Static typing is safer for large development teams.
You: Yeah, I know - but without all of that overhead (and frameworks) to manage types, you don't need as many developers involved in a project - so you don't really need to worry about team size.
Me: Naw - they'll get bigger eventually - you've just worked on trivial projects.
You: No, Eric, you are an ass - I've worked teams of various sizes.
... and scene ...

In both cases, the fan of static typing is an intermediate level, while the dynamic typing fan is a newbie in the first (unable to articulate his position) and expert in the second (able to make an experienced, non-theoretical case). But look at it from the static-typing fan's perspective: they're both wrong, and both inexperienced. The curve is a circle.

Of course, maybe this is all just hypothetical.

Friday, September 7, 2007

Linus Agrees with Me

Well, not personally, and possibly not at all. But - as you may have read his rancorous rant against C++ - one line in particular caught my eye:
C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes ... inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

Wow - and to think I bother to pull punches occasionally.

The only difference is, the point he makes about C++ I extend to static typing in general. But he is correct - premeditated abstraction is my point #3... static typing requires you to know the future.
Linus agrees with me => QED
(note: put away your blow torches, flamers, it's called witticism)

Cheap Tricks VII - Cleanup Subversion Projects

I've been writing too much lately. The whole point of "Cheap Tricks" was to make short posts with little tricks - interesting or not - come hell or high water - yadda yadda yatta.

Here's a trick for recursively removing .svn files from a project structure (as is sometimes necessary):
rm -rf `find . -name .svn`
If you don't like back ticks, you can also use xargs:
find . -name .svn | xargs rm -rf
Useful for all sorts of recursive deletes, like .DS_Stores, or anything.

Enjoy your weekend!

Wednesday, September 5, 2007

5 Reasons Static Typing Sucks

Static typing is a pedantic construct, bred from experiments of the first Object Oriented languages, in the same way that the Vienna Circle was an experiment with the Tractus - a confused failure (for those robbed of a formal philosophical education I'm not just being an asshole here, the case is apt and expanded below). I am not against all forms of static typing, and for example, do appreciate how ECMAScript 2.0 uses a mix of static and dynamic types (adopted by ActionScript 2+).

It is not type-safety I am against, per se, it is the mindless parroting of virtues of "compile-time checking" while citing none of its drawbacks. I am against being forced to statically type everything in a language when it is not always necessary (consider in Java giving an Object a type, just to put it into a Map, where its type is lost, and convert it, at runtime, back into a type - though to be fair, generics go a long way to fixing that mess. But I maintain that a real type-safe system would have no need for ClassCastException). In my opinion type safety has one shining virtue: to solidify APIs. But I feel the trade-offs between the dangers of dynamically-typed languages versus the constraints and verbosity of statically-typed ones is an easy choice to make. I will create my own safety, thankyouverymuch. For those craving a visual experience, here is my belief codified:


Perhaps it would be hyperbolic to claim - being forced back into wrestling with a static type system - I'd prefer to wrestle with the business end of a shotgun. But I do have reasons - a mix of Ivory Tower and practical reasons which are sure to sway no die-hards on either side of the isle, but must be made mention for posterity - so at least our progeny can rest in the knowledge we weren't all mad.

1. Static typing requires extra typing

Keyboard typing, that is. As far as I am concerned - anything that adds more code is a Bad ThingTM. It slows down development and increases the potential for defects. Working around the rules of a type system requires extra code that detracts from the problem at hand. All I ever hear in response to this is: yeah, but the compiler catches type errors. Have you ever run into a ClassCastException in Java code? How is that type-safety? Moreover, how common are type errors - I mean, really? I so rarely come across them at my job (where we have a whole staff of developers working on the same Ruby project) that it is hardly ever a consideration. All I can figure is that type-safety stops bad developers from doing dumb things, which my stance is quite simple on bad developers: fire them.

But the larger point is that programming will never get away from the need to give variables meaningful names and some sort of rudimentary documentation (even if that documentation is merely simple and readable code). If you use meaningful names, you can always figure out a type. In fairness, I have, in Ruby, been forced to resort to the following when running across unfamiliar code:
puts var.class
Before you start yelling "fowl!" I'll have you know I've typed my fair share of this kind of crap, too:
System.out.println(list.get(0).getClass().getName());
Have I ever written dynamically typed code that has run for two hours, only to return and find that it broke because of a typeo or a wrongly-used type? Yes. But in almost every case it could have been fixed by better unit tests. Besides, those few situations pale in comparison to the man-months saved in typing, digging through verbose code, and wrestling with the type system.

2. Static types are unreal

Real things are not statically typed. If you accept Phenomenology's basic views of reality (which - if you are an existentialist, Eastern philosopher, or relativist - you do by fiat, and you are an Objectivist - well, there is no hope for you), "objects" are only signaled (or named) by their utility. For example, we have a word "hammer" because in our system of perception we have a use for declaring it as a single class of objects with a common utility. What do you do if you need to bang on a nail and you don't have a "hammer"? You find a substitute - a rock for instance. You use the rock "as a hammer" in which case it too becomes a "hammer".

Even if you do not buy the above statement - in every day life, as long as we can successfully use something for which it is needed (as Heidegger would say Zuhandensein, it is "at hand"), that is good enough.

Consider that I am building a deck behind my house. My requirements for materials are: sturdy, cuttable, nailable, and looks_nice. Now I'm given objects of type "Wood" and some objects of type "Plastic". As long as my objects work for all criteria of which I require, it hardly matters what they are actually made of - even if I did not know in advance what I would be using those objects for.

Static typing not only requires you to know what you want to do with those objects in advance, it requires you to codify it (via either common inheritance or codifying for all known desired types - think if...instanceof in Java). This brings up the next problem:

3. Static typing requires you to know the future

Logical Positivism has failed. This is the philosophy that a comprehensive view of the world (via proven scientific statements - note the key word: proven) can be built up from simple to more complex statements like mathematical theorems. Of course, this was quickly shown unworkable via the criticisms of guys like Karl Popper and W. V. Quine - basically, science cannot "prove" anything (only disprove and give a best guess - or theory) and that since language can change with new discoveries, previous theories are all suspect (the term "gravity" has a different meaning after Einstein than it did after Newton, so building mathematical statements from the proofs of "gravity" would be to build on a house-of-cards).

Yet - despite the fundamental inability for a workable theory to be built off of a language of static terms - this is precisely what statically typed languages attempt. For example, consider that we create a software system that models a ball manufacturing company. Undoubtedly, we have an object named "Ball" that has a property "radius" and specialize (extend) that type to "SoccerBall" and "BasketBall" with their own properties.
abstract class Ball {
Float radius;
}

class SoccerBall extends Ball {
Boolean boringToPlay;
}

class BasketBall extends Ball {
Boolean boringToWatch;
}
Everything looks fine, so we build our entire system based on the "Ball" type including manufacturing and billing. Everything looks fine - that is - until the company decides to start making rugby balls. So we extend the "Ball" model with "RugbyBall" - now what does the inherited property "radius" mean? At best we retrofit a meaning, at worst we ignore it. Whatever you do - your manager may still chastise you for your short-sightedness. Just let her know that you fell victim to a shortcoming of the logical positivism of which static typed programming is too similar - it is not your fault.

If you do attempt to re-define what "radius" means we need to retrofit the term (this is a common phenom in linguistics. For example, consider the word "oven" - when "microwave ovens" became popular a new term was required to differentiate the two: "conventional oven"). Static-termed languages are not equipped to deal with this change so we create substitute tricks like Aspects or Dependency Injection. But whatever we do - we tend to require a lot more typing to fix the fundamental flaw: such languages are ill-equipped at dealing with reality except in the narrowest sense, and can only grow via retrospect. So-called dynamic or "duck type" languages minimize such problems, since they make no assumptions on what terms (types) mean, only how they are used. You change where you need to, and elsewhere leave well enough alone. Our temporal frailties aside, the fact that the future can bring about unexpected changes have birthed one of the most frightening words in the developer's lexicon: "refactoring". So much for the idea that terms are static - yet delusional, we lumber on.

4. People want to work around it

I consider this the best evidence against (required) static typing. Theories are good, but like the old quote goes, "in theory, theory and practice are the same. In practice, they are not."

People want to work around static type systems. This is evinced by the rise of frameworks such as Spring in Java (configuration and run-time object override) or Reflection in C# (run-time view and replacement). As time goes on these languages keep adding more and more features to loosen the static typing (Java did not originally have Reflection - now they are considering adding named arguments for easier integration to dynamically typed scripting languages). I've read James Gosling claim that "safety is freedom" since you always know what type you are getting back - but is that really the case?

Orwellian-sounding phrases aside ("safety is freedom", "war is peace", "static is dynamic"), many powerful modern Java frameworks are built on some sort of Inversion of Control principle (like Eclipse or Maven) - which completely removes compile-time safety since types are not resolved until run-time - and work by voodoo such as runtime reflection, bytecode manipulation, and killing chickens. (Now, don't come to me and say: you're confusing the compiler and the type-checker. True, the JVM verifies type safety at runtime, but by then it's too late... you may as well have scripted your code.)

My single question to these frameworks is: why all the hassle? If static typing is so great, why do these frameworks work so hard trying to circumvent it? Perhaps it is a cultural artifact of the C++ and Self days, and a lingering confusion of class versus prototype-based programming. Is it an idea that John Q. Programmer holds, that class-equals-static and prototype-equals-dynamic? Do fans of class-based languages think they need to support static typing to support the concept of classes? I wish I knew - but the love-hate relationship between a programmer and their favorite language's type system astounds me.

5. Valid logic is rejectable

class C {
Integer getDefault() {
return new Integer(0);
}

int func(Float x) {
if( x == null ) {
x = getDefault();
}
return x.intValue();
}
}
The above program will not compile in Java, despite the fact that the above program would not fail at runtime (ignoring JVM checks), since both Float and Integer inherit intValue from Number. But the type system requires you to rewrite the above perfectly logical code. This time - this one time - I want Float and Integer to be compatible. But no, the Mighty Type System has spoken! This is somewhat related to the first annoyance - but is not so much about the extra code required to rewrite the above into something acceptable by the type system, but the fact that it needs rewritten at all.

Here is a rewrite of the above function func to agree with the Java type system.
  int func(Float x) {
if( x == null ) {
x = new Float( getDefault().floatValue() );
}
return x.intValue();
}
It adds no real descriptive value as to what the program does - its extra verbosity makes the type system happy, sure, but does it make the code any more functional, more readable, or less error prone? The answer to all three questions is "no". Are cases like the above worth throwing away a whole type system - just for a few coding shortcuts? I claim yes, it is. At the very least drop such a rigid static type system... dare I say a static static type system? No, I suppose not. Coming up with such bad puns is unbecoming.

So that's my list. Did it change your mind? Unlikely - indoctrination is hard to unravel, hence the difficulty with Zen. Don't take my word for it, try creating a large-scale project without a statically typed language. Am I assuming you haven't? Yes. So few people get the opportunity. Try it, get back to me. Please, no stories older than 5 years ago: "Eric, we tried using Perl 15 years ago and it was a disaster!" Try again with modern techniques. Perl has grown - shouldn't we all?

Housecleaning

First: If you have not noticed, I've started restructuring the blog to reduce its ugliness quotient. First and foremost was the addition of dp.SyntaxHighlighter - truly mana from heaven. However - it requires code to exist in textareas, not pre, so RSS feeds will look kind of ugly until I figure out a fix (blame blogger - they like to injects <br/> after lines). I also added some better RSS (Feedburner) and rocked out the linkwhoring at the bottom of each article.

Second: I finally got added to the Terracotta committers page! Now whose leg do I have to hump to get my name added onto Maven?

Third: Apparently my post about overriding nil in Ruby ruffled a few feathers amongst the Java crowed. Who'd have known null was a sacred cow? If that is the case, I'm curious as to the backlash concerning my next post "5 Reasons Static Typing Sucks".

Fourth: A belated congratulations to Jimbojw for his (fairly) recent promotion as a MediaWiki committer!

Tuesday, September 4, 2007

Cheap Tricks VI - A Browsable S3 Index

Somebody emailed the Terracotta dev group the other day complaining that he could not navigate through the Maven repository. The problem being it is hosted by Amazon S3, which communicates via SOAP. Hung Huynh from TC quickly created a simple index.html page with a script that would display an S3 bucket's contents.

I liked the idea, but wanted more of an interactive, collapsible-tree format where you can dig down to a specific file and download it... like an explorer. So I ended up with the following:

http://s3.amazonaws.com/maven/index.html

See what it looked like before the index - just lots of ugly SOAP:

http://s3.amazonaws.com/maven/

Here is the source for the javascript :View the full source here

Just ensure that your S3 bucket is publicly readable via ACL.

Sunday, September 2, 2007

Code Te Ching - Verse 30

Do not code to optimize.
Let design spill over like milk.

There is always time to clean it up.

Keep focused on the center, and
systems improve themselves.