Sapphire - Two New Re-Implementations of Ruby
Post by Peter Cooper
Del.icio.us
Cosmos
Rather coincidentally, two different re-implementations of Ruby (a new interpreter and a new language, respectively) with the name of Sapphire have appeared on my radar recently. They’re both worth mentioning, so why not put them together?
Sapphire #1 - A Fork of the Official Ruby Interpreter (MRI)
The first Sapphire is, quite unusually, a fork of the official Ruby interpreter (that is, Matz’s Ruby Interpreter) by Daniel Berger and Park Heesob. The listed benefits / differences that Sapphire boast compared to the standard interpreter are:
- the use of C99-standard code that’s free of warnings
- an improved standard library
- better support for MS Windows
- “better overall management”
- the inclusion of previously separate libraries like Rake and RubyGems
- improved Unicode support
- Aspect Oriented Programming support
- type annotations
- .. and, naturally, lots more ..
I haven’t found many significant references to this project yet, other than a brief mention on Matz’s blog, but it appears development is well under way and on-going on the project. I expect the developers are attempting to reach a certain point with the project before putting the spotlight on it. Sapphire can, however, be checked out in its current state from the project’s CVS repository.
Credit to Sebastian Wittenkamp for prodding me on this story.
Sapphire #2 - A New “Ruby Minus The Inconsistencies”-esque Language
Sapphire #2, on the other hand, is the name of a new Ruby-inspired programming language which has a heavily simplified Ruby-like syntax, and is being developed by Huw Collingbourne of SapphireSteel Software. As Huw says:
[T]he overriding design principle of Sapphire is that the language should be consistent, unambiguous and deeply object oriented. In order to achieve this we have removed many constructs from Ruby: whereas Ruby often has many alternative ways of accomplishing the same effect, Sapphire aims to have one way of doing one thing. […]
The syntax of Sapphire is much stricter than that of Ruby. For example, commands (method calls without parenthesis) are not available. A method name without parentheses is not a method-call but a method-reference. Methods can be assigned to variables and passed as arguments. Lambda methods (nameless methods implemented as blocks) are assigned in a similar manner and these are first class objects. A lambda method is always an instance of the Block class and it has the same independent existence as any other type of object.
Our implementation of object orientation is more rigorous than that of Ruby. We have gone back to the fundamental principles of object orientation epitomised by Smalltalk. This means, for example, that encapsulation and data-hiding is enforced. There are a number of ways of breaking encapsulation as a ’side effect’ in Ruby; this is not allowed in Sapphire.
As a commenter says, “Welcome to Python minus tabs.” Huw suggests, however, that Sapphire will be a smaller, more Smalltalk-esque implementation of Ruby.
Despite being mentioned as merely a new language, there are good indications that it will be available in a .Net-only implementation, at least initially, due to the focus SapphireSteel Software has in that sector. A much smaller, more consistent Ruby-esque language certainly sounds appealing though, and it’ll be very interesting to see what Huw and SapphireSteel Software eventually do with it.
Fragmentation of Ruby?
Projects like these two Sapphires, along with the new features that are unique to other implementations like JRuby and Rubinius, make me think that the Ruby world is only going to become more fragmented from here on out.
There’s a lot we’ll still share as a community, but I’m starting to believe that “Ruby” is starting to represent both a community and a language “ideal” rather than just a single, well-defined programming language. More and more languages influenced by Ruby that then ride on the Ruby community are bound to come along. Since all of those implementations and redefinitions have, so far, shared the same spirit of simplicity, fun, and productivity that vanilla Ruby has, I think it’s a good thing. I certainly appreciate that many in the Ruby community could, however, see all of these developments as “diluting” the strength of the language itself in some way. What do you think?
March 21st, 2008 at 12:11 am
So, what is the point of either of these? I mean, I can understand something like Rubinius, but what’s the real gain of having a super strict ruby implementation that doesn’t let developers be creative? I thought part of the point of Ruby was to do just that…
This reminds me of what happened to Javascript, in a way…
March 21st, 2008 at 12:13 am
In terms of diluting the language itself, I’m not terribly concerned. Some may turn out to be useful crucibles for experimenting with new capabilities (e.g., typing hints) that could be rolled into future versions of The One True Ruby language. Others may wind up just going their own way (e.g., Sapphire #2 strikes me as a full-fledged new language more than a fork of Ruby).
What I am starting to get very scared about, though, is how all this affects RubyGems and the myriad of gems that are being developed and occasionally maintained. Having umpteen different deployment options, and discrete gem packages for each, will get to be problematic for all parties.
From the standpoint of gem “consumers”, just trying to figure out the right magic RubyGems name for the target environment could get messy. For example, right now, I can choose from x86-mswin32-60, java, and ruby flavors of mongrel 1.1.4, and there’s also an i386-mswin32 for mongrel 1.1.3. What happens when IronRuby ships? Or Rubinius? Does Ruby 1.9/2.0 add yet more options? What if you don’t know the answer (e.g., what is the difference between x86-mswin32-60 and i386-mswin32)?
From the standpoint of gem maintainers, demands for gem support for alternative deployments will outstrip the maintainers ability to deploy there. Will there be a good way to allow multiple teams to handle ports of a gem? For example, suppose Microsoft throws a bunch of developers at creating IronRuby editions of gems that presently use inline C or other platform-specific techniques. The official maintainers of those gems may not be in position to give the Microsoft folk a home in the main project tree for their IronRuby port. Does this mean Microsoft has to fork the gems? Or can the official maintainers delegate the IronRuby port to the Microsoft team, and when people do gem install, they get both the main team’s ports and the Microsoft team’s ports?
And while I use Microsoft as an example there, the same could be said for Sun and JRuby — if Sun decides to hire a few folk for JRuby ports of popular gems, the same issue arises.
If we can solve this problem, both technically and socially, the Ruby gem system would trump most, if not all, other language library systems. If we can’t, things could get icky.
On a completely unrelated note…could I trouble you for a preview button on this comment form? ;-)
March 21st, 2008 at 12:17 am
@Mark Murphy: I think there are a few WordPress plugins that will let me do that, so I’ll look into it :)
March 21st, 2008 at 1:09 am
I agree with Mark, the fragmentation new ‘implementations’ of Ruby generates is no good, but what else could we do?
Regarding the platform for Rubygems x86-mswin32-60 is acutaion i386-mswin32. The later is the old way (pre rubygems 0.9.5) to represent the platform. since there is a Ruby linked to VC8, gems that bundle pre-compiled extensions requires to be different from each other (VC6 is not compatible with VC8).
Is something similar to darwin builds of gems.
Get used to see x86-mswin32-60 and x86-mswin32-80
Regards,
Luis
March 21st, 2008 at 1:18 am
Fragmentation?
I doubt it.
Fragmentation usually happens when one fork is superior (or close enough) to the original that the userbase becomes split. Sapphire #2 looks less useful for real life and more useful for academia. Sapphire #1 might have something, but I don’t know if it’s enough to even get people to check it out outside of idle curiosity.
I think the one Ruby implementation everyone is looking at right now is Rubinus, and for good reason.
March 21st, 2008 at 7:37 am
A bit off topic, but when speaking of a new language, you might want to checkout Io language ( http://iolanguage.com ). It takes the idea of metaprogramming even further, but is way simpler than ruby in terms of design and implementation. If you follow this row C -> C++ -> Java -> Ruby, Io is the next in the row.
March 21st, 2008 at 9:49 am
I’ve already answered a good many questions about of the fundamental features of Sapphire here http://reddit.com/r/ruby/info/6chu7/comments/ so I won’t repeat that.
Two things I do want to make clear though are that:
a) SapphireSteel Software’s Sapphire is a new language. It is not a variant of Ruby. Its syntax is based on Ruby. Its version of object orientation has been more directly inspired by Smalltalk. We will continue to support Ruby and IronRuby (and, indeed, JRuby). The focus of the Ruby language is quite different from that of Sapphire and we have no desire to fragment or to replace Ruby itself.
b) Sapphire is not inspired by Python. One of the very surprising things to me has been that so many people assume it may have been. I can only guess that the fact that Sapphire is an orthogonal language - aiming for simplicity and clarity - may lead people to think in that direction. Sapphire is unlike Python in so many ways I hardly know her to begin. Here are a few starters though: Sapphire has a single line of inheritance, it has no procedural programming capabilities and it has complete data hiding (Python’s encapsulation is extremely ‘loose’ - far removed from the ‘black box’ encapsulation of Sapphire). Oh, and Sapphire’s indentation is not significant…
The driving impetus of Sapphire is clarity and lack of ambiguity. It is a ‘safe’ programming language in the true and original spirit of Smalltalk. It will be highly modular, it will allow the programmer to make ‘assertions’ of valid types (though the language itself does not require or enforce type information) to provide incremental ‘in development’ testing and it will include a broad range of other features to reduce ambiguity or the potential of unforeseen ‘side effects’. It is our view that while the sheer diversity and dynamism of Ruby is a great strength for highly dynamic scripting and is fundamental to frameworks such as Rails, there are many ‘mission critical’ applications where the main requirement is absolute clarity and complete certainty in the correctness and runtime reliability of your code. That’s what Sapphire aims to provide.
The major challenge has been to retain the features of dynamic languages (including duck-typing and metaprogramming) while simultaneously enforcing black-box encapsulation and the ability to check actual runtime objects against their expected class types, value ranges etc.
We have not ‘changed’ the Ruby language in order to do this. SapphireSteel Software’s Sapphire language is not a ‘fork’ of Ruby. It is a new language designed from the ground up. We do acknowledge a strong debt to Ruby, however, and we have deliberately designed the grammar (though not the semantics) of Sapphire to be familiar to Ruby programmers. But it is absolutely a new language. I’m not sure why anyone would think that the creation of a new language should have a negative effect on Ruby. All languages were new once… ;-)
best wishes
Huw
SapphireSteel Software
Ruby and Rails In Visual Studio
http://www.sapphiresteel.com
March 21st, 2008 at 3:00 pm
The LORD said, “If as one people speaking the same language they have begun to do this, then nothing they plan to do will be impossible for them. Come, let us go down and confuse their language so they will not understand each other.” Genesis 11:5-7
—
I’m worrying about the confusion that different dialects of ruby may cause to the ruby developer’s community … or worst, to those outside it.
March 21st, 2008 at 3:21 pm
I’ll be marginally philosophical here, but forking is a good thing as it organically leads to progress in the future. Spoken languages have dialects, forking computer languages is similar. It does no harm. If only the trunk gets built upon then it stifles experimentation. However there are always pragmatic problems.
On a side note: How about a brand new language designed openly using some form of voting system - and everyone can make suggestions. The writing of the language will not start until the design is fixed. A truly democratic language to keep us all happy!
Let me kick things off:
- Strongly typed or not?
- OO or something else?
Please someone pick up on this idea and build a website for it…
March 21st, 2008 at 3:48 pm
JP: I’d be very interested to follow the progress of such a development, although I can’t help but think it would be a train wreck in action.
The best produced works of literature, music, art, and, yes, even programming languages, weren’t and can’t be designed by committee. Or, rather, they *can* but not well.. consider most of the community projects that are developed by committee such as hideous community logos :)
March 22nd, 2008 at 5:59 am
JP: You can sort of do that now with Ruby Change Requests and monkeypatching/dynamic programming/etc.
Design by committee is more problematic than productive. :)
March 22nd, 2008 at 11:16 am
Hi all,
Ruby as it is today is not the Next Big Language! Agile programming requires agile programming languages:
1. The NBL must be self hosted, only then will it be agile. A self-hosted language has the major advantage that its developers gain much more experience of the language. From the compiler it will be more obvious what features are missing and how good the grammar and semantic are. It will be obvious if it is possible to write a lucid and neat compiler without obscure language structures (“magic” and “perlism” in Ruby terminology). I think Ruby today suffers from “there is more than one way to do it”, “perlism” and “magic” to make it the NBL. I think partly because it is not being self-hosted.
2. The NBL must fit into existing infra structure. I believe Ruby and Python where the last languages that are relative successful without having a library from the start. I believe the NBL must be based on JVM and/or .NET and benefit from those infra structures.
3. The NBL must be fast enough. So the NBL must be both between static and dynamic. Otherwise the language will hit glass ceiling. I’m not using Ruby because of this.
4. The NBL must have a well-documented lucid and neat framework, usable for both web applications and stand alone applications.
For Ruby to become the real NBL, it must evolve:
1. Matz should switch to Rubinius and clean up the Ruby syntax.
2. Ruby (Rubinius) should have JVM as the VM, IronRuby will of course be based on .NET
3 Solve the speed issues. Charles Nutter seems to understand that and seems also to have the solution.
4. Rails is here, but has too much “magic”. It may evolve to be more lucid or it will be replaced by another framework. I believe this is a minor issue since there are so many alternative Ruby frameworks, although they are not mature enough or not well documented. At least one of them should evolve into a well-documented, lucid and neat framework.
Yes, I think the NBL can be Sapphire as a cleaned up version of Ruby! Or the NBL can even be Groovy of it evolves well. Or Cobra (http://cobra-language.com/) can be the NBL, a cleaned up version of Python.
My 2 cents
Regards
Csaba
March 22nd, 2008 at 9:35 pm
Csaba-
The next big language will be both ’self-hosted’ and must be based on Java or .Net so it can use the libraries? Ummm… you can have one or the other.
Personally, I’ll take self-hosted.
March 23rd, 2008 at 9:23 pm
Csaba- (and everyone)
When you said it must run on JVM or .Net, I cried inside. Is there no respect, now, for Parrot? Does no one think the idea of a FOSS VM for FOSS languages is a good idea? Perhaps you believe in UNG over GNU? This is a disturbing trend I have seen in my many years of following FOSS, and it is only snowballing. Granted, JVM source is available through Sun, but aren’t all the performance (and other) issues that have been dragging down Java adoption for 15 years still an issue? Sorry to bemoan the death of FOSS culture, but the indifference of so many people to the progress of free software makes me feel that the dark side has already won.
My question: what are the technical reasons why I here next to nothing about Ruby on Parrot?
(Yes, I know Ruby is MIT licensed. I prefer GPL 3, but I am not a license zealot. I am a source zealot.)
March 24th, 2008 at 5:15 pm
@abStract – Sorry for my pessimistic view, I wrote what what I think, not what I would like. A FOSS VM for FOSS languages is a good idea, BUT there are far too many FOSS VM-s around. To be able to match the Java and .NET platform, the communities around “Perl 6” and Rubinius must cooperate. (The PyPy community seems to be able to change VM easier than I change underwear.). These three communities, if possible also the PHP community, must start to use the same VM and thus also be able to build a common library to match JEE and .NET!
Another good reason to be self-hosted is to prove that the language is good enough for a medium sized project! Not being self-hosted is to say I don’t believe in my language – I prefer to use C when it really counts…..
March 25th, 2008 at 4:17 am
Now that the Sapphire/Ruby connection has been clarified (thanks Huw) I’m pretty sure that it is a good thing for Ruby - Especially with the syntax homage that the sapphire team is paying.
These comment threads tend to have a life of their own, but I’ll get sucked in this time. I don’t think Ruby needs to use .NET or the JVM to be successful - That being said, I don’t think it’s appropriate to write a large application in Ruby right now. It’s just too slow. If there was some intermediate-compilation that could be done to increase the speed, then it would be much better suited (IMO).
I’m the lead DBA on a large Data Warehousing project, and we use ruby fairly heavily every day for the tasks that we find it to excel at - Screen scraping, data acquisition and XML processing. Hpricot in particular is excellent. Much of our business consists of pulling disaster and disease information from the web, processing it and loading it into an oracle RAC database. Ruby is VERY good at this, and it is even more attractive when other tools (Java, PL/SQL, etc) fall way short and would introduce more complications that solutions (Bloated Code, immature libraries, etc.)
Perhaps I am in a unique situation; I was able to choose my technology and implement it as I wished. Regardless, Ruby is ready for some things. It just needs work in the other areas, mainly performance.
March 25th, 2008 at 6:19 am
@Csaba: I am glad to hear that your statements reflect pragmatic thinking rather than disdain for Parrot. It is interesting how comment forums such as this unfold, and how misunderstandings can easily happen in text. Which is why I get sad at the lack of mentions Parrot gets: for every un-mention and non-mention of Parrot (not to mention mis-mentions 8) there is a small section of the Collective Open Source Psyche that disavows it forever. Or at least until it is declared cool (again). I respect that you didn’t mention it because it doesn’t seem likely, but that same lack of mention will result in deepening that unlikelihood. Too many times I feel that FOSS projects in general, and anything involving Larry Wall in particular, are written off because some kid couldn’t understand some elegant one-liner. Whew, there, I said it.
@Csaba: So Ruby is at least fast enough to handle the Katrina data, eh?
March 25th, 2008 at 6:20 am
Whoops, sorry, second was @ Jamie. Hope my rant offends few.
March 26th, 2008 at 5:49 am
Heh, we came way after that tragedy. We’re more concerned with human and animal epidemics (avian flu, mad cow, sars, brucelliosis, etc.)
And, yes, for the items that I mentioned it is fast enough (our feeds come in hourly…) especially with Hpricot.
March 28th, 2008 at 12:40 am
One of the open source concept’s byproduct is fragmentation, just check it out the humongous amount of Linux distros with so many discrete packaging systems, dependencies and so forth.
Ruby being fragmented reinforces its importance. But it doesn’t matter that much. There is room to grow. If Sapphire 1 or 2 prove themselves to the community to have real value, they will survive, otherwise they will become e very niche thing at best or be completely halted and forgotten.
Darwin plays here as well. MRI is not going away anytime soon. It is now the closest we have to a ‘reference implementation’. The more other implementations adhere to the reference, more chance they have to survive, the more it distances away from it, the more it risks extinction.
Right now, YARV, Rubinius and YARV are the only serious contenders of being the mainstream Ruby implementations. Other VMs will have their chance. But I wouldn’t hold my breath.
April 1st, 2008 at 11:44 pm
“Io is the next in the row.”
Io is a great language but it has FUNDAMENTAL differences from python and ruby.
I say python and ruby are much more “scripting” languages.
Besides, Io has a lack of documentation and the build system is still more annoying than python and ruby have.
Btw i am not concerned that either of the sapphire will have any effect on ruby.
Maybe sapphire 1 will make matz reconsider some aspects and thus change ruby in a positive fashion