Slashdot Mirror
Borland And Troll Tech And Kylix Delphi/C/C++
nici writes: "Borland and Troll Tech(Qt+KDE anyone?) have made some sort of licensing agreement to allow Borland's new brain child Kylix to be born. It's going to be a Delphi/C/C++ compiler for Linux... complete with a GUI interface. It's supposed to be completely compatible with windows. Here's a Press Release."
Several other people noted that Dr. Bob (CT:Not Dr. Dobbs, my bad! Mustn'y post before coffee!) has some
screenshots if you're interested in what the tool actually looks like (Hint: It looks pretty sweet).
RAD tools are sorely lacking in the Linux environment and, contrary to the GCC evangelists opinions, are really needed for success in business. Delphi on windows is REALLY strong, and I'm looking forward to being able to develop utilities with the same ease for X windows. I'm a DBA, and I need the ability to be able to throw together quick and disposable apps to fulfill a single purpose. Perl is fun and all, but sometimes things simply call for a compiled binary. I'm hoping that they will include the database interface objects in this release to give me that ability (and to have a good argument for dumping my Windows 2000 desktop =P). Anyone know if any kinda db libraries are going to be included in the release? It'd be kinda cool to whip up a MySQL/Oracle/insert your favortie Linux database tool here Enterprise manager for X.
Imagination is the silver lining of Intelligence.
Actual, don't knock me off as a troll. I'm trying to say, why should I bother with Borland when I can use gcc/g++ and any ol' IDE (sorry about that obscure pun) that I want. I just don 't make sense. I already got dem tools
But you for you windows boys, yes now you too can write programs for Linux!
Don't knock Delphi until you have tried it and written a app with it. It's amazing. The compiler is maybe the best compiler ever written. Compile time is effectively zero. There's no link time. Object Pascal has niceties, like having single file modules instead of source + header files, that make you wonder how you ever managed with C++. You can ignore all the GUI and OOP stuff and just use Object Pascal as a straight compiler. The built-in assembler is so nice I've even used it for all-assembly programs, as it's much faster than NASM/MASM.
And all of this is really just used as the back-end for a very slick and complete GUI design package. You can click on controls and add event handlers for just about anything. It's very complete.
The killer is that everything is extremely solid and well-implemented to a level that is foreign to Linux desktop environments. gcc may be nice, but we've all had our general oddities and bizarro error messages from it. Putting a cranky GUI layout package on top of this is not the same thing. The bottom line is that Delphi is much, much stabler and slicker than what we're used to using in Linux. Ignoring it for GUI-based programs is on par with writing an OS in assembly code instead of C. Don't wear a hair shirt because this comes from Windows. Delphi will change Linux application development, no question about it.
Let's start off with one huge assumption. This thing works well, is delivered on time, generates clean code, looks and feels like the Windows Burland stuff with enough Linux enhancements to attract new users. It should also generate KDE code with deep integration down to the KOffice and Panel applet level. Ohh... and it should mostly be compatible with The Windows software.
This is a tall order but is pretty much what has been promised and Burland has a habit of delivering. Under that scenario who would use this?
1. The Veteran Open Source/Free Software developer. Maybe but only if he has a day job that requires it. His real work will still be done in a plane text editor with GDB and GCC on call.
2. The New OSS/Free developer. Not him either. He hasn't got any money and cares enough about Free software to use KDEvelop.
3. The Commercial developer with eyes on Linux. Yes. They want to deliver salable stuff quickly.
4. The Internal corporate developer ( I.e. Burland's real market ). These people will use this in disproportionately large numbers. They will port legacy apps on limited function desktops to Linux and reduce maintenance headaches. They will develop in Linux and deliver across platforms.
5. Shareware author. Burland hinted at a desire to get it's support libraries included in popular distributions. If this happens then even junior developers will be able to deliver very small applications that are still fairly complex.
Will this make money ? My guess is that Burland will achieve a clear profit on it's Linux venture before even some companies that came before. This includes Corel. However Corel may have larger overal revenue in the long run.
--= Isn't it surprising how badly I spell ?
This story, about Borland's upcoming Delphi for Linux, has drawn a very clear line in the sand between introverted Linux zealots and the people who are going to move Linux forward. I see endless responses like "Bah! I can just use gcc!" and "Only fools would use a RAD environment! Real Linux programmers will keep using gcc and an Emacs-based IDE."
A fantastic--maybe the best--compiler and GUI development system is coming to Linux and we should ignore it? We should keep flogging ourselves until we remember that UNIX is The Only Way? What is happening here is that an elitist crowd with a confused agenda is suddenly being confronted with the painful truth that Linux development software is far, far behind what has been available for some other systems. This realization needs to be embraced, or we can never advance. We can only fool ourselves for so long.
And, you know, this may make Linux difficult to differentiate from Windows. But hasn't that been the plan all along? I mean, we could have been devoting energies to desktop environments that aren't re-workings of Windows, right?
Though it's nice to have power user interfaces as well, such as scripting interfaces. I agree with you here. Traditional Unix programs, being command line tools, are inherently scriptable. Very few Windows programs are (one notable exception is MS Office).
But Point and Click doesn't preclude the use of other interfaces in the same peice of software of course.
I'm reposting this since it got buried under a troll, and there is some confusion here with compatibility with regards to windows..
Bero-rh wrote
The nicety of it is that they're planning to generate (native) Linux applications from [Borland C++ and Delphi] source originally written to run on Windoze
Not quite. There is a an interview with Chuck Jazdzewski, the chief architect of Delphi that explains Kylix and how it will or will not work with current Delphi Windows source.
Specifically as far as Kylix and Windows source code compatibility he writes:
Will existing applications that don?t touch the Win32 API just recompile with Kylix? What about components inherited from TCustomXXX classes - will these work ok?
It is impossible to make a blanket statement that if you didn?t use this or did use that you will be compatible. There are too many variables. Our goal is make the porting effort to Linux easy for people who mainly use components to build applications. As for custom visual components, most will require significant changes from the component vendors. The component vendors? porting tasks will be much easier if the component writer neither subclasses Windows controls, nor handles exotic Windows messages, or if they avoid direct calls into the Windows API when a VCL equivalent is present (eg using TCanvas instead of calling GDI directly). Non-visual components, however, are much easier assuming the underlying API they are wrapping exists under Linux. A component wrapping the Berkley socket layer ports easily, but a MAPI component would not port at all.
I anticipate the biggest obstacle people will face when porting their code is not how compatible the Linux VCL is with the Windows version, but collecting an equivalent set of Linux third-party components to replace those that they have been using on Windows. Because we realise how important this is, we have started to work with our third-party vendors early to get them porting their components so our customers will have a wide selection when we ship.
---
So, at least for awhile, Delphi authors who want to work with both platforms will have to fork existing projects to get them to work with both OS's, and new projects will have to have a lot of platform-checking code.
I still can't wait until this is released.
I want to be the first to pedantically point out that this is not going to be a compiler, but rather a Develpment Environment, or, as Borland puts it, a "Rapid Application Development (RAD) development tool".
-Jan
-- "Tradition is the illusion of permanence."
At least that's what I thought when i read the name at first...
a Bit Like E-Music, which makes me think of music that you have to take E to like. After enough MDMA most people would dance to a car alarm and enjoy it.
Damn So much for staying on topic.
But seriously, How many people feel that their programming would benefit from an IDE to help them keep track of variables and function names. I grwew up with assembly language and can't get my head around these environments which can end up second guessing the user. If I can't keep te whole of a project in my head I tend to get bored with it. That's the way i've always been...
Personally - I wish I didn't need to write makefiles.
;-)
If you don't know what's going to be so cool about Kylix, here's an explanation from the author of "Delphi in a nutshell".
--
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.