One of the core tenets of object-oriented programming is encapsulation. It's one of OO's most powerful ideas. More powerful than inheritance. Unfortunately it's also one of the most ignored.

I want Heron control structures to be defined as macros. It should be easy for a programmer to introduce a do/while loop or a better for statement. One of the principal motivations, is that the programmer should be able to specialize these things for specific types, or meta-types.

The Concurrency chapter is finished (hurray!), and now I re-wade into the mysteries of Java Generics. The chapter isn't looking as bad as I was remembering, but there are still some issues that I'm struggling to understand and explain.

In a thread on Heron, some issues came up that I thought were worth clarifying.

Artima has launched Ruby Code & Style, a new online magazine dedicated to sharing the pleasure of Ruby programming. Edited by James Britt and Shashank Date, this magazine will publish technical feature articles, tutorials, and commentary for Ruby programmers.

The design of Heron is more inspired by the problems faced by library developers than software developers.

A pattern for the recursive creation of composite objects.

Think code can't lie? Think again.

As I can see the end of Thinking in Java 4e approaching, I'm starting to get into the mode to work on the Hands-On Java CD ROM (4th edition, skipping a release number to synch with the book), which I will do in Flash to eliminate various platform problems.

I am exploring the possibility of defining macros as patterns and transformation applied to an s-expression representation of the syntax. Maybe this is the path to writing a fully extendible language?

Macros are a frequently overlooked yet tremendously useful language feature. What if we give them a more modern twist?

Closures are extremely useful, no question, but they are hard to implement efficiently. I am considering implementing them in Heron but with auto-destruction semantics.

Guy says: "Essentially, programmers shouldn't have to worry too much about optimizing while they're writing programs. Instead, that optimization can be done by compilers, either ahead of time or on the fly.", but I disagree.

I've noticed that, in descriptions of threading, the levels of abstraction are often mixed, which I believe adds to the confusion already present in understanding threading. In this short exerpt from "Thinking in Java fourth edition," I attempt to clarify the situation.

The latest HeronScript does type-casting backwards.