www.not404.com

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? 

Ruby, We Need More Ruby

It would have been nice if JRuby was broken out into its own, separate, 30-minute segment – preferably right next to the IronRuby discussion. I think the audience might have been more engaged to compare and contrast the different approaches taken by the two teams, while the topic of “Ruby Implementations” was fresh in everyone's minds. 

Personally, I'd like to have had Charles Nutter and John Lam really tear into it and get into some of the technical challenges and clever solutions to implementing Ruby -- such as attempting an AOT (Ahead-of-Time) compilation of a Ruby Class for performance, and then figuring out how to handle those “Dynamic Runtime Gotcha's” like redefining a (now precompiled) method at runtime.  Oh well.  At least I got some of that satisfaction while listening to Charles and John talk shop outside the Symposium -- enjoying a beer together, no less. 

Ruby Once, Ruby Anywhere

As a former Java programmer, I just gotta say: I have never, EVER benefitted from Java's promise of “Write Once, Run Anywhere".  Yes, sure, you have a common JVM and a set of core libraries that come along with it.. but you darn well better make sure your WebLogic server has all the SUPPORT LIBRARIES loaded when you deserialize a Java Object that came from somewhere else.  The pain.  The horror.  The damn 3AM phone calls telling you that half your application's cluster barfed, because nobody wrote a try/catch statement for that.  *Grumble*

With Ruby, stupid stuff like this can be a non-issue if your developers stick to standard Gem Repository libraries – just add this to your code: 

require 'rubygems'
require 'some_spiffy_library'

This is one reason Ruby is compelling to me as an Application Developer. The language is also fairly elegant, and the Ruby Community encourages a decent coding style. Though, the PHP guys I met at Lang.NET did get one thing right: the Rails Community is riddled with immature elitists. Did you not read Zed Shaw's now infamous rant on the subject? 

I totally love Ruby as a programming language, but my confidence in the Rails Framework was greatly shaken by Zed's rant. In fact, I'm looking into Merb and Ramaze, as lightweight equivalents, and am considering writing an E-book equivalent to AWDWR (the Ruby on Rails Bible) based on one of those frameworks. Unlike AWDWR, though, I'd probably cover more on high-performance deployment, and would likely advocate deploying Merb/Ramaze on JRuby and Glassfish for performance.

Does it have to be JRuby/Glassfish?  Nope, and that's my whole point:  As a Ruby developer, I really shouldn't need to care what's under the hood -- all I'd need is Ruby, RubyGems, and (ideally) my Framework's Gem pre-loaded on the application server.  Now that is what I consider to be "Write Once, Run Anywhere".  When was the last time you wrote an Enterprise Application, bundled it up, deployed it on another server (that isn't identically configured), and just watched your application run?  It's been far too long for me.

Excel Spreadsheets as a Programming Language? ABSOLUTELY!!

FINALLY! Someone from a Company that truly “gets it”!! YES, YES, YESSSS spreadsheets are a FANTASTIC medium for non-programmers to express BUSINESS LOGIC, and I've been touting that opinion for nearly a decade now. In fact, I've casually worked on my own implementations, and have built a few prototypes that converted Excel to Ruby (kinda working), and Excel to C# (broken, due to C#'s strong typing). 

True story: I was working at a Software Development shop back in 1997 (No, I won't say who they were), and was talking shop with a colleague who was a former Andersen Consulting employee. Our gripe at the time was that we were using Excel Spreadsheets to mock up all sorts of Business Logic for the Financial Sector, and we noticed a huge gap in our development process. It took a week to mock up all that business logic in Excel, and then it took 6 MONTHS for a software development team to take that spreadsheet, play with it for a while, and try to implement that Business Logic Module in hand-written code.

The two of us decided to prototype a very simple idea: Put the spreadsheet ONLINE somewhere, and have the business back-end call into it as a Service. The prototype Server was basically an ASP page that used WinOLE to instantiate the Excel Spreadsheet, and pump Form-Submit Fields into (hard coded) input fields, and produce an XML dump of the (hard-coded) output fields.

While the prototype wasn't well received (we all knew using WinOLE wouldn't scale well), the idea lingered in the minds of the company even after I had moved onto greener pastures.  In fact, this company resurrected the idea in 2000, reworked their entire development process against the Spreadsheet-Generated model, and are actively marketing their own Spreadsheet Service Compiler.  Ah well, that's how it goes, I guess.  I'm often told that I'm just too far ahead of everyone else.   

