Kylix in Limbo
IgD writes "Kylix, Borland's Linux port of their popular Delphi compiler has been covered on Slashdot before. LinuxWorld is reporting that Kylix development is in limbo. Many speculate this is a politically correct way of saying the project has been abandoned. There hasn't been any updates to Kylix 3.0 in well over a year. One user who attended BorCon this year wrote in his blog that Borland didn't have any updates to Kylix planned for 2004. This is really disheartening news. Why didn't Kylix sell? Does this say something about the application or about the difficulties of marketing a commercial Linux application?"
Maybe it had something to do with the 1000+ price you had to pay for the full developer version? You think?
... hello to increasing "Shareholder Value".
Oh yes, Borland has come a long way since Phillipe's idea of a full blown compiler as good (if not better) than anything on the market for 99 bucks. Gone are the days of Turbo Pascal and Turbo C
And Helloooo to you too linux you cutie...you're looking better by the minute!
----- In Your Cubicle No One Can Hear You Scream...
The problem with Kylix was it's price. Borland was charing a ridiculous price for a product that albeit good wasn't worth the price. It's also hard to convince your boss (atleast in my situation) that Linux was free and came with C/C++ compilers but I had to pay for Kylix.
If they had a reasonable price perhaps it wouldn't flown but lets be realistic, it's not going to get a lot of support without having a cheap price or an open source version available.
Kylix didn't sell because it was a pile of crap. I used to do a lot of stuff with Delphi (paid lots of money to Borland too), but when I ditched Windows I felt no incentive to carry on with Kylix. I tried the Open Edition, and it wasn't a patch on Delphi. Klunky, buggy, lousy unportable code. Not worth it.
On Linux, there is a cornucopia of free programming languages and tool boxes ready to use. Why then should I use a commercial closed implementation of a proprietary non-standard language with non-standard libraries, not portable beyond merely Linux and Windows, and then only some versions of those?
I don't mind spending big bucks on good tools. After all, it is magnitudes more expensive to familairize oneself with new tools than actually buying them. But I do mind when my favourite tools suddenly become deprecated at the mere whim of a corporate - and Borland has a poor track record here.
Thus, no matter how good the performance of Kylix, and no matter how excellent and slick the IDE and libraries, I would not touch it with a ten foot pole unless I have some guarantee that I will be able to access the full source when I really need to.
Most people knowledgeable enough to develop on Linux have been burnt in the past by proprietary tools, have learnt expensive and painful lessons that way. Never more! Our freedom is too precious to sell out ever again.
It is called ease of use, also known as a RAD development. Fact is, using delphi you can get a program done in roughly half the time, complete with a gui ui. That is why Delphi/Kylix is importaint. That is why C# exists (and looks like delphi).
Bad User. No biscuit!
I bought Kylix 3.0, and my biggest complaint with it is that it feels like a Windows program forced to run on Linux. Not just the IDE (which uses WINE to run), but the language implementation itself.
:-)
It feels like the developers have hardly used it itself, and I guess that's why it just isn't as much of a pleasure to use as (say) Turbo Pascal was.
I love having a decent pascal compiler for Linux, and I like the fact that I can recompile my code on Windows, but I keep bumping into things that just shouldn't be the way they are.
For example: I have triggered segfaults when exceeding boundaries on arrays. Excuse me? I'm using a typesafe language with bounds checking specifically enabled. I expect the program to halt on the line of code that is attempting to access an out of bounds address BEFORE said access happens. I expect all variables to be current and correct. I expect to be able to see exactly what went wrong exactly as it happened. That's one of the reasons to use pascal. I'm paying 5% overhead for that luxury, now hand it over!
The other reason to use pascal is the fast compile times, which is great.
I'm happy to have a pascal compiler with a nice IDE and neat rapid application development stuff for applications, and I use it by preference. It just feels unpolished and rough.
Oh, yeah, shipping apps sucks too - they require you to make wrappers and point LD_* things to shared libraries that you have to identify yourself. VERY MESSY and STUPID. Let me make static apps if I have to, but I get pissed off when the recommended solution for messiness is to wrap every executable I make in a script. Yuk. Not likely.
*sigh* So I guess Love/Hate it is.
Love pascal. Loved Turbo Pascal. Like Kylix. Hate icky stupid bits in Kylix.
Kylix devs should be forced to eat their dogfood. When they release a fully functional IDE written in Kylix, I will be willing to believe they have actually used it. Until then, I'll use it anyway, and occasionally rant in public.
---
Once Visual Basic came along, it really stole a lot of their thunder in terms of making it easy to write windows programs.
Actually, Visual Basic came out before Delphi did. Delphi was designed later and was for many years a better product than VB, but:
- It was based on Pascal, not C, so lots of people thought it was a toy.
- It wasn't standard Pascal, so Pascal bigots didn't like it either.
- It wasn't a Microsoft product, so people didn't think it would stay around a long time.
There were lots of other problems too: Borland financial mismanagement, MS hiring away designers, etc., but I think "Not C" and "Not Microsoft" were the big ones.
No, maybe it's a sign when you take a Windows program and make a half-assed attempt to 'port' it using Wine, it doesn't work right, you slap broken registration code on top of that, and the bosses shout "SHIP!", hopefully over the objections of the engineers.
The failure of Kylix is just another example of the free market working, and in this case the value of Kylix to the consumer is less than zero. That's right, Borland would have to pay me quite a bit to 'switch' to Kylix for anything. And it still might not be enough, if it kept crashing unexpectedly.
But hey, YMMV; that was just my experience with it. And note that I managed to restrain myself to the point that phrases like 'flaming piece of festering monkey shit' never escaped my lips!
pb Reply or e-mail; don't vaguely moderate.
Yup, the problem is squarely with Delphi.
.NET. It makes you wonder if Borland is migrating from a tools vendor to simply an IDE vendor.
You've never used Kylix, have you?
I haven't had a chance to look at QT Designer or Anjuta, but KDevelop isn't a true visual (RAD) environment. Maybe I'm just spoiled, but I like being able to click on a component and drop it on my form. I'm not aware of any IDE on Linux that is as easy to use as Kylix.
Also, Kylix v3 supports both Object Pascal and C++. It is the Linux equivalents of Delphi and C++Builder.
For a shareware developer, just about any compiler is too expensive. Shareware development has odds slightly greater than the lottery. For commercial use the price is trivial. I wouldn't even mess with the Pro version, I could justify the cost of the Enterprise version in about 2 months.
It's not that Kylix was too late, it's still too early. Linux still doesn't have enough desktop penetration to support it.
But personally I wonder if Borland is having some kind of identity crisis. They have just about dropped all future Win32 support. C++Builder has been removed from their product list, C++BuilderX is the replacement. But 512meg of RAM to run your compiler??? Kylix is on life support. And even Delphi for Win32 is in doubt. Their new tools all seem to be an IDE slapped on top of Microsoft's
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
You are off the mark my dear.
Linux users may be averse to paying software.
Companies designing products for linux or under linux are not. There it is a bang for the buck. They will pay without a second thought if the product will save the same amount of money in in-house time and/or development.
Kylix in essence is a corporate product. So there is no aversion in question.
I think that the problem with Kylix is:
1. It was both early and late. Too late for the entusiasts and too early for the companies. Companies are just starting to be interested in Linux as a client and starting to look for RAD. Till now they though of it as only a server.
2. There is a considerable dislike towards borland in the professional development community. The general consensus is that their products are not up to the mark. As a result it is usually not even shortlisted (at least this was the case where I work).
Overall, if they want to ever sell in this market they have to continue keeping the barrier to entusiasts low or near zero and continue trying to sell. They are handicapped by selling against a negative opinion, but it is their fault at the end of the day so it is up to them to deal with it.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
This basicly means, you don't want to pay as long as you get the "service" from the company. That means, as long as you can USE the tool ... as long as it helps you to make profit, or have fun... you dont want to pay?
But when the product is discontinued or orphaned, you suddenly want to pay for the service? For one fixing or keeping it running? Strange.
You're missing the whole point. He's not talking about cost or money. What he's saying is that OSS products will never be orphaned as long as they have users. A proprietary product is viable only as long as the product's marketing team decides it is. I have developed in Delphi for years, and I tried Kylix 1.0 when it came out, but for professional development C++/Qt or C/Gnome are a safer choice, since there is no private product to cancel. Those who chose to go with Kylix are now stuck with orphaned code.
This whole notion of being able to orphan a product is similar to how vendor lockin is achieved... "If you can destroy a thing, you can control a thing."