What did Kylix do wrong?

Question

With all the talk about the Delphi team working on cross-platform development, one sentiment that keeps coming up is, "I hope they do it right this time, not like Kylix." I didn't really notice Kylix when it was around, because Linux wasn't nearly as mature back then as it is now and it just wasn't an OS I had any interest in. So now that it's starting to become an issue again, I find myself wondering, what did Kylix do wrong and how could CodeGear do it better this time around?

Answer 1

Kylix had two things working against it: widespread acceptance of Linux on the desktop just wasn't there yet, and Kylix itself was very expensive. Throw in Kylix's questionable quality (especially the first version) and you have your answer.

If CodeGear wants to do another version of Delphi on Linux, they should just look at Lazarus.

Answer 2

Trying to charge 600 bucks for people used to getting tools and software for free might not have been a wise decision!

Answer 3

They also had a lot of trouble creating reliable deploy on so many different distro varieties.

Answer 4

I bought Kylix when it first came out - it ran very slowly, looked clunky and actually only supported a few specific versions of Linux. Frankly, there were and are better Linux tools out there. But I think it is getting increasingly hard for anyone to make money selling development tools, whatever the platform - the free alternatives are just so good.

Answer 5

As for what could CodeGear do better this time around:

• There needs to be a more abstract way of laying out controls in dialogs, not the pixel-based stuff the VCL uses now. This breaks down on Windows already with high DPI settings or non-standard fonts, it will be much worse for multi-platform programs. Take for example the sizer classes in wxWidgets, or the layout classes / managers in GTK, Java or QT - they all do much better with changing fonts or control sizes. As another advantage this works transparently with translated texts in controls being shorter or longer.

• Make the libraries Unicode only. Ideally there would be a special string class, using UCS-16 internally on Windows, but UTF-8 for Linux and Mac OS X. A program should be able to work with the platform-native Unicode encoding, not be forced to have conversions for every file system access or screen output. But maybe they already dropped the ball on that one with the Unicode string changes for Delphi 2009.

• The GUI should use native controls on all platforms, for proper look and feel. That would be the standard controls on Windows, Cocoa on the Mac, and on Linux it should ideally use either GTK or QT, depending on the desktop being GNOME or KDE.

• The remote debugger needs to become a first-class tool, not the bug-ridden and half-hidden thing it is now. Development for different platforms happens often in VMs, sometimes there is only remote access to machines.

Answer 6

I worked on the Free Pascal Unix RTL at the time (and still), which did Pascal on *nix before Kylix, and we watched it closely from the fist beta's on. So one could say I had a good and unique perspective on the rise and fall of Kylix.

A main problem is that it wasn't geared towards server apps use, the main thing people were doing on Linux at the time, but IMHO that doesn't explain the failure.

While there were various other problems (Wine, deployment, being very Linux/x86-centric so harder to port to the "next" *nix, Borland not pushing it enough), I still think the fact that Kylix failed is more a testament to Linux' woes at the time than a direct result from Kylix problems. Some of which (like long term binary API stability) haven't been fixed still.

Still, it should have worked IMHO, since it was clearly ahead of the rest, and workable, and if the demand had really been there, people would have stepped up (and some have, we still get monthly people on the FPC lists that are converting large Kylix codebases).

A server oriented version might have been a bigger hit, and they marketed a bit too strongly on the single source thing (which raised expectations wrongly), but still the GUI principle as it is should have worked IMHO, and I blame Linux and the Linux market. Too soon, market too hyped, and not ready for commercialization after a Windows model yet.

Answer 7

What I hated about Kylix and VCL for Web (Intraweb) is that they have components that look like the standard components....

The VCL is itself quite generic (Except for the handles)... So I would want to have the same source code, same pas, dfm, dpr .... and by selecting a compiler option choose which platform to build for, or even have different dprs for each platform with the same source files.

Answer 8

In my opinion to go cross-platform native & hosted (VM) would be good for Delphi; however there is the catch that it needs to be well thought-out before implementation. (Generally the Turbo Pascal versions were, IMO... though some of the additions to the Delphi language were not; case-in-point you cannot declare properties in interfaces to be read and/or write only w/o declaring also WHAT the property's source was, either a field or method that had to be declared in the interface. IE it was/is a good idea... but they forgot to fully separate interface/implementation.)

So, IMO, what is needed is:

1 - A VCL-/TurboVision-/GeneralPurpose-like library, designed to be platform independent. ( The VCL really is a good example for object-oriented hierarchies; as was turbo-vision [for its time]... also TV introduced and used streams rather interestingly. ) So, to reiterate:

a) A good object-oriented hierarchy of visible components... perhaps also embracing a more "percent"/relative/vector-graphic scheme than the current pixel one. (Thereby compensating for screen-resolution disparities.)

b) Objects that "know" how to initialize and free their contained objects (though pointers to objects would be exempted, as we would like to have the ability to "share" objects), so the setting up of constructors to initialize and destructors to free the contained objects are not needed. {IE, Optimize the common case.}

c) The non-visual components like TList, TStringList and so forth should be implemented... though with the addition of ADTs such as Stack, Queue, PriorityQueue, Heap, Tree & BTree. As a personal request though, can we make them 1-based rather than 0-based? I ask this because when searching through them it would be nicer to have 0 be "not found" and a positive number be the index all while using unsigned numbers, much the style of ShortStrings. This also has the advantage of not chopping in half the maximum allowable size-constraint as using signed numbers would.

d) Objects should be able, at the lowest possible level, to send and send/delete themselves into a stream for reconstruction on the other end. {Difficult to implement, perhaps; but the TurboVision API did it with its registration scheme... with RTTI involved it should be a bit easier.}

e) The aforementioned ADTs should also have a mirroring generic interface heirchy, such that something like TStringList gives you a list of strings whose matching objects property are objects of the TIntergerObject type.

f) Container types, like the stack or StringList should also know their contained type; and whether they are homogeneous or not.

g) A parser-object subtree on the non-visual object-tree that is inheritable and generalized (perhaps one that "eats" BNF and parses input accordingly... a HUGE project in itself.

I know that this is a tall order, and a LOT of work. However the payoff would be immense as well. A JVM could be a Stack object and a parser object that translates the source-code to the appropriate objects to be pushed onto the stack... A Forth compiler/interpreter could be implemented in the same way with several stacks and a Forth parser object. You obviously see where this is leading: having a versatile and generalized ADT library at the base and working building the framework on that the next iteration of RAD studio could in one fell swoop become not only a competitor with .NET for its "any language" idea, but also for multiple archetectures on the backend. (Yes, there is the sizing and endian issue, but the idea of high-level languages is to remove the programmer from those issues, unless he is particularly focusing on them; those issues could be well resolved by keeping the Delphi's Byte, Integer, LongInt sizes stable, as it currently is [perhaps using NativeInteger, NativeLongInteger and so forth when the machine-dependent type/sizes are needed] and by letting the TStream-descendant objects for files handle storing and retrieving Delphi-/RAD-native app data and deriving from those when particular endian is needed for the format.)