How Microsoft is changing the programming world

Several years ago I knew a programmer, we’ll call him Joe, who fancied himself to be a great developer. He was a senior developer at “Big Co.”, who received a large enough pay check to just as easily compensate a few junior developers.

The guy had Microsoft certifications, as expected of one in his position, and he appeared to know Visual Studio inside and out, just as you’d imagine.

What was surprising for me at the time, was that as I got to know Joe better, I slowly started to realize that the guy was absolutely clueless about programming beyond the scope of the Microsoft bubble.

He had never used Linux in his life, nor was he interested in learning about it. He wasn’t aware of tools like CVS or SVN. He didn’t seem familiar with the ideas behind unit testing or Agile methodologies; words like “refactoring” were outside of Joe’s vocabulary.

How about other programming languages or paradigms, like functional programming? Nope, nothing there either. He knew Visual Basic 6 and VB.NET, C# (the first release at the time) and a bit of C++. That’s it. And he was proud of it. As I enquired further in an attempt to figure out what he was all about, he didn’t mind admitting to a complete ignorance of what wasn’t printed on Microsoft paper.

What’s interesting is that, despite his cluelessness – due to a strict adherence to the Microsoft view of the programming world – and perhaps a lack of intellectual curiosity, the guy did manage to be somewhat adequate at his job. Not spectacular by any stretch of the imagination, but good enough to keep his well paid job.

Joe simply didn’t care about tools and techniques that fell outside of the narrow, yet mainstream, beaten Microsoft path.

Over the years I’ve met countless Joes. In fact, if I were to generalize and characterize many Microsoft developers in the early 2000s, Joe would come to mind like an unpleasant stereotype.

I tell this story not to criticize Joe or to claim that Microsoft developers suck. On the contrary, my argument is that Microsoft will be a key factor in terms of enabling functional programming to become mainstream. In fact, what Microsoft is doing is introducing .NET developers to functional programming, one piece at a time.

Just a few days ago I was reading the blog of a guy who seemed happy to discover a cool “new” function called Zip in LINQ (hey Haskell programmer over there, stop laughing, you are disrupting my article). These days following blogs by Microsofties is in fact like witnessing some sort of Renaissance, with plenty of talk about exciting features that are clearly borrowed from the functional programming community.

The evolution of C# and Visual Basic, LINQ, and more recently the inclusion of F# as a fully supported language within the .NET Framework 4.0, all indicate Microsoft’s new outlook towards functional programming. F# in particular is essentially OCaml for .NET, and has been received with open arms by the Microsoft community (as far as I can tell).

There are very few books by mainstream publishers on OCaml. On the other hand, F# already has a rich ecosystem of printed books that have been published by O’Reilly, Apress, Wrox, Manning, and likely in the near future Microsoft itself. On top of that there are titles devoted to LINQ and countless books on the recent, more functional oriented, C# and VB.

I’m not measuring the popularity of programming languages by the availability of books alone, but it’s clear to me that there are millions of Joes out there who are ready to learn these new concepts that are now being put out and promoted by Microsoft. It doesn’t matter that they’re not new or that they’re borrowed from other programming languages like Ruby, Python, LISP, ML, Haskell, etcetera.

The end result of Microsoft’s new approach is that now Joes everywhere are getting exposed to functional programming (masses of people who would otherwise be virtually shielded from the rest of the programming world).

Microsoft may no longer be the influential powerhouse it once was, but I think it is fair to acknowledge the impact it’s currently having on making functional programming, or at least some degree of it, more mainstream.

Update: Initially I used the name “Dick” (short for Richard) to identify the programmer I talked about in this story. It was meant to be a humorous double entendre, but turned out to somewhat distract certain readers from the key points that this article was actually about. As well it seems that some people felt I was coming across as being strongly against Microsoft developers (which I’m not in the least). As a result, some readers ended up being offended by this post, which was never my intention. I don’t love political correctness, but I feel that replacing the name “Dick” with “Joe” instead ends up detracting less from the heart of the article.

A faster Ruby on Windows is possible (benchmarks for 4 implementations inside)

In yesterday’s post I compared IronRuby 0.9, Ruby 1.8.6 (from the One-Click Installer) and Ruby 1.9.1 (downloaded from the official site) against one another. IronRuby did great, but the discussion in the comment section quickly veered towards what version of the One-Click Ruby Installer should have been used.

I justified my choice of using the “old” One-Click Installer, by the fact that I wasn’t aware of official releases of the new installer. As well as that the old One-Click Installer is the most widely downloaded version. Very few people are familiar with the upcoming version of the project. This point is about to change.

Luis Lavena took over the One-Click Installer project and has been working on the next version (RubyInstaller from now on), the aim of which is to replace the One-Click Installer by building Ruby 1.8 and 1.9 with MinGW and GCC. In theory, this brings performance gains on Windows to the table, and gets rid of having to use Visual C++ 6 (a “ten year old compiler”) to build Ruby and other native gems. The project also strives to be lighter by bundling fewer (unnecessary) gems for Windows users.

There’s no doubt that in the long run, this new project will become the de facto standard for Windows, but the questions on everyone’s mind are, should I bother with it now? How much of a performance boost are we talking about here? 10%? 20%? Let’s find out.

