Maybe I missed something, but did the poster mention they were on webcams viewing each other in different places? How then would they get caught having anal sex?
a fairer comparison would be to compare Xlib to the Win32 API
Not really. Have programmed extensively in both, and having had the misfortune of fighting with xlib just a few months ago, I can tell for painful experience, that while the Win32 API is a bit weird, and documented poorly, it is heaven compared to the steaming pile of crap that is XLib (please not that this is *not* a complaint about the X protocol). The reason it's heaven is because it gives you a huge amount of functionality already built in, whereas with XLib you *must* either right much of your own code from scratch, or use a toolkit (which then largely defeats the point of making XLib calls). Things like menus, buttons, copy/paste, drag/drop, timers, blocking versus non-blocking message sending, etc are *not* implemented in XLib, and you must roll your own.
That said, I do agree that the Win32 API is a mess to learn, and the documentation can be pretty lame. Thankfully there have been a number of sites in recent years that have tutorials that cover just about every possible issue/problem with it, and make it much easier to work in, or at least find solutions for.
NO C or C++, or for that matter *any* compiled language is a write once, run anywhere proposition. Java can claim this *only* because it is interpreted and runs within another program (the Java VM), and this program is most certainly no WORA!
And even though Java is WORA (sort of), it usefulness for end user UI apps is next to worthless. No Java based UI application of any complexity that I have used has been anything other than outlandishly sluggish.
This ranges from the Java IDEs, to CASE tools, to various other editors, especially if they are based on Swing or AWT. IBM's SWT library is better (this is what Eclipse is written in), but even Eclipse is *still* sluggish when running with a mildly complex project.
If you're looking for a C++ framework that does use the STL, standard strings, modern C++, etc, and has none of the licensing restrictions (BSD license), check out the Visual Component Framework.
This is not entirely true. If you're a developer on the X11 platform you get it "free" via a dual license under the GPL.
For those of us on other platforms this is not the case (AFAIK). Plus if you do develop code with Qt using the GPL version, as I understand it, there are issues should you then choose to make it a commercial application.
"The Free Edition licenses do not allow the development or distribution of commercial software."
That said, Qt is a really nice framework.
However if you're curious, I'd humbly reccomend you take a look at the Visual Component Framework, a new C++ framework that is being actively worked on by your truly.
You, my friend, have obviously never had the "pleasure" of working with Forte.
I had the utterly miserable misfortune to spend a year on an all forte project at a large US Tire company from the very begining to the intial deployment of the software to the users.
And it sucked beyound belief.
The "IDE" that forte provided was a piece of shit (and that's putting it mildly). It was quirky to develop in, ungodly slow, resource intensive, brain dead peice of heaping crap.
Our CS intern that we got on the project quickly renamed the the language to Forte Objected Oriented Langauge (FOOL).
Deploying to 5, that's right folks, 5 machines was an utter nightmare, and took 3 of us to keep it going.
On the other hand you could partition the application to run on different machines. Useful of course, when the application actually ran.
From a language standpoint, the "plumbing" was indeed hidden from you. It was absurdly easy to talk to objects cross process or cross machines.
The problem was everything else was an amateurish piece of shit that rarely worked the way Forte claimed it did. And we had a consultant working with us to iron out all the problems (at $250 an hour, thank you very much).
And when we finally got it to run, the app ran SO slowly, that he had to hand massage the generated C++ (TOOL/FOOL doesn't itself get compiled - it generated C++ which was then compiled) and add a whole bunch of custom stuff, of course none of this was explained or documented, it Just Worked (well sort of - by the time I left the project, the users HATED the app so much because it was clunky and slow, that they never really used it - it was faster to calculate the retirement calcs by hand than to deal with the app).
So, yeah, Forte was a real good platform to base stuff off of.
Slashdot Mirror
Maybe I missed something, but did the poster mention they were on webcams viewing each other in different places? How then would they get caught having anal sex?
Not really. Have programmed extensively in both, and having had the misfortune of fighting with xlib just a few months ago, I can tell for painful experience, that while the Win32 API is a bit weird, and documented poorly, it is heaven compared to the steaming pile of crap that is XLib (please not that this is *not* a complaint about the X protocol). The reason it's heaven is because it gives you a huge amount of functionality already built in, whereas with XLib you *must* either right much of your own code from scratch, or use a toolkit (which then largely defeats the point of making XLib calls). Things like menus, buttons, copy/paste, drag/drop, timers, blocking versus non-blocking message sending, etc are *not* implemented in XLib, and you must roll your own.
That said, I do agree that the Win32 API is a mess to learn, and the documentation can be pretty lame. Thankfully there have been a number of sites in recent years that have tutorials that cover just about every possible issue/problem with it, and make it much easier to work in, or at least find solutions for.
And even though Java is WORA (sort of), it usefulness for end user UI apps is next to worthless. No Java based UI application of any complexity that I have used has been anything other than outlandishly sluggish. This ranges from the Java IDEs, to CASE tools, to various other editors, especially if they are based on Swing or AWT. IBM's SWT library is better (this is what Eclipse is written in), but even Eclipse is *still* sluggish when running with a mildly complex project.
If you're looking for a C++ framework that does use the STL, standard strings, modern C++, etc, and has none of the licensing restrictions (BSD license), check out the Visual Component Framework.
Doh, That should be Visual Component Framework
This is not entirely true. If you're a developer on the X11 platform you get it "free" via a dual license under the GPL. For those of us on other platforms this is not the case (AFAIK). Plus if you do develop code with Qt using the GPL version, as I understand it, there are issues should you then choose to make it a commercial application. "The Free Edition licenses do not allow the development or distribution of commercial software." That said, Qt is a really nice framework. However if you're curious, I'd humbly reccomend you take a look at the Visual Component Framework, a new C++ framework that is being actively worked on by your truly.
Where can I get one !
You, my friend, have obviously never had the "pleasure" of working with Forte. I had the utterly miserable misfortune to spend a year on an all forte project at a large US Tire company from the very begining to the intial deployment of the software to the users.
And it sucked beyound belief.
The "IDE" that forte provided was a piece of shit (and that's putting it mildly). It was quirky to develop in, ungodly slow, resource intensive, brain dead peice of heaping crap.
Our CS intern that we got on the project quickly renamed the the language to Forte Objected Oriented Langauge (FOOL).
Deploying to 5, that's right folks, 5 machines was an utter nightmare, and took 3 of us to keep it going.
On the other hand you could partition the application to run on different machines. Useful of course, when the application actually ran.
From a language standpoint, the "plumbing" was indeed hidden from you. It was absurdly easy to talk to objects cross process or cross machines.
The problem was everything else was an amateurish piece of shit that rarely worked the way Forte claimed it did. And we had a consultant working with us to iron out all the problems (at $250 an hour, thank you very much).
And when we finally got it to run, the app ran SO slowly, that he had to hand massage the generated C++ (TOOL/FOOL doesn't itself get compiled - it generated C++ which was then compiled) and add a whole bunch of custom stuff, of course none of this was explained or documented, it Just Worked (well sort of - by the time I left the project, the users HATED the app so much because it was clunky and slow, that they never really used it - it was faster to calculate the retirement calcs by hand than to deal with the app).
So, yeah, Forte was a real good platform to base stuff off of.
Pfft!
Way to go Dave! This is hilarious, a pity we can't do the same thing with the RIAA or MPAA numbers!