If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java.
You don't need to check the bounds of every single array all the time. This is why STL puts some trust in you. It's easy as hell to make STL-code that compiles and crashes and burns, but it's obviously for a reason. Constantly re-checking data that should be validated elsewhere, relying on exceptions to communicate an error message is extremely inefficient. That's why it's not done in C++. Writing operator[] with bounds-checking has got to be one of the simplest things in the world in C++.
Faster when run how many iterations under hotspot? 1? 10? 100?
There it is again, the cluthing-at-straws "somewhere down the line it will be faster" that is so typical from a member of the Java community. What does it take to actually produce some code and a supporting environment that actually outperforms some C++-code and is not just a castle in the clouds?
For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object, be it an ArrayList or a linked list, so in the Real World(tm) this is rarely an issue. Additionally, Java 1.5 has templates so it is a moot point.
Java 1.5 doesn't have templates, it has generics. Generics in Java are not much more than autocasting and autoboxing; basically two constructs that introduce even more runtime overhead. It also has a number of other shortcomings, like the inability to tell the difference between a List<JavaCoders> and a List<Donkeys>, and frankly so have I.
C# 2.0 at least makes a decent attempt to get this right, but falls a little short if you're used to C++ templates. In C++/CLI you can have both and should be a happy camper.
The point the original poster was trying to make, however, is that C++ templates are better than Java generics because they lend themselves to implementing generic algorithms. Being how you're a C++ coder, you should understand this.
The HotSpot will in time be faster than C++ is an interesting argument, and while it's not illogical or directly wrong, it's unlikely.
The typical argumentation goes along the lines of "in Java, we can monitor the program at runtime to do specialized optimization".
Well, guess what, you can do the same thing in C++. You simply profile the code with live production data and recompile using the profiling reports.
It might not be functionally equivalent, but you have the benefit of knowing exactly what binaries you are deploying and you need not worry that time will be spent optimizing at runtime things that can be perfectly well optimized ahead of time.
I've actually only ever seen one program that outperformed a C/C++-implementation, which was a highly recursive fibonacci-calculator; implementation extremely naive and favoured Java. Implementing the same thing in "real C++" allowed the program to solve the same thing in constant time (at compiletime using template metaprogramming), and even then the compiletime was more than 10 times faster than the Java execution.
I am, however, as always interested in pointers to other pieces of code that isolates a situation where Java outperforms C++, immediately or over time.
I believe language shapes thought and the other way around.
Language shapes thought faster than thought shapes language, at least with the languages most people speak today; languages that have been developed for many, many years.
To me, it seems that we're standing on the shoulders of giants, families of problems have been identified, components have been named and transferred to language.
You'll see this when you start learning about a new topic in school. You learn the meaning of a number of domain-specific concepts. The reason these special words exists is that they're easier to manipulate than "layman's terms". The domain-specific language makes the domain easier to control, understand and manipulate.
This is also extremely visible in programming. Compare good old basic with linenumbers to modern languages, and try to imagine how you went about solving your problems in the past. Picking up a new programming language always seems to make me aware of at least one elegant way of solving a problem that I didn't know of before, because it's typically idiomatic of that language, it's a part of the day-to-day vocabulary.
Also, when doing modern OO analysis/design, it's surprising how often a problem solves itself once you come up with the right names for things. Very often, I find myself "knowing" the solution to a problem, but I always gain more insight into it by putting it into words, correctly naming the different components and interactions.
I wouldn't really say that the algorithm is different, it is just implemented in an environment that defines a hard constraint; it's always deterministic what output values are produced from a set of input values (no side-effects). This means a template can (and will) be expanded only once, and there is implicit caching.
This could be automatically done by both Java and C if they either could detect that there was no side effects, or they provided explicit syntax for it.
Could this indeed be why the Java runtime is faster than the gcc-code, automatic caching of output for a given set of input after some analysis on whether the function has side-effects?
Now, we all know C++ template metaprogramming will kick both Java and C's ass, but look at these interesting numbers:
larsde@debian:~$ time g++ -o fibmp fibmp.cpp -ftemplate-depth-100
real 0m2.894s user 0m2.790s sys 0m0.110s larsde@debian:~$ time./fibmp Fib: 1134903170
real 0m0.024s user 0m0.010s sys 0m0.000s larsde@debian:~$ time./fib Fib: 1134903170
real 0m57.769s user 0m57.720s sys 0m0.000s larsde@debian:~$ time java fib Fib: 1134903170
real 1m23.296s user 1m12.740s sys 0m0.100s larsde@debian:~$
There are four different programs being run here; "fib", which is a C++-program compiled with icc (Intel's C++-compiler), it beats java slightly (gcc on the same program is beaten by java as you originally indicate).
Running the fib-program takes ~58 seconds.
Now, the "java fib"-program is your function with a class and a main-function, it completes in 1 minute 23 seconds (but still beats the gcc-version, which isn't listed).
Now, for the interesting part: Running the compiled C++ metaprogram takes 0.024 seconds, which is not much, but still, it doesn't really do anything.
But look at the time spent compiling the metaprogram (where the actual calculation of the fib is carried out);
2.894seconds, which hands down beats both the C and Java-implementation.
So the total time for calculating the fib(45)-call in C++ with template metaprogramming including compilation is ~3 seconds.
Which indicates that the suggested way of doing it is so amazingly inefficient that one would save over a minute spawning g++ from Java using JNI.
Interestingly enough, this is something C++ would do at constant time using template metaprogramming (that is, expand the fib(45)-call to the resulting value at compile time). So I guess the discussion would benefit from a real-life example.;)
Analysis indicates that I am 99.9% likely to want to see ZhAng Ziyi in a plastic raincoat going down on Jennifer Lopez in ripped SCUBA gear (or the reverse, I'm not picky.) Now, if "the Brain" can FIND such porn for me instead of just making playlists, I might get some use out of it! Teach the damn thing to know when the women are fat and skanky so it won't download lousy porn, and I'll be sold.
Let's call it "The other, only slightly smaller Brain".
This is a great book which concisely explains state charts, their application and the numerous ways to implement them.
The illustrated examples of how hierarchical state machines really work are great for anyone looking to really utilize the concepts embraced by among others the UML to their full potential.
That said, the approach used by the supplied framework is not without flaws (exception safety versus Run-To-Completion discrete steps, etc), as pointed out in discussions on USENET. Whether it fits your need will ultimately be a decision you have to make for yourself, no framework will fit every occasion. The main strength of the book, IMHO, lies in the clear explanations of concepts and implementation, not only in the supplied framework.
As a sidenote: I misplaced the CD that comes with the book and emailed the author. He replied within the hour, and he had put the full CD zipped on an FTP-site and provided me with a login/password. You've gotta love that kind of response.
All in all, I pretty much agree with the review and think the book deserves a strong 9/10. I recommend it to anyone who wants to rethink the way they currently write applications.
STL's sort is almost always faster than quicksort. This is because the sort can be implemented without doing a function call (even with user-defined compare-functions).
From "Efficient STL" (Scott Meyers), sort is measured to be upto 670% faster than C quicksort. This is from a couple of real-life tests Meyers did, and is by no means an absolute number on STL's sort speed.
The STL is sweet, it produces efficient code, than the source speak for itself; tasks like this are very hard to screw up.
$50 dollars can hardly be spent on anything more worthwhile than Tribes 2. It's a great game, and it's been released. I don't think all the servers out there will disappear.
I mentioned it before in this discussion forum, but just to make sure everybody that wonders gets it;
the SDK comes with compilers for C/C++ and pJava.
The compiler is based on GCC, and will be immediately familiar to most of you.
You can write VP is you want to take advantage of the extra features it gives (OO, Exception handling) or don't want to wait for long C-compiles when you can write with VP, which I personally find equally expressive, but takes a lot shorter to assemble.
Ok, I've posted a snapshot of the code I was talking about. Don't even try to assemble or run it unless you know what you're doing, it's by no means finished, and a proper release will follow shortly.
osmoserv.cpp - A C++ implementation of the framework
osmoserv.hpp - and corresponding headerfiles
osmoserv.asm - An assembly-implementation that does a lot of the same that the C++ file does.
It should be fairly easy for those of you who know C/C++ to get the basic idea.
Basically, the program reads a configuration, creates a socket, binds it and listens to it. The mainloop in the assembly-version needs to be rewritten to use select. Also, the assembly-version does not spawn children at the current time.
Again, neither the C++ or VP-version of this tool is done, it will be released in due time and under GNU GPL. This code is for illustrational purposes.
BTW, the C++-file compiles to roughly 4KB of executable code on the Amiga SDK.
Also, it would be nice if Amiga would allow some of the example files shipped with the SDK to be posted publicly, to give people an indication of the SDK and APIs.
You seem to be missing the point. The SDK is released with compilers for C/C++. It does come with a development tools for Java. Python has been ported by third parties. REBOL and Arexx is already available for it.
There is no do-it-all-in-assembly about the Amiga SDK.
On the other hand, if you decide to write assembly, it's just not painful anymore. As a matter of fact, I prefer programming VP over straight C; VP has more features, and can be programmed "as clean". The beauty of it all is that you have full access to the C-library and major parts of POSIX, in addition to a set of system specific functions.
If anybody wants more examples of VP code as illustration, I'll be happy to provide them.
On the other hand, while VP is easy to write code for, please don't forget that most people will never (want to/have to) write code in it directly.
Also, you were dissin' the opcodes; most of what you see isn't opcodes but macros. I'm sure a list of actual opcodes can be produced as a basis for futher discussion.
BTW, yesternight I sat down to write a small server application that spawns off child processes when connected to. 20 hours later it's a 1088 byte executable. I had some problems along the way, so I decided to also implement it in C++; the VP-"binary" turned out to be about 3520 bytes. (And yes, this executable also reads a configuration.) Just a small sidenote to illustrate how lean the system is, and to urge all of you to start writing Internet apps in assembly.;) It's an old buzzword just waiting to be reborn.
Ease of installation is one of Linux' strengths; 5 out of 6 Linux installations are IMHO easier to install than most incarnations of windows. Debian is probably the one I've encountered recently that isn't (but it happens to be my distribution of choice once it's installed).
Ease of installation was an issue a year ago, a lot of work has gone into it, and as far as I'm concerned, Linux currently leaves Windows in the dust. If you disagree, try Mandrake 7.1 or any new Red Hat.
My experience is that when I'm blocked, my mind is struggling with some big "problem" ahead. I'm sometimes hesitant to start typing until the whole problem has been solved upfront.
Sometimes I'm too blocked to even fire up my editor, just the thought of it drains me.
The simplest way for me is usually to just to start playing with the current version of the project. Then I usually go to the parts of the code that I know really well, review it and try to improve on it.
Playing with stuff you know really well is seldom very threatening, and it's gotten me started again a number of times.
Another simple way to get past the coding block, is to walk over to your boss and tell him that you'll have a working version on his desk by close of business today.
He'll be impressed, and you'll be coding 'til your fingers fall off.
The sad truth of the matter is that chances are that the next killer app will be a windows app. The way I see it, chances are also that it will be based on MFC or some proprietary GUI based on Win32 API calls.
Why? There are more professional developers on windows. Why MFC? It's not very expensive to use, is it? (In terms of shelling out cash.)
If Qt had a more liberal license on Windows, maybe it would be used instead. That would have made it easy to port to Linux in the future. I don't imagine porting MFC apps is very straight forward.
Another thing, I don't think I've ever met a person who bought Windows. Well, once, but he was a moron. Obviosly, most people get their computer with Windows preloaded, without ever knowing that there is an alternative.
Speaking of Troll Tech sucking MS developer market dry, I don't know, man. I don't think I've ever used a Qt application for Windows, and to be honest; if this is the path Troll Tech is choosing I don't think I ever will.
I've earlier stated that I believe Open Source software for Windows will benefit the Linux community because availability of software on more platforms will make it more a matter of choosing the best OS, not the OS that has a certain application that you just _need_ to run.
Troll Tech freeing Qt for Open Source Windows development would benefit all Open Source development, and thus the Linux community.
Of course Photoshop for Linux would help, even though it would obviosly be an addition to the commercial software available for Linux.
I'm a big fan of good software, commercial or free.
Thing is, Gimp is already ported to Windows, and as a free alternative to Photoshop, it goes a long way, IMHO it annihilates Paint Shop Pro and crap like that. Stability is of course an issue, but lots of good things will happen with the porting of GTK+ to windows (currently using MSVC++, but soon to also arrive in a cygwin incarnation).
I don't like windows more than the next guy, I just feel that any effort to make cross platform more available is an effort to promote Linux. If you have the same applications on your platforms, you'll choose OS based on the quality of the OS. Today, most people using windows, use it because of availability of applications.
If people use PHP with an Apache http server on Windows NT, they're bound to wake up and smell the Cherry Coke one day. There's no reason why they should be running NT at all. That's thanks to people giving Windows users alternatives to IIS and ASP, for instance.
I agree that $1000+ isn't very much of a price tag for serious, commercial software projects. It doesn't justify not having the option to use Qt for OpenSource projects on Windows, IMO.
Your last paragraph I don't understand, however. Cygwin can be used freely for making free, opensource products, Qt cannot. What are you getting at? I more than willing to pay the price if I ever decide on using Qt for a commercial product, as am I with the cygnus products.
I admit that I'm pleased with some companies releasing their products for free for Linux while they have commercial counterparts for other OSes. That benefits the Linux community. "Crippling" Qt by narrowing the fields where it can be used for creating free software, however, isn't what I usually consider a good idea.
Thanks to cygnus, BTW, for making the hell of being stuck in Win NT all day a little less. You guys are sweet.
Slashdot Mirror
Are you f-ing kidding me?
This is easy: (C#, P/Invoke, supported by
You don't need to check the bounds of every single array all the time. This is why STL puts some trust in you. It's easy as hell to make STL-code that compiles and crashes and burns, but it's obviously for a reason. Constantly re-checking data that should be validated elsewhere, relying on exceptions to communicate an error message is extremely inefficient. That's why it's not done in C++. Writing operator[] with bounds-checking has got to be one of the simplest things in the world in C++.
There it is again, the cluthing-at-straws "somewhere down the line it will be faster" that is so typical from a member of the Java community. What does it take to actually produce some code and a supporting environment that actually outperforms some C++-code and is not just a castle in the clouds?
Java 1.5 doesn't have templates, it has generics. Generics in Java are not much more than autocasting and autoboxing; basically two constructs that introduce even more runtime overhead. It also has a number of other shortcomings, like the inability to tell the difference between a List<JavaCoders> and a List<Donkeys>, and frankly so have I.
C# 2.0 at least makes a decent attempt to get this right, but falls a little short if you're used to C++ templates. In C++/CLI you can have both and should be a happy camper.
The point the original poster was trying to make, however, is that C++ templates are better than Java generics because they lend themselves to implementing generic algorithms. Being how you're a C++ coder, you should understand this.
The HotSpot will in time be faster than C++ is an interesting argument, and while it's not illogical or directly wrong, it's unlikely.
The typical argumentation goes along the lines of "in Java, we can monitor the program at runtime to do specialized optimization".
Well, guess what, you can do the same thing in C++. You simply profile the code with live production data and recompile using the profiling reports.
It might not be functionally equivalent, but you have the benefit of knowing exactly what binaries you are deploying and you need not worry that time will be spent optimizing at runtime things that can be perfectly well optimized ahead of time.
I've actually only ever seen one program that outperformed a C/C++-implementation, which was a highly recursive fibonacci-calculator; implementation extremely naive and favoured Java. Implementing the same thing in "real C++" allowed the program to solve the same thing in constant time (at compiletime using template metaprogramming), and even then the compiletime was more than 10 times faster than the Java execution.
I am, however, as always interested in pointers to other pieces of code that isolates a situation where Java outperforms C++, immediately or over time.
So...
"Huh-huh, Beavis, look. It's written in COBOL," will one day be "Huh-huh, Beaviz0id, look. It's written in Java. Jaaah-vaaar."
For many of us, I guess that day is already here.
I believe language shapes thought and the other way around.
Language shapes thought faster than thought shapes language, at least with the languages most people speak today; languages that have been developed for many, many years.
To me, it seems that we're standing on the shoulders of giants, families of problems have been identified, components have been named and transferred to language.
You'll see this when you start learning about a new topic in school. You learn the meaning of a number of domain-specific concepts. The reason these special words exists is that they're easier to manipulate than "layman's terms". The domain-specific language makes the domain easier to control, understand and manipulate.
This is also extremely visible in programming. Compare good old basic with linenumbers to modern languages, and try to imagine how you went about solving your problems in the past. Picking up a new programming language always seems to make me aware of at least one elegant way of solving a problem that I didn't know of before, because it's typically idiomatic of that language, it's a part of the day-to-day vocabulary.
Also, when doing modern OO analysis/design, it's surprising how often a problem solves itself once you come up with the right names for things. Very often, I find myself "knowing" the solution to a problem, but I always gain more insight into it by putting it into words, correctly naming the different components and interactions.
Speaking of which, don't you just love Microsoft's technologies "COM" and ".NET"? Try googling for that.
If solid state, you should not underestimate the bandwidth of a truck full of these chips.
I wouldn't really say that the algorithm is different, it is just implemented in an environment that defines a hard constraint; it's always deterministic what output values are produced from a set of input values (no side-effects). This means a template can (and will) be expanded only once, and there is implicit caching.
This could be automatically done by both Java and C if they either could detect that there was no side effects, or they provided explicit syntax for it.
Could this indeed be why the Java runtime is faster than the gcc-code, automatic caching of output for a given set of input after some analysis on whether the function has side-effects?
Running the fib-program takes ~58 seconds.
Now, the "java fib"-program is your function with a class and a main-function, it completes in 1 minute 23 seconds (but still beats the gcc-version, which isn't listed).
Now, for the interesting part: Running the compiled C++ metaprogram takes 0.024 seconds, which is not much, but still, it doesn't really do anything.
But look at the time spent compiling the metaprogram (where the actual calculation of the fib is carried out);
2.894seconds, which hands down beats both the C and Java-implementation.
So the total time for calculating the fib(45)-call in C++ with template metaprogramming including compilation is ~3 seconds.
Which indicates that the suggested way of doing it is so amazingly inefficient that one would save over a minute spawning g++ from Java using JNI.
Draw your own conclusions.
Interestingly enough, this is something C++ would do at constant time using template metaprogramming (that is, expand the fib(45)-call to the resulting value at compile time). So I guess the discussion would benefit from a real-life example. ;)
I just got an upgrade from NVIDIA, and it seems to fix the problem.
Let's call it "The other, only slightly smaller Brain".
--
O<
This is super cool. If you don't like it or don't have the CPU or graphics card for it, don't use it.
Every cycle not used is lost forever! Remember that.
(The same goes with bandwidth.)
This is a great book which concisely explains state charts, their application and the numerous ways to implement them.
The illustrated examples of how hierarchical state machines really work are great for anyone looking to really utilize the concepts embraced by among others the UML to their full potential.
That said, the approach used by the supplied framework is not without flaws (exception safety versus Run-To-Completion discrete steps, etc), as pointed out in discussions on USENET. Whether it fits your need will ultimately be a decision you have to make for yourself, no framework will fit every occasion. The main strength of the book, IMHO, lies in the clear explanations of concepts and implementation, not only in the supplied framework.
As a sidenote: I misplaced the CD that comes with the book and emailed the author. He replied within the hour, and he had put the full CD zipped on an FTP-site and provided me with a login/password. You've gotta love that kind of response.
All in all, I pretty much agree with the review and think the book deserves a strong 9/10. I recommend it to anyone who wants to rethink the way they currently write applications.
If the public will "buy" MP3 and DiVX, surely Theora is a marketable enough name.
STL's sort is almost always faster than quicksort. This is because the sort can be implemented without doing a function call (even with user-defined compare-functions).
From "Efficient STL" (Scott Meyers), sort is measured to be upto 670% faster than C quicksort. This is from a couple of real-life tests Meyers did, and is by no means an absolute number on STL's sort speed.
The STL is sweet, it produces efficient code, than the source speak for itself; tasks like this are very hard to screw up.
eeGN
$50 dollars can hardly be spent on anything more worthwhile than Tribes 2. It's a great game, and it's been released. I don't think all the servers out there will disappear.
I mentioned it before in this discussion forum, but just to make sure everybody that wonders gets it;
the SDK comes with compilers for C/C++ and pJava.
The compiler is based on GCC, and will be immediately familiar to most of you.
You can write VP is you want to take advantage of the extra features it gives (OO, Exception handling) or don't want to wait for long C-compiles when you can write with VP, which I personally find equally expressive, but takes a lot shorter to assemble.
Ok, I've posted a snapshot of the code I was talking about. Don't even try to assemble or run it unless you know what you're doing, it's by no means finished, and a proper release will follow shortly.
l es/
For those of you interested in VP, look here:
http://www.redloop.com/larsde/slashdot_codesamp
The directory contains three files;
osmoserv.cpp - A C++ implementation of the framework
osmoserv.hpp - and corresponding headerfiles
osmoserv.asm - An assembly-implementation that does a lot of the same that the C++ file does.
It should be fairly easy for those of you who know C/C++ to get the basic idea.
Basically, the program reads a configuration, creates a socket, binds it and listens to it. The mainloop in the assembly-version needs to be rewritten to use select. Also, the assembly-version does not spawn children at the current time.
Again, neither the C++ or VP-version of this tool is done, it will be released in due time and under GNU GPL. This code is for illustrational purposes.
BTW, the C++-file compiles to roughly 4KB of executable code on the Amiga SDK.
Also, it would be nice if Amiga would allow some of the example files shipped with the SDK to be posted publicly, to give people an indication of the SDK and APIs.
This is a Great idea.
You'll be happy to know that that's exactly what they do; the SDK ships with compilers for C/C++ and pJava.
You seem to be missing the point. The SDK is released with compilers for C/C++. It does come with a development tools for Java. Python has been ported by third parties. REBOL and Arexx is already available for it.
;) It's an old buzzword just waiting to be reborn.
There is no do-it-all-in-assembly about the Amiga SDK.
On the other hand, if you decide to write assembly, it's just not painful anymore. As a matter of fact, I prefer programming VP over straight C; VP has more features, and can be programmed "as clean". The beauty of it all is that you have full access to the C-library and major parts of POSIX, in addition to a set of system specific functions.
If anybody wants more examples of VP code as illustration, I'll be happy to provide them.
On the other hand, while VP is easy to write code for, please don't forget that most people will never (want to/have to) write code in it directly.
Also, you were dissin' the opcodes; most of what you see isn't opcodes but macros. I'm sure a list of actual opcodes can be produced as a basis for futher discussion.
BTW, yesternight I sat down to write a small server application that spawns off child processes when connected to. 20 hours later it's a 1088 byte executable. I had some problems along the way, so I decided to also implement it in C++; the VP-"binary" turned out to be about 3520 bytes. (And yes, this executable also reads a configuration.) Just a small sidenote to illustrate how lean the system is, and to urge all of you to start writing Internet apps in assembly.
Ease of installation was an issue a year ago, a lot of work has gone into it, and as far as I'm concerned, Linux currently leaves Windows in the dust. If you disagree, try Mandrake 7.1 or any new Red Hat.
My experience is that when I'm blocked, my mind is struggling with some big "problem" ahead. I'm sometimes hesitant to start typing until the whole problem has been solved upfront.
Sometimes I'm too blocked to even fire up my editor, just the thought of it drains me.
The simplest way for me is usually to just to start playing with the current version of the project. Then I usually go to the parts of the code that I know really well, review it and try to improve on it.
Playing with stuff you know really well is seldom very threatening, and it's gotten me started again a number of times.
Another simple way to get past the coding block, is to walk over to your boss and tell him that you'll have a working version on his desk by close of business today.
He'll be impressed, and you'll be coding 'til your fingers fall off.
The sad truth of the matter is that chances are that the next killer app will be a windows app. The way I see it, chances are also that it will be based on MFC or some proprietary GUI based on Win32 API calls.
Why? There are more professional developers on windows. Why MFC? It's not very expensive to use, is it? (In terms of shelling out cash.)
If Qt had a more liberal license on Windows, maybe it would be used instead. That would have made it easy to port to Linux in the future. I don't imagine porting MFC apps is very straight forward.
Another thing, I don't think I've ever met a person who bought Windows. Well, once, but he was a moron. Obviosly, most people get their computer with Windows preloaded, without ever knowing that there is an alternative.
Speaking of Troll Tech sucking MS developer market dry, I don't know, man. I don't think I've ever used a Qt application for Windows, and to be honest; if this is the path Troll Tech is choosing I don't think I ever will.
I've earlier stated that I believe Open Source software for Windows will benefit the Linux community because availability of software on more platforms will make it more a matter of choosing the best OS, not the OS that has a certain application that you just _need_ to run.
Troll Tech freeing Qt for Open Source Windows development would benefit all Open Source development, and thus the Linux community.
Of course Photoshop for Linux would help, even though it would obviosly be an addition to the commercial software available for Linux.
I'm a big fan of good software, commercial or free.
Thing is, Gimp is already ported to Windows, and as a free alternative to Photoshop, it goes a long way, IMHO it annihilates Paint Shop Pro and crap like that. Stability is of course an issue, but lots of good things will happen with the porting of GTK+ to windows (currently using MSVC++, but soon to also arrive in a cygwin incarnation).
I don't like windows more than the next guy, I just feel that any effort to make cross platform more available is an effort to promote Linux. If you have the same applications on your platforms, you'll choose OS based on the quality of the OS. Today, most people using windows, use it because of availability of applications.
If people use PHP with an Apache http server on Windows NT, they're bound to wake up and smell the Cherry Coke one day. There's no reason why they should be running NT at all. That's thanks to people giving Windows users alternatives to IIS and ASP, for instance.
I agree that $1000+ isn't very much of a price tag for serious, commercial software projects. It doesn't justify not having the option to use Qt for OpenSource projects on Windows, IMO.
Your last paragraph I don't understand, however. Cygwin can be used freely for making free, opensource products, Qt cannot. What are you getting at? I more than willing to pay the price if I ever decide on using Qt for a commercial product, as am I with the cygnus products.
I admit that I'm pleased with some companies releasing their products for free for Linux while they have commercial counterparts for other OSes. That benefits the Linux community. "Crippling" Qt by narrowing the fields where it can be used for creating free software, however, isn't what I usually consider a good idea.
Thanks to cygnus, BTW, for making the hell of being stuck in Win NT all day a little less. You guys are sweet.