JOB REFERRALS
    ON THIS PAGE
    ARCHIVES
    CATEGORIES
    BLOGROLL
    LINKS
    SEARCH
    MY BOOKS
    DISCLAIMER
 
 Sunday, November 29, 2009
Thoughts from the (Java)Edge 2009

These are the things I think as I sit here in my resort hotel on the edge of the Dead Sea in Israel after the JavaEdge 2009 conference on Thursday:

  • The JavaEdge hosts (Alpha CSP) are, without a doubt, the most gracious hosts I think I've ever had at a conference. And considering the wonderful treatment I've had at the hands of the 4Developers and JDD hosts in Krakow (Proidea) and the SDN hosts in Amsterdam, this is saying a lot. But the Alpha CSP folks have simply floored me, top to bottom, with their generosity and warmth.
  • The JavaEdge crowd is a great one. I wasn't quite sure what to expect, because in the US we don't hear much about the tech going on in Israel, so I was a bit concerned that (a) my English was going to be difficult to grasp or that (b) my humor was going to sail over their heads due to the language barrier, or worse, (c), the developers at the conference wouldn't be ready to hear the keynote message ("Why the Next Five Years Will Be About Languages"). I shouldn't have been concerned on any of those points—this crowd understood me perfectly, laughed at most of my jokes (hey, not even my family gets all of them), and more importantly, not only accepted the thrust of the message but also came up to me afterwards and either sought clarification, challenged one or more points, or simply said they enjoyed the keynote. It was as engaged and enthusiastic a crowd as just about any I've had.
  • Fan(tom) is something worth looking into. Some of the speakers at the conference were talking with me about Fan (recently renamed to Fantom, to make it easier to Google/Bing), and I've realized that Fan's too interesting a language for the amount of press that it gets. I think this is something I'm going to pursue in the coming calendar year, maybe put together some presentations and/or workshops on it.
  • Israel is ready for Groovy, Scala, and closures in Java. These folks were chomping at the bit at the thought of using one or all of these, at least based on the comments and questions I got after the keynote.
  • Swimming in the Dead Sea is a truly bizarre experience. To be honest, one doesn't really "swim" in the Dead Sea—one just rests on top of the water, because the salt content in the water is so high that it is (quite literally) impossible to go under the water. It's like lounging on an inflatable raft in the water, except without the raft. It borders on the creepy. Still, my skin is much softer now than it was before. ;-)
  • Jerusalem is a fascinating city. Alpha CSP set me up with a tour guide (Ido Notman), and we toured Jerusalem yesterday: all four quarters of the Old City (the Christian quarter, the Jewish quarter, the Moslem quarter and the Armenian quarter), the "Tomb" of King David, the Holy Sepulchre (where Christ was supposedly crucified and buried), the Western Wall, and then back to Tel Aviv for the night. Throughout the entire day, Ido kept up a running commentary about the history of the city and the three religions that are centered there (Christianity, Judaism and Islam) and the stories/legends that each holds about the city's place in their religious beliefs. I came away just flat overwhelmed, and, once we got back, flat on my back—we walked for most of the day, and Jerusalem is not a flat city like you might expect—it's nestled in some serious mountains, which makes it a bit rough on the calves. But it was well worth it, because there's nothing like standing and looking at pillars right in front of you—excavated from beneath a high-rise apartment building, just there for anybody to stroll up to and see and touch and take photos with—that were built back when Rome meant the center of civilization. Wow.
  • The Palestinian-Israeli and Arab-Israeli conflict(s) are a lot more "real" when you're in the middle of it (geographically). Seeing armed Israeli guards, driving through security checkpoints, even just driving past the wall that Israel is building to keep a physical barrier between them and Hamas/Hezbollah is all a vivid reminder that the nine-o'clock news is more than just something that's happening "over there" when you're "over there" too. The highway we took (the road from Jerusalem to Jericho, the same one mentioned in the parable of the Good Samaritan—and, yes, we passed the Inn of the Good Samaritan on the way here, which was just a little creepy and exciting and weird all at the same time) drove right alongside that wall for a stretch of about five or so kilometers, and I couldn't help but wonder if somebody in one of those apartment buildings over there, who had a clear line of sight to our car zipping by on the freeway, was looking at us through the scope of a sniper rifle. It's a creepy feeling, and even worse knowing that there may well have been an Israeli sniper looking back across the wall as well, into somebody's apartment. I won't weigh in on one side or the other here, because that's not my point; my point is that we in the US take our physical security way too much for granted, compared to some other parts of the world where it's not such a given.
  • And no, in case you were wondering, I was never concerned for my safety. Yes, it's something I thought about. But you have a better chance of dying on a New York street corner from a runaway ice cream truck than you do from a rocket attack or a terrorist suicide bomb (or something like that). I'd come back in a heartbeat.
  • Israelis really know how to party. First the after-conference party on Thursday night, then a quieter speaker dinner last night, but each time, the company was excellent, the food was amazing, and the wine/beer/liquor-of-choice was flowing fast. I don't know if it's just the Alpha CSP folks or Israelis in general, but these people really have a work-hard-play-hard mentality that I just love.

