If you thought Delphi was the only Object Pascal programming system available, think again! Chrome from RemObjects Software brings Object Pascal into Microsoft Visual Studio. And that’s just for starters - as bitwise discovered when we spoke to RemObjects’ Chief Architect .NET, marc hoffman

Before going any further, maybe you can explain how Chrome got its name?

mh: That's an interesting question. As you can imagine, picking a name for Chrome was a lengthy process and many different names were suggested at one time or another, from the simple "RemObjects Pascal" to fancy acronyms that were beyond explanation.

When we started out with the project a year and a half ago, the codename we picked was "Adrenochrome", in homage to the same-titled song by The Sisters of Mercy. During the course of the alpha and beta phase, many of us (and many of the beta testers) had grown fond of the name and it was actually suggested to keep it for the final product - an idea that was rejected mostly for marketing reasons - we felt the name was to long and not something easily remembered by potential customers.

In the end, we decided to keep the second half - Chrome - both because it reminded us of the original codename for the project but also due to the connotations of something luxurious and shiny that the name invokes.  

Given the fact that Borland's Delphi 2005 already supports Object Pascal for .NET, why did you decide to create an alternative product?

mh: This has got to be the single one most asked question about Chrome.

As you know, we at RemObjects software come from a Delphi background; I personally have been using Delphi for over 10 years now, starting with its very first release (and I had been using Turbo Pascal and Borland Pascal before it).

About two or three years ago, we started investigating the possibility of expanding our product range of developer libraries to cover the Microsoft .NET Framework, and naturally Delphi for .NET was one of the first things we looked at for this job.

Unfortunately, we were disappointed with what we were seeing. It seemed that Borland had developed Delphi for .NET with one main goal in mind: to hide the transition from Win32 to .NET from the developers.

What sounds like a good idea on first sight had backfired tremendously: .NET as a platform is radically different from Win32 on many levels, and in most cases it requires a different development approach than one would use for classic Win32 development. Delphi for .NET had, in our opinion, failed to realize this platform difference and introduced many Delphi-isms and Win32-isms that felt out of place and awkward in the .NET world.

What's more, the .NET platform is all about language interoperability, something that is even more important for us as a component vendor than it is for the average application developer. Delphi for .NET introduced many quirks that make it difficult (if not impossible) for us to use it to develop third party component libraries that would feel natural to C#, Visual Basic.NET or even Cobol.NET developers - something that was obviously very important for us.

To cut a long story short, the decision was easily made for us to start using C# for our .NET projects instead of Delphi, because C# was the only language that allowed us to fully embrace the .NET framework.

And C# was a great language to use, no doubt about it, but we soon realized that we missed our beloved Pascal syntax. The thought was born: what if there was a language that gave us Pascal syntax, but at the same time was designed from the ground up to work with the .NET Framework and the Common Language Runtime? The rest, as the saying goes, is history….

What are the benefits of developing using Microsoft's Visual Studio rather than a dedicated development environment such as Delphi?

mh: First of all, Visual Studio is just as "dedicated" a development environment as Delphi is. At this time, both Visual Studio and the Borland Developer Studio are multi-purpose IDEs hosting a variety of languages. So I suppose this question boils down to: why use Visual Studio rather then developing our own IDE?

Let me answer this in two parts:

For one thing, Visual Studio is a great IDE that was designed from the ground up to be very extensible - even Microsoft's own languages are nothing but extensions to the IDE core, just as the Chrome integration is - and with the upcoming Visual Studio 2005 it is getting even better. Microsoft is pouring enormous resources into improving and expanding Visual Studio; in my opinion very successfully.

To even think about competing with Visual Studio by implementing our own IDE is ridiculous - the amount of resources needed would be unimaginable, and to what purpose? It's not the basic skeleton of the IDE that matters, it's the internals that fill the IDE with life that count - and we have full control over that with Visual Studio.

Basically, integrating with Visual Studio instead of writing our own IDE allowed us to concentrate on these essentials: creating a great compiler and related tools, without having to worry about the basic plumbing of the IDE skeleton.  

Secondly, I want to stress that Chrome is not tied to Visual Studio. First and foremost, Chrome is a compiler. We are releasing a version which integrates this compiler with Visual Studio as a first class citizen next to C# and VB. But this is just the first step, not the final destination. In the future, Chrome will integrate with other development IDEs (among them SharpDevelop/MonoDevelop) as well.

So I personally do not think of Chrome as an "add-in for Visual Studio". Chrome is a product on its own, and - among other options - we're happening to be leveraging Visual Studio to allow our customers to use it inside this state-of-the-art IDE.

How compatible is Chrome with the Delphi version of Object Pascal? Are there any significant incompatibilities?

mh: The answer to this is a very decisive "depends".

