Slashdot Mirror


Borland Releases Kylix 3.0 for Delphi and C++

An anonymous reader writes "Looks like Borland is giving us Kylix for C++ after all. Kylix 3.0 is available in Open, Professional, and Enterprise versions. Time to start banging out those CLX apps! The Register also has a story about this."

8 of 265 comments (clear)

  1. Re:amusing quote by jpvlsmv · · Score: 2, Insightful

    This guy is obviously not an emacs user.

  2. Re:amusing quote by DearSlashdot · · Score: 2, Insightful
    Since when is having multiple xterms "not easy to use"?

    How about for people who are still learning how to code? Oh, I forgot, real 1337 linux hackers never went through that phase, they came out of the womb with their knowledge.

    All other things being equal, an integrated RAD environment will very often shorten time to code and debug a project. It is definitely easier to use a RAD tool like Delphi than just a text editor and command-line tools. For some people, it may not be that much different. For others, that may be the difference between getting into programming and not.

    Oh, I forgot again, you don't want those people in your precious Linux world.

    --

    "Why should we leave America to go to America Junior?" - H. Simpson, on visiting Canada
  3. Re:amusing quote by Peter+La+Casse · · Score: 2, Insightful
    How about for people who are still learning how to code?

    For them, nothing is easy to use, since coding is full of new concepts that they don't understand yet.

    Using multiple xterms is not more difficult than using multiple windows within an IDE, and both require the multiple window concept in order to display different files simultaneously.

    Now, coding in a single window, closing one file in order to view another - that's more difficult / less productive.

  4. Re:amusing quote by DearSlashdot · · Score: 2, Insightful
    For them, nothing is easy to use, since coding is full of new concepts that they don't understand yet.

    I think you are drawing a too black-and-white distinction here. The fact is, someone learning understands things to varying degrees. Using a tool like delphi that 1) has excellent integrated debugging, 2) has excellent integrated, context-sensitive documentation, and 3) has excellent intellisense shortens that learning curve by taking what they know and making it easy for them to access the documentation and declarations, and extend their current knowledge. If they were completely in the dark, neither command-line nor RAD would be much of a help. But that's not the reality for most people (at least not for very long).

    Take Delphi. I want to use an object. I type the object's name, dot. Up pops a box with all of the properties and methods, in order of inheritance, with their parameter declarations. I can instantly see what options I have, which give me a great deal of insight into what this object does. If I need more, I press F1, and the help takes me to the object or property that I am on. Functions work the same. Type [function]( and up pops the declaration, so you can see exactly what you need to send this. Hit F1, and...you get the point.

    I find myself relying on Delphi's intellisense features to help me code because it reduces typos and is a lot faster. And that's just one feature. A good RAD environment is extremely useful for both newbies and veterans.

    This is less about difficulty than it is a matter of efficiency and expense. It costs more time, effort, and mental overhead (for most people, there are always exceptions) to work with multiple windows and command-line tools than with an integrated environment. I would argue that a great many, if not most, people would find that the benefits of a well-designed RAD tool are worth the costs ($ and time to learn how to use it properly).

    --

    "Why should we leave America to go to America Junior?" - H. Simpson, on visiting Canada
  5. Re:Has Borland dropped their dependency on Qt yet? by Anonymous Coward · · Score: 1, Insightful

    > People wanted QT under the GPL...

    No, we wanted it under the LGPL, like the rest of the libraries.

    Trolltech chose the GPL instead, because it let them pretend to be open, when in fact it does the opposite, by forcing commercial developers use a proprietary license for Qt.

    I find it interesting that the original post, that raised a valid concern, was modded down to (Score:-1, Flamebait), while the above post, that states an obvious falsehood, gets modded up to (Score:4, Interesting). Does Trolltech employ astroturfers?

  6. Re:Troll Tech, Qt license? by Omnifarious · · Score: 2, Insightful

    Ahh, so you wanted it under the LGPL so you could make money and Trolltech couldn't. How very well-spirited and thoughtful of you.

  7. Preprocessor as a language is no better. by NDSalerno · · Score: 2, Insightful
    You got to be kidding me. I would never write code like that. This kind of programming is what makes MFC a bad library. Your C/C++ macro preprocessor is a tool, not a language. Don't use it like a language. Here is a short list why:
    • Can't trace preprocessor code during debugging.
    • Can't inspect the value of a #define during debugging. I prefer const variables.
    • You undermine the code completion because it doesn't know about the existence of the property. When you press '.' or '->' you will not see your property in the popup window.
    • Can very easily introduce obscure bugs that can be hard to find.
    Take a look at MFC message maps to understand why using the preprocessor as a language is a mistake. I'm sorry but I disagree with you. Altering the language can be a good thing. Adding a new feature is not the only criterion for altering the language. If the alteration helps productivity then I am for the alteration being done. C++, especially, could really use it.
  8. But when do the training wheels come off? by extrasolar · · Score: 2, Insightful

    But when do the training wheels come off? Either you learn to adapt to new environments easily, or you use an environment that will always be there and will always provide what you need it to do.

    While you can rely on a language, you shouldn't need to rely on the tool. Especially proprietary tools.

    This is probably one reason a lot of really good developers prefer the unix tools, mostly emacs or vi rather than the latest fad, because a fad is exactly what it is. One year its C++ and Visual Studio, the next year its Java, now its .NET and C#. Yet Unix people are still using the same tools they've always used, emacs or vi, and just drop in a new compiler and extend the syntax rules in the editor for the new programming language. On proprietary systems, developers purchase a new system.

    So I think you're right when saying that developing in a "visual" environment is easier and you can catch on to programming quicker. But I believe that investing some more time into a "unix" tool is more valuable for your programming career. Actually, this isn't my idea--something I read on USENET.

    And that's why I am spending time learning emacs. Because I don't think I'm wasting my time.