Delphi user and Kylix enthusiast Simon Kissel (Kissel is the author of CrossKylix) has written a sharp critique of Borland’s developer tool strategy.
He says few are buying Borland’s .NET tools. They buy Delphi for its native code compiler, and need new features like Unicode and Win64 support. Borland (or DevCo) by contrast is focusing on .NET, but is failing because it cannot keep pace with Microsoft.
I am about 75% in agreement with Kissel. In addition, the splitting of DevCo from Borland, presuming it eventually completes, changes the dynamics in favour of native code. If you put ALM (Application Lifecycle Management) at the centre of your strategy, that pushes you towards .NET, which is great for Enterprise development. If you split off the pure development tools from the ALM side, that gives more voice to the non-Enterprise developers, where .NET has less appeal.
However, a key issue not covered by Kissel is that Win32 development is in decline. That decline will accelerate once Vista and .NET Framework 3.0 become widely deployed (admittedly that will take a couple of years at least). Another factor is the continuing growth in web applications and rich internet (or “smart client”) applications, for which Win32 is ill-suited. It would be tough for Borland to bet its future on a declining market.
Further, Kissel makes too much of how “The other big market player in native RAD Land, Microsoft, has just left the fields.” That’s true only up to a point. Microsoft has abandoned native code VB, but then again VB was never close to Delphi as a native RAD development tool; it did eventually get a native code compiler but always had big runtime dependencies and difficulty in making full use of the Windows API. In addition, Microsoft still has Visual FoxPro (more RAD than native) and Visual C++ (more native than RAD), so it hasn’t altogether abandoned the field.
What’s clear though is that Borland can’t continue with a .NET strategy based on supporting .NET features a year later than Microsoft. And it has to make more of its native code tools – though it actually took a big step in that direction with Delphi 2006, which is excellent for Win32 work.
I feel a little bad here. I said some years ago that Borland should embrace .NET. Still, I did also say this:
However, and it is a big hesitation, to prosper with .Net Borland needs to do more than simply build a Delphi for .Net at its own rather leisurely pace. To succeed the company needs to capture and pursue a vision of what .Net can do; RAD for the Enterprise, .Net beyond Windows; or whatever.
At the time I was hoping Borland would get 100% behind Mono and come up with elegant cross-platform .NET tools. That has never happened; though perhaps it still could.
“To succeed the company needs to capture and pursue a vision of what .Net can do; RAD for the Enterprise, .Net beyond Windows; or whatever.”
That’s only a dream. With .NET, MS has put the lock on development. Noone can introduce new language features and so on. The CLR is the common denominator, and it’s in MS hands (ECMA is just a facade, noone would go against MS). The framework is the library. There are far less degrees of freedom than under Win32. All you can pursue is a sideline library like ECO or the like. You can’t purse any vision under .NET, you can only follow MS dictatorship and try to adapt. It was one of the .NET goals.
“At the time I was hoping Borland would get 100% behind Mono and come up with elegant cross-platform .NET tools. That has never happened; though perhaps it still could.”
Why? Just to help MS to spread .NET around and crush them completely? MS will won, not DevCo. Mono *is not* .NET and its implementation will always lag behind .NET like BDS lags. Why should I use such a crappy tool? I’d use Java that at least is available on several platforms as standard releases, and with the same development tools on several of them.
Do you really believe there is no space for native development? How many .NET applications are shipped with Vista? AFAIK, most .NET development is asp.net.
“Another factor is the continuing growth in web applications and rich internet (or “smart client”) applications, for which Win32 is ill-suited.”
Web applications are ill-suited for any task beyond basic ones. “Rich internet” just mean “more people become rich selling crappy applications”. I’ve seen SAP trying to build a client in Flash…
They are just trying to inflate too much air in the ball… let’s see when it blows out.
> Do you really believe there is no space for native development?
Not at all. I think it is a large space, but declining.
> How many .NET applications are shipped with Vista?
Not many. But not many of us are shipping an OS, so it does not prove much. A more interesting thing to look at is what proportion of enterprise apps are in win32 vs .NET or Java or something else, and what the trends are.
Tim
>Not many. But not many of us are shipping an OS, so it does not prove much.
If MS doesn’t mind to write Vista utilities – not the OS – in .NET should I? Is IE7 written in .NET? Is new MS Mail written in .NET? If not, why?
> A more interesting thing to look at is what proportion of enterprise apps
> are in win32 vs .NET or Java or something else, and what the trends are.
“Enterprise apps” is a too wide category. Ranging from the little intranet website to large distributed systems. You can find everything within (C/C++, ADA, COBOL, Java, .NET, PHP, Python, Ruby and Delphi). And most of them don’t run on Windows. And anyway, a lot of them are native applications written in C/C++, especially the heavier ones. If you want Delphi to be just a db frontend/web app tool it’s up to you, but Delphi is (was?) far more powerful. That’s why we choosen it. If it changes, well, no longer what we need.
> If MS doesn’t mind to write Vista utilities – not the OS – in .NET should I?
It is not a question of “should”. You can choose. But .NET is a best-fit for enterprise apps, web apps, and applications where productivity is more important than runtime efficiency. That’s a poor fit for an OS but a good fit for many other scenarios.
Vista’s Media Center is a .NET application, by the way.
Tim
Well, Microsoft controls its CLR implementation, but that does not mean that they control every CLR implementation.
Plenty of people have used Mono and its components for research and development. There are 3 or 4 languages based on Mono’s C# compiler that are derivatives to explore new ideas (it is a lot simpler to prototype ideas with Mono C# compiler as its written in C# instead of C++).
But prototyping does not have to finish there, if there are valuable additions that should be put on the CLR, they can be tried out in Mono (or Rotor) and the useful ideas brought forward to the ECMA committee (ECMA standardizes *existing* practice, which means that at least one prototype should exist).
There are thousands of ideas that people have played with, including native compilation (mkbundle + aot), becoming an object hub for other things other than COM (XPCOM, Uno, Corba integration), support for scripting languags (tagged types, continuations) or support for other inheritance systems (multiple inheritance for example).
Then the issue is whether the idea makes actual sense in the core or not. For example, multiple inheritance has been implemented with some very clever tricks by Eiffel on top of the existing object model, and considering the deployment times, it might not make sense.
Continuations have been explored outside the realm of changes to the CLR by using code instrumentation tools (See the SecondLife presentation at LangNet2006).
Miguel
Thanks Miguel.
> Microsoft controls its CLR implementation, but that does not mean that
> they control every CLR implementation.
an important distinction
Tim
“Well, Microsoft controls its CLR implementation, but that does not mean that they control every CLR implementation.”
Do you believe any CLR implementation not made by MS has any chance of success, beyond – as a matter of fact – prototypes? Be prosaic. .NET is a proprietary MS platform. MS.NET comes with Windows. MS.NET is backed up by a large company, not a bunch of hackers. ECMA is just a facade to try to avoid new antitrust actions. But they know that no one is large enough to get in the way.
> Do you believe any CLR implementation not made by MS has any chance of
> success, beyond – as a matter of fact – prototypes?
Mono is not just prototypes. I suggest you research some of what is happening with Mono right now.
Tim
I always wonder about the win32-in-decline statements. They somehow seem to assume that the decline will continue to zero.
It won’t, just like the growth of Java didn’t kill native development.
Most of the .NETies are not going to .NET for application development, but simply because ASP.NET is a good and cheap webdevelopment method.
Nearly all .NET development that I see, Microsoft OR Delphi based, is ASP.NET.
It’s not C# or .NET that has the pull, but ASP.NET, but that will only appear to the webdevelopers faction
I can’t imagine why. Win32 development will continue for the forseeable future. That doesn’t mean it won’t decline though.
There is a ton of .NET development in the Enterprise. Just check the job ads.
Tim
“Mono is not just prototypes. I suggest you research some of what is happening with Mono right now”
What’s happening? Mono lags behing .NET just like Delphi does. They have to rewrite any bit of code, meaning that you can’t be sure it works *exactly* like the MS ones, extensive tests are required. And noone would be fool enough to run Mono under Windows.
Mono exists only because MS needs to avoid antitrust issues. Under any operating system, Java is a far better VM for cross-platform development, if you need it. At least it’s the same standard Java on any platform.
“There is a ton of .NET development in the Enterprise. Just check the job ads”
As there are tons of Java ads. Java has been around for ten years, and it didn’t killed native apps as many ten years ago were saying. Actually, the most successful Java app is a Java IDE…
I tend to agree with Kissel that getting win32 up to date is more important than chasing the rapidly changing .NET environment. Win64, Linux and unicode support would possibly open up more markets to Delphi than following behind Microsoft’s toolset.
I am a small developer working in the areas where win32 shines: soft real-time machine vision and robotics applications. I wouldn’t even try doing these in .NET because CLR is way too slow and automatic memory management can cause problems with the program flow. Sure, there are third party libraries for vision processing and I use one, but they only do some of the work necessary. I still need to code some custom processing to put it all together. The closest I need to get to the Enterprise is needing support to pump some data into an SQL database and I really don’t need to do that from the vision application as I write the data in binary files and use an offline application to read it and pump it into SQL. Currently I use VBA in an Excel spreadsheet linked through ODBC to generate reports and I really don’t have much need for anything more fancy.
Other applications that don’t run well under .NET include any process intensive program such as the physics calculations for game play. Three companies exist here in Eugene, Oregon that create game SDKs and they all target C++ for game creation. I’m sure MS has some plan for people to write games in .NET, but I doubt they will be used for anything serious. Game creators may not trust MS to define their ability to create games by forcing them to use a certain API other than the basic things that are needed to speed up the interface such as DirectX. Doing games in .NET would require a large addition of physics and graphics APIs and would need to be outside of CLR to be efficient.
I always wondered why Borland was so quick to drop Linux/Kylix and go with .NET. Remember many years ago when MS got all other compiler vendors to switch to MFC and Borland refused and stuck with OWL. Borland came through but almost all the others are gone. Now here’s a paranoid thought: several years ago Borland licensed .NET though a cross licensing deal with MS. Around the same time they dropped support for Kylix. Ever wonder if the licensing deal had anything to do with this? I have! MS killed the other C++ vendors with MFC and they may be doing the same to Borland with .NET. MS also killed OS/2 and is keeping Linux off of new PCs with exclusive licensing deals. I seriously believe that in order to license .NET that Borland had to agree to some special terms, but we will never know about it unless MS gets into trouble and some document leaks out of a court case. Just a paranoid thought at this point, but given past history it might just explain why Borland is going down the .NET road so fast.
I didn’t get the impression that Simon is suggesting that Borland shouldn’t develop .NET tools. It seems to me that he’s suggesting that the development of DELPHI should be focused more on native applications. If Delphi is part of a larger toolbox that also includes .NET development then that’s great.
My primary development tool is – and probably will be for some time – Delphi 7 Enterprise. I invested in the upgrade to Delphi 2006 and was largely very unhappy with the product.
Microsoft’s Visual C++ is also on my shelf, and while I’m already familiar with C++ for Borland C++ on DOS based systems the Visual C++ IDE was absolutely terrible. I much prefer the Delphi IDE so it was very upsetting when Borland cloned the MS IDE.
Maybe I’m just being picky, and maybe I’ll eventually get over it and see that Delphi 2006 is ok, but without having any pressing need to upgrade I just don’t feel compelled to completely relearn a new development environment.