Zen and the Art of Programming

Antonio Cangiano February 4th, 2008

It saddens me to learn that the Ruby.NET project is dead. About 5 minutes ago, Dr. Wayne Kelly announced the following in the Ruby.NET Mailing List:

Ruby.NET started life in 2005 as an academic research project with the goals of learning more about the challenges of mapping a dynamic language such as Ruby onto the relatively static CLI platform. When we released our first beta in 2006, many people got excited and started blogging about the project, at which time the project took on a life of its own heading towards a production quality release that people could one day actually use. The release of IronRuby last year obviously caused us to question this unstated goal. At the time we didn’t know if the IronRuby project and the DLR would succeed, so we decided to continue with Ruby.NET at that stage. Last week at the Lang.NET Symposium, I presented our work on the Ruby.NET project and also had the opportunity to learn more about the progress of the IronRuby project and the inner workings of the DLR (and also the JRuby project presented by Charles Nutter).

I’ve come to the conclusion that the DLR is clearly here to stay - it’s becoming an even more important part of the Microsoft platform. I also believe that to obtain production quality performance, Ruby.NET would need to reinvent (or adopt) something equivalent to the DLR. If we were starting the project today, there is no way we wouldn’t use the DLR. Whilst Ruby.NET initially had a good head start on the IronRuby project; by incorporating the Ruby.NET parser and scanner and by leveraging the DLR, I now believe that IronRuby is more likely to succeed as a production quality implementation of Ruby on the .NET platform. I believe that ultimately there is no need for two different implementations of Ruby on .NET. So, if Ruby.NET is ultimately not going to be that implementation, then we should not waste further developer effort fruitlessly chasing that goal. There is still a massive amount `of work required to achieve full semantic compatibility, to achieve production quality performance and to get Rails to run robustly.

There have already been a number of practical and research outcomes from the Ruby.NET project, however, at this stage, I believe we (the Ruby.NET community) can make the biggest impact by levering our experiences with Ruby.NET to contribute to the IronRuby and DLR projects. Personally, I still feel we have unfinished business - we set our selves the goal of running Rails on .NET and we haven’t achieved that yet. If we can leverage our experience to help IronRuby get to that point, then I’d at least have the personal satisfaction of helping see the job completed.

These are just my views. As a researcher, my prime interest is not in developing products, but in developing innovative new ideas and having an impact by having those ideas used in the real world. I’m aware that others in the community will have different goals and so will presumably have a different take on this - I’m keen to hear what you think. If anyone wants to press ahead, then the code base is still owned and controlled by you the community, so you are free to do with it as you please with our full blessing.

I’d also like to make it very clear that this decision is entirely my own - based on research and technical considerations. Microsoft did not in any way suggest or encourage us to kill the project and we thank them again for their support of the project.

I’d like to thank all of our contributors and supporters and apologize if this decision comes as a disappointment. I hope many of you will join me in contributing to the IronRuby project and see it through to a successful completion.

Cheers, Wayne.

While this news leaves an unpleasant taste in the mouths of those who followed the project, it has been clear for some time that the future of Ruby.NET was shaky at best. They did the right thing though and I wish the best to Wayne and his team. Hopefully we’ll see a surge of IronRuby contributions, because a valid .NET implementation of Ruby is important to many people.

• .NET , Ruby
• Comments(12)

Antonio Cangiano November 23rd, 2007

A few days ago Microsoft announced the final release of Visual Studio 2008 and .NET 3.5. As expected, .NET developers were impatiently awaiting such a major release, which introduces countless improvements and new features within the IDE, the framework and the compilers for the two main languages, C# 3.0 and Visual Basic 9. It didn’t take long for the news to spread across the blogosphere, with all sorts of details for those interested in the Microsoft platform.

What didn’t get much attention, as far as I can see, is the almost concurrent release of the first community edition of Ruby.NET (version 0.9). For us Ruby lovers, this is a significant event which deserves to be the focus of this post.

Back in July of this year, Queensland University of Technology (QUT) decided to entirely transfer the control and ownership of the project — that was initially sponsored by Microsoft Research — to the Ruby and .NET open source communities. The project was formerly known as Gardens Point Ruby.NET and the first beta of the compiler was made available back in June of 2006 by the leaders of the project, Dr. Wayne Kelly and Prof. John Gough. Renaming the compiler was a choice that aimed to reflect the desire to make the project truly independent and open source; code from the community for the community. It is however reassuring to know that QUT’s staff (who has a solid track record of delivering compilers) continues to be heavily involved with the project and their commitment, along with the work of the community, has permitted the launch of this community edition release in the span of just a few months.

Ruby.NET 0.9 includes substantial improvements, and amongst the many bug fixes, it is worth mentioning the improved Ruby and .NET interoperability, the possibility to visually design Windows Forms application within Visual Studio, the creation of .NET delegates through Ruby blocks, and .NET sub-typing.

Ruby.NET should not be confused with IronRuby, the alternative project I mentioned in a couple of posts, a few months ago. There are several differences between the two projects, but I feel that the two strongest distinguishing factors at this stage are the maturity and, I suspect, the affiliation of the projects. IronRuby is hosted at RubyForge but it’s still in pre-alpha mode, but no files have been released to date on RubyForge (albeit you can grab the code directly from its repository). Ruby.NET on the other hand, is at version 0.9 and is almost production ready. The final test — being able to run Rails — has not been passed yet, but it is clear that the project is getting closer and closer to a production quality 1.0 release. Furthermore, Dr. Kelly is open to work together (w.kellyATqut.edu.au) with those who intend to use the compiler for production purposes, as a form of showcasing examples of real world usage.

From an affiliation and legal standpoint then, IronRuby as a Microsoft project, is released under the Microsoft Permissive License, while Ruby.NET can be considered fully open source and independent from any vendors at this stage (and it has a BSD license). Depending on how you see this, it can either be an advantage or a drawback.

When discussing languages such as Java and C#, it’s rarely the JVM or the CLR (Common Language Runtime) which is the subject of harsh criticism, but it’s rather the language itself, for its verbosity, complex design patterns required to solve simple tasks, or its lack of advanced features, in the eyes of the experienced programmer who has experimented with Ruby, Python, Lisp, Haskell, Erlang and similar languages. In response to these needs, the industry has reacted with a couple of trends. The first approach is that of using a common virtual machine and also offering a handful of advanced but less common languages for it. Ruby.NET, IronRuby, IronPython, JRuby and Jython are all examples of this. At least in theory, this offers developers the possibility to program in their favorite language while still integrating their code with the existing one, and relying on “enterprisey” runtimes, frameworks and libraries that are accepted also by the least adventurous IT managers.

The second trend, adopted by both Microsoft and Sun is that of improving upon the main promoted languages, C# and Java respectively, by integrating functionalities and programming paradigmas taken from functional, distributed and research languages. The two approaches are somewhat complimentary but they end up meeting asymptotically when advanced, research, “toy” and less common languages become more “real” and are fully integrated on the Java and .NET platforms, and mainstream languages like C# become advanced and sophisticated enough to please the most refined developers.

This convergence is harder in practice, especially if we get into the topic of side effects and purely functional languages. But for mixed paradigm languages like Ruby, the advantages deriving from projects like Ruby.NET or JRuby are clear. As a Technical Evangelist, for example, I interact with many consultants and their most frequent question is always about suggestions on how to introduce Ruby into environments that are typically against anything new and “not yet proven”, especially if open source. For shops that heavily rely on Java or .NET, a production ready JRuby or Ruby.NET is a free ticket to the introduction of Ruby within the company, without requiring too many changes, risks or raising any alarms in conservative settings. In the case of Ruby.NET, it works with Mono too, so it doesn’t have to be limited to Windows either.

Let’s give some love to this important project, as it may help us to soon write Rails applications which seamlessly interact with ASP.NET, or visually design nice desktop ones whose program logic is powered by Ruby (and we all know what a boost in productivity that can be).

I invite you to blog about the release of Ruby.NET 0.9 and if you know at least a bit of Ruby or C#, to contribute to this very promising project. You can start by reading the page for the contributors and the PDF paper Ruby.NET: A Ruby Compiler for the Common Language Infrastructure for an architectural overview of the implementation.

• .NET , Ruby
• Comments(2)

Antonio Cangiano August 5th, 2007

In his article, ”Desktop Applications are Dead”, Eugueny Kontsevoy - a Windows developer - argues sarcastically about the demise of Desktop applications. His article has real merit though and focuses almost exclusively on the problems which are introduced by Vista’s aggressive security policies. The annoying aspect of Windows Vista’s “cancel or allow” is undeniable, especially if seen through the eyes of an Independent Software Vendor (ISV, or in the case of a one man show, a Micro-ISV) who needs to convince the customer to download his program and install it in order to try it before buying. Every customer who gives up on installing your program is a possible lost sale. In a world where Windows users are already afraid to compromise their operating systems, the ability to make a sale needs to be preserved and defended; any extra barrier is harmful for multitudes of software vendors. Here Kontsevoy is damn right about this factor.

From DLL Hell to .NET Framework Hell

Eugueny even has a point in regards to applications which are developed with the .NET Framework. It is a necessary requirement of C#, VB.NET and managed VC++ .NET apps that you install the .NET Framework. You can’t just pick an arbitrary framework version either, depending on what language and framework features you employ, you may be targeting .NET 1.0, 1.1, 2.0, 3.0 or the currently in beta, .NET 3.5. Windows Vista ships with the redistributable version of .NET 3.0, therefore it is safe to assume that a developer will be able to run their applications on Vista if they target .NET 3.0 (Visual Studio .NET 2008 Beta2 allows you to define a target for you project, from 2.0, 3.0 and 3.5). .NET 3.0 incorporates Windows Presentation Foundation and with some design skills and the most colorful .NET book around (Windows Presentation Foundation Unleashed- easily the most eye pleasing book I own) you should be able to create attractive User Interfaces and be happy, right? Not exactly. I don’t have any hard numbers, but I would guess that the majority of users are still running Windows XP. The SP2 of Windows XP has an optional .NET 2.0 framework installation (not 3.0 though) so you’d be out of luck even if the user did install the optional component. From a business perspective you have to remove any possible barriers between your product and the customer. You absolutely need to maximize the number of people who successfully try your program in the hopes that they’ll love it enough to shell out their hard earned cash and actually purchase a copy of your product.

It would make sense then to target the .NET 1.1 Framework, as it is the most widespread version, plus applications written for 1.1 will work on .NET 2.0, 3.0 and all subsequent versions. But programming for 1.1 means not using any of the cool features that Microsoft introduced in C# 2.0, it means using Windows Forms 1.1 and being stuck with a rather primitive version of VS.NET (2003). It also means that you won’t be able to take advantage of many commercial and free third party components whose minimum requirement is Microsoft .NET 2.0. C# 3.0 and LINQ (both available only in .NET 3.5 require .NET 2.0) make for great blog posts and can raise a hell of a buzz, but they won’t help you too much when it comes to maximizing your profits – at least in the commercial/shareware sector at this time. This cycle will be repeated when newer version of .NET come out and new innovations (be they copied or original) are introduced by Microsoft. Vico was definitely right, history does repeat itself. There are attempts like ClickOnce deployment to solve these problems, but they raise other issues, and as far as I can see it, there is no definitive solution right now.

.NET is not the only option

Microsoft produces the most popular operating system in the World. It is natural then for developers to embrace the development solutions proposed by the maker of the OS that they are going to develop for. The marketing division of Microsoft is particularly good at attracting millions of developers, especially if we consider that they can afford to produce highly productive and decently innovative tools which are available for free or at fairly reasonable price tags. We all laughed when Ballmer shouted, “Developers, developers, developers…”, but when you think of Windows development nowadays, you are inevitably thinking about .NET. However, whether you view this as a pro or a con, ultimately it doesn’t need to be the only case.

If .NET imposes too many constraints on Independent Software Vendors, then we must not forget that .NET is not the only available option. It’s a personal choice, each company or developer can decide which way to go, but it is important to raise awareness about the potential alternatives. Sure, Microsoft produces Windows and should know better (in theory). Sure, they have a market cap of $271.65 Billion versus the few hundred million or less that most of their competitors reel in, but in the end, if .NET clashes with your business model, you have to consider looking over at the other side of the fence in order to find alternatives that fit you better. Let me make this clear, I’m not dismissing .NET for Desktop applications, I know full well that there are companies out there making millions in this market, while still using .NET.

A few potential alternatives to .NET

If you are aiming to develop commercial applications for Windows, be it the next Adobe Photoshop or a $15 utility, Microsoft .NET’s mainstream presence may give you an advantage. How so, you may ask. We’ve already exposed possible issues with .NET and this portion of the business of software, but the main problem in the end, is an inconvenient runtime which weighs you down as the right version of the framework has to be installed somehow before your application is able to work. A winning alternative would have to provide you with a stable environment which is affordable, as productive as its Microsoft counterpart, has a decently sized community and so on. But its main selling point would have to be that it needs to produce native Win32 executables. Doing so will be the secret advantage that an ISV holds over the majority of their competitors who use .NET. When you ship a really fast application in a single non-bloated .EXE file, you are embracing a meaningful percentage of the Windows market. The application will run on older versions of Windows, from Windows 95 up to Windows Vista, it will most likely feel more responsive and the lack of an extra layer which needs to be installed is going to enable it to be easier to install on your customer’s PC. The aim of maximizing your customer base will have been achieved from a technical standpoint.

Delphi

Wait a second, didn’t Delphi die out many years ago? Not quite. What do the following applications have in common? Skype, MySQL Administrator, SQL Backup, Macromedia Captivate, Inno Setup, Borland Developer Studio itself, TOAD, Beyond Compare, Macromedia HomeSite, etc… You bet, they’re all written in Delphi. Delphi (the IDE) and Object Pascal (the language) have always been much more popular in Europe than in the States, but despite this, what almost killed Delphi was its management. Borland made a few crucial mistakes that cost Delphi a lot in terms of its popularity. It’s a typical scenario really, were a technically superior product (think of Betamax vs VHS, etc…) ended up being much less successful than a better marketed, but less valid alternative (e.g. VB6). The press has long spread word of Delphi’s imminent (or present, depending on where you’re sourcing your info from) death for almost a decade now, but Delphi is still alive and kicking. Sure, since .NET came along market percentage that Delphi covers has dwindled, but Delphi may be the right answer for the sorts of development needs outlined above.

If you speak to the majority of Delphi developers, you will notice that they are passionate and very convinced about the product they use. They may be a small group at this point, but it’s a good, endearing community. The other positive news is that Borland has separated their Developer Tool Group into a company called Code Gear. This company makes up 25% of Borland’s total income and they’re 100% focused on the promotion and improvement of Delphi and their other development tools. Delphi’s Product Manager, Nick Hodges, is very active in promoting the product and responding to people online. The buzz is slowly growing, and Delphi’s future is looking far more positive now than it has for quite some time. Code Gear may be the best thing to happen to Delphi in ages.

Code Gear Delphi 2007 for Win32 is a development solution for ISVs that doesn’t fall short of Microsoft .NET. The professional version sells for less than $900 (US). There are also two other editions that you can use for commercial products: Turbo Delphi Explorer (entirely free) and Turbo Delphi (for Win32) Pro which costs less than half the price of Code Gear Delphi 2007 Professional. The free version is mostly limited by the fact that you can’t add third party components, and Delphi’s market is full of these kinds of high quality components. I really think that for ISVs it is worth investing in the Delphi 2007 Pro version. Code Gear produces a version of Delphi which targets .NET as well, and while this may be good for interoperability (Borland Development Studio 2006 even includes C# Builder), I believe that Code Gear should really focus on Delphi for Win32 as that is the crucial element which distinguishes it the most from Microsoft’s offering. They should also work on support for Win64, Cross Platform development, and Unicode. All of these things are lined up and they’ll take care of them in future releases, but I’d say that even having to spend time developing further ASP.NET support in Delphi is somewhat wasteful. The idea of writing code once and then being able to compile it for both Win32 and .NET is nice, however most software developers who decide to go for .NET, would rather go directly with Microsoft rather than use Delphi. So instead just opt to do one thing, but do it right.

Within the market we defined above, Delphi 2007 for Win32 offers up speed which is comparable to C++, but with an ease of programming similar to that of Basic. And yes, the executables are “Vista enabled”. My number one choice, if you’re not adopting .NET, is to go with Delphi. If you decide to do so, you can start by watching introductory videos here. And if you’re skeptical about Delphi’s future, consider the open source Lazarus project which can produce Win64 executables and cross platform executables through Free Pascal. It’s not as polished as Delphi, so for Windows Delphi is definitely the way to go. Yet you could always port your projects to Lazarus in order to target Mac OS X and Linux when required. This also guarantees that your code won’t go to waste, should Delphi disappear in the future (very unlikely).

Unmanaged C++

C++ with MCF or WCL or whatever toolkit you prefer is an option as well. You can even use Visual Studio .NET 2005 for this. So what’s to question about C++, you may ask. Well, C++ is not for the faint of heart and I think that it is a few time slower to develop with than Delphi. But you get the same benefit of native programs and there is nothing wrong with this option – if you know what you’re doing.

Cross platform solutions

Beside Delphi and VC++ there are a few cross platform options available. The bad news is that none of them is as productive or polished as Visual Studio and Delphi are. Furthermore, cross platform applications have a tendency to look good but “not quite right”. Possible options in this category are Real Basic, Trolltech QT, wxPython and even Java. Keep in mind that Java has two big issues. It doesn’t really solve the problem of runtime (though it makes it much more manageable), and while UIs can look good, they are usually clearly not native in any operating system.

An important cross platform solution for both Windows and Mac, is the uber-popular pairing of Flex and Adobe Air. Again, you still have runtime issues and, on top of that, you don’t have native widgets on either Windows or Mac. However applications can look very sleek and sexy, and I think it was worth mentioning this possibility.

Windows is not the only option

I can hear you thinking that this doesn’t solve Windows’ Vista issues. We have shown alternative solutions that simplify the process of delivering software over the Web, but we haven’t addressed the main concern in Eugueny’s post. We simply can’t change Vista; its issues remain. Should we then conclude that Desktop applications are dead? I don’t think so. Most customers will eventually learn to work around Vista’s nagging (or annoying, depending on how you look at it) features and will end up installing the software that they really want one way or another.

Providing a solution that doesn’t require a runtime install on top of the application would be a way to make good headway, as we (the developers) have done all that we can at this point. But let’s assume, as absurd as it might seem, that Vista really does block the majority of customers from installing software. Don’t you think that Microsoft will be forced to do something to address such a worrisome problem? If they don’t, it could practically be called suicide. And let’s move forward, let’s assume that Microsoft ignores the problem and only 5% of the Windows user base will install Internet commercial software from an ISV. Does this imply that Desktop applications are dead? I don’t think so either, because what Eugueny failed to consider was that Windows is not the only operating system available. Sure, it’s hugely popular, but that alone is not a good enough reason to ignore the other possible markets. There are emerging markets for the development of Desktop applications on Mac and Linux. Especially on Mac, where there’re plenty of companies making a lot of money by producing native Objective C and Cocoa applications. And there are plenty of users paying for these applications. Heck, even for Linux it’s possible (albeit harder) to create and market commercial software. As long as there are millions of customers out there who’re willing to pay for Desktop applications which scratch a particular proverbial itch that they happen to have, the Desktop application market is not dead. Luckily.

Did Web 2.0 kill the desktop star? What if the average quality of the software for Windows is so low that users don’t even bother to go through the annoying Vista installation process? Even in a pessimistic scenario where Windows Desktop applications are no longer in fashion, the claim that ‘Desktop applications are dead’ is not supported. Why? Because all this doesn’t affect Mac OS X. Mac users enjoy good applications, they appreciate the effort it took to create well designed software, and many are ready to spend money for valuable tools that solve a specific problem. One could argue that even if the catastrophic situation forecasted in the article mentioned above was to come to fruition, we could only state that Windows Desktop applications are dead. And honestly, I don’t think this is ever going to be the case, because Windows users are not too different from Mac users in regards to purchasing software that they value (or pirating it). Most likely, Desktop applications will be redefined and they’ll continue to evolve as a consequence (or positive side effect) of the endless stream of ubiquitous Web applications. Many applications will be moved onto the Web, sure, but many others are here to stay. I wouldn’t declare a whole broad category of applications to be dead with such ease.

Desktop applications or Web Applications

Web Applications offer several advantages over ‘fat clients’, but a “Web aware”, well written and properly designed Desktop application can provide an experience that is in my opinion, superior to that which you can experience through your browser. I love many of the so called “Web 2.0″ websites, but I also love several Desktop applications that I would never want to see end up being moved to the Web. Integrated with the Web or synchronized on the Web, perhaps, but not entirely replaced by a Web Application. Highly interactive and responsive sites are cool, but let’s not make of Web 2.0 a hammer which is eagerly ready to consider each and every problem as a nail.

Google Reader is a good Web Application for example, but it’s not a replacement for NetNewsWire on Mac OS X. If the Desktop app is practically dead, how come this product got downloaded more than a million times in a niche market such as that of Mac? We need less crapware and more high quality Desktop applications on Windows. Users will be ready to click a couple of scary “allow” buttons if we produce software that is genuinely worth installing. It’s inconvenient that Windows developers have to deal with poor OS choices that may lead them to lose significant amounts of customers in the long run, but the market is big enough to economically justify this in many cases.

Feel free to port your applications to the Web, if there are concrete advantages to doing so, but despite the look of it, Desktop applications (perhaps as smart clients or any other evolution of them) are here to stay. I don’t want a Photoshop, a Visual Studio, an OmniGraffle on the Web, even if it’s technically possible to do so. Let’s not forget that the Web was born for sharing hypertexts. And while it’s fine and dandy that it’s evolved since then to a point where we’re now able to run applications through a browser, let’s not lose sight of what is better suited to a browser and what’s not. Desktop applications are not dead. Even if in ten years there may be a convergence of web applications that look like Desktop applications, and Desktop applications with many of the advantages of Web applications, Desktop applications will still have a florid market, so long as we aim for quality, usability and web integration.

• .NET , General , Mac
• Comments(39)