· · Dynamic Languages
Other Android Languages
· I’ve been having this same conversation with a variety of programmers in recent days, and so I ought to share it with the world. I think it would be nice if you could build Android apps in other languages. The leading candidates seem to be Ruby and Python. People are working on it. This is my take on the state of play ... [32 comments]
· I owe a whole lot to Perl. So does the practice of computing in general, and the construction of the Web in particular. Perl’s situation is not terribly happy; I wouldn’t go so far as to say “desperate”, but certainly these are not its glory days ... [22 comments]
Django on Jython
· It’s starting to happen. There’s a long way to go between successfully executing a bit of Rails and actually making the sucker run usefully, as the JRuby guys will tell you. But speaking of JRuby, there are some eerie similarities: a language-platform project that was promising, then drifting, now revitalized. The ecosystem gets more interesting all the time. [Update:] Frank Wierzbicki reports that Jython is rockin’ & rollin’, it’s not just Django. Good stuff!
· Check out Antonio Cangiano’s The Great Ruby Shootout, which addresses the vexed question of Ruby performance, takes names and hands out numbers. Damn interesting numbers, too, if not terribly surprising. You want surprising? Engine Yard, which already employs Rubinius Guy Evan Phoenix, has just hired Ryan Davis and Eric Hodel to work on Rubinius. Holy crap. That makes four Ruby-implementor teams with multiple people grinding away at the problem full time. This is what they call good news. Meanwhile, the Mac corner of the Ruby World is glowing with scarlet Ruby love.
R and P
· I was reading Eric Rescorla’s First Notes on Django, which mentions in passing that the IETF is rebuilding its (currently pretty lame) tooling in Django. A few pieces of infrastructure that are important to Sun are also in Python. Meanwhile, Rails and Ruby go from strength to strength in their world. It occurs to me that there might be a pattern here: Python for utilities and infrastructure, Ruby for applications. Early days yet, but it’s not completely implausible. [9 comments]
· I suppose I could have entitled this A General Model for Progress In Adoption of Popular Programming Languages. What happened was, I was composing a rant intended for use in an internal discussion of developer futures, and it dawned on me that there’s a repeating pattern in the waves of programming languages that manage to succeed in finding broad usage ... [14 comments]
· I can’t help but notice that two really important new pieces of developer infrastructure inside Sun have something in common. OpenJDK and lots of other pieces of the ecosystem are using Mercurial for source-code management. Then there’s the new OpenSolaris Image Packaging System (think apt). The thing is, they’re both in Python. [7 comments]
On PHP and Ruby
· Check out Matt Mullenweg’s On PHP, which takes a fairly caustic look at the (slow, stalled in many places) transition from PHP4 to PHP5. The comments are interesting, too. Sometime in the next couple of years, there’s actually going to be a Ruby 2, and the Ruby and Rails communities will decide, probably without much consideration for the Ruby implementors’ feelings, whether or not to take the step. There’s a fairly widespread feeling that, as a piece of language design, the current Ruby (1.8.6) is more or less Good Enough. The Unicode handling needs to be fixed, and the libraries need some work here and there, and I see Charles Nutter proposing plausible-sounding language changes which would be invisible to 99% of developers; but there’s no big community out there waiting hungrily for the next Ruby. A version that was a lot faster would be snapped up PDQ you betcha, but few would care much about the version number. So I think the Ruby community as a whole would benefit from reading the conversation Matt started, as we try to head into the Ruby 2.* future. I personally think “runs faster and does Unicode right” will probably do the trick, but let’s see. [3 comments]
· And is there ever a lot of it. I was going to break this into a handful of targeted snippets, but anyone who cares about the language would read ’em all anyhow. Thus, an illustrated tour through Tokyo conferences, JRuby 1.0, Refactoring, and M17n ... [3 comments]
Tech Tab Sweep
· I break with my no-underlying-theme theme and do an all-technology tab sweep; in fact, almost all XML ... [8 comments]
Groovy Flickr Escape Hatch
· In the mail from Manning this week, Groovy in Action, nicely timed to follow up on the 1.0 release. I still haven’t made up my mind about Groovy, so I’m watching the community with interest. For example, Alex Brown’s Bulk Programmatic Conversion of Photos from flickr to SmugMug. There are a bunch of interesting issues all mixed up here: Yahoo’s identity ploy, wildly-contrasting Web programming interfaces, choosing from the lengthy list of Java XML-processing alternatives; and of course, watching Groovy at work. I have to say the source code is real easy to read; oddly, what it makes me wish for is regex literals in Java. Hmm, it’s not obvious to the casual eye when you declare variables and when you don’t; I’m sympathetic to the optional-declaration idea though. I guess I’ll have to have a look at the book; it was cracking the Pickaxe book’s covers that dropped me onto the slippery Ruby slope. [1 comment]
· That’d be Cédric Beust, who, writing both in my new comment system and his own space, declaims “The bottom line is that IDE’s for dynamic languages will *never* be able to perform certain refactorings, such as renaming” and asks “Who wants a refactoring IDE that ‘works most of the time’?” He closes with a major dynamic-language diss: “I'm convinced that they are not suited for large-scale software development”. Obviously a fun-loving fellow. Geek girls and boys, I think that man is getting in yo face. [21 comments]
· Following on our hiring the JRuby guys, I’ve had emails and links from representatives of pretty well every other dynamic language: Groovy, Python, Pnuts, you name it. All of them saying, more or less: “Why Ruby? There are other languages which are better (or better-integrated, or faster).” Some of them would like jobs (perfectly reasonable, we like getting that kind of email) and some of them would like Sun to assign money and resources to their language project (we like to hear about those ideas, too). So if you think those things should happen, I recommend looking at the JRuby situation for lessons. First, these guys took an existing semi-dormant project and brought it alive, unprompted, unpaid, applying energy and engineering skills to the problem in large quantities. Second, they were working in a field that has a large and growing community; in this case because of the hype around Rails. Third, they were vocal and outward-facing and articulate, getting on the stage at Java One and lots of other events with impressive demos. Fourth, they shipped code that worked pretty well and improved qualitatively from release to release. I’m not sure it’s Sun’s role to pick and choose the winners and losers in this space, or anoint leaders; what would make us think we’re that smart? But when obvious leadership emerges in an interesting space, why wouldn’t we get behind it?
· Charles Nutter and Thomas Enebo, better known as “The JRuby Guys”, are joining Sun this month. Yes, I helped make this happen, and for once, you’re going to be getting the Sun PR party line, because I wrote most of it. [Update: It strikes me that thank-yous are in order. Given that Sun is in the process of (appropriately) slashing some of its engineering groups, new hires are a little tricky. A lot of people helped, but I think the biggest contributions were from our Software CTO Bob Brewin and especially Rich Green, who approved the reqs about fifteen seconds after Bob and I raised the issue.] ...
The Ruby Ape Diaries
· I took tons of notes while I was working on the Ape. I was going to hold off publishing till I released the code, but once I actually launched the formal Sun process to do that, I discovered that it can take two or three weeks, and so I decided to go ahead while it was fresh in my mind. Unfortunately, the piece pretty soon had fifteen different sections and would have been too long for mere mortals with jobs to read, and furthermore, the sections didn’t have much to do with each other, and there just aren’t that many people on earth who’d be interested in all of them. Some of them look close at the issues of making Java and Ruby get along, while others wallow in duck-typing perversity and finer points of Ruby style. So I’ll keep them short and do one a day (or so) for the next week (or so) and fill a table of contents in here.
I. Why JRuby?
II. Back to Ruby
III. Quack Like a URI
V. << !!
VI. Java APIs from JRuby
VIII. Surface Phenomena
IX. Those Libraries
X. Making Markup
XI. Where To?
RAD XI: Where To?
· [RAD stands for Ruby Ape Diaries, of which this is part XI.] I think this concludes the Diaries, although ongoing already has a couple of five-part trilogies. The Ape works reasonably well and is getting quite a bit of use; Sam Ruby has convinced me that, rather than whittle away at the to-do list, I ought to figure out a way to build a large catalog of problems and edge cases, test-suite style, in such a way that you can add new ones without writing code. I haven’t yet figured out how to do it. My Ruby is still not fully idiomatic but it’s better than pidgin, and there’s a real possibility that the next time I get my back to a wall and need to do something to a few million lines of text right now, I may not use Perl. It should be reasonably obvious that I like Ruby. Still, there are flies in the ointment, worms in the apple, fake jewels in the shop window ...
RAD X: Making Markup
· [RAD stands for Ruby Ape Diaries, of which this is part X.] If you’re writing Web apps, and even if you’re one of the few who isn’t, you’re probably going to have write code to generate markup, HTML or XML. Historically, programmers have found this difficult, and thus there are lots of libraries that try to abstract markup away behind code (for example, my own Genx). There are tricky issues and trade-offs here, and Ruby throws them into pretty sharp focus ...
Spolsky Starts a Language War
· In Joel Spolsky’s new Language Wars, he argues that .NET, Java, PHP, and maybe Python are the safe choices if you’re going to build out a Web app that’s really big and really critical. He ices this cake with a shovelful of classic FUD aimed at Ruby and Rails. Not surprisingly, David Heinemeier Hansson volleys back twice with Fear, Uncertain, and Doubt by Joel Spolsky and Was Joel’s Wasabi a joke? Bruce Tate has a more thoughtful response over at InfoQ: From Java to Ruby: Risk. You may not agree with all of Bruce’s points, but they’re well argued. It may surprise some who’ve endured the flood of Ruby-red writing around here recently, but I think Joel’s correct that Python is quite a bit better proven than Ruby; and also that Ruby has a big Unicode problem. But I can’t get around the fact that Joel sounds exactly like a mainframe droid talking about Personal Computers, or a VMS droid talking about Unix, or an EDI droid talking about the Web, or a C++ droid talking about Java. Yeah, the new thing is kinda unproven and kinda shaky in places and kinda slow and not very full-featured. But it’s got ease-of-use advantages and programmer-productivity advantages and developers like to use it. See the Technology Predictor Success Matrix, and particularly the last three criteria: Happy Programmers, Technical Elegance, and especially the 80/20 Point. Joel’s probably wrong.
RAD IX: Those Libraries
· [RAD stands for Ruby Ape Diaries, of which this is part IX.] Ruby’s debugging facilities, compared to what IDE users like me are used to, are, well... sincere. At one point during the Ape work, I had a bug that was really driving me crazy. The symptom was that my HTTP interaction with the server would just freeze up, and I couldn’t spot the pattern behind it. It’s a fact of protocol-testing life that this particular kind of shit happens. Sometimes you’re reduced to debugging with print statements, and I was. But after a while they weren’t helping me, I was calling
Net::HTTP#start on an apparently-valid connection and then... nothing. Eventually, I was driven to looking in the library source,
net/http.rb. Hey, it was easy to understand! (Have I talked about Ruby and readability before?) I could see where my request was going, but I couldn’t see how it could go wrong. Well, this is a dev machine, and Real Men debug with
print statements. So in they went... right into the Ruby distro libraries, I mean. And I ran it again. Only took a couple of minutes to zero in the problem; in this case, a JRuby bug. I’m not sure what the lesson is... but the code spelunking was frighteningly easy. This is not typical of other peoples’ HTTP libraries; I have bitter memories of bashing my head to a bloody pulp against LWP back in the last millennium. Did I mention readability? [Ed. Note: You’ll be happy to hear that there are only a couple more RAD entries in the pipeline, then I’ll be done.]
RAD VIII: Surface Phenomena
· [RAD stands for Ruby Ape Diaries, of which this is part VIII.] Programming is supposed to be an engineering discipline, or maybe a branch of mathematics. But, as Don Box memorably said: “the only people who should do it are those who can't not do it”, calling us “those few people who absolutely must live in the world of executable abstractions”. One consequence is that we’re passionate about the content and the form. Herewith some remarks on appearances; the way Ruby code looks and how you store it and so on; issues as important, perhaps, as any other ...
RAD VII: J?REXML
· [RAD stands for Ruby Ape Diaries, of which this is part VII.] In native Ruby, the default way to do XML processing is via the REXML library. In JRuby, you have another default choice—Java’s built-in XML APIs. Neither option is that great. Still, there are some reasonably safe ways to get the job done. I wrote some glue code called JREXML to make the Java APIs look more like REXML, which forced me to think about this stuff perhaps more than is entirely healthy ...
RAD VI: Java APIs from JRuby
· [RAD stands for Ruby Ape Diaries, of which this is part VI.] The reason I first built the Ape in JRuby was so I could get at all those nice Java APIs, and that turned out to be a good reason. Of course, there is a bit of impedence mismach, and I ended up writing some glue code. I kind of suspect that, should JRuby catch on, there’s going to be scope for quite a bit of this glue-ware. This fragment is just a few examples of the genre, to provide examples and perhaps provoke thought ...
RAD V: << !!
· [RAD stands for Ruby Ape Diaries, of which this is part V.] If you look at Ruby code, you keep seeing this little two-character motif
<<, and maybe everyone else already knew about this, but it sure feels like magic to this farm boy from the Prairies. Bonus: Lisp speculation ...
RAD IV: TMTOWTDI
· [RAD stands for Ruby Ape Diaries, of which this is part IV.] That glob of letters in the title stands for “There’s More Than One Way To Do It”, and it comes from Perl culture. It is a distinguishing feature of Perl that if there’s something you need to do, not only does Perl have a way to do it, it has lots of different ways. Perl’s legion of evangelists, led by Larry Wall, argue that this is an advantage. Larry has a compelling argument by parallel with linguistics; natural languages usually have many ways of saying anything that’s worth saying. Not everyone agrees that this is a virtue; in particular, Pythonistas have historically grumbled. Ruby seems to fall into the Perl camp. And now, dear readers, I must confess to a bit of duplicity. When I wrote RAD III: Quack Like a URI, I knew that my example was perhaps not the purest possible example of duck typing, but my hidden agenda, namely gathering material for a TMTOWTDI essay, worked out well ...
RAD III: Quack Like a URI
· [RAD stands for Ruby Ape Diaries, of which this is part III.] This little illustration of a programming idiom is solely designed to horrify newcomers from the Java world, and will look mundane to existing Rubyists. Problem: I want to check a URI to make sure it’s appropriate for use in the Atom Protocol, and if not, report a coherent error message ...
RAD I: Why JRuby?
· [RAD stands for Ruby Ape Diaries, of which this is part I.] To build a validator you need an HTTP engine and an XML parser, both of which Ruby is advertised as having. JRuby, when I first took this on, was as at release 0.9.0 and had plenty of rough edges. But I decided to use it anyhow ...
OSCON—Perl & Python
· I managed to attend most of both Guido van Rossum’s talk on Python 3000, and Larry Wall with Damian Conway on Perl 6. It’s refreshing to look at technologies that have passed that tenth birthday that seems to be crucial for software to establish that it’s real, and to see that they’re living and squirming and growing. Python, per its culture, seems to be treading a straight-and-narrow path on a well-defined schedule guided by a ruthlessly rational set of design criteria. On a technical note, Python 3 will have a String type that is 100% Unicode and that’s all it is, and separately a byte-array type that lets you indulge your most squalidly-perverse bit-bashing fantasies. I approve. Perl, on the other hand, is whimsical and witty and unscheduled and blithely disregards many genera of conventional wisdom. One could easily have concluded, listening to Larry and Damian, that the problem with previous versions of perl was that they didn’t have enough syntax, and thus there was an urgent need to add more. It ill behooves me to diss Larry Wall’s language designs, since I have successfully internalized all but the most perverse (typeglob, blecch) of those that are here today and they have enabled me to wrangle large amounts of data in surprisingly little time with generally-popular results. Nothing would warm my heart more than Perl 6 leaping to the center of the dynamic-language stage and reclaiming mindshare. The jury’s out.
· I have previously admired the Ruby language, albeit from a distance, and been impressed by the vigor of the Rails community. In the last week I have written a few hundred lines of Ruby code that actually do something useful and I’ll probably release (come see it at OSCON); so now I’m somewhat better educated ...
Rubies and Pearls
· I’m still feeling my way into this comments system, but my first days with Ruby are making me think back a dozen years or more, to when I was learning Perl. It was a big data-filtering job and Michael Leventhal had pulled together a very typical Perl bundle-of-regexps and suddenly one day I was pitching in on handling more types of input data and pulling out more structure. Larry Wall, the author of Perl, is a linguist by training, and is proud of the fact that with Perl, as with a natural language, you don’t have to be an expert to be effective Just as a child derives value from using English even if inexpertly, a novice Perl programmer starts being rewarded quickly. Other languages have this characteristic to a greater or lesser degree; and I’m beginning to think Ruby is right up there. (For me, Java had it too, as it would I think for any expert C programmer comfy with O-O thinking.) At the moment, there are lots of Ruby idioms that are still gibberish to me; but I find two crucial things: my pidgin Ruby is already pretty useful for getting things done, and I’m learning new tricks.
· We push technology along slowly, gaining a bit here and a bit there. Most improvements, in anything, are incremental; the big advances, every one of ’em, are rooted in the fertile soil whose grains are all those little steps forward. Here are a few grains. Item: Bruce Eckel squeezes XML into a single Python class. Item: Niall Kennedy pulls together all the syndication specs you might need; for example see atom.feedspecs.com or itunes.feedspecs.com. Item: Peter Thomas pulls together a spine-chilling graphic mapping what happens around a Hibernate
storeItem call. Question: is what this picture shows a problem or not? Item: Charles Nutter pushes the JRuby Gems along, interestingly (and read the comments).
Go Visit Phobos
Canada on Rails
· As I was picking up my badge from the slinky black-cocktail-dress-wearing women (huh?) at the registration desk, this guy came running up saying “We’re sold out! Don’t sell any more!” And the conference was packed, all right. Herewith notes on DHH’s keynote, the crowd, and BDD from Dave Astels ...
Rails in Vancouver
· It turns out they’re holding what’s advertised as “the first ever 100% Ruby on Rails event in the world” right here in Vancouver, April 13-14: Canada on Rails. I’ll go for sure. Given the enthusiasm that built up around that PHP piece, I’m thinking that a comment system for ongoing is inevitable, and maybe RoR is just the ticket. [Snicker... the URI of the registration page ends in
LAMP and Java
· Take a minute and read Stephen O’Grady’s write-up, which starts at the Sun Analyst Conference, but says a bunch of things about Java and LAMP and related subjects. I’ve been thinking about this stuff almost all the time for the past year or so, so let’s take his ideas a bit further ...
Shiny Red Rock
· It’s about That Language. All the software fashion slaves will tell you: down on the plantation, Massa’s new missus is a far-Eastern belle named Ruby. Herewith Ruby remarks: on the Pickaxe, slickness, language learning, and duckstatic typing ...
More Dynamic Java
· It’s pretty clear that dynamic languages are a hot area, maybe the hottest, in the world of software development. We need to do more to make them easily usable by people in the Java ecosystem. So on Tuesday we held a summit here at Sun, with a few of our internal Java leaders, and on the dynamic-languages side, Larry Wall and Dan Sugalski (Perl and Parrot), Guido van Rossum, Samuele Pedroni and Sean McGrath (Python), and James Strachan (Groovy). It was an educational day for us; herewith some take-aways and pictures ...
· I was on the phone this morning to the Italian part of Switzerland, talking to Samuele Pedroni, currently chief priest in the Jython temple. I think Jython is real important, which means that I think Samuele is important. But only if you care about Java ...
By Tim Bray.
The opinions expressed here
are my own, and no other party
necessarily agrees with them.
A full disclosure of my
professional interests is
on the author page.