Zen and the Art of Programming

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)

Antonio Cangiano July 30th, 2007

In my previous post about IronRuby, I expressed optimism while pointing out issues with the first pre-alpha release. Just as John Lam acknowledged, this is indeed a very promising start. My post received two great responses: a patch for all the problems that I pointed out and even a tutorial on how to approach the hacking of IronRuby’s source code.

I knew, or at least I hoped, that this would happen. When I hit the publish button, I was almost certain that someone would come up with a patch in an hour or so. This is a testimonial to the power of open source software. In this case though, something more was shown: the power of open source when your source code is damn good. IronRuby’s code is clearly elegant and extremely easy to change and extend. I rarely say this, but I’m highly impressed by the quality and clarity of IronRuby’s code. Pretty much anyone can amend the code for the bugs I pointed out, all you need to know is some basic C# syntax and the concept of method overload.

I’ve known C# since its first appearance (2001) and I usually consider it rather verbose, but IronRuby shows what good C# code is all about. I’d argue that the same issues wouldn’t have been fixed so easily or quickly if the code was cryptic or if this was the main C implementation of Ruby. So what can we expect when the project hits RubyForge? A lot of participation and very rapid progress because the barriers of entry are very low. We’ll need plenty of test cases, a decent road map and good leadership, but I see this project excelling and progressing at a fast pace.

I sincerely hope that Microsoft won’t “embrace, extend, extinguish” this one, because it would be a shame. So far, starting from hiring John, all the way up to the decisions regarding distribution of the code and contributions, Microsoft has nailed it.

• .NET , Ruby
• Comments(4)

Antonio Cangiano July 26th, 2007

Ruby is a remarkable language, and even companies like Microsoft and Sun, end up taking notice of, and embracing, it rather than opting to fight against its widespread appeal. More than ever Ruby is seen as an unwritten (sic) specification that is not limited to its official implementation. The main current interpreter is suboptimal as we all know. This scenario has one big advantage, though it may appear as a disadvantage at first: projects keep popping up in a quest to generate an efficient and widely adopted interpreter/virtual machine. Generally speaking, this diversification is a risky business because it can’t help but divide the effort put forth towards it by those within the community. Years of Open Source history have taught us though that options are usually a good thing and the majority of development efforts will still go towards the most promising projects. We allow mutations of an original idea into multiple projects, and in turn let a sort of natural selection decide their destiny and long term adoption.

In the specific case of Ruby, besides the current interpreter, JRuby is the most prominent implementation. Other notable mentions are Yarv - the work in progress at the core of what will be Ruby 2.0 -, Rubinius, Ruby .NET (formerly Gardens Point Ruby .NET) and now IronRuby. JRuby and IronRuby are directly developed and promoted by the producers of the two mainstream platforms, respectively Sun and Microsoft. Their interest goes beyond the simple issue of putting out a Ruby implementation which performs well, that is already being answered by Yarv. What they bring to the plate is the possibility of integrating Ruby with the existing code base respectively for Java and .NET. This is a key point, because let’s face it, despite its success, Ruby is not going to replace Java or C# in the mainstream market over the next few years (if ever). Interoperability is exciting as it is synonymous with removing the barrier of entry to Ruby for the Enterprise world and non-Open Source based shops. Simply stated, we’re not asking them to toss their Java or .NET investments out the window, but rather we’re enabling them to take advantage of the rapid development which is possible through Ruby - while still using very refined tools, the existing code base, and a platform which they are accustom to.

By now you should get that I’m highly interested in the development of these implementations, particularly for the .NET and Mono platforms where beautiful GUI development works well. And while I’m afraid that Microsoft will continue to strongly influence the “natural selection” process that we covered above, limiting the Ruby.NET project which is about to be open-sourced by Queensland University, I can’t help but feel excited about IronRuby. So why the mildly negative title of this article, you may ask. On July 23th, John Lam announced the release of a first pre-alpha version which is available for download. This arrived sooner than expected, and Scott Guthrie - General Manager within the Microsoft Developer Division - even showed us some shiny windows made with IronRuby and WPF. Not only this, John also announced that they will be soon taking contributions for the IronRuby libraries and that they will host the project at RubyForge (wow, they must have Lawyers 2.0 as well :-P) and that they have some interesting micro benchmarks. This is all great, so again what’s the issue? Well, I was very interested in trying out IronRuby, but I immediately discovered that it is very crippled from a mathematical standpoint, even for a pre-alpha version. I have a lot of respect for John Lam and the people working on this, and I do understand that it’s a first drop of code and therefore basically in its infancy and that in turn we can’t, in all fairness, have unreasonable expectations at this stage. However after running some simple tests, it is clear that a lot of work is required in order for this project to live up to the buzz that is being generated online about it, when you take into account that even some simple arithmetic functionalities are either flawed or missing altogether.

Some basic calculations

If you build IronRuby and run rbx.exe, you will find yourself in a .NET enabled version of irb. By the way, it may be a good idea to change that name as it is the one already adopted by Rubinius and possibly by spyware on Windows. Let’s see what happens when we do some basic calculations:

As you can see, this incorrectly converts 3.0 to the integer value and then performs an integer division. If you run this in the official Ruby interpreter, and presumably in any other implementation, you will get 0.333333333333333. Trying to be forgiving on this one by using a floating point number for the numerator as well, makes things worse:

We can’t divide two floating point numbers in IronRuby? OK, let’s stick with Fixnum (small integer numbers) and perform another basic mathematical operation: the exponentiation.

This didn’t work either (of course, we were expecting 8 as a result). So while calculating several multiplications, I noticed another problem:

The safety of performing calculations with big numbers (without having to deal directly with overflows) is an important aspect of Ruby. While the Bignum class appears to be defined:

It is clear that it is not implemented and it’s only there as a placeholder at the moment:

Conclusion

Please don’t take this as an attempt to bash IronRuby, as it most certainly is not intended as such. I have great expectations for this project and look forward to writing lots of Ruby code running on both .NET and Mono through IronRuby. Also, the developers have done a great job at coming up with a preliminary implementation in a very short amount of time. However, when you read about IronRuby and talk about it as the next great thing in the Ruby world, keep in mind that they were not kidding when they called it a “pre-alpha1″. I look forward to documenting the progress of this project on this site, and I will definitely continue to keep an optimistic eye on IronRuby.

• .NET , Ruby
• Comments(11)