Thanks again to Miya, Ety, Shlomi, Roi, Alex and Ido for a wonderful combination work/vacation trip.


Conferences | Java/J2EE | Languages | Review | Social

Sunday, November 29, 2009 9:08:46 AM (Pacific Standard Time, UTC-08:00)
Comments [5]  | 
 Sunday, November 22, 2009
Book Review: Debug It! (Paul Butcher, Pragmatic Bookshelf)

Paul asked me to review this, his first book, and my comment to him was that he had a pretty high bar to match; being of the same "series" as Release It!, Mike Nygard's take on building software ready for production (and, in my repeatedly stated opinion, the most important-to-read book of the decade), Debug It! had some pretty impressive shoes to fill. Paul's comment was pretty predictable: "Thanks for keeping the pressure to a minimum."

My copy arrived in the mail while I was at the NFJS show in Denver this past weekend, and with a certain amount of dread and excitement, I opened the envelope and sat down to read for a few minutes. I managed to get halfway through it before deciding I had to post a review before I get too caught up in my next trip and forget.

Short version

Debug It! is a great resource for anyone looking to learn the science of good debugging. It is entirely language- and platform-agnostic, preferring to focus entirely on the process and mindset of debugging, rather than on edge cases or command-line switches in a tool or language. Overall, the writing is clear and straightforward without being preachy or judgmental, and is liberally annotated with real-life case stories from both the authors' and the Pragmatic Programmers' own history, which keeps the tone lighter and yet still proving the point of the text. Highly recommended for the junior developers on the team; senior developers will likely find some good tidbits in here as well.

Long version

Debug It! is an excellently-written and to-the-point description of the process of not only identifying and fixing defects in software, but also of the attitudes required to keep software from failing. Rather than simply tossing off old maxims or warming them over with new terminology ("You should always verify the parameters to your procedure calls" replaced with "You should always verify the parameters entering a method and ensure the fields follow the invariants established in the specification"), Paul ensures that when making a point, his prose is clear, the rationale carefully explained, and the consequences of not following this advice are clearly spelled out. His advice is pragmatic, and takes into account that developers can't always follow the absolute rules we'd like to—he talks about some of his experiences with "bug priorities" and how users pretty quickly figured out to always set the bug's priority at the highest level in order to get developer attention, for example, and some ways to try and address that all-too-human failing of bug-tracking systems.

