“A lot of developers in the Java world have been looking for an easier Java than Java, and they are seeing Ruby on Rails fitting that need. “ — Michael Swindell, VP of Product Development, CodeGear
The developers who brought us Delphi, that Ferrari of Integrated Development Environments, are entering the dynamic language tools race, and this time they are sporting Ruby red.
Delphi combined a natively compiled and fully object-oriented language, Object Pascal, with an elegant and easily extensible object framework, the Visual Component Library (VCL), and put them in an editing and debugging workbench that was the envy of the industry. Microsoft famously had limos pulling up to Borland’s corporate headquarters at lunchtime, poaching talent until Borland was forced to seek injunctive relief, resulting in an undisclosed out-of-court settlement.
Microsoft’s bastardization of Java, J++, was the immediate result of some of that poaching, and Anders Hejlsberg, creator of the compiler technology for Turbo Pascal and chief architect of Delphi, then went on to shape C# and .NET. Sun consulted with Borland while creating Java, and key Java technologies such as the JavaBeans specification (but not its clumsy cousin, EJB) were the result. The languages, IDE’s and platforms that shape present-day computing share a strong lineage to the innovations that formed Delphi.
Borland’s focus shifted to Application Lifecycle Management (ALM) tools – products aimed at CIO’s, VP’s, middle managers, and other drinkers of that pricey software-as-manageable-process Kool-aid. Those loyal developers who remained – among whom I am proud to stand — vented on the newsgroups, badgering the company to release a road-map of their plans for the development tools that we relied upon.
We felt abandoned.
It was clear that the makers of the developer’s tools within Borland needed to pursue their own mission, to fill the needs of the journeyman programmer, and so CodeGear, an independent subsidiary of Borland, was spun off just four months ago, on November 16, 2006, to do just that. I spoke recently with Michael Swindell, CodeGear’s Vice President of Product Development, about how he wants to bring the tools that simplified the development of powerful applications with rich interfaces on Windows to the web, and to Ruby on Rails.
While the shiny buttons, big fonts, and pretty gradients of the Web 2.0 experience have caught the eye of the savvy web user, it is the heightened interactivity that Ajax affords that has cleared the way to move even more desktop applications to the web. “With Ajax you are closing the gap with the event-driven [UI] model,” Swindell said. “Now, the UI latency, rather than being memory and CPU bound — and maybe a little bit API bound — is now web server and framework and, obviously, network bound. So if you have a fast connection and good servers, you can get very good rich user interaction.”
“What this is doing for enterprise application development is to make the user interfaces [that are developed] more acceptable, to make it easier to move from the client-server, rich-client model to a web presentation model,” said Swindell. Increasingly, these enterprise developers are turning to Rails. “Rails provides an out-of-the-box framework that is elegant, well-designed, and completely object-oriented. A lot of developers in the Java world have been looking for an easier Java than Java, and they are seeing Ruby on Rails fitting that need.”
That need to have rich, event-driven interfaces makes the programming models for desktop apps, including the VCL, relevant again.
The Visual Component Library was a framework that was all about “making the hard things simple for developers,” it put an elegant veneer over the Windows API, and various database access API’s, so that developers could easily write visually rich client-server applications. But it also made it easy to write your own components, since the VCL was written in the same Object Pascal you used to write your apps. While Visual Basic components suffered fragility from the dual whammy of having to be written in C++ and having to rely on COM DLL’s, VCL components provided simple reusability with minimal external dependencies. They just worked.
Thousands of these components became available, and a thriving community of open-source component developers surfaced on the web. That ecosystem of readily available plug-in functionality affirmed the soundness of the basic design of the VCL, and seems to me to be one of the strongest validations of the promise of re-use in OOP yet to be seen.
CodeGear recognized the usefulness of a workable component model for web apps and so has just announced a new product, Delphi for PHP, including the open source VCL for PHP. This platform builds on existing open source PHP projects and brings RAD design tools and code sharing through componentization to the vast domain of PHP code.
Componentization is an approach that has worked for Apple’s WebObjects (upon which the iTunes Music Store stands), Jakarta’s Tapestry, and Smalltalk’s Seaside framework, among others. These frameworks provide a higher level of abstraction than the HTTP request/response cycle to provide richer interaction with less complexity. With the VCL for PHP now among them, and CodeGear’s newfound love of all things Ruby, it seems to me that a workable component model for Rails in the form of a VCL for Rails is a promising prospect.
“That is definitely something we are interested in,” said Swindell. “There is a lot more that can be done from a basic tooling perspective to help developers build Ruby and Rails applications from the start. Making the IDE Ruby smart and Rails smart is the thing that is most important up front, but the RAD approach is also something that is interesting.”
First we are likely to see intelligent IDE’s that provide code-completion, smart file navigation with integrated object and class hierarchy browsers, and debuggers that provide code-stepping and variable watchpoints. Such environments shine a floodlight into the darkness of running code and provide the visual tools that keep the entire context of your application on the screen in front of you – invaluable assistance for our simple minds that can juggle only a handful of discrete ideas at once.
“How do we tune the IDE and the developer’s approach so that it is really focused on the problems that developers are going to face in building really rich Ruby and Ruby on Rails applications? There are a lot of benefits that Ruby on Rails brings, but there are also things that become hard for the developers as they build out their applications — as they become more and more complex,” said Swindell.
CodeGear will be making announcements about their product plans at the Rails conference which runs from May 17th to the 20th. “We are really interested in having an open conversation with the Ruby community. Our goal is not to have a stealth-mode project in an iron vault for six months and then unleash it. We certainly will be leveraging open source technologies and open source projects in our Rails efforts and there are projects both in the Rails and Eclipse communities that we will likely be contributing back into. We are not interested in creating black boxes, or proprietary runtimes in anything we are doing.”
“We would like to become the benchmark standard for Ruby on Rails development [environments]. If we can achieve a customer base that consists of leaders in the Ruby on Rails community, then we will have succeeded. We really want to respect and add value to the community, not to come in and take things over and impose our will. We want to earn our way into the Ruby and Rails world.”
Update: See Joe McGlynn’s comment in response to an earlier blog post to see how you can get involved in field testing “Red Diamond”.
Another update: See Rails creator David Heinemeier Hansson’s reaction to this article.