Chrome is certainly compatible enough with Delphi that it is possible to write code that will compile in both Delphi and Chrome. The question is: is this really desirable? As mentioned before, .NET and Win32 are really vastly different platforms, and moving from Win32 to .NET requires a certain amount of adjustment in the way we approach development tasks - we cannot simply expect to take any given piece of Win32 code and be able to "just compile it" for NET.

Porting an application to .NET involves more then just recompiling the code; it involves rethinking the design decisions made for the original Win32 code and considering how they apply (or don't apply) to the new platform at hand. This is not specific to .NET, the same applies to porting your applications to, say, Java, Linux or MacOS.

For example, .NET uses a garbage collector, while Delphi Win32 code uses an explicitly managed heap. As a result, any non-trivial Win32 code will be full of try..finally sections that take care of freeing objects, while 90% of all .NET code will not care about freeing objects at all. Removing this extra code on the Win32 side is not an option, and keeping it around for .NET would add a tremendous unnecessary overhead to your applications (fuelling the ".NET code is slow" myth).

It is my opinion that maintaining a common set of code for Win32 and .NET is a myth for all but the most generic business-logic type of code. The differences between the platforms are just too stark to make this feasible.

That said, for those that are interested in porting Delphi Win32 code to Chrome, there is an open source project called ShineOn (http://shineon.berlios.de) that is focusing on providing a compatibility layer for compiling applications that use the Delphi RTL with Chrome. The focus is not to achieve 100% code compatibility with Delphi code, but to ease the migration of code that heavily relies on Delphi RTL functions and classes (such as the System and SysUtils unit, TStringLists, etc).

You've introduced a few new language features. Can you give a brief summary of the most important of these and explain their benefits to developers.

mh: We basically have three kinds of language enhancements in Chrome. On the one hand, we have some major new features that enable you to do things previously impossible or requiring unreasonably larger amount of code; among those are things like Class Contracts, asynchronous methods, and of course generics.

Then we have a quite comprehensive list of small language tweaks, things that aren't really rocket-science or radical new language concepts, but which will allow you to write code more efficiently and more clearly; for example Chrome provides the ability do declare for loop variables inline, initialize fields right inside the class declaration, declare inline property readers, or the "for each matching" extension to for loops that allows you to easily process a particular subset of a larger collection.

Finally, we have changes and extensions to the language that basically are second nature to the .NET platform, such as events and delegates, virtual properties, "for in" loops, finalizers, so called "unsafe" code and proper no-compromise namespace support  

Borland has gone to some lengths to ease the migration path from Win32 to .NET using a .NET version of its VCL class library. Is there any easy migration path from Win32 Delphi to Chrome?

mh: Chrome's main goal from the get-go was to provide a new language that cleanly integrates into the .NET world - without compatibility baggage weighing it down. So wherever we had to make a decision to compromise the cleanliness of the language vs. compromising Delphi compatibility, we usually sided in favour of the language.

But we do provide a couple of compatibility switches and features that will ease porting of Win32 (or .NET) Delphi code. Also, as I mentioned before, there's the ShineOn project that's working on providing an Open Source compatibility library for the Delphi RTL.

I think that it's safe to say that porting a substantial project to Chrome will involve a certain amount of work and adjustment (in other words, it usually won't be a matter of copy/pasting the code and compiling it), but should be a straightforward and easy enough process - and hopefully well worth it, given the benefits of the Chrome language.

You've created a version of Chrome to run under Mono. How different are the .NET and Mono releases?

mh: There is no difference at all. We do provide a separate "for Mono" version for download, but the only difference is that it's a tar.gz file instead of a Windows based installer, and that the sample projects are - where needed - adjusted to use Linux style path strings. This version is more of a benefit for Linux users who don't have a Windows system - there's not really any technical difference. The exact same Chrome compiler binary works on both systems; you can literally copy the Chrome.exe (and the couple of related dlls) from your Windows box to your Linux box and run it there.

If you think about it, this is a really great accomplishment from the Mono team. We do a lot of testing under Mono, on both Windows and Linux, of course, but as far as I recall there wasn't a single incident where we had to make significant changes to the compiler to make it run under Mono - it just worked.

It is probably worth mentioning at this point that, no matter what platform the compiler is running under, it will allow you to link against either .NET or Mono. So, for example, even with the compiler running under .NET (say, inside the Visual Studio IDE), you can point it to the Mono .dlls and link your application against Mono - or the Compact Framework, or Portable.NET (http://www.dotgnu.org), for that matter.

In your opinion, how important is the Mono platform? Isn't there the risk that it will always be trailing behind the lead set by Microsoft as new versions of .NET are released?

mh: I think the Mono project (http://www.mono-project.com) has great potential, and we at RemObjects are very committed to fully supporting Mono, not just with Chrome but also with our other .NET products such as RemObjects SDK.

In my opinion, Mono is the first real chance this industry is seeing for real and usable cross-platform software development for Windows and Linux (as well as, eventually, MacOS, BSD and the other platforms targeted by Mono). As mentioned above, Mono has done a really awesome job at providing an implementation of the CLR that is compatible to Microsoft's - I think the fact that a piece of software as complex as the Chrome compiler itself works without hitches and without any major portability considerations necessary from our side already speaks volumes. The way things are looking right now, Mono has a real chance at succeeding, where other attempts (such as Kylix, or even Java) have failed.

The big test for Mono will of course be the Windows Forms implementation, which at this time still needs a lot of work, and which will, of course, be the deciding factor for whether Mono will become interesting for the average developer of GUI applications.

But in reality, the big desktop push for Linux that many anticipated hasn't really happened, and Linux is still mainly a server operating system. And for server and command line applications, Mono is a very usable reality - now.

What is the future of Chrome? As you've already introduced language features that are not found in Delphi, this seems to imply that you have decided to sacrifice compatibility with Delphi. Does this mean that you will, from now on, be in direct competition with Borland?

mh: As I said before, compatibility with Delphi is definitely not our top concern; we want to concentrate on innovating and extending the Chrome language beyond what it is now, by adding more features in the future. Right now, work is already going on for the next version of the compiler, which will introduce more .NET 2.0 features to the language, as well as some other exciting language features we can't really talk about, yet.

By focusing too much on Delphi compatibility, we would slow down this innovation, and we'd also cut off our own market - if Chrome was the same as Delphi, why would anybody bother using Chrome? That'd be senseless. No, the purpose of Chrome is to provide language innovations that are not, at this time, happening on the Delphi front - I think we've been very successful in achieving this for Chrome 1.0, and we have a lot of more cool stuff up our sleeves...

Of course, I'd be very happy for Delphi users if some of the enhancements we introduced to Pascal with Chrome might inspire the Delphi R&D team and would make it into future Delphi versions.

As to whether we are in competition with Borland... Chrome is a Object Pascal language for .NET, so is Delphi. I'll leave the rest as an exercise for the reader!

Many people would say that Pascal has become something of a niche language these days. If I were presently using some other language such as VB or C#, why should I consider using Object Pascal instead?

mh: Well, that's a tricky question. By their very nature, Pascal, C# and even VB.NET are very similar languages where the basic OOP concepts are concerned, so the main deciding factor is, and probably will always be, the syntax. A developer from a C/C++/C# background who dislikes Pascal's verbose syntax will have a hard time warming up to Chrome, just as developers from a Pascal background usually don't want the "curly braces" of C-style languages.

So if you're a die-hard C# "I need my curly braces" user, chances are you're not going to be happy with Chrome. That said, I think we do provide a number of features that make it attractive for C# users to consider Chrome:

For one thing, the Pascal language with its separation into interface and implementation sections can be a lot more readable then C#, especially what larger classes are concerned. Its language constructs are also more intuitive than the often-cryptic C-style syntaxes, making code easier to read and understand.

Also, we provide a number of productivity features that allow you to accomplish certain tasks with much less code than in C# (or other .NET languages), such as the before-mentioned Class Contracts, "for each matching" or asynchronous methods. Chrome also offers a lot of options for so called "unsafe" code, that go beyond what can be done in C# - making it interesting for developers that are otherwise considering moving to C++.

Finally, a big feature that no other .NET language provides, as far as I am aware of, is Chrome's cross-linking capability. This allows you to link your applications against other platforms than the ones you're running on. One example mentioned earlier was linking against Mono; another interesting possibility is to link against .NET 2.0 from the Visual Studio .NET 2003 IDE - allowing you to use make use of new features such as generics (including full IntelliSense support for them), without having to upgrade to the Beta IDE of Visual Studio 2005.  

As a long term Delphi developer, I need to know at least one really good reason for using Chrome instead of Delphi 2005. Can you give me one....?

mh: I hope that the above answers have given a lot more then just one good reason to choose Chrome…

Three of my personal favourites are:
(a) Proper namespaces
(b) Generics
(c) the Visual Studio IDE.

marc hoffman was born in 1975 in Dortmund, Germany; in 1992 he spent a year in Nelson, Wisconsin and finally moved to Berlin in 2003. marc has been writing software since he got his first Commodore C64 in the late 1980s, and has been a user of Delphi since day one. In 1996 marc founded elitedevelopments software, a company that creates developer tools and platforms for web hosting; in 2002 he co-founded RemObjects Software with Alessandro Federici and co-wrote their first product, RemObjects SDK fo Delphi. Since early 2004 marc has been the Chief Architect for RemObjects' line of .NET products, and project manager for Chrome; marc's blog is at: http://blogs.remobjects.com/mh/

June 2005