How Many Languages Do You Code?

Released in 1996, Java is now 17 years old. The most recent new trend, is not so much new language features, but new languages altogether! The so-called JVM languages are completely non-Java languages, but they compile down to the same Java byte-code that a Java compiler produces, and so are able to co-exist with the Java ecosystem in a very simple, easy way.

The major JVM languages are:

• Clojure -- a Lisp for the JVM
• Scala -- a functional language
• Jython -- an implementation of Python
• JRuby -- an implementation of Ruby
• Groovy -- a scripting language

It's dead easy to call anything written in any of these from within a standard Java program; and the other way around works easily, too -- so from within any JVM language, you can call out to a standard Java program.

This means you can now write in the language of your choice, yet still use any Java-based library or framework.

So, in the Java world, we're all trying to figure out what JVM language to add into our Technology Portfolio. Where do we lay our bets? Which will be the Market Winner? Adding in which new JVM language will augment our career? Which one will get us the higher salary?

These are the questions on the Java developers mind these days. Because it's a large investment of time to learn a new language. Just because I mentioned the major contenders, don't think that there aren't several dozen others!

In my case, I've been laying my bets and spending my time in learning Clojure. But that's another topic for another day. For now ...

I Remain

TheHackerCIO

4 to 6 Reasons Why Blogs Shouldn't List Reasons

I'm told that TheHackerCIO will get a higher click-through rate, and thus attract more readership if I put numbered lists in my Post title. TheHackerCIO has a pretty negative view of this, but since I'm an easygoing guy, and since it's Friday, or  "FunDay," I thought I would take a stab at it. So here are N reasons why blogs or articles with numbered lists of reasons are irrelevant. Notice that I'm not predetermining the number in advance of writing this. I'll fill in the value of N at the conclusion, and then substitute the value into the posting title. That's the scientist or engineer in me, doing that! Hang on now, here we go:

1. The numbers are arbitrary. Couldn't they come up with one more reason why the Cloud is good for your business? If the article was too long, couldn't they trim one? More than one? Aren't some of them really aspects of the same reason? Reasons are typically hierarchical and nested, with lots of interdependencies and cross-relationships which are not captured by linear numeric lists. In fact, this structure is destroyed by such a flattened list.

2. The focus is on distinguishing the reasons, not exploring them in depth. In consequence, you will get a shallow understanding from these kinds of articles. I can count on one hand the number of articles with numeric lists that have seriously aided my understanding of anything. In fact, I can count it on one finger. You can see the trend starting even here and now!

3. Using this technique is manipulative of your audience. You are playing on a peculiar aspect of psychology in order to manipulate them into clicking into your blog. I hate manipulative people. Why would I now want to become one. I've got better things to do, like Hacking.

4. It's a very unnatural, forced approach, tending to produce uniformity and conformity  rather than variety and freshness.  It amounts to forcing the content of my thought into someone's Procrustian "numeric lists" format, which will result in the same thing that Procrustes' bed did: lopping off variety and improper emphasis given to what should receive short-shrift. TheHackerCIO is anything but a conformist publication. And what you read here is far from the normal, or "consensus".

5. I can't come up with another one right now, and I need to get back to Hacking. I've got a scheduler problem with my Server which isn't kicking off my batch jobs. However, you can see the problem right here from within this very list. If I really need a "5", I can always break #4 into two:

1. produces uniformity
2. produces conformity 

or, I could break it out into 3 reasons, and have a list of 6, like this:

1. forced, unnatural approach
2. produces uniformity
3. produces conformity 

which is just to prove my point #1: the numbers are arbitrary; and to corroborate #2, that the more I break these out, the less you see the interrelationships and the less time I spend on exploring them. So instead, just to keep things a bit quirky and unconventional, let's establish a range for N,  where N is number of reasons, as I defined it at the start of this article. Then the range for N is 4-6, and so we now have calculated our Posting Title for the day: "4 - 6 Reasons Why Blogs Shouldn't List Reasons".

Have a FunDay! Learn some new technology!

I Remain Faithfully,

TheHackerCIO

Creating Tomorrow's Legacy Code Today

"Creating Tomorrow's Legacy Code Today" was the humorous motto of a group I worked with at a major financial institution, Feral Hangman. 

• Yes, the name of this client has been changed to protect the guilty.
• No, this was not official
• Yes, there was a high Dilbert Index at this client

A Dilbert Index is a way of determining the level of pathology found in a company. The higher the number of posted Dilbert cartoons, the greater the likelihood that this is an unheard message to the management. Or a protest.

The point is that code becomes a legacy the moment it's written. But why is this so? And how can it be mitigated?

Michael Feathers introduced a novel definition of legacy code as "code without tests," in his Working Effectively with Legacy Code. But inheriting a large code base in a strange language without any author to consult is still scary, even if it is accompanied by a regression test suite. Here's a thought experiment. This same financial institution (see above) found a portion of crucial code in production which was written in assembler, somewhere between 3 and 5 decades ago. There was no source code. Would this have been eliminated as a problem if only a test suite had been available?

The problem with code is that it is an enormously mental activity. My copy of Coders at Work is loaned out, so I can't quote the source, but one of the interviewees claimed that what made a top coder was the ability to hold the entire program in ones' head at one time. This is a huge achievement. And it's difficult. One phone-call can destroy it.

But the further problem is that when you do have this Wondrous Vision everything is crystal clear about how your program works and why you did it in this particular way and how all the tricks, tactics, and techniques fit together to do it elegantly.