It needs to be said, right from the beginning, that Debug It! will not teach you how to use the debugging features of your favorite IDE, however. This is because Paul (deliberately, it seems) takes a platform- and language-agnostic approach to the book—there are no examples of how to set breakpoints in gdb, or how to attach the Visual Studio IDE to a running Windows service, for example. This will likely weed out those readers who are looking for "Google-able" answers to their common debugging problems, and that's a shame, because those are probably the very readers that need to read this book. Having said that, however, I like this agnostic approach, because these ideas and thought processes, the ones that are entirely independent of the language or platform, are exactly the kinds of things that senior developers carry over with them from one platform to the next. Still, the junior developer who picks this book up is going to still need a reference manual or the user manual for their IDE or toolchain, and will need to practice some with both books in hand if they want to maximize the effectiveness of what's in here.

One of the things I like most about this book is that it is liberally adorned with real-life discussions of various scenarios the author team has experienced; the reason I say "author team" here is because although the stories (for the most part) remain unattributed, there are obvious references to "Dave" and "Andy", which I assume pretty obviously refer to Dave Thomas and Andy Hunt, the Pragmatic Programmers and the owners of Pragmatic Bookshelf. Some of the stories are humorous, and some of them probably would be humorous if they didn't strike so close to my own bitterly-remembered experiences. All of them do a good job of reinforcing the point, however, thus rendering the prose more effective in communicating the idea without getting to be too preachy or bombastic.

The book obviously intends to target a junior developer audience, because most senior developers have already intuitively (or experientially) figured out many of the processes described in here. But, quite frankly, I think it would be a shame for senior developers to pass on this one; though the temptation will be to simply toss it aside and say, "I already do all this stuff", senior developers should resist that urge and read it through cover to cover. If nothing else, it'll help reinforce certain ideas, bring some of the intuitive process more to light and allow us to analyze what we do right and what we do wrong, and perhaps most importantly, give us a common backdrop against which we can mentor junior developers in the science of debugging.

One of the chapters I like in particular, "Chapter 7: Pragmatic Zero Tolerance", is particularly good reading for those shops that currently suffer from a deficit of management support for writing good software. In it, Paul talks specifically about some of the triage process about bugs ("When to fix bugs"), the mental approach developers should have to fixing bugs ("The debugging mind-set") and how to get started on creating good software out of bad ("How to dig yourself out of a quality hole"). These are techniques that a senior developer can bring to the team and implement at a grass-roots level, in many cases without management even being aware of what's going on. (It's a sad state of affairs that we sometimes have to work behind management's back to write good-quality code, but I know that some developers out there are in exactly that situation, and simply saying, "Quit and find a new job", although pithy and good for a laugh on a panel, doesn't really offer much in the way of help. Paul doesn't take that route here, and that alone makes this book worth reading.)

Another of the chapters that resonates well with me is the first one in Part III ("Debug Fu"), Chapter 8, entitled "Special Cases", in which he tackles a number of "advanced" debugging topics, such as "Patching Existing Releases" and "Hesenbugs" (Concurrency-related bugs). I won't spoil the punchline for you, but suffice it to say that I wish I'd had that chapter on hand to give out to teammates on a few projects I've worked on in the past.

Overall, this book is going to be a huge win, and I think it's a worthy successor to the Release It! reputation. Development managers and team leads should get a copy for the junior developers on their team as a Christmas gift, but only after the senior developers have read through it as well. (Senior devs, don't despair—at 190 pages, you can rip through this in a single night, and I can almost guarantee that you'll learn a few ideas you can put into practice the next morning to boot.)


.NET | C# | C++ | Development Processes | F# | Industry | Java/J2EE | Languages | LLVM | Mac OS | Parrot | Python | Reading | Review | Ruby | Scala | Solaris | Visual Basic | Windows | XML Services

Sunday, November 22, 2009 11:24:41 PM (Pacific Standard Time, UTC-08:00)
Comments [0]  | 
 Thursday, November 19, 2009
Closures are back again!

Those of you who've seen me speak on Java 7 at various conferences have heard me lament (in a small way) the fact that Sun decided last year (Dec 2008) to forgo the idea of including closures in the Java language. Imagine my surprise, then, to check my Twitter feed and discover that, to everyone's surprise, closures are back in as a consideration for the Java7 release.