In this follow up article I’m going to compare the performance of Ruby 1.8.6 from the One-Click Installer (mswin32), Ruby 1.8.6 from RubyInstaller (mingw32), Ruby 1.9 (mswin32) downloaded from the Ruby-Lang.com site, and Ruby 1.9 from the RubyInstaller project (mingw32) against one another. I’ll copy and paste part of the setup and disclaimer from yesterday’s post, for those who haven’t read it. Feel free to skip this part if you wish.

Setup

• The benchmarks were run within a virtual machine with 2 GB of DDR3 RAM and a 2.66 GHz Intel Core 2 Duo processor. The operating system adopted was Windows XP SP3 (32 bit) with the .NET Framework 3.5 SP1 installed.
• Here I employed a large subset of the current Ruby Benchmark Suite project. The source code for all of the benchmarks is available within the repository.
• The best time out of five runs is reported for each benchmark. When the results report a Timeout, it means that more than 300 seconds were required for a single iteration and was therefore interrupted. Conversely, N/A means that a test that was compatible for the given implementation was not available or the setup on my machine was lacking the required libraries to execute it (1 test affected).

Disclaimer

• An attempt has been made to improve the quality of the tests. Some of them may be more representative of realistic workloads, but most of them remain micro-benchmarks. They are indicative of how these implementations compare, but cannot be viewed as a guarantee of how they will actually affect your own programs.
• There are lies, damned lies, and statistics.

Benchmark results

The table/image below shows the times for each benchmark, for Ruby 1.8.6 (mswin32), Ruby 1.8.6 (mingw32), Ruby 1.9.1 (mswin32), and Ruby 1.9.1 (mingw32). In the table I used (RI) as shorthand for RubyInstaller to indicate mingw32 versions.

Red values are errors, timeouts and inapplicable tests. Green, bold values indicate better times than what Ruby 1.8.6 (mswin32) delivered. A pale yellow background indicates the best time for a given benchmark. Total time is the run-time for the subset of benchmarks that were successfully executed by all four implementations. Timeouts have been included this time around. Each timeout has been counted as an additional 300 seconds.

The total runtime (including timeouts) is summarized in the chart below:

Conclusion

Wow! Ruby 1.8.6 (mingw32) improves from 3% to 664% (depending on the test), over the current One-Click Installer. The geometric mean of the ratios (read “on average”) tells us that it was about 283% faster. The Ruby 1.9.1 version provided by the RubyInstaller was slower than the mswin32 version in a couple of tests, but faster everywhere else. How much faster? Up to 342% faster, with an average (again calculated through the geometric mean of the ratios) of a 77% increase in speed.

These finds prompt me to ask, what are we waiting for? You know how unresponsive Ruby is on Windows, and how tests take forever to execute? These mingw32-based releases may very well solve this. And incidentally the bar has been raised for IronRuby as well. I formally invite the Ruby on Windows community to embrace these two projects.

Comparing the performance of IronRuby, Ruby 1.8 and Ruby 1.9 on Windows

In my latest article I discussed the importance of JRuby as a means of introducing Ruby to the Enterprise world. Most of the companies that belong to this ecosystem are Java based, but we cannot forget that a sizable portion of them are Microsoft-centric. Within these companies, Ruby will be far more welcome if a .NET implementation is available. The answer to this need is sufficiently fulfilled by IronRuby (version 0.9 was just released).

IronRuby has been progressing fast lately. First came support for Rails and then, with this release, a great deal of effort has been placed on improving performance. In the past, IronRuby was all but fine-tuned. In fact, it was several times slower than Ruby MRI, as the team worked on improving compatibility with Ruby 1.8 and mostly ignored performance.

In this article I’m going to provide some performance results for IronRuby 0.9 on Windows, which I’m sure will interest readers of this blog as well as of my book. Before revealing all the details, let’s start with the setup and a disclaimer. Please read through it carefully, because the old, trite comments about how “micro-benchmarks are useless” won’t be published. We’ve already been there, folks. Thank you all for your understanding.

Setup

• The benchmarks were run within a virtual machine with 2 GB of DDR3 RAM and a 2.66 GHz Intel Core 2 Duo processor. The operating system adopted was Windows XP SP3 (32 bit) with the .NET Framework 3.5 SP1 installed.
• Here I employed a large subset of the current Ruby Benchmark Suite project. The source code for all of the benchmarks is available within the repository.
• The best time out of five runs is reported for each benchmark. When the results report a Timeout, it means that more than 300 seconds were required for a single iteration and was therefore interrupted. Conversely, N/A means that a test that was compatible for the given implementation was not available (2 tests) or the setup on my machine was lacking the required libraries to execute it (1 test).
• I realize that there is a MinGW One-Click Installer effort that may improve the performance of Ruby on Windows. Here however, I used the regular One-Click Installer as it is the most common one (it’s been downloaded almost 3.5 million times so far). For Ruby 1.9 I used the binary provided by the download page on the official Ruby site.

Disclaimer

• An attempt has been made to improve the quality of the tests. Some of them may be more representative of realistic workloads, but most of them remain micro-benchmarks. They are indicative of how IronRuby compares to MRI (Ruby 1.8) and KRI (Ruby 1.9) performance-wise, but cannot be viewed as a guarantee of how this will actually affect your own programs.
• I didn’t calculate a RubySpec completeness score for IronRuby. That said, IronRuby 0.9 should be a fairly complete implementation of Ruby 1.8.
• There are lies, damned lies, and statistics.

