Lambda the Ultimate

On Ruby has an interview with two members of the Diamondback Ruby team.

There is a long-discussed tension between statically [...] typed languages like Java and dynamically [...] typed languages like Ruby. My hope has been to discover how to include the best aspects of static and dynamic typing in a single language. We all really like Ruby's design and features, and felt it was the right language to start with. As we go, we'll look to derive general design principles that make sense for most any programming language, to simplify and improve the process of programming generally.

The interview covers DRuby's goals as well as a bit about its OCaml based infrastructure. More technical information about DRuby's type system can be found in Static Type Inference for Ruby.

A short audio presentation (Avi speaks for less than ten minutes, I guess), about the lessons the Ruby community should learn from Smalltalk. It's mainly about turtles-all-the-way-down, but Self (fast VMs), GemStone (transactional distributed persistence), Seaside (web frameworks) are also mentioned briefly.

The video and slides of David Pollak's BayFP presentation on lift are available online.

While the thrust of the talk is on lift as a web framework, you get a very nice intro to Scala along the way, and David even mentions a quick way to get a PLT PhD, for those interested in that sort of thing...

The End of an Architectural Era (It’s Time for a Complete Rewrite). Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland. VLDB 2007.

A not directly PL-related paper about a new database architecture, but the authors provide some interesting and possibly controversial perspectives:

• They split the application into per-core, single-threaded instances without any communication between them.
• Instead of using SQL from an external (web app) process to communicate with the database, they envision embedding Ruby on Rails directly into the database.
• They state that most database warehouse tasks rely on pre-canned queries only, so there is no need for ad-hoc querying.

The somewhat performance-focused abstract:

In two previous papers some of us predicted the end of "one size fits all" as a commercial relational DBMS paradigm. These papers presented reasons and experimental evidence that showed that the major RDBMS vendors can be outperformed by 1-2 orders of magnitude by specialized engines in the data warehouse, stream processing, text, and scientific data base markets.

Assuming that specialized engines dominate these markets over time, the current relational DBMS code lines will be left with the business data processing (OLTP) market and hybrid markets where more than one kind of capability is required. In this paper we show that current RDBMSs can be beaten by nearly two orders of magnitude in the OLTP market as well. The experimental evidence comes from comparing a new OLTP prototype, H-Store, which we have built at M.I.T. to one of the popular RDBMSs on the standard transactional benchmark, TPC-C.

We conclude that the current RDBMS code lines, while attempting to be a "one size fits all" solution, in fact, excel at nothing. Hence, they are 25 year old legacy code lines that should be retired in favor of a collection of "from scratch" specialized engines. The DBMS vendors (and the research community) should start with a clean sheet of paper and design systems for tomorrow's requirements, not continue to push code lines and architectures designed for the yesterday's requirements.

A critical comment by Amazon's CTO, Werner Vogels.

I am a bit reluctant to post about this, since many of the issues involved are not programming language related. I hope we can manage to avoid discussing these issues here - there are plenty of better places to discuss them.

Still, many issues that are raised in this multi-blog discussion about the performance of Rails, and Ruby in general, may be of interest from a programming language perspective. More important, in my opinion, is to put this discussion in the context of the recent revival of frameworks. We discussed many of the recent interesting libraries and frameworks. Let me point out that not only are we reaching a point where languages and frameworks are judged together (with "Ruby on Rails" a classic example), but more and more libraries make use of advanced programming techniques that were considered arcane and esoteric not long ago (e.g., jQuery use of closures, metaprogramming and code generation etc.) This is an important development, and an interesting area to keep an eye on.

An interesting visual comparison of the grammars of Ruby, Java 1.5 and Javascript.

Anyone care to interpret the graphs?

Two opposed views about the "no continuations in Ruby 2.0" announcement:

Patrick Logan: Ruby Sucks?

Don Box: Two Excellent Things for Ruby at Microsoft.

Back when Python was all the rage, we often discussed metaprogramming tricks in Python. Well, it seems the metaprogramming action has moved to Ruby, just like everything else... ;-)

I'm back... Going through my RSS feeds, two items caught my attention:

Tim Bray: Charles Nutter and Thomas Enebo, better known as “The JRuby Guys”, are joining Sun this month.

Jon Udell: Why argue about dynamic versus static languages when you can use both? Which discusses, among other things, why the first three versions of the IronPython compiler were written in Python, but today it's written in C#.

I’ll jump to the conclusion first. For people like me, who are proficient in Perl and Java, Ruby is remarkably, perhaps irresistibly, attractive.

Tim Bray shares his experience with Ruby.

The main advanatges seem to be more readable code, that the language seems to encourage short methods, and the lovely comuunity. Sounds good to me...