It looks like the Sapphire in Steel camp feels they need to create their own language on top of Microsoft's CLR/DLR (.NET) platform. Yawn, ho-hum, here we go again.  *Snort* wait a sec.. this isn't coming from Microsoft?

*Sigh*.  Here's an open question to the Programming Community: Why, oh WHY do so many developers feel the need to create their own programming language? With an alphabet soup full of programming languages available, why do we really need another one?  Can't we just figure out how to do what we want via Domain Specific Languages (DSLs) within our preferred language platforms?

From my understanding after reading the Sapphire announcement, it seems the Sapphire Language is inspired by Ruby, but adds constraints to make the language more “unambiguous”. Funny, that sounds a lot like what Charles Nutter recently blogged about, with his experimental, type-inferenced, Ruby-like language that he calls Duby.

With Sapphire and Duby floating around, I have to question.. nee... CHALLENGE future direction of the Ruby Language. Are Ruby Language implementers getting tired of “In Matz We Trust”, and caving into temptations to make platform-specific extensions? I seriously hope not!

Remember how screwed up things were when Microsoft added J#-specific “extensions” to their implementation of Java? “Write Once Run Anywhere” went out the window, and Microsoft forced us into “Java Wars” -- much like how we were already engaged in the “Browser Wars”. Life as a programmer back then was a freaking nightmare!  Instead of focusing on getting the job done, Technical Architects worked on conditional-coding to bring out the “flavor-specific” candy for each platform, or they used the “lowest common denominator” approach by abstaining from ALL extensions.

If the Sapphire Language closely resembles Ruby (i.e. it's a fork, despite their claims), we could soon see a lot more conditional-coding constructs showing up in Ruby Application code (versus Ruby Library code, where this is hidden from Developers):

def do_something(a,b)
    return do_sapphire_thing(a,b) if PLATFORM_SAPPHIRE
    return do_jruby_thing(a,b) if PLATFORM_JRUBY
    do_generic_ruby_thing(a,b)
end

Needless to say, I don't care for conditional-coding constructs.  It detracts away from the Application Solution.  I specifically choose to develop in Python and Ruby because all the desirable platforms have implementations available:

• UNIX/Solaris/Linux - using the original Python and Ruby implementations
• JVM (Java) - using Jython and JRuby
• .NET (Windows) - using IronPython and IronRuby
• Parrot - Ha ha ha, just kidding!  As if Parrot and Perl 6 will be useful for Production-Quality code in my lifetime.

As a developer, I strive to create “Cross Platform” applications where possible, and go Platform-Specific when something needs to be more optimized.  With that goal in mind, Sapphire Camp, I just gotta say... PLEASE DON'T FORK RUBY!

It's been an interesting 3 days, attending the Lang.NET Symposium. While I expected to hear more on the typical Compiler Theory courseware, it was a pleasant surprise to learn more about the “Guts n' Gore” stuff under the hood, especially with the Expression Trees used by recent technologies built upon the CLR and DLR – most notably LINQ. 

I'll spare you a rehash of what was presented, and instead will focus on my “Alpha Geek” impression of where I think we (the collective “we” as Software Developers) will be going in the future. 

The Future of Java and the JVM

The talks at the Symposium heavily biased toward development on CLR and DLR technologies, with IronPython as the poster child of what can be accomplished on the CLR. As I mentioned earlier, Jim Hugunin made a compelling case for building for the CLR, and then optimizing for the DLR.

Thankfully, Java and the JVM were represented by John Rose and Charles Nutter. The Da Vinci Machine is comparable to the DLR, in that it provides extensions to the base Virtual Machine in order to supply Dynamic Languages. 

And that was about it for Java – barely an hour's worth of content about building Dynamic Languages on top of the JVM, supplanted by a brief rehash of Charles Nutter's RubyConf material. *Grumble* Oh well, considering Microsoft had the Home Court advantage, I guess the JVM guys had to pare everything down to that one hour. 

My final take-away on Java, the JVM, and the Da Vinci Machine: It's promising, but I'd really like to see other dynamic language efforts on it. Python and Ruby are given, but I don't see a JVM equivalent to Phalanger (php for CLR), or any early rumblings of porting Perl6 to run on the JVM. 

While the JVM isn't going away, I don't see it as being competitive to the CLR in the long-term unless other dynamic languages are being actively ported to it.  Any volunteers from the PHP or Perl camps?