Benchmark results

The table below shows the times for each benchmark, for IronRuby 0.9, Ruby 1.8.6 (2008-08-11 patchlevel 287) and Ruby 1.9.1p0 (2009-01-30 revision 21907):

Red values are errors, timeouts, inapplicable tests and times that were worse than Ruby 1.8.6. Green, bold values are better times than what Ruby 1.8.6 delivered. A pale yellow background indicates the best time for a given benchmark. Total time is the runtime for the subset of benchmarks that were successfully executed by all three implementations (whose cardinality is 54).

The total runtime is summarized by the chart below:

And let’s compare each of the “macro-benchmarks” on an individual basis:

Conclusions

IronRuby went from being much slower than Ruby MRI to considerably faster across nearly all the tests. That’s major progress for sure, and the team behind the project deserves mad props for it.

One final warning before we get too excited here. IronRuby is not faster than Ruby 1.9.1 at this stage. Don’t let that first chart mislead you. While it’s faster in certain tests, it’s also slower is many others. Currently, it’s situated between Ruby 1.8.6 and Ruby 1.9.1, but much closer to the latter. The reason why this chart is misleading is that it doesn’t take into account any tests that timed out, and several of such timeouts were caused by IronRuby (more than those caused by Ruby 1.9.1). If you were to add, say, 300 seconds to the total, for each timeout for the two implementations, you’d quickly see that Ruby 1.9.1 still has the edge. The second chart that compares macro-benchmarks does a better job at realistically showing how IronRuby sits between Ruby 1.8.6 and Ruby 1.9.1 from a performance standpoint. If you were to plot every single benchmark on a chart, you’d find a similar outcomes for a large percentage of the tests.

Whether it’s faster than Ruby 1.9 or not, now that good performances are staring to show up, it’s easier to see IronRuby delivering on it’s goal of becoming the main implementation choice for those who both develop and deploy on Windows. This, paired with the .NET and possible Visual Studio integration, the great tools available to .NET developers, and the ability to execute Ruby code in the browser client-side thanks to projects like Silverlight/Moonlight and Gestalt, make the project all the more interesting.

What are your thoughts on IronRuby, and how will this dramatic performance gain affect your projects?

Merb, Rails Myths, Language Popularity and other Zenbits

Zenbits are posts which include a variety of interesting subjects that I’d like to talk about briefly, without writing a post for each of them.

Merb: A few days ago Merb 1.0 was released. Congratulations to Ezra Zygmuntowicz on this important milestone, the Merb community and Engine Yard (who finances the project). Merb 1.0 wasn’t even out yet when some people had already started commenting on the fracturing of the Ruby community that this new framework might bring with this, and the impact that this high visibility “competitor” might have on Rails. I believe that having more than one widely adopted web framework will only benefit the Ruby community. Furthermore, it’s important to remember that this is not a zero-sum game. Ruby programmers are perfectly capable of learning two frameworks and using one or the other, depending on the project at hand. This is particularly true if we consider that Merb, for all of its advantages – and disadvantages – when compared to Rails, is not totally different from its forerunner. If you are an expert Rails programmer, you should be able to become proficient in Merb in very little time. To help with this process, the Merb community needs to concentrate on the documentation now, given that the API is finally stable.

Rails Myths: David Heinemeier Hansson began a series of posts about Rails Myths. I like the idea of seeing common myths addressed straight from the horse’s mouth. Over the past two years, Rails has received quite a bit of backslash and old fashion FUD, so it’s important to set the record straight, whether the myths are entirely fabricated or if there is some element of truth to them. Whether you agree with David or not, it’s also nice to hear two sides of the same story. In fact, at the beginning of my book I debunk a few myths, just to set the record straight regarding what some readers may have heard surrounding the framework. It was a fun part to write.

My Book: Speaking of my book, Ruby on Rails for Microsoft Developers, I’m getting closer to the finish line. I’m about to complete Chapter 9 (out of eleven chapters). The initial schedule I was provided with has been extended slightly so that there will be sufficient time to properly review the content and ensure that it’s up to date with the final release of Rails 2.2. Some people wondered what the “Microsoft Developers” part means. Is it for people that work at Microsoft? Is it for .NET programmers? Is it for people who develop on Windows?

The truth is that “Microsoft Developers” is probably just a marketing term that Wrox selected as a catch-all for of the aforementioned categories of programmers. As an author I’m trying to serve all of them well, by providing a guide that sneaks in much of the Rails culture and softens the migration path by using an Operating System, and to a certain extent, tools that they’re already familiar with. In my opinion one of the major obstacles when switching to, or trying, Rails when coming from the Microsoft world, is the culture shock. The documentation and most books assume that you are familiar with *nix systems and tools, and this can be frustrating for those who are forced not only to learn a new language and framework, but also an entirely new set of tools. As it’s targeted at Microsoft developers, the book obviously makes quite a few references and comparisons to the .NET world, where they fit. This is done so that the many .NET programmers amongst the group of so called “Microsoft Developers” will find the book particularly useful. Yet the book remains generic enough so that it can be used by any programmer (particularly Windows users), even those without any knowledge of the Microsoft .NET Framework or ASP.NET.

Python books: While on the subject of books, I wanted to mention that the final version of the Pylons book is available online. Despite the much less fancy UI, the book pretty much does what the Django Book did in the past. And both are available in print as well (The Definitive Guide to Django: Web Development Done Right and The Definitive Guide to Pylons). Pylons is a Python web framework that can be viewed as a Ruby on Rails clone, in a far greater way than Django could ever be considered.

Another thing I want to mention is that I received a copy of Expert Python Programming. I haven’t gotten to far into it yet, but from what I’ve seen so far, things look good. I hope to be able to read it through, over a weekend in the near future and then provide a proper review. Stay tuned.

Language Popularity: If you take a look at the TIOBE Index, you’ll notice a few interesting things: Ruby has dropped two positions since last year, and it’s now the 11th most popular language in the world. This shouldn’t be cause for concern though, as shown by this Ruby graph. Python on the other hand is increasing in popularity and moved from the 7th to the 6th most popular language. Interestingly, according to the index (the results of which are educated guesses only), Python would seem to be more popular than C#. I find this to be true, in terms of online activity within an increasingly vibrant community, but in my opinion, the job market hasn’t caught up yet. In fact, at least in Toronto, when there’s a Python opening it’s pretty much an event that’s worthy of being discussed on the local Python mailing list. C# openings are much more common. This may be different in Silicon Valley, of course. It would also seem that Delphi has experienced a huge come back, moving from the 11th position last year to the 8th one this time around. It’s hard to imagine that Delphi has had a similar level of adoption as C# and thus has become more popular than Perl, JavaScript and Ruby. Delphi is a great solution for Win32 programming, but I don’t quite believe this overly optimistic outlook. And if this is the case, where are all the Delphi jobs and buzz?

DB2: This interview shows a few good reasons why even smaller and medium sized companies are increasingly adopting DB2. And while the video doesn’t mention it, IBM is coming out with an updated version of DB2 Express-C 9.5. This new version, 9.5.2 or 9.5 FixPack 2, is going to introduce exciting new features, including an engine for full text search.

The Great Ruby Shootout These days you hear a lot of talk about parallel programming. Intel promotes it and despite their bias, it’s plausible that parallel programming will become important as the CPU market heads towards an increasingly larger number of cores, as opposed to focusing on the frequency of said CPUs. In the world of Ruby, this translates into multiprocessing, as opposed to multithreading due to the infamous GIL (Global Interpreter Lock). This means that Ruby will most likely approach the problem similarly to how Python 2.6 did with the multiprocessing module, which is a process-based interface. The obvious exceptions are JRuby and IronRuby, which establish a 1 to 1 relationship between green threads and OS threads.

For the shootout, it would be interesting to see some multithreaded code, so as to get a better sense of how well JRuby and IronRuby compare to MRI and 1.9, when more cores are available. In fact, the long-promised shootout will be performed on a quad-core machine with 8GB of RAM. If Charles Nutter, John Lam, or any of their team members would like to contribute some programs that are able to take advantage of “native” multithreading, I’d be very happy to include them in the Ruby Benchmark Suite, to be used for my shootout.

The repository requires some love and refactoring, since it needs to be split in two types of benchmarks. The simpler one will evaluate the execution time minus the startup time, while the more advanced benchmark will also exclude the time required for parsing and loading modules, classes and methods in the AST. It would also be nice to test each program with variable input sizes and report these results accordingly. Right now I’m very busy with the book, but as I become more available, I’ll start working on this.

Finally, I want to point out a very interesting article about performance and UIs. Slow is indeed a very relative concept, and it’s important to understand how to analyze and respond to the user requirements when it comes to the responsiveness of an application as a user interacts with it.

Hardware: I finally bought a Trackball made by Logitech and the Microsoft Ergonomic Keyboard (Microsoft makes great hardware). I don’t have wrist problems, but I’d like to see how these two affect my extensive computer usage. I plan to report my experience as soon as I’ve had a chance to use these input devices for a while, since I know this is a topic that interests lots programmers (many of whom end up being victims of RSI, and some of the IRS ). I also bought a bad-ass color laser printer which is quite handy when you’re a programmer and you are writing a book. I’ll let you know how it goes. What I didn’t buy, but still think is awesome, is the Flip minoHD. It’s the equivalent of an iPod for the world of camcorders. $235 for a camcorder that’s so perfectly compact, and yet that can record in HD, is a pretty sweet deal. I’m considering it for Christmas, assuming it reaches Canada by then.

The Rise of the Functional Paradigm

In yesterday’s address to the Ruby community, Dave Thomas invited Rubyists to fork Ruby, to freely research and experiment with new and interesting features. If this process is successful, many of these features will inevitably see their way back into Ruby’s core, thus improving the language in leaps and bounds. And I feel he couldn’t have been any more right. In fact, the whole industry is experiencing the trend of incorporating features developed in less common languages, research languages, “toy languages” if you prefer, within mainstream ones.

Experimenting with these alternative languages is important because occasionally they themselves become widely used, and even when they fail to do so, they lend their insight to the world of software development, finding their way into other languages. This approach greatly accelerates the development of common languages for the good of their large user bases and the improvement of the software industry. It’s a win-win situation for everyone involved and for the development community as a whole.

Pay attention to the development community online, and you’ll quickly notice a few non-mainstream programming languages appear over and over again. I’m referring to languages like F#, Erlang, Haskell, Scala and Clojure. I’ll admit to a certain selection bias, given that I tend to hang out in communities where hackers and developers actively pursue the betterment of their programming skills, beyond the stereotypical 9 to 5 requirements. But nevertheless, three or four years ago the average developer probably wouldn’t have heard about any of them (at least the ones that existed at the time). And today all of these languages have active communities, books being published about them, and most programmers have at least encountered some of these names.

They are all different languages, but their common denominator is the functional paradigm. Notice that I titled this post “The Rise of the Functional Paradigm” and not “The Rise of Functional Languages”. In a sense the latter is true as well, since there’s been much more attention towards functional programming languages lately. But there is a subtle difference. I don’t expect purely functional languages to become the most used programming languages anytime soon. For the foreseeable future, I don’t predict US companies to outsource Haskell jobs to India or China, like they do today for Java or .NET projects.

Yet these functional languages serve a higher purpose. Not only do they satisfy the needs of intellectually curious developers and companies looking for a competitive advantage, but they also have a great deal of influence on the rest of the development world.

We are seeing a convergence between these two groups of languages. Functional languages will strive to become as useful as possible, with libraries and tools that are more adequate for mainstream developers, while conserving their functional purity (I’m looking at you almighty Haskell). Meanwhile, mainstream languages will slowly adopt powerful features found in these functional and other research languages, adding further expressiveness and capabilities to their largely adopted foundations. F#, the evolution of C# and the addition of LINQ should be enough evidence that this is the case at least for the .NET platform. And even C++0x and D are leaning towards the incorporation of some functional features (e.g. lambda expressions and closures). The two types of languages come from different directions but will reach a similar destination.

The ever increasingly popular Ruby, Python and JavaScript owe their success to several factors. And while they are considered multi-paradigm and were mostly aided in their popularity by their immediacy, simplicity, usefulness and a set of historical circumstances, they’re all hybrid languages that adopt functional features. The functional paradigm is becoming so common, that it’s hard to imagine seeing any new programming language rise to fame without including at least a subset of the features available in other functional programming languages. As developers, we’ve grown to expect the elegance of functional features in a language. No lambda, no party.

