Friday, March 23, 2012

The VB Model versus the Delphi Model

As an older school client/server developer, I've used by VB and Delphi for a few projects in the past. Having seen both tools, they have a difference of approach that I think is significant. The VB model is "90% of what you want to do is easy and the remaining 10% is impossible" whereas the Delphi model is "80% of what you want to do is easy and the remaining 20% is more difficult".

In the VB model, because it was such a closed ecosystem, when I couldn't do something, I'd have to go buy components from a third party or write a C library. There were multiple times when using VB I needed to write a special component in C or Delphi because VB just couldn't handle it. In addition, I was often forced to purchase third party components because nothing was available in the open source space.

In the Delphi model, with it's richer open source ecosystem, when I couldn't do something, I'd first look and see if there was an open source component that did what I wanted. At first this was relatively rare, but as time progressed it got to the point where 90% of the time, someone had already written what I needed. The additional 10% I had the option of either #1 writing it myself or #2 purchasing it.

In short, VB was easier to market because it "did more out of the box" and people making tool decisions would tend to think this was the best choice. After using it for a while and getting "locked in" to multiple proprietary third party components, it would often be obvious (to me) that Delphi would have been a better choice, but difficult to justify without stepping away from the problem. This is something to consider when buying things from companies and tools that are very proprietary. The hidden cost of making up for missing capabilities can often vastly outweigh the "safety" of choosing a tool that does more of what you want "out of the box".


client server architecture said...

This is really interesting post. Currently I work for Dell and think a client server architecture is a network architecture in which each computer or process on the network is either a client or a server. Servers are powerful computers or processes dedicated to managing disk drives (file servers), printers (print servers), or network traffic (network servers ). Clients are PCs or workstations on which users run applications.

Jeff said...

Interesting. With many of our clients currently considering whether to start new web applications in .NET (C#, of course) or an open-source language and framework like Ruby on Rails, this question is as relevant now (or perhaps more so) than it was then.

The key difference now is that choosing a "proprietary" vendor-provided solution like .NET no longer means locking yourself away from open source extensions to the ecosystem. NHibernate and Spring.NET have been around for years, and Microsoft has recently open-sourced its entire web application framework (including new features like MVC).

On the flip side, if you start a Rails app and decide to use a particular gem or set of gems (Devise, CanCan, ActiveAdmin, CMS's like Refinery, etc.), you begin to trade out-of-the-gate features and productivity for down-the-road flexibility, as you are necessarily "locking yourself into" these gems by coding to their APIs.

As is so often the case, it's not black and white - it's as many shades of gray as you can produce with a 64-bit graphics card. Which is not all bad - it's part of the reason there's a market for smart guys like us. :)