Well, I learned an important lesson from this contest — never try to run a contest when your judge is going to be in Hawaii, there's no way you can compete against the beach.
In better news for the rubinius community (and for our winner), I did eventually get enough of Evan's attention to pick a winner. After a lot of thought, Evan's decided on a new name for RNI. Zed's subtend is the winner, and I'll coordinate with him to get his choice of books off to him.
I've been thinking about starting a tumbleblog for a while now, but haven't wanted to bother setting one up. Now, Tumblr has made it too easy for me not to do it. Watch On Ruby (the tumbleblog) for quick posts as I run into them.
In this episode, Kevin and I talk more about Parrot and objects, other Ruby implementations, and some of the sources Kevin's been working with.
The big news in alternative implementations was a shootout by Antonio Cangiano. While I think this is still a bit premature (only YARV and Ruby 1.8.5 complete 100% of the tests, see chart below), there's a lot to learn from it. I think it can help each of the alternative implementation projects to see where they can focus some of their effort to really improve their version of Ruby.
I know Cardinal been blocked by the lack of solid Object support in Parrot so far, but what do you think can be done to help get Cardinal 'over the hump' so that you (and other contributors) can really get some momentum going?
Kevin: Attempts could be made to work with the current object system in Parrot. Having seen the trouble others have had with the current object system, I have decided that it is not worth my time to work with the object system as is.
Allison Randal has checked in a PIR based MOP called Simple Meta Object Protocol (SMOP). SMOP in its current form only supports attributes and parent classes. Support for methods needs to be added. I have the initial translation of SMOP to C based PMC coded up. The translation however, depends on the ability to call C PMC methods from C with PIR calling conventions. I have a plan to implement this functionality and call it PMINVOKE. This is the corresponding piece to PMETHOD functionality which I recently added to Parrot. PMETHOD allows C PMC Methods to be implmented with PIR calling conventions.
You've talked about wanting to build a MOP based object system, what advantages does that have for Cardinal and Parrot?
Kevin: MOP is a huge win for Parrot. MOP will allow common Parrot infrastructure pieces to be reused to implement the distinct object systems features that each language has. Parrot developers hope that a common Meta-MOP will permit the different object system philospohies of each language to interoperate at some common denominator level. At a minimum a common Meta-MOP will permit language implementor write object system translators. JRuby is having to do this with the Java and Ruby object systems, but without the help of any low level tools or common meta object subsystem.
As you see the JRuby and rubinius teams moving ahead, what pieces of their work do you think will apply to Cardinal?
Kevin: I think the knowledge base that they possess will be beneficial to Cardinal. The JRuby and rubinius projects currently trade and share a lot of insights about the problems areas of MRI. I'm a little disappointed that the alternative implementations have not built more common infrastructure in Ruby itself. Parsing is a real problem. I believe alternative implementors should build a common ruby parsing library to support rich parsing constructs that would make parsing ruby easier. Building a parsing framework is difficult, but adding code generation backends to a completed parsing framework would be relatively easy. Antlr and Perl 6 Rules are excellent examples of parsing frameworks with multiple code generation back ends. I am as guilty as the next implmentor in this respect, because Parrot provides a very rich parsing framework (Perl 6 Rules) which I'm proponent of.
Dan talked about using the plethora of papers on optimizing register based compilers to help improve Parrot. What papers and/or projects are you watching to help with your work?
Kevin: I've read the traits papers that discusses role composition. I've also checked out and read the CLOS MOP book. The traits papers have been very educational. The unanswered question is how to compose or accomidate state. I think a mix of the C++ multiple inheritance paradigm and explicit annotations as advocated by the traits papers may be the solution for composable state.
Given Kevin's work with on and MOP, the only sponsor that made sense this week was The Art of the Metaobject Protocol
If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:
James Gray has also started a serial interview. He's talking with Matz and Koichi. His first episode introduces them and discusses the recent merger of the VM formerly known as YARV and Ruby 1.9.
You might also enjoy my new Serial XRuby Interview or the original serial interview with the rubinius team.
One of the least known alternative Ruby implementations is the XRuby project. The programmers behind the project have been doing some great work, and deserve more visibility. I thought it would be fun to do a serial interview with them to help get XRuby in front of a bigger audience.
Would you please introduce yourselves and XRuby?
dreamhead: My name is Ye Zheng, but you can call me dreamhead. I became a programmer for my interest. In my career, I've experienced server application development and image recognition research. Now I'm applying myself to data parallel on multi-core platform.
I joined XRuby team in Sep. 2006. I'm the first member besides Xue Yong Zhi. At that time, I just translated some chapters of Ruby Hacking Guide from English into Chinese. I got some knowledge of Ruby implementation from RHG. Xue Yong Zhi called for contribution to XRuby. I decided to join the team, because I have Java experience and Ruby is my latest favorite programming language, but the most important is that I had a great opportunity to construct a compiler. I have the strong interest in the programming language implementation all the time.
At first, I wrote some builtin code. After studying the runtime of XRuby and C Ruby, I developed a new runtime which will be merged in XRuby 0.2.0. XRuby is a good team. Every member is kind and every attempt is encouraged.
Besides programming, I like reading. There's a lot of books in my room. I also like writing. I've written down some understanding of Ruby implementation on my blog which is in Chinese.
Yu: My name is Yu, I've already graduated, and am a software engineer in Shanghai. I joined this team in Nov. 2006. I implemented a rough "javasupport" component, some built-in types and their functions.
When I'm not programming, I like to play squash (you may call that racket ball), watch movies, and cook.
As to XRuby, it's so great a project. Xue Yong contributes most code, and Ye Zheng implements the new run time. They are all excellent developers. It's my honor to work with them together.
Xue: I am a software engineer and live and work in Maryland. I started XRuby because (at that time — almost two years ago) there was no ruby compiler available, and I feel like it is an interesting idea to write a ruby compiler for JVM/CLR.
XRuby is a ruby compiler that compiles ruby scripts to java bytecode, so that a ruby program can run directly on top of JVM. The output of the compilation is a jar file, which you can launch like a regular java application.
Actually I had a quite ambitious goal when the project started, I thought after finishing the compiler for java, I would create one for .NET, then a pure ruby implementation & that is why it is named 'X'Ruby. Right now it is definitely not happening as the compiler for java has taken all my spare time, meanwhile projects like Ruby.NET and rubinius have emerged to be the lead in these fields.
For quite a long time the code just sat on my computer and I progressed slowly due to the lack of time after busy day job. In September, 2006 I uploaded the repository to google code and posted an announcement to some maillists and online forums.
Most of the messages got little attention but one posted on a Chinese ruby forums received good response, that's how Ye Zheng, Yu Su, Jie Li found the project and joined. The extra hands give great lift, and finally we put together the first public release this year.
dreamhead: Besides Xue Yong Zhi's XRuby description, XRuby gives us a opportunity to let Java and Ruby work together. This means that we can combine development efficiency(Ruby) and abundant resources(Java).
The rubinius team has mentioned using your parser for their project. How much interaction do you have with the other non-standard Ruby implementors?
Xue:I encourage other people to use/hack/break our parser. It is in very good shape and is much easier to maintain (thank to the power of ANTLR). And I will be very happy to help if they need. Btw, The v3 version of ANTLR may have a ruby backend that generates ruby code.
I have chatted with Charles Oliver Nutter several times and he kindly updated me on Sun's effort to support dynamic language on JVM. And I was amazed by his great effort to turn Jruby from a near death project to a vital community.
dreamhead: We've contributed our front end to rubygrammer project. I hope it is helpful.
Given XRuby's ability to compile Ruby down to Java bytecodes, this episode's sponsor is Beyond Java
If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:
James Gray has also started a serial interview. He's talking with Matz and Koichi. His first episode introduces them and discusses the recent merger of the VM formerly known as YARV and Ruby 1.9.
You might also enjoy my new Serial Parrot/Cardinal Interview with Kevin Tew or the original serial interview with the rubinius team.
O'Reilly has just released the Rails Cookbook
The Rails book market is getting full fast. Other than the O'Reilly name, what sets this one apart? Why should people buy it?
Rob: Well, from a developer's point of view, more books to choose from is not really a problem at all, right? Also, no market is ever really full — it just becomes unprofitable to participate in. Since profits from direct sales were not my motivation, it's up to each publisher to decide whether they want to push another Rails book into the market or not.
When I was asked to write a book on Rails, it was initially going to be
Rails Hacks or Head First Rails. After some discussion, we decided to write
the first cookbook on Rails. I did a little investigation and saw that
Rails Recipes had been in the works but then was stalled for some reason.
It wasn't until about two months into it, at O'Reilly's sales conference,
that Andy (of the Prags) announced that Chad would be picking up Rails Recipes
At that point I was a little concerned about duplication between the two cookbooks. It turns out though that our books are really very different. Chad's book is 70 recipes that range from intermediate to advanced, while my book has 190 recipes that really cover a much broader spectrum — covering many of the basics through some pretty advanced rails concepts.
Of course, my book took a lot longer to write, so we really ended up covering the framework at different times. The bottom line is that there is very little duplication between the two cookbooks and the consumer has the luxury of choosing between the two — or they can buy both.
I think that i did a pretty good job of covering all the material that a Rails developer need to know in order to become productive, fast. So far I've been getting good reviews but I encourage people to check out the table of contents to make sure it's the right book for them.
What is the appeal of the recipe approach in books?
Rob: The way that different people tend to learn is a very complex subject. Everyone might take a unique path towards mastery of a specific technology. I find that when I'm learning something new, I make a series of "passes" over the subject. The initial fly-over is analogous to skimming the table of contents of a book. Each subsequent pass reveals more details and hopefully leads to a more in-depth understanding of the subject. In terms of Perl books, for example, Learning Perl may be an initial fly-over where Mastering Perl for Bioinformatics would be much later pass. This is one dimension; that of varying degrees of complexity.
In addition to complexity, there's granularity. Think of granularity as the size of the chunks of information that are being presented within a book. A very small chuck might be a line from a Pocket Reference that says to use "params" instead of "@params" while a large chunk might walk you through the creation of an entire web application. The level of granularity I prefer in a book at any given time depends on how in-depth an understanding I need combined with how much time I have available at that moment.
I see a cookbook as a highly indexed body of medium sized chunks of information that vary in complexity. A cookbook is something you reach for as you're developing. You have a problem that you're trying to solve and you want the answer as fast as possible. The idea behind the cookbook is that you look in the list of recipes (and then their problem statements) and find something that resembles your problem, and then you have your answer. That's the goal anyway.
I don't expect that the cookbook format is right for everyone but I think having it in the selection of books a Rails developer has to choose from is critical.
You mentioned a Head First book. Do you think we'll see a Ruby book from the Head First team?
Rob: I expect so but I really can't say for sure. Head First books differ drastically from traditional books in that they only work with the perfect author. I'm sure O'Reilly is looking for that author but I'm not sure what the status of that is. I'll keep you posted.
What kind of Rails development were you doing before you started on this book? How did that experience affect the book?
Rob: About the time I started working at O'Reilly my wife and I decided that we needed to try to raise our kids on a single income. This meant that I had to fire up my contracting business up in order to supplement my O'Reilly salary. This was right around when Curt Hibbs posted his first Rails articles to O'Reilly's OnLamp.com. My Rails adoption route was probably similar to most; starting with amazed curiosity, followed by a healthy amount of skepticism ("Does it scale?", etc...), and finally by the confidence that Rails is, in fact, a better way to develop web applications efficiently.
I can't boast about any high profile Web 2.0 Rails projects but I had no trouble finding a steady stream of Rails work. I really got wrapped up in the excitement of Rails and wanted to share it with my friends and others. At that point I did couple of talks on the subject. In fact, it was at one of these talks (at a North Bay Linux User's group meeting) that I was approached by Mike Hendrickson from O'Reilly about doing a Rails book. Incidentally, Mike (an executive editor) and a few other O'Reilly brass were playing poker around the corner form our meeting.
Basically, I didn't enter the Book writing process as a total noob to Rails, but neither was I a Rails expert. Much of what I've learned about Rails, beyond my contracting experience, has been from researching and writing the book. Ironically, I think this is part of what makes this book work. I know the learning curve that new Rails developers are up against and I believe I've offered a clear and no-nonsense path past it, towards the end of being self-sufficient with the framework. But also remember that much of the book was contributed by other members of the Rails community — many of them having a enormous amount of Rails experience and expertise in areas that I was lacking.
With Rails 1.2 out now, how much of your book is already obsolete? How do you write a book against a target that moves this quickly?
Rob: You'll notice that the book states on the cover that it's been updated for Rails 1.2. This is because I made the decision in December to pull the book out of O'Reilly's production process in order to update it for Rails 1.2. At that point we already had a chapter on RESTful Rails development so there wasn't as much to update as you may think. Still, there was plenty of work to be done. Luckily, I had the help of a couple of my good friends; Christian Romney and Ryan Waldron.
I wasn't really sure when Rails 1.2 would emerge from it's release candidacy but the timing really couldn't have worked out better. My book went on sale a single day before Rails 1.2 released.
As for writing about a moving target, such as Rails; It was a challenge. There were many parts that I had written months before that had to be revised as new features appeared and as old techniques became deprecated. The good news is that you can see most new developments coming from pretty far off by staying in touch with the community and by following changes to the framework via the Rails Trac project and/or blogs of the people driving Rails development.
Part of what makes Rails exciting is it's flexibility to change with the evolving needs of the Rails community. While trying to document things as they change is sometimes difficult, I really wouldn't want it any other way.
What is your favorite recipe from the book and why?
Rob: One cool recipe that I've been thinking about recently is titled "Creating a Custom Report with Drag and Drop" in the JavaScript/Ajax chapter. The idea behind this recipe came from a Rails application that we use at work called Dove, written by John Butler. The idea behind Dove is that it allows users who don't know SQL or much about the complexities of our database to easily create custom reports from our database. Roger Magoulas, of O'Reilly's research department, designed Dove to be a web-based version of query tools like Brio.
Because of the back story of this recipe, it was interesting to see it mentioned on the Ruport mailing list recently. Someone suggested that a Ruport plugin for Rails should be created based on the techniques demonstrated in this recipe. Come to think of it, maybe I should work on that.
Have you spent any time looking at other web development frameworks? What can Ruby on Rails learn from them?
Rob: Over the years, I've had to deal with many web applications that probably should have used a framework, and occasionally some that were designed well enough that they could have had a framework extracted from them, but didn't. To confuse the issue, I've used many components of frameworks. For example, I've used several different ORM (object relational mapping) layers, and as many different stand-alone template languages. Rails is really the first full-stack framework that I've used for more then a single project.
Before discovering Rails, I was shopping around for a framework and was hoping to find a suitable one in the Python world. When I was webmaster at Industrial Light and Magic I was introduced to Zope by a friend (Jed Parsons). He was using it successfully for a large documentation management system for ILM's training department. My impression of Zope was that if you could climb its very steep learning curve then you could eventually be very productive. This seemed like a bit more then I needed at the time so I started checking out CherryPy — a lighter weight Python framework. (This must have been before Django and TurboGears were out in public.) Unfortunately, I never got a chance replace the Servlet/JSP based intranet I was in charge of before leaving ILM.
Shortly after starting at O'Reily, I jumped into my first Rails project with a friend of mine, Ben Bangert. We learned Rails together as we rebuilt a client's site that had been running PHP-Nuke. After that project, I worked on a few more Rails gig before eventually starting on the book. Ben, on the other hand, began writing Pylons. It's funny; the whole time I was writing the book, I had Ben IM'ing me about how he didn't like one thing or another about Rails, and that he had "fixed" it in the framework he was working on (Pylons). Pylons is built to work with the WSGI standard (Web Server Gateway Interface) and supports the idea of pluggable middleware layers. You can stack these layers together as needed. I think this could be an area for Rails to learn from, in terms of clean and standardized way to extend the framework. Rails plugins are great but there is no way to know if one plugin is going to work with another without testing them together. I think Pylons and the WSGI standard have a good solution for this.
What do you think are the most glaring weaknesses of Rails?
Rob: This might sound like an odd point, but I think it's the explosive growth of the framework. It may be that this growth is exposing weaknesses that might not otherwise have been problematic. The rate at which people are jumping into the community is really presenting some difficult challenges. The Rails mailing list is extremely high-volume and is almost a full-time job to monitor. Because of this, many people (some who may have a lot to offer new users) opt out and retreat to more private discussion venues. The same goes with the IRC channels. I assume this will all work itself out as more people get Rails experience under the belt, but this almost frenzy-like growth has definitely been an issue. I don't mean to say that growth is a bad thing for the framework — we just need to work on the logistics of being able to handle that growth.
Documentation is another weakness and one of the areas that suffers most in Rails. The early adopters tend to want to document the most advanced areas of the framework and report on new features the moment they see the light of day. This really leaves the bulk of the community without consistent documentation for some of the mostly commonly used areas of Rails. This is why I think my book is such a good fit right now. I tried to compensate for what I see as a void in general Rails documentation.
A final weakness that I'd like to point out is about process. I would like to see the Rails core be more traditional (professional, whatever) about their software release process. The way we bounced from Rails 1.1.4 to 1.1.6 (I call this Revision Reverb), and how the security flaw that caused all of that was handled, needs work. Open source works best with predictable release practices and security notification systems. Of course, all of this has been hammered out now, but I'd like to see Rails adhere to more established best-practices in its management. I'm sure we'll see improvement going forward, but I has been a weakness.
If you weren't programming in Ruby and Ruby on Rails, what languages and frameworks would you be using?
Rob: In response to a literal interpretation of that question: I don't feel that because I build a lot of Rails apps or even because I wrote a book on the subject, that I can't use other languages or frameworks. In fact I do. I love that I have the freedom to choose the best tool for the job. I like to think that I'm a pragmatist about the tools and languages that I use for any given project. I do feel strongly about Open Source tools and I always lean towards them when possible.
If I wasn't programming in Ruby and Rails, that would have to mean that they didn't exist. If that was the case, my top choice for a language would definitely be Python. As for a framework (again, assuming Rails was off the table), that would necessarily have to be Pylons because otherwise I'd never hear the end of it from Ben (who I sit next to all day).
What non-Ruby/RoR books should Ruby and RoR hackers be reading?
Rob: This one I can answer with out blowing anyone's cover, but
what complicates the question is that so many people are coming to Rails
from different backgrounds. So, I could repeat a fairly standard suggestion
that software developers read the 'gang of four' Design Patterns book but
getting a designer to work through that book might be a bit much to ask.
For most people I think Chad Martin Fowler's Refactoring
is a much more digestible approach to design
patterns, as well is O'Reilly's Head
First Design Patterns. Any kind of object-oriented design pattern
homework a developer can do will payoff, especially with larger Ruby and
Rails projects.
Database design is another topic I think that many Ruby/Rails developers
could read up on. One of my first books on the subject was Database
Design for Mere Mortals. I don't think you need to go too deep with
database theory but you need get to a point where a metal alarm goes off
when you see a bad database design. After all, this is the foundation of
your application and problems born here will reverberate up the stack and
potentially cause a lot of problems.
Another category of books that developers should read are on sound
development methodologies. Right now, the Pragmatic Programmers have a
number of good ones in this area. Practices
of an Agile Developer is a good one to start with that will resonate
well with common practices found in both the Ruby and Rails
communities.
What I do is read up on whatever interests me at any given moment. When I hear about a new gem or a topic from someone, I add it to a text file that I store in subversion. This serves as a "todo" list of things to investigate, as time allows. One way to chisel away at this list is to divide the investigation up among a group. This is a great thing to do in Ruby or Rails user's groups or even your software team at work. Having other people do the leg work of looking into a new topic can help you stay on top of more subjects then you might be able to follow up on alone.
Well, after much reading and deliberation, we have a winner!
Jason, Jarkko, and I sat down and read all the entries from the January blogging contest — "How has Rails made me a better programmer". There were a lot of great entries, and some very fun writing styles. We each rated all the posts, giving them a score of 0-3 (more points is better). Then we combined our scores and took the top five to deliberate over.
The winning entry was: How Rails made me a better programmer by Christian Neukirchen. If you haven't read the other entries, they're worth a look.
Chris has already chosen his prize:
Good looking stuff. If you're interested in picking up some free books for yourself, why not try your hand at this month's challenge, "How has Ruby blown or stretched my mind?"? All you need to do, is write a blog post, and post a link to it in the comments of the contest page.I'd really like to thank Jarkko and Jason for helping me judge this contest; Apress for providing the prizes; and, especially, everyone who participated in January and so far in February — this series of contests just wouldn't work without you.
With the great work that the rubiniius hackers in Portland, Oregon have been doing I thought I'd better sit down with them and find out more. Given their plans, we may see a few installments of this side interview.
I think you might be the first .rbc (rubinius coders) group around. I'm jealous. How and why did you guys start this up?
Thomas: I'm not really sure who got the idea rolling, but Aaron happened to mention an interest in rubinius at our last PDX.rb meeting (I missed the beginning of the meeting, so this probably had come up earlier). I expressed similar interest and he suggested getting together to hack on it. I don't know if the discussion with Phil and Brian happened before or after our conversation, but I was sure that it was the right approach to get the ball rolling. Trying to tackle a new project like rubinius is a bit intimidating, but when you have someone else sitting there to bounce things off of, it makes it a little less so.
Phil: I have been interested in Rubinius for a couple of months now, but it seemed to be moving so fast that it was difficult to get a hold on what was going on. When Aaron and I found out that Brian was involved in rubinius development it seemed like a great opportunity to for him to be our 'guide' to rubinius. It's great to be able to ask questions about the history of the code or why something was done. There's not a huge amount of documentation in Rubinius yet (hopefully that's changing) so it's tough to jump in and start contributing without someone to help explain how things are organized and why they are that way.
Brian: From my view, it was rather impromptu. When I attended the 2/6 pdx.rb meeting, I wasn't prepared to or planning on saying anything about Rubinius. Aaron and Phil piped up and I thought I'd throw my 2 cents in. I didn't think I had that much to contribute. Later in stroll over to LuckyLab (a nearby bar) Phil suggested getting together. Aaron posted an event to the pdxruby.org site and we met. Of course, I was thrilled to see some local interest, so I came prepared with a whole list of things we could work on. :) Irb seemed like a good place to start. If I have 2 tabs open in iTerm, one is probably IRSSI and the other is surely irb.
Aaron: I asked at the monthly pdx.rb gathering if anyone was interested in working together to contribute to rubinius. Both Phil Tomson, Brian Ford and myself had already signed up for commit rights. It quickly became apparent that Brian was up to speed on the activity in the irc channel and commit logs.
I really enjoyed meeting the guys up in Seattle a few years ago and have always hoped to be able to contribute to their on going projects. I like building groups that help each other, instead of rivalries.
I also feel more comfortable meeting in person to ask questions. Old habit, I suppose.
You picked irb as your first project, and it looks like you've got a simple working version out already. Tell us about it. How much work did you need to do on rubinius to get it working?
Brian: Unfortunately, I was probably a roadblock to getting sirb going during our meetup. I failed to grasp that we would have a persistent machine that would contain the state ( e.g. the state from previously evaluated expressions). Later last weekend, after thinking that an irb transcript would just be a program, and remembering that in Prototype B (the MRI-based VM Evan had prototyped) there was a Machine class, I looked for the analogue in shotgun (Prototype S, the C VM). From there, it wasn't a whole lot of work. Again, unfortunately, this was after our meetup so no one was around to share the excitement, except on IRC.
Aaron: We located the Readline.readline stub in kernel/core/readline.rb and replaced
""
print prompt
STDIN.read(1024)
When we added Compile.execute(str) to the loop in apps/irb/sirb.rb Phil pointed out that this had no context which is something I had always taken for granted. So we then started looking at stdlib/irb.rb with ./shotgun/rubinius stdlib/irb.rb and examining the backtrace.
This lead into a tour that covered rspec, mri, target host, and what was left to do before rspec could run natively on rubinius and the convolutedness to run it until then.
Thomas: Well, honestly, what we did when we met bears little resemblance to what is out there now. We used it as a gateway mostly to try and understand how the compiler functioned (irb, or sirb, in this case, is perfect for this -- it has to invoke the compiler on small chunks of code as user inputs them). What Brian later committed was quite a bit more complete than what we had put together, but I guess the kernel of that got started in our initial attempt.
zenspider and Eric up in the Seattle.rb are big believers in using forcing functions to make their code better. How is (or isn't) sirb a forcing function for rubinius? What other projects are you going to work on that might be forcing functions for rubinius?
Thomas: Mostly sirb just sounded like a good first start -- we're all heavy users of irb in our normal ruby development. In fact, when I first started looking at rubinius, I looked for its irb implementation.
I think that mostly we'll just be looking for good bite-sized chunks of missing functionality, documentation or whatever that we can tackle in a single afternoon. Of course, one would hope that over time this leads to each of us being able to contribute even more on our own.
Aaron: Forcing functions are new concept for me. My driving force is to find something that can be done within a few hours and committed. The feeling of accomplishment is the biggest piece. I need to find out more about identifying forcing functions.
Brian: Well, I had to head over to Wikipedia to look up forcing function. :) I remember the use from my Diff Eq math class. I see sirb as both an extremely useful tool to have while developing code for Rubinius, as well as great way to expose how Rubinius works, You can, for instance, pass command line arguments that cause sirb to print the s-expression or assembly, etc. for every expression it evaluates. This could help people get a handle on what's happening during the compilation phase. The direct access to this should enable people to make quicker progress when working on Rubinius.
rubinius isn't the only thing you guys are working on, I also hear you're learning OCaml. How is that meshing with the Ruby, Garnet, and C work you're doing for rubinius?
Aaron: Learning other languages has always taught me more about ones I already know.
Thomas: This was our first meeting, so that remains to be seen. I didn't even realize that Aaron, Brian and Phil had talked about OCaml, but oddly enough, it's the functional language I've been most interested in studying for some time now. It remains to be seen how this will fit with the rubinius work, but I think at the least it shows a common interest in learning something new.
Phil: I'd like to add that I've been wanting to learn a functional programming language for a while now. After finding a presentation on the web (something like "The one day compiler") where someone had posted slides about how they created a make-like tool using OCaml I was impressed with the capabilities of OCaml and decided that I wanted to learn it. I also started seeing some ads show up in gmail about OCaml jobs in the financial industry, so that told me that people are starting to get paid (and apparently well paid) to code in OCaml. The fact that OCaml also supports OO programming was also a draw (I don't think that Haskell does?)
Brian: I think the consensus was that we'd focus on Rubinius, since adding OCaml to the mix could be distracting with the limited time we have available. However, hopefully we'll still entertain the idea of getting together to learn OCaml. I plan on using it in my current game theory math class to implement the finite state automata we're using to model repeated games, and compare that to a Ruby implementation.
This bi-week's sponsor is Ruby for Rails
If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:
Here's the first episode of the serial rubinius interview since we've gone to our new bi-weekly format. There's some good stuff in here about a roadmap, the new fastmethodcontext work Evan's been doing, and user contributions. Before we get to that, there's some great news in the rubinius community that I'd like to pass along.
One thing that I'm incredibly happy to hear about is a Portland, OR group that's meeting regularily to hack on rubinius (and learn OCaml — an odd combination). They've already turned out a simple, but working, irb. I'm in the middle of an interview with them that should be posted in the next day or so.
Another idea that has come up on the irc channel is an aggregator for rubinius blog feeds. There are a number of bloggers there: Evan, Wilson, Brian, mae (Matt Elder), and rue among them.
There's been some discussion about a rubinius roadmap on the irc channel. What are the odds we're going to see something like that? What's going to be on it?
Brian: Evan is definitely the one to set the roadmap. And I think it's important that he does it fairly soon so that we can focus on getting the essential features done for 1.0. This has become something of an issue recently as different people see Rubinius as a playground for ideas. While all the contributions are (mostly?) heartily appreciated, too little shared vision means too many separate directions. That's just plain tough with any project.
While I'm certainly not setting any roadmap, I'm all in for helping document it and explain it. I'm also continually pestering Evan to co-author a book. No one has announced anything about it, but Evan, Wilson, and I have talked about doing this together. I'll leave it up to Evan to decide if he wants to publicly confirm that.
The reason I think a book at this stage would be great is because it would get written while Rubinius development is occurring and will hopefully get a lot of folks interested. I think the AWDWR was a huge help in getting people knee-deep in Rails quickly, and doing things mostly right from the beginning.
Wilson: Compatibility with other Ruby implementations is one important item that we need to publicize. For newcomers to the project, knowing which behaviors are bugs, and which are deliberate differences that need a 'compatibility mode' added can be a challenge. Obviously a roadmap isn't a spec, but I think even a little treatment of this could help people get started.
Brian: I think compatibility is extremely important. Until now, what did we have to worry about? Just whether MRI was available on the platform. Now, with all these Ruby implementations, we have to consider it. The issue it, what is our reference for evaluating compatibility? What does 'compatibility' really mean. So far, I've seen people grabbing ideas of compatibility from other language domains and some of those aren't appropriate. Consider the recent concern that Rubinius having Tuple as a core class will encourage, or at least result in, some programmer coding in a dependency on Tuple. If that program is run on MRI without a compatibility class, it will fail. For me, that is more similar to a logic error in a program than an compatibility issue. It is also important to note that with rare exception, we are not changing the behavior of any core MRI class. Anyway, my main point is that we have some defining to do regarding compatibility. In Ruby, classes, methods, etc. can come and go at any time and duck-typing is the name of the game. So I think our idea of compatibility has to be defined similar to how we deal with 'types' and duck-typing.
Evan: A roadmap is absolutely necessary, because it sets the tone for 1.0 release. As for timeframe, I'm trying to finish up the patch to add FastMethodContext and a bunch of other speed related fixes. Once that's done, I'm going to do the first parts of the roadmap. I'll be on vacation for a week starting the 13th, so my plan is to return from the trip having done parts of the roadmap.
As for the contents of the roadmap, I plan to layout features and new classes to be implemented for 1.0. The list will include threading (Scheduler, Thread, NativeThread), additional hooks, and much more.
Evan, rue has been talking about the impending release of the new fastmethodcontext too. What can you tell us about this? How much of a performance impact will it have?
Evan: FastMethodContext increases the performance of the VM by simplifying the creation of stack objects, used to store information about method calls. Something like 85% of all objects created in the system are just stack objects, so making them faster helps speed up everything else. Due to the amount of time the system spends just creating, maintaining, and recycling these objects, improvement them vastly changes performance.
Back at the beginning of this serial interview, I asked you what contributions had surprised you the most. Now that we're a couple of months (and 500 or so SVN commits) further along, it's time to rephrase the question. What have been the most impactful contributions so far.
Brian: Hmm, good question. I think one significant thing is how much of the core lib is now passing specs. We have nearly 1,000 specs covering the essential classes like NilClass, TrueClass, FalseClass, Fixnum, Bignum, Float, Array, String, Regexp. Just a couple of days ago, out of 132 String specs, over 80 were failing. We're down to 50 or less. Most of the Float, Fixnum, and Bignum, Regexp, and Array specs now pass. This has been due to great contributions from a bunch of folks, so I'd say, the most impactful lately has been the contributions of a whole group of people. :) Nothing like getting collaboration going. If I were to single anyone out for special mention, I'd probably say Alan Hurdle (hurdlea). He pretty much single-handedly whipped Regexp into shape. There were some essential methods before, but now it's nearly complete.
Evan:I agree. Alan Hurdle has really kicked ass on many fronts. He's really shown how much the project lets people dive right in and make a big difference. My hope is that with more documentation and roadmaps, the interpreter will be as accessible as the ruby-basedruntime has proven to be.
Wilson: Several weeks ago, I wasted some time complaining about the Numeric API in Ruby. 'coerced_from', 'prec_f', etc.. there are tons of methods that are never used directly in user code; at least, no code I've ever seen. People came along shortly after that and implemented what looks like the whole set of them. That greatly improved the Rubinius feature set, and helped me understand why Ruby does it that way in the first place. Awesome.
This bi-week's sponsor is Ruby for Rails
If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:
Recently, rue has been posting summaries of important discussions from the #rubinius irc channel to the rubinius mailing list. This is a great way to catch up the discussions you might have missed.
What made you decide to start writing these irc summaries?
rue: I got back into looking at rubinius a month or so ago after finally getting some free time and did the normal signing up for the ML and idling on IRC routine. After a while I noticed that there is very little public communication despite the yelps of interest from all over Rubyworld and beyond. On IRC, it is usually just the knowledgeable regulars talking.
A good part of it has to do with the subject matter; people are apprehensive about diving in to a compiler project. The catalyst for any thriving newsgroup or ML and thereby the community are questions which yield answers and reciprocal information about the project and with people afraid to ask, the information flow just is not getting established.
So I decided to try to both keep the casual public informed and to try to encourage people to participate whether in discourse or committing code. It is a lot easier to get into rubinius than one would think.
Plus, as you can tell, I like to write.
How do you decide what to keep and what to drop from the summaries?
rue: The summaries are largely the result of personal bias and assumptions I make. Any news about the overall progress and new features and so on are automatically in but aside from that I tend to pick anything that was new or unclear to me or someone else on the channel.
The IRC conversation flow actually makes it fairly easy to highlight the important bits (after some signal to noise reduction practise.)
And some of the stuff in the summaries has nothing to do with IRC except that something there sparked an interest in me to write about it.
Do you have any plans to start putting your summaries into a blog or web format?
rue: Yes, as soon as possible. It is unlikely that I would at this point create any sort of a dedicated structure for these but once some technical problems are resolved, I will add these to my modest journal.
Which threads have you summarized that you think have the most value?
rue: It is hard to ascribe value that way; I like the chats that taught me something and I believe others feel the same way.
Anything that yields follow-ups and gets people involved is the most valuable for the project but it is hard to say which ones do that ahead of time.
Which threads do you remember from before you started summarizing them that you wish you could go back and capture?
rue: Mainly the architectural issues. The project often seems daunting and it will certainly take some time to get one's head fully around it. Anything that sheds light to how and why things are done is excellent material.
This is the second week of my break from the serial rubinius interview, and it's time for another piece on parrot and cardinal. Is there any interest in making this into a second (for me, third overall) serial interview? I'd love to do it if there's enough interest.
This week, I'm talking to Kevin Tew (who I interviewed a while ago). In addition to some general information about his Cardinal and Parrot plans, he also gives us his take on VMs supporting multiple languages and register based VMs.
Kevin, now that you're past the current round of heavy lifting involved in school, you've gotten back into Cardinal and Parrot work. Can you tell us a bit about what you've been working on and what's next on your plate?
Kevin: For those who don't know me, I'm a language junkie. I really enjoy working on the low level guts of virtual machines. Lately in Parrot, I have been working on the portion of PIR calling conventions that interface between PIR (parrot high-level assembly language) and C.
Working on Parrot has been an exercise in focus for me. Once you understand the beginnings of how languages, interpreters, and virtual machines work, it is very tempting to start/invent your own language/VM. Working on an existing language/vm project may not be as glamorous as starting your own but for me, choosing to work on Parrot has been very rewarding.
I've spent my most recent Parrot time cage cleaning inter_call.c, which is where Parrot's calling convention and subroutine argument handling code lives.
The cleanup was in preparation for adding PMETHOD support to PMCs. For those that don't know Parrot PMCs are a pseudo C++ objects, implemented in C, upon which much of parrot is build. PMETHODs allow PMC methods, which are written in C, to support the full Parrot Calling Conventions that are available to Parrot Intermediate Representation (PIR, Parrot Assembly). Examples of PIR's enhanced calling capabilities include: optional arguments, named arguments, optional named arguments, slurpy arguments,slurpy named arguments, and array flattening.
What is next on my plate? I'd like to start working on the Parrot Object System. I noticed this past week in Parrot's weekly status meeting that Allison Randal has started working on ParrotBase based on Leo Toetsch CStruct ideas. I better dig in before I get left behind. I started implementing Stevan Little's Class::MOP (Meta Object Protocol) in C PMC's which he of course borrowed from Common Lisp. I soon realized that I wanted full calling convention support in C PMCs so I backtracked and created PMETHODS.
One of the knocks against Parrot is that it's a VM for many languages. It looks like the JVM and rubinius are headed down that road too (to some degree). How does hosting multiple languages help or hurt a VM?
Kevin: Writing a VM for multiple languages is certainly a challenge. The only other comparable VM I can think of that set out to be a VM for multiple languages would be Microsoft's CLR.
Microsoft built the CLR specifically with C# and C++ in mind. VB.NET is also becoming a mature language that is stretching the CLR design. Parrot's multiple language support is a development tactic that has shaped and insured the robustness of Parrot's implemented features. Building a VM, targeted by a spectrum of languages, requires Parrot designers to survey and research how each languages might use or pervert the VM feature in question. While the cost is substantial, I believe it is well worth the price.
Stating multiple language support as a prime object keeps Parrot designers and implementers honest. Corner cutting bits back pretty fast on the Parrot project.
Another knock is that Parrot is register based. Why don't you think this is a problem? (I also asked Dan Sugalski about this.)
Kevin: Stacks are simple to teach and simple to implement. Stack operations, however, are inherently linear. For quite a few years now, all mainstream processors have been superscalar (supporting parallel instruction execution). One of the key roles that caches and register files play in modern processors is to widen the window of instructions which can be analyzed and scheduled for parallel execution. Register based VM architectures remove the overhead of administrative stack operations and map efficiently to the data caches of modern processors.
NOTE: Dan's answer here is better than mine. The above is my opinion, I'm not well versed in this area. I know that stack lovers will say that stacks can map efficiently to register file based processors as well. It was a decision, it's made, life goes on. This issue really gets blown out of proportion. Its not that big of an issue.
I've been watching refactoring in Ruby for quite a while and have long believed that while tools would be nice, Ruby itself made refactoring (and other things) pretty easy. (You can read a bit about that here.) I've also mentioned that this might be the year we get some real refactoring tools. It looks like I might be right.
Martin Fowler wrote an article called The Refactoring Rubicon. He suggested that there are a lot of 'toy' approaches to refactoring built atop regular expressions, but that these will fall over pretty quickly. It's only once you start analyzing the parse tree of a program that you get ability to handle significant refactorings. The simplest refactoring that requires this kind of peeking under the hood is Extract Method, and this is Martin's 'Rubicon'.
Smalltalk crossed the Rubicon long ago. Java crossed it in 2001. And now, Ruby's finally crossed it as well[0]. Jon Tirsén wrote about Ruby crossing the Rubicon. Surprisingly, this advance didn't come out of the Ruby or Smalltalk worlds, it came out of the Java world.
Perhaps, it shouldn't be such a shock. The loudest cries for tools like this have always come from Rubyists with a Java background. Now that JRuby is pushing Ruby deeper into Java-land, it's only natural to see some of the good ideas from the Java community starting to leak into the Ruby community too. It'll be interesting to see what shows up next.
[0] Well, rrb (the Ruby Refactoring Browser) sort of crossed it a couple of years ago, but it was using regular expressions (the regexps that I remembered dealing with were all in the elisp interface to emacs), and wasn't foolproof in its approach (it had a hard time dealing with Extract Method when working with class methods, see bug # 2507) , so I don't think it counts.
It's stuff like this that keeps reminding me that I should run a tumbleblog. Evan Phoenix has just posted a rubinius style guide ... if you want to hack on rubinius like the rest of the cool kids, you should go read it.
Want to help the rubinius team? Want another chance to win a book? Well then, this just might be the post for you!.
Every good open source project relies on good names and other cool stuff to keep it running, and rubinius is no exception. We've been trying to come up with a good name for our C API layer for a while now, but we're still stuck with 'RNI' and that's just not good enough.
Now, we're turning to you, intrepid reader — and we're offering a reward. Here's the deal, I'll take submissions for a better name for the C API until midnight (MST) on February 18th (Chinese New Year) then Evan will pick the best name from the batch. All you need to do to submit a book is to enter it in a comment below, you can submit as many names as you like (you're welcome to submit multiple names per comment). The person who's entry is chosen will win their choice of one of these three books:
The (not so) Fine Print:
