Tag: dot-net

.NET Compact Framework

Ever since I posted my experiences creating software for the .NET Compact Framework back in 2006, I’ve received a steady trickle of thank-you emails. Apparently there are bits of information in there that are (or at least were, at the time) somewhat hard to find.

Sadly the information there has fallen somewhat out of date due to new CF and VS.NET releases, and I’ve been busy on other platforms and projects (Java and much more) since then. If anyone out there can suggest a handful of the best places to learn now about CF development, please do so in the comments below, for the benefit of others reading this page.

Is Delphi Dead? No.

A few months ago Alex Miller pointed me to this Delphi doom article (the site appears to be down at the moment), which reminded me to post about the same topic. Here goes.

Delphi shipped in 1995, and its demise has been declared frequently since 1997 or so. In a sense this demise is true, yet also false. Delphi’s current popularity is very different in form (not only in magnitude) from that of Java, C#, etc. Delphi is used substantially by commercial software vendors, and only rarely by enterprises. An ugly reality of the software industry is that the bulk of software developers nationwide work inside large non-software companies, so this usage pattern most likely does not produce the level of unit sales that Codegear (Borland’s dev-tools subsidiary) would like to see. It does, however, produce an enormous number of Delphi application instances running “in the field”, used by real paying end users, who don’t care (or know) what development tools were used to build the software they buy. Many commercial software products, both those in shrinkwrap at retail stores and those for vertical markets, are written in Delphi and will continue to be, because there are very few other good choices for high quality (polished) native Win32 GUI software. In these markets, shipping a Java or .NET app can be a competitive disadvantage (though to a lesser extent over time), and old-style VB is a sad joke.

I don’t think Delphi is eligible for demise until the dominant desktop operating system ships with a dominant runtime platform “in the box”. For example, if all of this happens at the same time:

  • Microsoft ships Windows with the .NET runtime already installed
  • That version Windows is the commonly deployed version
  • That version of the .NET runtime is the commonly targeted version

At that time, the .NET platform (with the language of your choice) could be a compelling replacement for Delphi in its niche. There is a lot to like about .NET (and Java, and I use them both), but I’m not holding my breath for the above conjunction.

Over at Oasis Digital we have several ongoing Delphi projects in which we develop and extend in-house, enterprise applications. These projects feel notably lonely (very few developers here in the midwest use Delphi), and the Delphi language leaves a lot to be desired (such as garbage collection) – but the resulting software works very well for our customers, especially when we add in a bit of Lua or Prolog (story coming someday…).

Delphi is not dead. It’s not at the top of the popularity charts, and won’t be. It probably shouldn’t be your first choice for a new in-house enterprise application starting today, because of the network effects of Java and .NET popularity. But Delphi is not going away anytime soon, and is a great choice for certain classes of projects.

Joel, you have got to be kidding

Joel seems to “play it safe” … then goes off the deep end of irony in his final paragraph:

“FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.”

Fortunately DHH saved me some minutes of typing about it, with a scathing commentary.

Over at Oasis Digital we use both common tools (.NET, Java, PHP, C, Delphi, etc.) and more unusual ones (Lua, Prolog, Ruby, sorry no Lisp yet), so I believe that puts us in the DHH and Paul Graham camp: If you want to win, you must be willing to do something different from the pack… such as, in an extreme case, creating your own language optimized for the task at hand, whether in the form of Lisp macros or a C# compiler for Wasabi.

Hints at Win32 Deprecation

I just read today (wow, where have I been?) about the issue with Win32 binaries under the (delayed) Vista version of Windows – most notably, that Win32 binaries will need to be signed, otherwise they will provide a, er, “downlevel” user experience. A proposed workaround is to code to another runtime environment (.NET, Java, Ruby, you name it) so that getting the actual Win32 binary signed is someone else’s problem.

This reminded me of comments I made a few years ago, closer to the dawn of .NET: that if .NET works out well, native binaries will end up deprecated, supported for a long time but in the same way that we can still run an ancient DOS “.com” binary on Windows XP… i.e. not really as first-class citizens. At the time I got rather negative feedback to such a comment, but now the Vista feature above seems like the first step in that direction.

Update: As far as I know, this feature did not make it in to Vista – unsigned EXEs are still OK.

.NET Traction at Microsoft?

According to this article from Richard Grimes, it appears that .NET has not gained as much traction inside Microsoft as anticipated:
http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

“My conclusion is that Microsoft has lost its confidence in .NET. They implement very little of their own code using .NET. The framework is provided as part of the operating system, but this is so that code written by third party developers can run on Vista without the large download of the framework. Supplying the .NET runtime for third party developers in this way is similar to Microsoft supplying msvbvm60.dll as part of XP.”

I think his conclusion is a bit overreaching, but this isn’t a big deal to me either way, and I’m neither a raving Microsoft fan nor a rabid Microsoft detractor.

However, this is good news in at least one important way:

To the extent Windows itself is not built on .NET, that in a sense leaves more room for other, non-.NET runtime environments to flourish as first class citizens, leaving more room for Java (we ship a commercial Java application, so that’s good…) and also for other currently and upcoming dynamic language runtime environments.