Yes it is. I used to live there, too. But I have to say that at least there are tangible benefits to average citizens for those taxes in Canada... few visible benefits here.
And we have no room in the US to be smug. Taxes here are pretty high, too, and the politicians are no more realistic here than there.
What I am suggesting (and I'm not volunteering: my Linux experience is inadequate) is that the project will not succeed without oversight. Linux continues to grow because there are core groups which are managed. Communication is a large part of the equation.
Linus makes the final call on kernel changes, and has a small core of trusted managers of subsets of the kernel who funnel things to him. That's a hierarchy, and no group of any size is manageable without hierarchy and delegation.
The organization of LDP production seems altogether too loose. What I propose is that through inaction, a HOWTO becomes unowned, and is available to be taken over by a volunteer whose energy level prompts him to do so.
Now. Tell me how that can be worse than the present situation? All you have done is to nay-say my suggestion, and I see no proposal for improvement in your comment.
Stasis doesn't work. Dynamic systems which are not continuously rebuilt and developed are subject to entropy. And entropy is a great way to lose the growth Linux is currently experiencing.
A lot of Linux growth was supported by *nix-experienced enthusiasts and developers. When you exhaust that group, either the docs have to be a damn sight better than they are, or yo hit a plateau.
Your point is valid, to an extent. In my case, the lack of quality information caused me to put Linux aside for now. I'm quite willing to contribute when I have something to offer which is of sufficient quality, but I will not expend energies on producing a document which does not improve on what already exists.
I tried LDP, and I also tried the newsgroups. My need was for good information on serial programming, and the responses I received were few and of little use. The books I investigated did not help, either. The lack of cohesion in the LDP approach, where each doc tries to exist independent of all others was an added hurdle to my understanding.
I'm not interested in point and click answers. I want to see some rigor in documentation. I would like to see documents on low level programming written with an approach similar to that found in the documentation of a UART or a CPU. There is, after all, a high degree of similarity in the topics.
A document which purports to present a topic like serial programming should begin by identifying each of the system functions and structures which is involved, and should clearly define the necessary jargon, within the document. It should make clear, with minimal assumptions about its reader's knowledge, the purpose of structure members, and of function calls. To the degree that it does not, it fails at its purpose. With those standards in mind, review the Serial Programming HOWTO, and see whether is succeeds or fails.
Matt, it IS true. The LDP info is sparse and out of date. All the statements you make about volunteer projects are true, but isn't it ironic that Linux itself is the same kind of project, and yet its development appears to flourish, even as LDP languishes?
Linux desperately needs good, detailed, and current documentation for users and developers alike. There need to be some commitments authors make before being granted custody of a document. In particular, there needs to be a commitment to currency.
It's true that volunteers cannot be forced, but unless someone who is highly motivated to see LDP succeed takes charge and contacts each of the authors on a semi-regular basis, the project will collapse from apathy. Authors need to feel that they are part of a cohesive gropup, I think.
My own pet peeve is the Serial Programming HOW-TO, which has not received a revision for over 18 months, and was written by someone who admits his understanding of the topic was poor.
Once an author stakes a claim as maintainer for a document, there should be a requirement that the author revisit the document, perhaps quarterly, and do two things: first, review and correct or amend, and second, comment back to whoever is the coordinating member of the group that the quarterly work has been done. If the maintainer fails to maintain, then the document should be returned to the pool of unsupported documents. A web site with a list of ownership and status on the docs should not be too onerous a task for someone to maintain (see the Lazarus site for a model.)
I am new to Linux, but have been writing software for 25 years, on other OSes. I find the state of LDP docs, and of Linux docs in general, very frustrating. I have shelved my plans to move some of my company's development to Linux simply because on Linux I lose the ability to adequately schedule and predict development time. I doubt that I am alone in this.
There seems to be a pervasive assumption that we all studied Unix in college. Sorry to disappoint, but I was a fine arts major, and came to software design after having self-educated on hardware design. Coming to software from a hardware background, I expect a certain rigor and detail which is seldom found in software manuals, at any level.
I look on Linux as a potential alternative to Windows. So far, the stress must be on potential, as I cannot and will not commit the welfare of my employer's products to a system for which answers are often very hard to find.
Linux is anarchy; there is no industry. And Unix lost their franchise. What counts is a solid and easy to use interface. All the rest is for hobbyists.
I would be perfectly pleased to see Borland port their own components. They cover all my basic needs, and I don't see any conflict with any of the formats in Qt/KDE.
As far as GUI kits, I'm agnostic. I just want to be productive, and very soon after moving to Linux. Coding GUI by hand doesn't cut it, and never will.
Nice that there are such tools, but I am experienced in Delphi and would like to move some apps to Linux. As a practical matter, if I have to switch tools, I will be very slow to make such a move.
Re:Good for both newbies and gurus
on
Delphi for Linux
·
· Score: 1
With all due respect to Tog, I would say that Pascal is easier to learn than C in the beginning, but they both require diligence and commitment to master, and at that level, are probably on par.
I think that Delphi is terrific at a number of levels. For the sometime programmer, it is a tool which will allow him or her to build apps which are reasonably clean, and to focus on the functionality, without having to strain to achieve an interface for the user. For the programmer who uses Delphi every day, it affords the ease of building a meaningful app in minutes, literally.
The great visions Borland pursued are the VCL and the "two-way tools". Unlike MS with VC, there are no framing comments to signal a deficient file processor who owns what. I can modify any part of a file, or a form, and Delphi will make the correct determination. Can I do the wrong thing? Of course. If Delphi prevented that, it would be too restrictive in its access to system resources.
There are a few tasks which Delphi cannot accomplish, or at least would be harder than with VC. Writing drivers is one. But really, how many of us can digest the horrendous MS docs on that topic, anyway? And how many of us really want to write drivers? Needing to write a driver implies that you have designed a new card for the PC, and the prolifieration of PCI (and the reduction in ISA slots) has made that ever less likely.
People who claim that Object Pascal isn't up to "real programming" tasks have wrapped themselves in their ignorance.
VCL is, IMHO, the most significant development in software in years.
The Red Hat installation tool is horrible. It's clearly designed only to be used by people who only give the right answers. If I had that knowledge and skill, I wouldn't need an installer at all.
I used Red Hat for a while, but was repeatedly disappointed in the (many) rough edges in Gnome.
Mandrake feels much better than Red HAt, but so far, Caldera's install is the best I've seen. I'll get a CD from cheapbytes with the new Mandrake, to try theirs.
Because Linux has not yet convinced me to commit a product development to it, I have the luxury of trying and retrying distributions.
I note with interest that Caldera is the only one which has correctly set up X for either of my video cards. I'll be very interested to see whether Mandrake gets it right in the new installer.
Ethical cancer? In the USA? this is, in case it escaped your notice, a capitalistic country. Although some of Stallman's notions are excellent, the great difficulty with the Open Source movement is that it bids fair to become a fanatical cult.
Your ignorance of Delphi is impressive. With the Professional package and above, you do get source to RTL and VCL. I sincerely doubt that anyone in the Linux community is at great risk of improving the core of the compiler, so that really is a non-issue.
I have no idea what you're spouting with respect to "fictitious" things, but if you have any proof of your allegations, speak up. Otherwise you are merely trading in Microsoftian FUD.
Borland didn't rig it. The majority of respondents are Borland product users. What else would you expect? The survey was not intended or presented as anything other than a marketing tool for Borland. What it clearly showed is that among Borland tool users there is a great deal of interest in Borland tools for Linux. Quit griping: it means more growth for Linux.
If Jave becomes the defacto tool for Linux, then the apps will suffer. But for those of us who champion Borland tools, it doesn't matter: we will use Delphi, and will be productive, and our users will enjoy performance benefits over Java-built apps.
What gives you the idea that Object Pascal is "pseudo-object"? There are many ways of approaching OOP, and Delphi is as valid as any other, and more than some. At least it avoids the catastrophe called multiple-inheritance! Your comment smacks of ignorance of language.
Agreed, in every particular. I spend a good deal of time exploring alternatives to MS OSes, because I am tired of the time I spend (even with Delphi) fighting undocumented features of the OS. I'm also tired of weird problems with kernel level services and/or drivers getting in my way.
As to MS tools, I recently had occasion to explore VC (again.) It makes me appreciate even more how well designed a product Delphi is. The notion that anyone could consider VC a visual development environment is unbelievable. After spending 10 days on it I concluded I would rather go back to assembly coding on embedded processors.
I have reservations about Linux, but 98% of them would diminish or disappear if I could use Delphi. My number one concern is the productivity hit I will take in making the transition to Linux.
One of the best aspects, of course, is that most components shold come across with little or no change needed. Some will require change, such as the serial I/O component I use every day.
I doubt that there are many Linux users who can comprehend what a sudden increase in the developer community will occur when Delphi for Linux ships.
Then you make your choice, as is always true in an open market.
No, your tone was not Gestapo, but the notion of anything which is not open source being pointless is cut from that cloth. If there is no room for commercial products to run on Linux, then there are many market sectors which will remain with Windows.
My view is that all Linux-based applications benefit the furtherance of the OS, whether free or commercial.
Delphi gives me freedom to code my apps without being a slave to the GUI. I like that. Also, at the levels that count (the components and rtl), Delphi ships source code (in Professional and above).
Inprise/Borland has always had one of the best outlooks on licensing and on source access. To think that I might either debug or otherwise improve their compiler would be foolishly egotistical. But to have the source to the components protects me from obscure bugs interfering with my applications. The best of both worlds, for my money.
I have a large investment in development which has been for Windows. As much as I look forward to moving apps to Linux, I dread the thought of being forced into C++. And I dread still further the thought of having to code for Linux as I would have before Delphi saved me from hard coding for the WinAPI.
I will be shocked if Delphi for Linux makes cross-OS coding transparent. But if it makes it practical with compiler conditionals, I will be extremely pleased.
Even more than the matter of cross-OS compatibility is the cross-OS components issue. If we are able to immediately make use of most, if not all, of our existing collection of components, then we, as developers, win big time.
And how can you call it pointless? What a silly remark. There is much more to Linux than being "free."
There's an oddly Gestapo flavored tone which arises in Linux circles when the mention is made of commercial software.
If Linux must be a crusade, I'm staying home. If, on the other hand, Linux is a viable OS to be judged and used (or not) on its own merits, then I will probably use it. And I am far more likely to risk using it for commercial apps if I have a tool which makes me more productive. Delphi will.
GUIs are intended to make life easier for end-users, who clearly are not at ease with the command line (else Windows would not currently own the market.) The immediate side-effect of the GUI on the programming side is to engulf the programmer in the details of constructing the visual interface. The notion that such an interface should be built in any way but with a visual editor is truly bizarre. And painful.
Delphi combines a very highly productive IDE and visual toolset with a very capable language and compiler. Into the bargain, it introduces components which are arguably the first example of a successful software component. I do not count OCXs, which incur a large overhead, nor any sort of similar element in an interpreted language (sorry, Smalltalk.)
Inprise/Borland, in committing to port to Linux, confer on the OS another level of credibility, and a crucial one, in my view: that Linux can be the foundation for commercial software success, as well as for the free stuff.
As to those who froth at the mouth about the evil nature of commercial software, I fail to understand why having more choices is a bad thing. If I would rather pay for a good tool which I already know how to use, why should I be forced to use gcc instead? Free software is nice, but free choice is better.
And here I thought I was the only one on/. old enough to remember Dompier.:)
I had an Imsai, not an Altair, and remember too well loading some simple programs from the front panel switches. (Let the kids try to figure out what that means.)
There is nothing intrinsically wrong with Linux for video production. If you have the money, Avid is a no-brainer... in many ways.
If, on the other hand, the end product is on tape, then so long as you are able to produce the desired result without introducing visible degradation to the source, and can ultimately produce the tape, then any tool that works is just fine.
The LML card is M-JPEG, and the chip is the same one on the new $6000 Matrox card. Nothing wrong there. What's missing? Genlock, last I knew, but if you only need to play to tape, that's not a problem.
Avid is easy, if expensive, but there ARE alternatives, and some of them WILL be on Linux. With 25 years of experience in the video industry, I am completely confident of that.
10% isn't control, and I know people at Borland, and they aren't into being M$ windup toys, either.
Look around. M$ has a 10% stake in a lot of companies. Often, as much as anything, it is to help assure the continued existence of at least the appearance of competition. The troubles they have with the DOJ now are as nothing to what would happen if they wiped out Borland and others.
Actually, I prefer Mandrake and Caldera, so far. I want KDE, not Gnome, and Caldera has the only good installation process I have seen.
Shipping PC based boxes means adapting to change in the environment, and that means using the install tool, not just cloning drives. All of the other installation tools (other than Caldera) just suck. Especially if you select a custom installation.
I don't care whether Linux is open source. I'm not on a crusade. I do care about a viable alternative to Windows, though. And it has to be viable as the foundation for commercial products.
I'm sure that many of us who are programming for Windows share these concerns. This isn't a hobby, or a labor of love. It's a search for a better, cleaner OS that isn't strangling under legacy support and code bloat.
Many of us may have responded as we did because the licensing of Qt could be a complication. I know that was the deciding factor for me.
As to Gnome vs. KDE, I have used both, and Gnome just ain't ready for prime time yet. KDE has a polished feel, and into the bargain, will be less of a surprise to users already familiar with Windows. That makes my life simpler when I ship a product.
RAD is more than an interest: it's a necessity. Not having RAD means either outrageous prices for application software, or a failing company. The only way a small company can compete today is through RAD.
Consider this: by supporting Object Pascal under CBuilder, they made it possible to use the majority of the already 3rd party components without change. It had less to do with converting the core VCL, I suspect, than with acquiring that very large, and growing, collection of components.
In addition, these components become more truly components when they may be used in two different languages.
I suspect that we will see a JBuilder for Linux before Delphi, as I understand that JBuilder 3 is written in Java.
I am sure we will see Delphi for Linux, and I suspect that CBuilder will follow. One open question is whether they will port their compiler or use gcc. Either one would work as well for me, but I suspect that the latter case would draw more interest from existing Linux coders.
As to synchronization of product releases, it would be incredibly difficult. Moreover, CBuilder has all of the C++ complexity and compliance issues to manage, whereas OP is Borland's own lanmguage. Finally, I think each benefits from the other -- they one-up each other over time, so each new release raises the bar for the other product.
Also, for any who don't know, the compiler back end is the same for Delphi and CBuilder. And CBuilder can compile Delphi source (subject to a few restrictions).
Ultimately, the issue of which products migrate to Linux will depend on how many units are sold. If the Linux market snubs tools with pricetags, then they won't get commercial tools. And as should be apparent, Borland will have to go by stages, testing the waters. Anything else would verge on malfeasance.
I hope very much to see Delphi and CBuilder for Linux, and the sooner the better. I also hope to see Delphi for BeOS. Mostly, I hope that this will show Borland the merits of stepping into multi-platform.
For those who may be unaware, Borland has twice before developed tools for other platforms, and both times they lost money on the deal. The first was TP for Mac, and the second was C++ for OS/2. Let's show them that Linux is a good place to be.
I agree with you about C over C++. Was C++ designed with the intention of being hard to read? Or does Stroustrup just have some of the most counterintuitive notions of any programmer I've encountered?
I like strong typing. I have casts to override when I want to add chars and integers. I detest automatic type conversion and "promotion". Give me no surprises.
Sometimes when I am parsing text I wish I were using C, but the most recent changes in Object Pascal have made that less an issue than it once was.
Almost anything written in VC++ could serve as an example of how not to write. (Let the flames begin.) Why does little or nothing from MS conform to the principles espoused in McConnell's excellent books?
I have no comment on Linux source style, as I have not yet delved into it.
Each time I am bitten by unexpected behaviors (rarely when in Delphi) I crave the good old days of assembly level programming.
I'm not a Basic programmer, and never have been. (See the comment above on automatic type conversion.)
I'm only welded to Delphi by virtue of production ease and speed. Give me an alternative which doesn't reduce my productivity, and I will use it.
Slashdot Mirror
Actually, no. I just paid from 8.50 to 14.00 for a half-dozen CDs in the US, and I buy blanks at 50 for $59.00.
Yes it is. I used to live there, too. But I have to say that at least there are tangible benefits to average citizens for those taxes in Canada... few visible benefits here.
And we have no room in the US to be smug. Taxes here are pretty high, too, and the politicians are no more realistic here than there.
What I am suggesting (and I'm not volunteering: my Linux experience is inadequate) is that the project will not succeed without oversight. Linux continues to grow because there are core groups which are managed. Communication is a large part of the equation.
Linus makes the final call on kernel changes, and has a small core of trusted managers of subsets of the kernel who funnel things to him. That's a hierarchy, and no group of any size is manageable without hierarchy and delegation.
The organization of LDP production seems altogether too loose. What I propose is that through inaction, a HOWTO becomes unowned, and is available to be taken over by a volunteer whose energy level prompts him to do so.
Now. Tell me how that can be worse than the present situation? All you have done is to nay-say my suggestion, and I see no proposal for improvement in your comment.
Stasis doesn't work. Dynamic systems which are not continuously rebuilt and developed are subject to entropy. And entropy is a great way to lose the growth Linux is currently experiencing.
A lot of Linux growth was supported by *nix-experienced enthusiasts and developers. When you exhaust that group, either the docs have to be a damn sight better than they are, or yo hit a plateau.
Your point is valid, to an extent. In my case, the lack of quality information caused me to put Linux aside for now. I'm quite willing to contribute when I have something to offer which is of sufficient quality, but I will not expend energies on producing a document which does not improve on what already exists.
I tried LDP, and I also tried the newsgroups. My need was for good information on serial programming, and the responses I received were few and of little use. The books I investigated did not help, either. The lack of cohesion in the LDP approach, where each doc tries to exist independent of all others was an added hurdle to my understanding.
I'm not interested in point and click answers. I want to see some rigor in documentation. I would like to see documents on low level programming written with an approach similar to that found in the documentation of a UART or a CPU. There is, after all, a high degree of similarity in the topics.
A document which purports to present a topic like serial programming should begin by identifying each of the system functions and structures which is involved, and should clearly define the necessary jargon, within the document. It should make clear, with minimal assumptions about its reader's knowledge, the purpose of structure members, and of function calls. To the degree that it does not, it fails at its purpose. With those standards in mind, review the Serial Programming HOWTO, and see whether is succeeds or fails.
Matt, it IS true. The LDP info is sparse and out of date. All the statements you make about volunteer projects are true, but isn't it ironic that Linux itself is the same kind of project, and yet its development appears to flourish, even as LDP languishes?
Linux desperately needs good, detailed, and current documentation for users and developers alike. There need to be some commitments authors make before being granted custody of a document. In particular, there needs to be a commitment to currency.
It's true that volunteers cannot be forced, but unless someone who is highly motivated to see LDP succeed takes charge and contacts each of the authors on a semi-regular basis, the project will collapse from apathy. Authors need to feel that they are part of a cohesive gropup, I think.
My own pet peeve is the Serial Programming HOW-TO, which has not received a revision for over 18 months, and was written by someone who admits his understanding of the topic was poor.
Once an author stakes a claim as maintainer for a document, there should be a requirement that the author revisit the document, perhaps quarterly, and do two things: first, review and correct or amend, and second, comment back to whoever is the coordinating member of the group that the quarterly work has been done. If the maintainer fails to maintain, then the document should be returned to the pool of unsupported documents. A web site with a list of ownership and status on the docs should not be too onerous a task for someone to maintain (see the Lazarus site for a model.)
I am new to Linux, but have been writing software for 25 years, on other OSes. I find the state of LDP docs, and of Linux docs in general, very frustrating. I have shelved my plans to move some of my company's development to Linux simply because on Linux I lose the ability to adequately schedule and predict development time. I doubt that I am alone in this.
There seems to be a pervasive assumption that we all studied Unix in college. Sorry to disappoint, but I was a fine arts major, and came to software design after having self-educated on hardware design. Coming to software from a hardware background, I expect a certain rigor and detail which is seldom found in software manuals, at any level.
I look on Linux as a potential alternative to Windows. So far, the stress must be on potential, as I cannot and will not commit the welfare of my employer's products to a system for which answers are often very hard to find.
Linux is anarchy; there is no industry. And Unix lost their franchise. What counts is a solid and easy to use interface. All the rest is for hobbyists.
I would be perfectly pleased to see Borland port their own components. They cover all my basic needs, and I don't see any conflict with any of the formats in Qt/KDE.
As far as GUI kits, I'm agnostic. I just want to be productive, and very soon after moving to Linux. Coding GUI by hand doesn't cut it, and never will.
Nice that there are such tools, but I am experienced in Delphi and would like to move some apps to Linux. As a practical matter, if I have to switch tools, I will be very slow to make such a move.
With all due respect to Tog, I would say that Pascal is easier to learn than C in the beginning, but they both require diligence and commitment to master, and at that level, are probably on par.
I think that Delphi is terrific at a number of levels. For the sometime programmer, it is a tool which will allow him or her to build apps which are reasonably clean, and to focus on the functionality, without having to strain to achieve an interface for the user. For the programmer who uses Delphi every day, it affords the ease of building a meaningful app in minutes, literally.
The great visions Borland pursued are the VCL and the "two-way tools". Unlike MS with VC, there are no framing comments to signal a deficient file processor who owns what. I can modify any part of a file, or a form, and Delphi will make the correct determination. Can I do the wrong thing? Of course. If Delphi prevented that, it would be too restrictive in its access to system resources.
There are a few tasks which Delphi cannot accomplish, or at least would be harder than with VC. Writing drivers is one. But really, how many of us can digest the horrendous MS docs on that topic, anyway? And how many of us really want to write drivers? Needing to write a driver implies that you have designed a new card for the PC, and the prolifieration of PCI (and the reduction in ISA slots) has made that ever less likely.
People who claim that Object Pascal isn't up to "real programming" tasks have wrapped themselves in their ignorance.
VCL is, IMHO, the most significant development in software in years.
The Red Hat installation tool is horrible. It's clearly designed only to be used by people who only give the right answers. If I had that knowledge and skill, I wouldn't need an installer at all.
I used Red Hat for a while, but was repeatedly disappointed in the (many) rough edges in Gnome.
Mandrake feels much better than Red HAt, but so far, Caldera's install is the best I've seen. I'll get a CD from cheapbytes with the new Mandrake, to try theirs.
Because Linux has not yet convinced me to commit a product development to it, I have the luxury of trying and retrying distributions.
I note with interest that Caldera is the only one which has correctly set up X for either of my video cards. I'll be very interested to see whether Mandrake gets it right in the new installer.
Ethical cancer? In the USA? this is, in case it escaped your notice, a capitalistic country. Although some of Stallman's notions are excellent, the great difficulty with the Open Source movement is that it bids fair to become a fanatical cult.
Your ignorance of Delphi is impressive. With the Professional package and above, you do get source to RTL and VCL. I sincerely doubt that anyone in the Linux community is at great risk of improving the core of the compiler, so that really is a non-issue.
I have no idea what you're spouting with respect to "fictitious" things, but if you have any proof of your allegations, speak up. Otherwise you are merely trading in Microsoftian FUD.
Borland didn't rig it. The majority of respondents are Borland product users. What else would you expect? The survey was not intended or presented as anything other than a marketing tool for Borland. What it clearly showed is that among Borland tool users there is a great deal of interest in Borland tools for Linux. Quit griping: it means more growth for Linux.
If Jave becomes the defacto tool for Linux, then the apps will suffer. But for those of us who champion Borland tools, it doesn't matter: we will use Delphi, and will be productive, and our users will enjoy performance benefits over Java-built apps.
What gives you the idea that Object Pascal is "pseudo-object"? There are many ways of approaching OOP, and Delphi is as valid as any other, and more than some. At least it avoids the catastrophe called multiple-inheritance! Your comment smacks of ignorance of language.
Agreed, in every particular. I spend a good deal of time exploring alternatives to MS OSes, because I am tired of the time I spend (even with Delphi) fighting undocumented features of the OS. I'm also tired of weird problems with kernel level services and/or drivers getting in my way.
As to MS tools, I recently had occasion to explore VC (again.) It makes me appreciate even more how well designed a product Delphi is. The notion that anyone could consider VC a visual development environment is unbelievable. After spending 10 days on it I concluded I would rather go back to assembly coding on embedded processors.
I have reservations about Linux, but 98% of them would diminish or disappear if I could use Delphi. My number one concern is the productivity hit I will take in making the transition to Linux.
One of the best aspects, of course, is that most components shold come across with little or no change needed. Some will require change, such as the serial I/O component I use every day.
I doubt that there are many Linux users who can comprehend what a sudden increase in the developer community will occur when Delphi for Linux ships.
Then you make your choice, as is always true in an open market.
No, your tone was not Gestapo, but the notion of anything which is not open source being pointless is cut from that cloth. If there is no room for commercial products to run on Linux, then there are many market sectors which will remain with Windows.
My view is that all Linux-based applications benefit the furtherance of the OS, whether free or commercial.
Delphi gives me freedom to code my apps without being a slave to the GUI. I like that. Also, at the levels that count (the components and rtl), Delphi ships source code (in Professional and above).
Inprise/Borland has always had one of the best outlooks on licensing and on source access. To think that I might either debug or otherwise improve their compiler would be foolishly egotistical. But to have the source to the components protects me from obscure bugs interfering with my applications. The best of both worlds, for my money.
I have a large investment in development which has been for Windows. As much as I look forward to moving apps to Linux, I dread the thought of being forced into C++. And I dread still further the thought of having to code for Linux as I would have before Delphi saved me from hard coding for the WinAPI.
I will be shocked if Delphi for Linux makes cross-OS coding transparent. But if it makes it practical with compiler conditionals, I will be extremely pleased.
Even more than the matter of cross-OS compatibility is the cross-OS components issue. If we are able to immediately make use of most, if not all, of our existing collection of components, then we, as developers, win big time.
And how can you call it pointless? What a silly remark. There is much more to Linux than being "free."
There's an oddly Gestapo flavored tone which arises in Linux circles when the mention is made of commercial software.
If Linux must be a crusade, I'm staying home. If, on the other hand, Linux is a viable OS to be judged and used (or not) on its own merits, then I will probably use it. And I am far more likely to risk using it for commercial apps if I have a tool which makes me more productive. Delphi will.
GUIs are intended to make life easier for end-users, who clearly are not at ease with the command line (else Windows would not currently own the market.) The immediate side-effect of the GUI on the programming side is to engulf the programmer in the details of constructing the visual interface. The notion that such an interface should be built in any way but with a visual editor is truly bizarre. And painful.
Delphi combines a very highly productive IDE and visual toolset with a very capable language and compiler. Into the bargain, it introduces components which are arguably the first example of a successful software component. I do not count OCXs, which incur a large overhead, nor any sort of similar element in an interpreted language (sorry, Smalltalk.)
Inprise/Borland, in committing to port to Linux, confer on the OS another level of credibility, and a crucial one, in my view: that Linux can be the foundation for commercial software success, as well as for the free stuff.
As to those who froth at the mouth about the evil nature of commercial software, I fail to understand why having more choices is a bad thing. If I would rather pay for a good tool which I already know how to use, why should I be forced to use gcc instead? Free software is nice, but free choice is better.
And here I thought I was the only one on /. old enough to remember Dompier. :)
I had an Imsai, not an Altair, and remember too well loading some simple programs from the front panel switches. (Let the kids try to figure out what that means.)
And then there was the ASR-33..........
There is nothing intrinsically wrong with Linux for video production. If you have the money, Avid is a no-brainer... in many ways.
If, on the other hand, the end product is on tape, then so long as you are able to produce the desired result without introducing visible degradation to the source, and can ultimately produce the tape, then any tool that works is just fine.
The LML card is M-JPEG, and the chip is the same one on the new $6000 Matrox card. Nothing wrong there. What's missing? Genlock, last I knew, but if you only need to play to tape, that's not a problem.
Avid is easy, if expensive, but there ARE alternatives, and some of them WILL be on Linux. With 25 years of experience in the video industry, I am completely confident of that.
10% isn't control, and I know people at Borland, and they aren't into being M$ windup toys, either.
Look around. M$ has a 10% stake in a lot of companies. Often, as much as anything, it is to help assure the continued existence of at least the appearance of competition. The troubles they have with the DOJ now are as nothing to what would happen if they wiped out Borland and others.
Actually, I prefer Mandrake and Caldera, so far. I want KDE, not Gnome, and Caldera has the only good installation process I have seen.
Shipping PC based boxes means adapting to change in the environment, and that means using the install tool, not just cloning drives. All of the other installation tools (other than Caldera) just suck. Especially if you select a custom installation.
I don't care whether Linux is open source. I'm not on a crusade. I do care about a viable alternative to Windows, though. And it has to be viable as the foundation for commercial products.
I'm sure that many of us who are programming for Windows share these concerns. This isn't a hobby, or a labor of love. It's a search for a better, cleaner OS that isn't strangling under legacy support and code bloat.
Many of us may have responded as we did because the licensing of Qt could be a complication. I know that was the deciding factor for me.
As to Gnome vs. KDE, I have used both, and Gnome just ain't ready for prime time yet. KDE has a polished feel, and into the bargain, will be less of a surprise to users already familiar with Windows. That makes my life simpler when I ship a product.
RAD is more than an interest: it's a necessity. Not having RAD means either outrageous prices for application software, or a failing company. The only way a small company can compete today is through RAD.
Consider this: by supporting Object Pascal under CBuilder, they made it possible to use the majority of the already 3rd party components without change. It had less to do with converting the core VCL, I suspect, than with acquiring that very large, and growing, collection of components.
In addition, these components become more truly components when they may be used in two different languages.
I suspect that we will see a JBuilder for Linux before Delphi, as I understand that JBuilder 3 is written in Java.
I am sure we will see Delphi for Linux, and I suspect that CBuilder will follow. One open question is whether they will port their compiler or use gcc. Either one would work as well for me, but I suspect that the latter case would draw more interest from existing Linux coders.
As to synchronization of product releases, it would be incredibly difficult. Moreover, CBuilder has all of the C++ complexity and compliance issues to manage, whereas OP is Borland's own lanmguage. Finally, I think each benefits from the other -- they one-up each other over time, so each new release raises the bar for the other product.
Also, for any who don't know, the compiler back end is the same for Delphi and CBuilder. And CBuilder can compile Delphi source (subject to a few restrictions).
Ultimately, the issue of which products migrate to Linux will depend on how many units are sold. If the Linux market snubs tools with pricetags, then they won't get commercial tools. And as should be apparent, Borland will have to go by stages, testing the waters. Anything else would verge on malfeasance.
I hope very much to see Delphi and CBuilder for Linux, and the sooner the better. I also hope to see Delphi for BeOS. Mostly, I hope that this will show Borland the merits of stepping into multi-platform.
For those who may be unaware, Borland has twice before developed tools for other platforms, and both times they lost money on the deal. The first was TP for Mac, and the second was C++ for OS/2. Let's show them that Linux is a good place to be.
I agree with you about C over C++. Was C++ designed with the intention of being hard to read? Or does Stroustrup just have some of the most counterintuitive notions of any programmer I've encountered?
.)
I like strong typing. I have casts to override when I want to add chars and integers. I detest automatic type conversion and "promotion". Give me no surprises.
Sometimes when I am parsing text I wish I were using C, but the most recent changes in Object Pascal have made that less an issue than it once was.
Almost anything written in VC++ could serve as an example of how not to write. (Let the flames begin.) Why does little or nothing from MS conform to the principles espoused in McConnell's excellent books?
I have no comment on Linux source style, as I have not yet delved into it.
Each time I am bitten by unexpected behaviors (rarely when in Delphi) I crave the good old days of assembly level programming.
I'm not a Basic programmer, and never have been. (See the comment above on automatic type conversion
I'm only welded to Delphi by virtue of production ease and speed. Give me an alternative which doesn't reduce my productivity, and I will use it.