Several thoughts come to mind:

  • "WTF?!?!? This is a community effort?" Originally, when Sun created the Java Community Process, the tradeoff for a committee-based development process was against the open and fair inclusion of ideas from outside of Sun. But with the Java7 release still lacking a JSR (as of a few weeks ago, anyway; I haven't checked today to see if it was opened), and both the Modules facility and language extensions deferred to "Projects" (not JSRs), it seems Sun is now abandoning the JCP in favor of a Sun-dominant process that is certainly solicitous of the community at large, but not constrained or defined by it. And for the life of me, I can't tell if this is a good thing or a bad thing. It's good in that now we don't have to garner a critical mass of community momentum to get something included into the platform or language, but it's bad in that Sun has historically been the bigger drag on innovation there, not the community.
  • "Can we please stop calling them closures?" This is a nit, but technically what we're talking about adding here are either lambda expressions or anonymous methods, depending on whose glossary you're using when you're talking. A true closure is one that will compute all referenced variables from the enclosing scope and automatically include them in the generated code, which (so far as I can tell) none of the Java anonymous method or lambda expression proposals currently include. But it's a nit, so I'll say it this once and then drop it.
  • "Will Groovy, Scala, Clojure and all other JVM languages please report to the refactoring room?" People look at me quizzically when I say I'd like to see Java have closures in the language, because in general my take on language features in Java is that the Java language is more or less dead, and I could care less what happens to it; I'd vastly prefer to code in Groovy or Scala or Clojure or JRuby before writing something in Java. My rationale for wanting closures in Java, however, is this: by defining a common implementation for closures in Java, all of the above languages can refactor their implementations of anonymous methods/lambda expressions/etc into something that uses Java's closure implementation, and that'll make calling Groovy anonymous methods from Scala much much easier.
  • "Why there, now?" Devoxx is apparently turning into JavaOne Winter, because Sun's been making a lot of pretty big announcements at that show, including last year's "no closures, no built-in XML support, ..." announcement about Java7, and now this year's "well, we lied, we're thinking about closures again". Fortunately I think the Devoxx folks have much better skills at keeping their conference relevant to the Java community than JavaOne's organizers did. And I say that despite the fact (or perhaps because of the fact) that I didn't speak there this year. ;-)
  • "When is this all supposed to ship again?" Originally, my understanding was that JDK7 was slated to ship in the early part of 2010, but now rumor has it slipping to this time next year (2010). That is a huge postponement, and gives Microsoft a bit of an edge, since Visual Studio 2010 and .NET 4.0 are (again, according to rumor) supposed to ship somewhere around the end of 1Q2010. If Sun/Oracle keeps this up, we could very well be seeing a 2-.NET-releases-to-1-Java-release pattern, and that's disturbing in its own right. (Anybody else remember the days when Sun withdrew Java from ECMA, ISO and ANSI standardization consideration because they wanted to "innovate on the platform faster"?)
  • "We really have no clue what we're talking about." Aside from rumors and hearsay (including the one that says that Mark Reinhold, who made the announcement, made up the syntax on the flight from the US to Belgium), we really don't have much by way of Sun-blessed official discussions of what this will look like or act like, at least none so far as I've been able to find, so any sort of supposition on whether it will be good or suck like an inverted hurricane is a tad premature. Trust me, I want to see where this goes, too, so I'll be keeping an eye out.

In the meantime, if you want to keep on top of the Java space, maybe it's time to consider a trip to Antwerp this time next year, since, if the new ship date rumors are to be believed,  it looks like Sun (once again) is planning to use Devoxx as the platform from which to make a large announcement, this time the release Java7 itself.


Update: Ola Bini noted that...

Two things:

  • They are definitely closures. Calling them anonymous functions are incorrect, since they aren't really functions. Lambda expression is an OK name, but it has connotations that aren't really correct for a language like Java. A closure is defined as an anonymous piece of code that closes over at least one free variable, which in the case of this proposal will definitely happen. In fact, all of these will be closures, since they will be closing over the this at least.
  • This is mostly on the level of compiler, syntax and type checking, and will NOT have any real implications for runtime. This means there will be no real sharing of implementation - at most JRuby, Groovy and Scala blocks will implement another interface (but all of them already implement Runnable and Callable so it's a limited win).

which prompted me to respond thusly:

First off, I actually never used the term "anonymous function"; instead, I said "anonymous method", which, as I understand it, is how the underlying implementation of these proposals will work: the syntax "#() return 42" will create an anonymous inner class instance of an interface defined by the library (in its "SimpleClosure" example, the BGGA compiler uses the interface "javax.lang.function.I", which has one method on it, "invoke()"), which, thus, makes this an anonymous method. We can't call them "anonymous functions" because Java has no function type, and probably never will. (And yes, it may seem like we're splitting hairs somewhat to differentiate between functions and methods,but once you've explored ML, Haskell, Scala, or F#, you really begin to see a huge difference in those terms, so it's important to be precise with our terminology, or else the conversation becomes almost entirely meaningless.)

Neal Gafter uses the definition "A closure is a function that captures the bindings of free variables in its lexical context." (http://gafter.blogspot.com/2007/01/definition-of-closures.html) Given that said same post also claims that Java has no function type (and therefore, by his definition, can't really have a closure), I suppose we could split the hairs even further and suggest that Java will never have closures until it has true function types. Personally, I'm happy to say that we can swap in "methods" for "functions" in this particular discussion, but my understanding is that capturing free variables also implies capturing variables referenced in the enclosing lexical context, which the current "closures" proposal (as reported by Alex Miller's closures page) will not do. (Non-final enclosing parameters will not be accessible, only those passed in formally as parameters. Stephen Colebourne reports as much: "[Mark Reinhold] also indicated that access to non-final variables was unlikely.")

Given that the current proposal suggests the new #() syntax will essentially generate an anonymous inner class with a method of the appropriate signature (though I do believe that method handles are targeted for use at some point, based on what I've been hearing through the rumor mill), to me it feels like the "closures" implementation is generating an anonymous method of an anonymous class with a few other restrictions included--hence my commentary above.

(Having said all that, the FCM proposal does provide complete capture of all referenced variables in enclosing scope, but Mark's keynote hasn't officially endorsed either the BGGA proposal or the FCM proposal, and if Sun keeps to their habits, they won't. They'll build something that's an amalgamation of all of them. Right now the current consensus seems to be to adopt the BGGA implementation behind the FCM syntax, which jives with Neal's 0.6a specification proposal.)

On top of that, the comment "all of these will be closures, since they will be closing over the this at least" is not, I don't think, entirely true. The details of the closures proposal aren't clear, but the "outer this" (which I believe is the "this" Ola refers to above) hasn't been explicitly mentioned in any of the closures proposals I've seen, nor have I seen any text suggesting that they will honor it, so I don't know that this is true. Of course, in absence of a specification or real working bits, all we can do is just speculate. However, having said that, playing around a bit with the BGGA prototype compiler (which, admittedly, is still one minor rev back from Neal's revised proposal), I saw no generated "outer this" in the generated code for the generated inner class implementation of the closure. If the comment above is meant to refer to the "this" of the inner class instance, then that would make all methods of an object-oriented language that provided an implicit "this" a closure, and somehow I doubt that's what Ola means, though I could, as always, be wrong.

As for the runtime implementation, as I said earlier I believe the plan is to use method handles (already on the table for JDK 7), which do have some runtime implications (generally good ones, from what I can tell so far), but not beyond what was already on the table for 7.


Conferences | Java/J2EE | Languages | Ruby | Scala

Thursday, November 19, 2009 12:10:11 AM (Pacific Standard Time, UTC-08:00)
Comments [5]  |