Anyway.  I had the opportunity to meet Giles Thomas from Resolver Systems, and what he had to show thoroughly blew me away.  Sure, they have the simple Spreadsheet Compiler stuff figured out.  And yes, they provide a real spreadsheet development studio.  But here's what's mind-blowing about Resolver One:  they embed a real programming language (IronPython) into the spreadsheet development environment! 

Take it from someone who's been tackling the Spreadsheet to Busines Logic conversion problem for quite some time: Embedding a real programming language into a spreadsheet development environment is the holy grail! Wanna know why? Just one word: Loops. Excel is absolutely HORRIBLE when it comes to looping over sets of data. I've seen lots of workarounds to implement loops around Spreadsheet-Generated Business Logic, and let me tell you: none of them are pretty.  With Resolver One, you can write Python methods, and invoke them from Spreadsheet Cells, and do a lot more useful things than plain old Excel!  Furthermore, when you compile the spreadsheet, your Python logic goes along with the result!  (You just can't do that with embedded VBA in Excel!)

I'll be playing with Resolver One over the next few weeks to see if I can write a Spreadsheet WebService for Mono.  You all better buy your $200 unlimited-use copy before I publish that, because I could easily make Resolver One worth over  $2500 per runtime CPU if I write a WebService wrapper around the compiled Business Logic spreadsheets.  And don't even get me started on the possibility of constructing Business Rule Services such as Decision Tables -- just look at Drools and see the potential there! 

OMG, maybe I should see if they're hiring a Resolver One Evangelist. 

Cobra Programming Language

Cobra looks like an elegant syntax that's easy to follow. I love the fact that you are encouraged to embed working unit tests straight into your Object's method declarations – good programming style always gets a thumbs-up in my book. This style is in sharp contrast to most other platforms where Unit Testing is an after thought, often placed in a separate tests subdirectory of the project.  Such unit tests are often cooked up by QA Engineers who don't really know what's going on under the hood.

In Cobra, you declare Nullability on method parameter signatures. Such a declaration allows your development environment to eliminate the possibility of passing a null value unless you explicitly say it's allowed. Overall, it's pretty nice, and I'm looking forward to watching Cobra mature in the near future.

Translating to C#, While in Visual Studio

Cobra also piqued my interest because it takes an approach that I've been meaning to try: Converting your language into C# to reap the benefits of the C# environment. But Cobra goes a step further, by allowing you to edit Cobra source code in Visual Studio. Thus, you get the benefit of Visual Studio's strong checking of C# (syntax highlighting, static type checking, etc) applied to your "foreign" programming language. 

This is a compelling approach, and I'd love to investigate it further for my own pet project: a COBOL to C# translator. I've had a functional Java CUP grammar for COBOL for years, and it can produce an AST off of simple COBOL input. My goal was to save the AST as an XML file, and then create a suite of XSLT templates to do the actual Code Generation. I'd then complete the thing by writing a COBOL runtime equivalent for each target language. (I translate statement-by-statement, and most COBOL statements wind up being parameterized function calls into my Runtime library). 

Funny thing about pet projects, though: They get kicked to the curb when a paying project comes along. I wouldn't mind finishing it up and emitting C# for .NET and Mono, or Java for the JVM. I'm still irritated that there's no freely available, fully functional COBOL implementation that could be run on Linux. But at least there are a handful of efforts to get there. 

No, I'm not a COBOL lover by any means.. I just can't ignore the opportunity to translate COBOL into something more modern. That way, your real programmers (C#, Java, whatever) can just import the COBOL-generated code, and later refactor said code if they need to. It's the only feasible way to wean corporations off of legacy COBOL, in my opinion.