Putting New Light into the IDE

I've written before about how every technology has an internal "genius" or set of inherent, cohesive, driving principles, which need to be recognized and employed when working with it. This the the right way to deal with "new wine." Which is to say, it's not putting it into old bottles! It's the right way to do things.

You'll see a perfect example of what I mean by rethinking new technology in new contexts. The REPL was great when the command line was the king of programming environments, before the GUI and IDEs. But today, the REPL can be so much more than a command line thing. Instarepl in LightTable is a wonderful example of this. You'll see a reduction in cycle time and instantaneous coding feedback in a way that the REPL could never afford.

Clojure Koans in Light Table, found here,  is a cool way to see a bit about Clojure and Light Table.

Not only can you see the instantaneous feedback of the Instarepl, but also get a feel for Clojure, not to mention how the "Koans" are an active approach to learning a new language. (As opposed, for instance, to the passive reading of a book, or even watching this video. So, to be pedantic and irritating, you'll get to see how excellent Koans are by passively watching someone do them, rather than exert yourself and get the real benefit by actively struggling through them and actually improving your knowledge).

Or, if you prefer, there is a short intro video here on the Light Table home page. You'll see that this offers a new way to organize development and code reading: one oriented around functions rather than around files. And that is the way that an IDE should be, when coding a Functional language like Clojure.

I Remain,

TheHackerCIO

Blued; NOT Screwed!

Blued; NOT Screwed! Which is to say "Zinged"!

TheHackerCIO is fluent in Spanish. So Azul Systems is "Blue" to him. Last night at the LAJUG we were amazingly lucky enough to get a tremendous presentation on Java Garbage Collection from the CTO and Cofounder of Azul Systems,  Gil Tene.

Azul, for those who don't know, make a JVM which, while it costs money, resolves a lot of the performance problems commonly encountered in Java environments.


TheHackerCIO is never tempted to Lionize anyone, or write puff-pieces about any product. What set this presentation apart were the following:

• factual information about all available GCs was the main thrust of the talk.
• Zing (Azul's product) was only mentioned briefly at the end.
• Basic terms were defined, some in cleverly clear ways that made for greater retention
• Basic principles were developed.
• Principles of GC operation were then examined in the context of those basic terms and principles, so that everything was brought into a coherent whole.
• The focus was on understanding the Mechanism, not on explicating the JVM flags. As Gil put it "Once you understand how it works, you can use your brain" to figure out the flags. TheHackerCIO likes that. Always use your brain.
• A lot of misinformation and fallacies were debunked. Turns out, surprise, surprise, the Conventional Whiz-Dumb is wrong much of the time. 

The presentation was so superior to the Performance book, that in my mind it formed a perfect contrasting concrete. If only the Performance book we are studying had been written in this manner, we would have all been happy campers. 

I took pages of notes, and I suspect that I'm going to have to break them out over several days. But, you have to start somewhere. And what better place than his attention step?

He began by claiming that most of what people "know" about GC is wrong. Then he told a story

Early in Azul's history they encountered an application taking 18 second pauses. This was somewhat embarrassing for a pause-less JVM, so they investigated. What they found was that every class had a finalizer that set all instance variable references to null. 

Notice that this is the right discipline for a C++ environment. But it's dead wrong for Java. Dead objects cost nothing to collect! Except, when you put finalizers on them! This is a perfect example of how people fail to rethink new technology in the context of it's own spirit and intent and continue to use it in antiquated, outdated manner. But that is a major topic for yet another day's blog, and was not a topic of Gill's talk. 

So, despite the Conventional Whiz-Dumb:

• GC is extremely efficient. Much more so than malloc().
• Dead objects cost nothing to collect (Except when you put finalizers on them!)
• Those pauses you eliminated from your 20 minute test are not really gone. They just got pushed out to 30 minutes. Your times may vary, but the pause just got pushed out to a later time!
• There will be a 1s per live GB pause. This is not really tunable. The only way around it is Zing.
• No, GC doesn't mean that you can't have memory leaks.

Even I fell for some of these in times past. But this is getting long. 

I would say in conclusion that rarely have I been so impressed by a company's values. The talk we scored came from Azul honoring the commitment of a junior sales engineer to speak to us in October, but who had left the company. In the absence of anyone local to fill in, the Cofounder/CTO hopped on a plane to give us the promised presentation. TheHackerCIO deeply respects keeping commitments and  can't think of a more paradigmatic example. More on GC will follow.