If the 90s were characterized by the rise of the Object Oriented paradigm, and this decade can be considered as a transition phase, then the future belongs to the functional paradigm. Whether developers prefer to mix this with other paradigms (e.g. in languages like Ruby, Python, C#, etc…), like a powerful cocktail, or shoot it straight down (e.g. in purely functional languages like Haskell), the functional paradigm is here to stay.

Take this survey and win a free ticket for the Professional Ruby Conference

Addison Wesley will hold their first Professional Ruby Conference in Boston, Massachusetts between November 17 and 20, 2008. This conference, for which Obie Fernandez is the Technical Chair, is highly educational and boasts some of the best speakers from the Ruby and Rails communities.

The organizers were kind enough to invite me, offering me a complimentary pass for the Professional Ruby Conference. I won’t be able to attend, so I decided to donate my free admission to one lucky reader. They also provided me with a priority code (like a coupon) for my readers, which entitle you to receive a $200 discount off the regular admission price.

I really value your opinions and I’d appreciate it if you could take this survey, so that I can improve the quality of this blog. At the end of the survey you’ll receive your $200 discount code, and will be entered into my draw for your chance to win one free ticket. I will announce and get in touch with the winner early next week (Monday or Tuesday depending on participation levels).

What Arc should learn from Ruby

There was a lot of buzz surrounding Arc before it was released. Then Paul Graham made an early version available to the public and most people weren’t too impressed. Paul is a charismatic figure and has his own following, so despite the uncertain welcome that the language received, Arc managed to attract a small community of curious developers. Then silence. For a few months, most people hardly heard anything about Arc. Until today. A post on news.arc suddenly found its way into the spotlight. In this post, its author tried to summarize the status of the language, its failure to attract new developers or even retain the existing ones, and what is perceived as a lack of leadership for the project and a very uncertain future.

I joked about this and said that “Arc is the infogami of programming languages”. Infogami was a project started by Aaron Swartz, that was claiming it was going to revolutionize the web “like the Macintosh did for computers” (if I recall the quote correctly). Despite the great expectations and the grand announcements that were made, the project (launched by what was a YCombinator startup) never really flew. But I digress; the point is that Arc, like infogami was wrapped in layers of expectations, like a scallop with bacon, but the delivery and the outcome were less than stellar.

Don’t hold this against Paul (or Aaron); projects fail or have rocky starts all the time. It’s the nature of software and of this business. Don’t jump to conclusions too quickly and assume that Arc has failed and is dead, either. Paul seems to have long term plans for the language. Many popular languages today were absolutely obscure to most developers for their first several years. Should Arc become the great language many had hoped for, people will have no qualms in adopting it in 1, 3 or even 5 years time.

I think that Paul is trying to distinguish between what the core features of the language are and its libraries, and his aim and focus is currently directed towards the former; a core that he wishes to change and evolve with a certain degree of freedom. From many of his writings, it is apparent that Paul has set out one clear cut criterium for the features of his language: whatever changes are made, need to make Arc concise. Concise doesn’t mean terse or unreadable, it means powerful and expressive enough to enable the language’s users to write a certain program with much less code than what’s required by other commonly adopted languages, and if possible, even by the most popular dialects of Lisp.

This approach to the design of the core language is far from off course. For example, Ruby’s conciseness is one of its most appreciated characteristics and one of the prominent features that sets it apart from compiled languages like C or Java. But a powerful and well designed programming language is not enough. That’s not really what developers are after.

Programmers are looking for solutions to existing problems and pains. They want tools, and this includes languages, that are good at helping them while they try to implement certain types of software. The languages may be general purpose, but if they don’t represent an advantage over other alternatives in a particular domain, they are hardly used.

In short, libraries and the ecosystem surrounding programming languages are often as important as the languages themselves.

In a somewhat related “ask News.YCombinator” question, Clojure was mentioned as a possible “next big thing” for the Lisp world. As you can imagine, the subject of Arc was brought up and Paul stepped in with a few comments. Two significant ones specifically focused on the subject of libraries, trying to address what is currently perceived as one of Arc’s big weaknesses, whereas it’s a strong point for Clojure, which can rely on all the existing code available for the Java world (since Clojure targets the JVM).

The first of these comments included the following quote:

Powerful libraries are a cheap way to make a new language the language du jour. (Think Rails.) They’re not the critical ingredient if you’re trying to make something to last; they may even hurt. — Paul Graham

And the second one, further explained what his position was:

The dangers of libraries are that they distract one’s attention from the core language, and that they could conceal or perpetuate flaws in the core language. I’m not saying that languages *shouldn’t* have powerful libraries, btw, just that they may not be 100% upside. — Paul Graham

Read that first quote again. I agree with the initial part of it, but find the conclusion is not supported by the facts. Paul himself brought up the example of Ruby and Rails, so let’s explore this further and see what Arc could learn from Ruby’s experience.

Ruby was a very good programming language that for a long time was hardly used outside of Japan. Beside the scarcity of documentation in English, one of the major untold challenges of the language was that it didn’t really solve a particular problem. It was a beautiful general purpose language and that was it. Sure, quite a few smart early adopters realized the potential of the language, and it started to gain some momentum amongst Perl developers, as a possible Perl successor. But let’s face it, for most people Perl was good enough.

Ruby’s core didn’t really change in 2006, when a large majority of the development community acknowledged the merits of the language. Ruby in 2000 and Ruby in 2006 were not really that different. What was drastically different about the two was the ecosystem surrounding Ruby. And the fact that Ruby now offered an incredible solution for those developers who desired to address the problem of web development. Matz was right, Rails is Ruby’s killer application.

But let’s not stop here. Paul agrees that Ruby’s growth rate has been exponentially increased thanks to Rails. So much so that he mentioned it as an emblematic example of a “cheap way” to bring a language to the front of the class. He concludes however, that this is not really the right approach or the critical ingredient needed to create something that lasts. He even goes so far as to say that it may end up hurting the language. And in this, I absolutely disagree.

I disagree because the history of Ruby and that of a few other programming languages shows how the arrival of a community of interested developers has always had many more benefits than drawbacks, provided that a minimal leadership for the projects existed. Taking an accelerated course in Ruby History 101, we’d discover that Ruby already had its own group of fans and a growing English speaking community. Ruby was able to stand on its own merits. What Rails did was inject an incredible amount of attention towards Ruby from developers, companies and the tech oriented media.

What was the effect of all this on Ruby? Countless libraries were written for the language; thousands of companies, particularly startups, adopted Ruby as their language of choice. There was a spur of alternative new Ruby web frameworks (like Merb, Ramaze, etc…) and also a dozen alternative implementations that attempt to improve upon the shortcomings of the language’s main implementation and, in a few occasions, to integrate Ruby with other existing VMs (e.g. with JRuby and IronRuby). There were a grand total of two generally available books on the topic, yet now bookstores are filled with Ruby-specific books, not just ones about Rails (something I predicted to my wife back in 2004). Perhaps more importantly, Ruby is now also widely used outside of the web development world as the truly general purpose language it was intended to be. Every time a DSL is needed, Ruby delivers. There are very popular conferences for the language held throughout the year and companies (e.g. Engine Yard) and VCs are investing money in the future of Ruby. mod_ruby wasn’t working for Rails? Along came Mongrel (and several other alternatives) and now even mod_rails to address the deployment issues.

Paul, I’ll take this flourishing community and ecosystem if its downside is just a sea of newbies asking silly questions in forums. Rails has shown the world what Ruby is capable of, and by doing so, it also presented Ruby’s faults in a clear light. Only this time, there weren’t 100 people ready to jump in and fix it; there were 10,000, several companies and millions of dollars to back it up. To me this is a critical ingredient to make something last.

I understand that Paul isn’t rushing when it comes to Arc, and that he wants to perfect his language before letting a large crowd gather around it, but the risk here is the alienation of early adopters and letting many people who were genuinely interested in the project down. Arc like Ruby did (and unlike Clojure), cannot rely on a wealth of existing code. To ensure its bright future Arc will therefore need to make up for this with, yes, a well designed powerful core, but above all with a growing set of libraries, a growing community and if possible, at least one easily identifiable area where Arc shines in resolving one problem better than other existing languages are capable of doing. Based on the trend of the development world, this killer application will probably come in the form of a Rails or Seaside equivalent for Arc. There isn’t a mad dash, Arc is still very young after all, but it would be a mistake to underestimate the importance of such a critical component for the future and success of this language.

Free version of Ruby in Steel

Later today, SapphireSteel is going to release a free ‘personal’ version of their Ruby in Steel IDE (based on the Visual Studio Shell). This is great news for those of you who are used to Visual Studio and are now switching to Ruby/Rails, or simply for developers who opt to work on Windows (both categories of developers may also be interested in my forthcoming book).

This has not been officially announced, but trust me, the free version should become available later today, so keep an eye on their site. Enjoy!

UPDATE: Direct link to the announcement.

This Week in Ruby (July 26, 2008)

This is the 13th episode of This Week in Ruby, please consider subscribing to my feed so as to not miss any weekly installments. Also, if you enjoy the series and this blog in general, please consider recommending me on Working With Rails.

JRuby 1.1.3 has been released. This version includes several bug fixes and major speed and memory improvements.
Satish Talim of RubyLearning has announced a new course dedicated to the subject, and also interviewed Charles Nutter for the occasion, who provided some suggestions for RubyLearning participants. This week, Satish also interviewed Guy Naor, the CTO of Morph Labs, a prominent cloud computing Rails hosting company.

On the .NET side, things are moving just as quickly. Some great news emerged from OSCON 2008 regarding IronRuby, including the first binary release and the setting up of a project called ironruby-contrib on GitHub. This already includes the Rails plugin for Silverlight. Meanwhile, Peter Cooper published a great set of IronRuby tutorials to bring C# developers into the Ruby fold.

In the alternative framework world, Mack Framework 0.6 was released, which includes DataMapper 0.9.2 and RSpec support, transactional tests, internationalization and other improvements. The roadmap to Merb 1.0 was also posted on the official blog.

I had previously mentioned a few well known issues with Ruby and XML. Well, it appears that there is hope regarding a libxml-ruby resurrection after all. RedCloth 4 was also released this week.

Two interesting articles were: Don’t forget about RubyForge, which covers the issue of mass migration towards GitHub, and Modules underuse by Jay Fields.

Toronto’s sponsor-less conference RubyFringe is over and according to its participants it was fantastic. I truly regret not being able to participate in it. For those who were there, feel free to share your opinions in the comment section.

One last thing before you go; I must give my “caught-red-handed Ruby Community award” this week to Thiyagarajan Veluchamy. This dude thought it was a good idea to lift the entire content of one of my most popular articles from more than a year ago, even hotlinking the image, and then attributing the post to himself. Did he really think that no one would notice? Its link became popular on Del.icio.us for the Rails tag, and I got all sorts of emails from people who recognized my old (and now somewhat outdated) article. After a brief investigation, it turns out that Thiyagarajan has a habit of stealing content. Other articles appear to be copied verbatim from various blogs. Thiyagarajan, a word of advice, gathering inspiration from a certain post is fine, copying it is not. Especially if you try to pull it off by copying from someone who reports on the most interesting and popular posts in the community. That’s just a really dumb move.

To keep the good times rolling, the fourth edition of This Week in Rails is available on the official Rails blog.

Ruby on Rails for Microsoft Developers

Last Friday I sent the first chapter of my book to the Development Editor. It’s only one chapter, which is about 30 pages or so of text and figures. I foresee and fully expect that the real challenges are still to come; yet a great deal of work already went into this first stepping stone and I feel very satisfied by the initial results.

While I briefly mentioned, on Twitter and here, that I was going to write a Rails book, I never provided any details given that the book was still being discussed and the contract had yet to be finalized. Now I can finally provide you with a bit more information. The book will be Ruby on Rails for Microsoft Developers and it will be published in December 2008 by Wrox (in their Professional Series).

I’m always motivated by a sense of purpose, and wouldn’t be able to find it if the book were to be yet another generic Rails one. I’m ecstatic about this project, because I feel that it’s a book that matters. If I do a good job, this title will be more than a Rails guide for .NET programmers, it will be an immersion course into the Rails community and culture for those developers who come from a very different background and have, more often than not, different opinions and viewpoints on development. I’m writing it because I feel it’s a book that needs to be written.

Being a book by Wrox, you’ll also get to see my chubby face on the cover, a very strong argument against the otherwise nice personal touch that Wrox covers convey. Given that self-portraits are discouraged, I’m open to suggestions and recommendations for a good professional portrait photographer in Toronto or the GTA. More than a photographer, I’d need a miracle worker. But oh well, I started a proper diet nevertheless, even if it won’t have done any good by the time my picture is taken in June.

Frivolous matters aside, so far the journey that just began has been great and characterized by the distinctive feeling of working with a team of real professionals who’re eager to help. I’ll keep you posted as I progress through this marathon.

This Week in Ruby (May 12, 2008)

This is the 7th episode of This Week in Ruby, please consider subscribing to my feed so as to not miss any weekly installments.

Ruby

The tickets for RubyKaigi went on sale yesterday. RubyKaigi is the Japanese equivalent of RubyConf and will take place from the 20th to the 22nd of June.

Yehuda Katz blogged about Benchwarmer, which is an improved DSL for doing benchmarks. The repository can be found on GitHub.

That mad man, commonly known as why, has released another interesting proof of concept, aptly named Unholy. It’s a Ruby to PYC converter that aims at compiling Ruby sources to Python bytecode, making it possible to write Ruby code and run it on CPython. Not only that, but with a patched version of decompyle, it’d be possible to obtain Python source code that could be used, for example, on Google App Engine. Don’t expect to run Rails on mod_python anytime soon, though.

The Rails community may favor Macs, but there is no denying that there exist a huge amount of developers using Ruby and Rails on Windows. As a matter of fact, the One-Click Ruby Installer is the most popular project on RubyForge with almost 2.4 Million downloads, and Instant Rails is not doing too bad either, having surpassed the half a million mark. However, there is now another easy way to get the whole stack that’s required to run Rails on Windows (also available for Mac and Linux), and it’s called RubyStack. Unlike InstantRails, this is an actual installer and it includes: Ruby, RubyGems, Rails, MySQL, SQLite, Subversion, ImageMagick, Mongrel, Apache 2.2.8, PHP 5 and phpMyAdmin. The company, BitNami, also recently published a tutorial on how to add Aptana RadRails and Ruby Debug to the stack. If you’ve tried RubyStack, please leave your comments and opinions in the comments section.

Alternative implementations

Adam Fine, of Israel.rb, has a nice Ruby implementation roundup. You can read and comment on it here.

A couple of weeks ago the IronRuby project received a healthy dose of criticism (including my own) within the mailing list. A lack of openness and status updates, made contributions harder and portrayed the project as progressing at a deadly slow pace. I’m glad to report that the team has reacted in a proactive manner and embraced a more open approach where, for example, code reviews are now published in the ML. IronRuby has changed pace, or at least that’s the perception, and in an open source project this is also important. Now I’m confident that we can expect good things from this project. Meanwhile, you can try IronRuby in your browser, courtesy of Oleg Tkachenko.

You may remember, from a few editions ago, that I mentioned Dan Berger and his fork of the MRI, called Sapphire. DevFi has an interview with him in which he expresses quite clearly his intentions and rationale behind the decision to fork Ruby. Better support for Ruby on Windows, attention to correctness and testing, improving the standard library and a faster evolution of the language, seem to be the main reasons.

Sticking with the name Sapphire, Huw Collingbourne has a nice writeup on Multiple Inheritance, modules and mixins. While his language isn’t a fork of Ruby but rather just inspired by it, Ruby developers will find the article interesting as well, because it covers what Huw perceives as being issues when it comes to Ruby’s modules.

In JRuby-land, on the heels of Java One, Nick Sieger has announced JRuby-Rack which can be used to run Rails, Merb, or any Rack-compatible framework inside a Java application server.

Merb

According to this post Merb is running on Rubinius (if we exclude the ORM layer). Both projects are promoted and sponsored by the same company, so it’s natural that we’ll continue to see better integration.

Two new bundles for Merb and DataMapper are finally available for TextMate users. You can download and read about them here.

A post by Michael Klishin created quite a bit of controversy. Entitled State of Merb on road to 1.0: the good, the bad and the ugly, this kind of status update can be very appealing, as we head towards version 1.0 of Merb. Unfortunately “the ugly” in this case is the tone of the post, which made the author appear immature, due to the gratuitous bashing of Rails developers. It is unfortunate that the author of this nice mapping of a Merb server’s boot process, opted to convey his enthusiasm through blind antagonism. Let me reassure you though, that this is not representative of the Merb community as a whole; which is welcoming, definitely enthusiastic, but far from disrespectful of other projects. Merb developers believe in their project and the technical advantages that it offers over Rails, and have no qualms in stating so either. But they do so in a factual manner, as opposed to vague attacks against people who opt for a different framework.

Rails

Through his Twitter account, David announced that “Rails 2.1 RC1 has been tagged and the gems are on the beta servers”. Now is an ideal time to test it out. If you need some help, this screencast should do the trick.

The fourth part of a tutorial on Routing in Rails 2 was recently published. If you haven’t done so, follow the links to part 1, 2, 3 and 4.

Emacs fans may be interested in this screencast, that shows how to use Emacs with Rails. Other interesting highlights this week were: Write your Rails view in… JavaScript?, Community Engine (a Social Networking plugin), the release of El Dorado 0.9.2 (which adds a group chat option) and finally after_create :pimp, which automatically pings Google (and possibly other services) once the contents of your Rails app have been updated.

Rails deployment

Ron Valente has a guide on setting up a Rails server through Ubuntu 8.04 using Passenger. While Jim Neath, published Using Capistrano with Passenger (mod_rails).

For those interested in cloud computing, I found this article on how to create a “poor man’s” Content Delivery Network with NGINX, Varnish, Merb and Amazon S3, to be very compelling.

Meanwhile the VC funding spree of Ruby/Rails hosting companies continues, with a $3 Million round of financing being handed out to Heroku by Redpoint Ventures.

This week, Ezra’s Deploying Rails Applications: A Step-by-Step Guide finally hit the press. I ordered my copy from Amazon and it shipped yesterday. At about the same time, Advanced Rails Recipes: 84 New Ways to Build Stunning Rails Apps was published but, at least in my case, hasn’t shipped yet.

Railscasts 100th Episode Contest

Ryan Bates had a contest for his 100th Episode of Railscasts. Yesterday night he announced the winners. Congratulations to them and to all of those who participated. What’s really interesting though is that now there are several hundred Rails tips out there. You can read (and in some cases watch) all of them by following the links on the contest page.

All this material should be enough to keep you busy until next week. Please feel free to provide comments and feedback on this series.

Ruby.NET is dead

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.

Give Ruby.NET 0.9 some love

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.

Desktop Applications are not dead!

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.

In praise of IronRuby’s Source Code

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.

Is IronRuby mathematically challenged?

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 ) 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.