Wednesday, November 21, 2007

Tab Sweep

Inspired by Tim Bray's periodic tab sweeps (Tim, do you collect unread tabs into the dozens like I do?) here's the first of hopefully many tab sweeps from me.

Kindle by Amazon - I've been waiting for an ePaper-based reader, but I don't think this is going to be the one. No cables or syncing? That says to me everything I read has to go through Amazon, and my existing PDFs will be worthless. Black and white. Ugly as sin ("Hello 1996? I found something that belongs to you"). Flop.

Neal Ford on JRuby and Ruby versus others (podcast) - Neal does a great job explaining JRuby to the masses while understanding the deeper reasons why it's one of the better languages for the JVM. One note to Neal: JRuby is far from being a simple port of the MRI C code; it's grown far, far beyond that now and is considerably more advanced in design and implementation.

Tim Bray's two-question Ruby tools survey - Tim's pretty good at keeping his finger on the pulse of the dev community. Guess that's why he's a director and distinguished engineer.

John Rose's report on his and my meeting with the PyPy team - John summed it up pretty well, but he's interested for different reasons than I. He's interested in finding ways to evolve the JVM to support the sorts of optimizations the PyPy JIT is performing (or will perform, where it's not complete yet). I'm interested in the possibility of a generic language toolchain that allows you to build your language of choice in a subset of your language of choice; effectively a way to quickly bootstrap a language's most rabid users directly into the implementation process, rather than forcing them to use a new language like Java or C#. If it can be done, my money's on that approach beating all "Language Runtimes" that saddle implementers with exactly the sorts of languages they don't want to use.

Glimmer - Despite sharing its name with the ill-fated Whitney Houston movie, Glimmer appears to be an interesting yet-another-JRuby-GUI-framework based on SWT and data binding. Is it obvious yet that GUI development in the C Ruby world is sorely lacking?

Greg Haygood mixes traditional JSP webapp and Rails in the same WAR - Perfectly valid. Now to start blurring the lines between JRuby on Rails and the various Java web frameworks and technologies.

Oracle Mix, the first big-time public JRuby on Rails site - A top-level oracle.com site running JRuby on Rails. That's hardcore. And I don't think they're even running JRuby 1.1, with all its performance glory. And I know about upcoming sites you don't. Future is bright.

David Bock with another OS X Java rant - But he's right about one thing...until Java 6 comes out on OS X, JRuby users will have to be content running the slower Java 5 or the somewhat-flaky Java 6 developer preview (no longer available for download). Write your congressman.

Tor Norbye's NetBeans Ruby features for last week - The guy's a machine. Awesome stuff, and more to come.

JRuby CafePress Store - Any proceeds will go...somewhere, I dunno. I just put it up because I got tired of people whining that they wanted JRuby t-shirts. I didn't bump up any prices, so who knows if there will even be any profit from them. If there is, I'll leave it be until there's something to use it for. If not, so be it. BTW: Don't get the logo on a black shirt; it won't look right.

Experiments with frameless execution - (site is down at the moment; try later) JRuby, like many other language implementations on general-purpose VMs, suffers from the overhead of heap-allocated "frame objects" that hold information about the current method call. They're needed because various languages often need per-call information on an easily accessible stack, or need to be able to tuck call frames away for future use (in closures, for example). They're overhead because the JVM already is allocating (and frequently optimizing away) call frames for the underlying Java code, and there's no way to get at those frames or overload them with new duties. IronPython is a notable example of a language impl that has opted to avoid frame objects, at the cost of some Python features. JRuby, in an effort to support all Ruby features, still has frame objects; but it may be possible to optimize them away in certain cases. The link has microbenchmark numbers for framed and frameless execution. Both are faster than Ruby 1.9; frameless by several times.

Paul Brannan's Ludicrous JIT compiler for Ruby - Promising work, and it gets some decent gains over Ruby 1.9.

6 comments:

Ola Bini said...

About Mix, yes, it's running a trunk snapshot from two weeks ago, so yeah, sure, it's 1.1.

donnacha said...

Kindle - I find it somehow reassuring that you haven't had time to look into Kindle deeply enough to get why it does, in fact, get enough things right to be a hit. I suspect that, in their quest to market a simple message, Amazon failed to emphasis some of the issues that we techies would be looking for and over-emphasized the very ones that would horrify us. All the same, the information is all there if you take the time to look more deeply into the manuals etc ... but please don't, keep working on JRuby instead!

You can upload your own files via the included USB cable or wirelessly via Amazon for 10c per document. Amazon also offers a free conversion service.

It is worth remembering that PDF, being primarily about formating, is simply not suited to any small-screened device. PDFs are for your laptop, not for sitting back in your armchair or curling up in bed. Seriously, have you seen PDFs on the Sony Reader? It's a mess. You could, of course, convert your PDFs to Word and thence to Kindle.

This is a device for reading, one whose designers are aware that they are up against one of the most established and beloved technologies ever, printed books. For speed and ease, for the ability to forget the device and get lost in what you're reading, you need the sharpness of the black and white e-ink screen, you do not need color.

Ugly? That was my first reaction too but, as the first real-world reports filter through, it appears that it looks better in the flesh and that the e-ink screen is particularly attractive. I also feel that there is a lot of sense to Bezos' reasoning behind the look: he wanted something that would allow you to simply forget the device. What we are missing when we look at the pictures is how light and comfortable to hold it it, how intuitive the page-turning is. People are saying that the keyboard does not get in the way when you are reading but is good for quick annotations.

This is not the Apple Tablet, this is not the geek-dream-do-everything-device. It allows you to carry around a pile of books, buys books, read books, conveniently check the dictionary and Wikipedia, write annotations, surf the web (in black and white) and listen to music. It is something you own in addition to a laptop, not instead of. And, yes, it will almost certainly be a hit among people who read for leisure.

Karl von Laudermann said...

"Glimmer - Despite sharing its name with the ill-fated Whitney Houston movie..."

Um, I believe that was "Glitter", and it was Mariah Carey. Or was that meant to be tongue-in-cheek, FSJ style?

Anonymous said...

Is there any info on Glitter besides the blurb on Rubyforge? I'd be interested in stea--- un, borrowing any good ideas they have for Monkeybars. Oh, and a screencast is coming soon, I promise.

Anonymous said...

As for the Kindle, it is a flop, agree. There is a cable to sync, but it will work only for TXT files and sound. For Word or PDF ones, they should go through Amazon, which is a 100% deal breaker for me. Not to mention, that Kindle will not work outside USA at all, double-flop. :)

Andy Maleh said...

This blog post contains extra information about Glimmer:

Sneak Peak at Glimmer

You can post comments if you have questions about it.

Monkeybars is cool. Let me know if you ever want help with it. I used to be a Swing'er before I crossed to the dark side of Eclipse RCP development.