Borland/Codegear Doesn't Plan to Revive Kylix
An anonymous reader writes "Borland's tools spinoff, CodeGear, is laying plans to revive the classic developer products — but Kylix is staying dead, the CEO says. "I hear lots of discussions about Kylix, but I didn't see lots of revenue in my reports about Kylix," he told CRN."
The Linux crowd has a natural dislike for products that don't work well and cost money. We've little issues with paying money for things that work right. Kylix was a feeble attempt on Borland's part, done far, far too late to make any difference in things.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
For those of us who haven't used Kylix before, what IS Kylix?
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
At the time of the release it was not like there was much potential of a big revenue stream from the nix crowd to begin with. Who was the target audience? Lone developers that would have used it to build "free" apps. couldn't afford it, and corporate dev. shops that were using nix were only using it on the back end. So at best you are building middle tier or web services, both of which were already well supported by other languages/platforms for nix.
.NET train because that was where the money "is/was" but now instead of innovating, they play catch up for the privilege of being dependent on someone else's technology.
There were functional problems as well. Making Delphi/CBuilder developers not use the controls and code base for win32 but requiring the use of CLX and custom libs for Kylix portability. An unstable initial IDE release. To name a few. Developers that work in Delphi or CBuilder all the time think in those languages, and know all the details (hidden features/bugs) of the controls they use. The compiler/linker should have taken care of the different platforms. Like compiler options that determine if you are compiling against win32 or nix. Making the developers try and remember all the differences is the same as making them learn a new language. Thats just dumb, and if there is one thing developers tend not to be it's dumb.
Now if you come forward to today where Desktop nix is starting to make headway. What would be really interesting is if there were a stable version of Kylix that let you use your Delphi or CBuilder code, (not CLX and custom libraries for nix.) and the compiler/linker took care of the platform specifics. Price it around the same as the Turbos. You have a good viable product. ["Of course if wishes were horses we would all be eating steak"]
I don't think Borland/CodeGear has the courage to do this. Because while the website says "Where developers matter" what it really means is "Where developers pocketbooks matter". Just look at the sad state of the BDS products. Borland hopped on the
I could rail all day on mistakes Borland made, but as they say hindsight is 20/20. Let's not focus on the past but look forward to the future and all the mistakes they have yet to make.
I stick to Delphi 5, too. It isn't dead. I was pleased to find that it runs great in Wine, so I can even dump Windows and still support legacy stuff. By Delphi 5, Delphi did everything you could want the product to do - I never saw any reason to upgrade. Most of the later versions were just "enterprise" stuff that didn't have new features to make desktop apps. Delphi may have been a victim of its own success, because version 5 was a natural place to say "this is the stable version we're developing apps on!" and not upgrade.
I'm surprised nobody has bothered to use wxWidgets to clone Delphi.
Check out Lazarus. Not exactly a "clone", but very close and much more cross platform.I am not your blowing wind, I am the lightning.
One negative Delphi supporters like to point out is that Lazarus isn't quite ready yet, you know lots of bugs ... well neither is Kylix, so it follows that the most sensible thing is to go with an open source development tool.
At one time Borland said they were committed to Kylix in the long term, so I guess I know how good their promises are.
But most Windows boxes have the .net runtime installed...
.NET 2.0, which you should be, since the 2005 IDE is light-years beyond 2003, and the new features of the language are well worth it IMO.
.NET Framework v2.0 or higher installed" when they run them.
You might be surprised. Especially if you're compiling for
Obviously as time progresses, more and more people will have it, but a lot of them still don't. I put a note in my readmes and on the download pages for the apps I've released publicly, and I still get people asking me why they get an error along the lines of "you must have the
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Linux needs a modern, stable, bytecode-based, object-oriented, cross-platform language and runtime. For Windows this is .NET. )Since this is Slashdot, 1000 people will poo-poo .NET by the time they make it to this sentence) The corporate reality is that C# .NET is replacing C++ as the standard language for enterprise development and GUI application development. As a language, C++ hasn't kept-up fast enough, and to turn C++ into a platform you need a whole variety of 3rd-party libraries. .NET is a one-stop solution and it is a joy to program in.
.NET. And Linux doesn't have a viable alternative. The current options I see are:
Now while everyone is talking about this being the year of the Linux desktop, I see companies moving away from standards and toward
Java
Mono
Kylix?
Each has limitations. Mono has/may have dangerous patent problems, and the Novell/Microsoft deal seems to confirm it. I'm not sure what Java's limitations are today, since I abandoned it a decade ago. Kylix was supposed to be the solution. It had the ease of VB, the cross-platform power Qt, and the power and elegance of C++. But today the VB IDE is considered anemic, Windows Forms is better integrated into the IDE than Qt, C# has integrated most of the good features of C++, and bytecode compilers are 70% of native speed which is good enough.