But this vision is a perishable good!

And, therein lies the rub. When the vision is present, it is beyond pointless to write it down. Plus, you're under delivery pressure and documentation/explanation is not the primary deliverable.  But the vision decays: geometrically. Inexorably. Heck, we said before that a mere phone call can destroy it! But time eventually kills it entirely and all those explanations that were so clear become murky, unclear.

Almost every programmer has experienced this. You go into some code you wrote last year and wonder, "why did I do that in that way?" And this may take quite some time to resolve.

This blog is too long already, so discussing possible mitigations will have to await the future. In the meantime, ...

I Remain,

TheHackerCIO

Geek Book Club: Java Performance

Java Performance Book

A Users Group is a bit low-tech, but still an excellent way to improve technical ability. This is re-demonstrated by the advent of agile techniques such as pair-programming, and Mob Programming. What is Mob-Programming, after all, but a sort of Users Group working on the same problem collaboratively, using only one keyboard! I have reservations about the value of  MBA-hole touted "teamwork," since it is often the last refuge of the incompetent; No better means of blame-shifting has ever been invented than the "teamwork" of a committee. But clearly there is a place for collaboration. And a Users-Group is a self-selected group of interested valuers of a particular technology.

I go regularly to a local Java Users group, which has a weekly Study Group, whose present book is on Java Performance. So, on Wednesdays, typically, I blog about the Tuesday night's book discussion. This week we're on Chapter 10, about performance on the Web.

Since I haven't blogged about the book at all until now, I'm going to generalize my impressions on the first ten chapters. This is not a book for the faint-hearted. It's very a very dense, tough read. I made it through about chapter 5 or 6 without serious problems, but got slogged down at that point, and only picked it up again here at Chapter 10. And what I learned was limited and somewhat frustrating. I can't entirely blame the book. Part of what limited my learning was the mere fact that an almost overwhelming number of tools are discussed in considerable detail. Now, if I had the time to use this as a tutorial, and work through those tools, my learning would have been much greater. For that, I'll take the blame. But the book raises a number of very tantalizing details which are not presented in sufficient detail to be really grasped or understood. On the positive side, I'm glad to know of the existence of all these tools. I'm also glad that I know where to turn to find all the tools and things-to-do to monitor a particular aspect of the performance of an environment. But, of course, this is a dwindling asset: as time passes, the list will logarithmically decay in terms of usefulness. The part that is frustrating is that many topics are referenced obliquely -- enough to raise them as a point of interest, but not enough to really grasp what is going on. I'll try to post an example of this next week -- in the interests of keeping this post manageable.  Back on the positive side, there are many tips and tidbits scattered through the text.

Last night, for instance, we read with considerable interest that enabling the Java Security Model resulted in a 33% performance degradation. That's much more overhead than I would have guessed. We also learned a cool trick for avoiding the 404 error associated with lack of a favicon. Provide a 1x1 pixel blank icon! Now that is way cool! And the whole group agreed.

My experience working through this book are shared by many other club members, by the way. One of them was posting to potential visitors not to judge the club by this book!

I Remain As Always,

TheHackerCIO

UsiN' l33T 42 p4rt 0f H4X0r kultuR3

People have asked me what the The H4ck3rC10 means in the Blog banner. That's because you don't have a proper appreciation for Hacker culture. Many hackers, in times past, had problems getting past the profanity checkers with their emails, not to mention having problems with certain BBSs, when they discussed hacking topics. So they developed an alternative alphabet, called 'leet. You can read more about the history of Leet at Wikipedia. I've used Leet in the Title of this post, so you can get a sense of it. If you want to copy this, you can go to this Leet Translator , paste it in,  click "Convert to english," and see it transformed. There are different versions of Leet. You'll notice on the translator that there is a checkbox for "advanced." I write very basic leet, because I'm drawn by an overwhelming desire for comprehensible communications. Remember, I'm not just a h4X0r!

I'm also a top-notch CIO.

So I remain, Equally,

TheHackerCIO

Error is a Problem

Today, TheHackerCIO is back to hacking. And he's ticked off. With all the improvements to coding languages; with all the frameworks dedicated to improving productivity and accelerating development by shortening the build-cycle, why, oh why haven't error messages improved any over the last 30 years. You still get presented with merely a cryptic message when you offend the parser. Let this posting be a manifesto for improving programmer productivity! Let's build a language/environment where the abstract message is tied to the actual concretes that produced the error. Let's see, side by side the elements of the parse tree that are no good, and the line numbers where these are involved. if there were some recourse to the actual originating and intermediate steps that led to the error it would be a serious advance over the standard operating procedure of pasting the error into Google along with "Stackoverflow" as search term.

I Remain and hope to Remain for some time Hacking, As ...

TheHackerCIO

Who is TheHackerCIO?

Who is this mystery man, TheHackerCIO? And what is he like? Once he asked a colleague, "Do you think I'm a pessimist or an optimist?" He noted, "You're an optimist about what you can do and a pessimist about what others can do." That's true: it makes me a realistic optimist. Another colleague said "you have an edge." True, too. It wasn't intended as such, but I take it to be a prime compliment! Any tool, to be of value must have an edge. And keep it honed. I don't struggle to keep my edge -- it comes naturally. And I hate falsehood, pretense, and euphemism. You aren't going to read corporate-speak here. No Political Correctness. No mission statements. No threadbare cliches. I keep it real. I keep it as close as possible to reality.

I Remain, Faithfully,

TheHackerCIO

Next in the series