1) Winzip 2) Adobe Acrobat Reader (you DO read docs for the rest of the software you are installing, right?) 3) driver updates 5) antivirus software 6) Lavasoft adaware 7) ssh.com windows ssh client 8) putty 9) Mozilla and friends 10) OpenOffice
Yes, I agree. I think it is understandably hard for people to accept the term "libertarian socialist", since those terms would superficially seem to be contradictory. Socialism is a very vague and generic term but some people have built up an instinctual reflex against it (or for it for that matter) without actually digging deeper.
Ok, maybe that statement doesn't surprise some of you, but it did surprise me, when I hit on this eloquent article that was printed in the first issue of Monthly Review. I was not aware of this publication, or of Einsteins political views until I stumbled on this (I don't remember how I did now...).
Anyway, this was something never mentioned at least in my primary and secondary education.
You can also add to that list George Orwell, which although it may sound counterintuitive, was a staunch Socialist to his death, fighting fascists in Spain, even though during his middle and later life his observation of Soviet Russia made him very cynical about the prospects and practicability of socialism (at least as far as I understood).
Anyway, that opened my mind a bit (mostly because the notion of Einstein we are lead to believe is one of a absent-minded nonchalant apolitical genius...if I could know so little about the core of such a major figure what else wasn't I taught?).
Why are you saying it ? there is nothing wrong with Linux. We use JDeveloper, and it is the same in Linux and Windows.
The problems of deploying your code in another platform its because C++ does not define a compiler interface and an ABI. If it did, one would write the compilation scripts for one machine, then run them on another. It would be just an installation step.
I can't understand what you are saying here or how it either agrees or disagrees with what I said. It would be a huge waste of effort to try to get our developers to develop on the target platform (which currently is AIX and Solaris). Even running a compile or install script is a waste of effort if they can currently already drop in a JSP, or drop in a jar file (through webdav or sftp, etc.), and then just restart their servlet engine (again through a web interface).
that of constant dynamic casting and the virtual interfaces. Don't tell me that they don't make a difference.
I won't tell you they don't make a difference but I will tell you they don't make a difference that matters. Do you have benchmarks showing that it is in fact dynamic casting and virtual interfaces that is adding latency to Swing applications? I always presumed it was the depth of object hierarchy (not necessarily virtual interfaces but the amount of composition or extra logic), the probably less than optimal event/task system coupled with SLOW software painting instead of native widgets (which would presumably be backed more directly by hardware). I wonder how, for instance a more hardware-backed backend would fare, e.g. OpenGL, etc. I believe Sun demo'd this with "Looking Glass" but I have no idea how it performs.
What do you mean massive ? massive as in "have an extensive set of APIs" or massive as in "Everything is documented ?" and what kind of middleware can't be developed with C++ ? give me an example.
Yes. Both. A large and well-documented API. As for "what kind of middleware can't be developed with C++": if you don't already agree that Java provides a tradeoff between safety and power/performance, then there is no longer any need to continue this discussion. C++ would always be better for everything always. On the other hand, in the real world, real people use Java not because it is the fastest around but because it is simpler, more easily verifiable, cheaper, more reliable, and less prone to errors. If you don't believe this is a legitimate tradeoff then there is no point continuing - Java has no merits at all then.
Boost and Qt are 100% portable from one platform to another. The arguments you say are valid for C++ also.
Well, now there is the "Qt platform", maybe...but still, I see no support in the "Qt platform" for web applications and I certainly think that that is a significant "kind of middleware can't be developed with C++". So where is it, short of ASP/C#/.Net? No sane person is going to develop standard web applications in C++ when platforms like Java and.Net are around. Amazon, maybe, Ebay, maybe, due to sheer crushing load...anybody else?
But I am not comparing apples with oranges. I am comparing the core Java APIs with Qt, not the Java platform with Qt, which is not a valid comparison.
Whatever. Qt's widget set I will grant is nicer and faster than the widget set provided by the Java platform (Swing). Other than that I don't see performance as an issue in the rest of any of the libraries.
No, C++ is faster than Java. Qt justs makes it as easy as Java. You are confused.
Um. Duh. Qt is in C++ no? And therefore by deduction we find that the "Qt platform" is faster than a "Java platform".
Not only they are slow as hell, but the Java model of doing things does not help at all...it makes it very easy to introduce subtle bugs, d
But you've got to have the target platform, one way or another, due to differences in things outside Java, which affects Java. At least, that's what I've seen in our company: Linux Java apps are preferrably developed on Linux, because Windows behaves differently. But it may be an exception though, so you may have a point.
Nope. Not for us at least. While some savvy developers are starting to play around with Linux, the day to day development is all done on Windows and to a lesser extent Mac OS X. We do not develop on the target platform. If our developers had to use AIX as a development environment I think we would find a large chunk of our staff commit mass suicide (granted we are moving generally to Solaris...but still).
If users of your apps are frustrated by the delays, it is. Only for trivial apps this does not matter...in all other apps, it matters greatly....
Hey, spending all this time looking at JDeveloper trying to update the display would have been better spent coding.
Yes. I am willing to grant latency and startup as legitimate performance issues in the Java GUI platform. Swing is OK, but it is built upon another toolkit (AWT) and the API and object hierarchy is really bloated. I'm sure a better job could be done if starting from scratch again, but that is not feasible at this point (although there are side projects like SWT which use true native peers, and are MUCH FASTER).
But the main lure of Java is that is has a cross platform gui...by far the most important part of a library.
Well, that is where we are approaching this differently. For me, and for most Java developers, the allure of Java is certainly NOT the GUI. I don't know of any Java developer who is completely satisfied with Swing (or at least as satisfied as I gather Qt developers are with Qt). The main allure of Java is 1) massive, well documented platform for developing middleware and web applications (server side stuff) 2) portability, both in code/object as well as human skills (in that you can apply the same general knowledge to both server-side stuff and client side stuff, which makes our developers much more productive and cross trained... we don't need a C++ gui developer and a Java server developer).
I would not rank GUI anywhere near the main draws of Java. I have never heard anyone pick Java because of the GUI. There are other portable toolkits, notably WxWidgets (previously WxWindows) and Qt itself.
I think you are coming into the platform from using Qt and expecting to compare another platform based on widget toolkit. The discussion started like "Qt is not a platform like Java is a platform" and moved to "well Qt is a faster platform than Java". I'm willing to admit of course Qt is faster in the GUI realm, where it matters. But for most other things (i.e. not highly latency-sensitive) I stand by my statement that Java is fast enough (disk IO, network IO, text processing, etc. etc.).
I was not talking about that kind of profiling. I was talking about having all the program as one translation unit an optimize on the large scale.
Well, I'm not sure how this is different from what I described. The VM is a Virtual Machine, and as such, is aware of everything about the program. The article says:
"Generate profiles from running the executable/dll on real-world inputs, which are then used to assist the compiler in generating optimized code for the particular executable."
The only difference is that in modern Java VMs (let's just stick to Sun's for simplicity), this is done at *runtime* automatically. Bytecode is not all that optimized, and profile-driven-optimization (if that is what you want to call it now) does not necessarily optimized at the opcode level, but at the program level. This is exactly what the "hotspot" VM does. The only difference is that it will do it *each* time the program is
"And what do the core Java APIs have that Qt does not have ? you do not mention any example"
You're right I didn't mention, and I should consult the docs.... a little time passes... This is what I found: http://doc.trolltech.com/3.3/groups.html , and you are correct. To my surprise (and pleasure), comparing this to the Java core libraries, it seems mostly complete (at least compared to the standard edition, I don't see any web application stuff but I don't expect to either).
"Yes, but Qt apps are compiled once and are delivered as-is (in binary form);"
You're not saying accross processor architectures are you?
"If you compile a new web app every half an hour, the Java system is better. But how often is this the case ? not very often, especially in non-web apps."
For us, this actually turns out to be important, because it is an immense waste of time and money to have to also train developers on Unix and how to compile their application on Unix (which I presume would include common concepts, shell navigation, unixish build tools like make/automake/autopackage). Granted this situation would be different if either the processor architectures or operating systems were the same between development and production, and while Linux and Mac OS X provide this possibility, there are many real world reasons (one of which would be massive initial retraining and purchasing costs) to be able to support heterogenous processor architectures and operating systems among environments.
"But Qt is exactly that: 100% standard across all libraries. Once you have Qt, you don't need any other libs, nor you need to know anything about memory allocation techniques of other libs). Qt does everything."
Yes, as I found out...this is really cool, and I hope that this is sold not as "Hey, look we added a platform to Qt" but really as a seperate product so that even non-Qt C++ developers can use a standard platform. That would make C++ development much less painful IMHO.
"All other things, involve the freaking one-size-fits-all Object class: too much time is spent in casting, creating objects just to search collections, calling virtual interfaces, etc.I know it, because I've measured it in our apps."
I won't argue this.
"Then why our developers have a 2x increase in productivity when moving from JDeveloper 10.5 to Visual Studio.NET ? I will tell you why: because JDeveloper, written in Java, is 5 times slower than VS.NET."
Yes, a lot of these development environments are truly monsters. Don't get me wrong, I'm not saying Swing is great...there is a lot of room for improvement. I'm not saying that Java ISN'T slow at all...I'm not a zealot, I can see where it is obviously slow in various circumstances... my argument is that yes it may be slow, but on the whole it is not THAT relevant. What IS relevant to GUI is latency/responsivity (i'm not talking X context switches, or OS windowing system, I'm talking how fast a menu actually responds, etc.), and startup overhead. These are still areas Java can work on, in the GUI. These issues have little relevance to non-desktop applications. Startup time is still relevant to non-GUI (CLI) desktop apps. I don't think throughput is an issue.
"Java does not have profile-based compiling. It is something different than optimizing on the fly the compiled code."
Eh? The current breed of Java VMs include profiling compilers - the first popular implementation of which from Sun, was called HotSpot, because it found and optimized the hot spots you are talking about. Modern JITs don't just JIT once and forget it (I don't know, maybe.NET/Mono does this?) but they JIT (perhaps a fast, less-optimized version to aid startup), and then possiblye unJIT and reJIT many times over the lifetime of the application to adapt to how the program is running.
"Java can't do it, because it does not work like that."
Considering the prior situation in XFree86 was that developers themselves had very little overall control - I think, you know, actually giving developers (including those that happen to work for companies) some say in the project they are working on might be a good thing, huh?
"Java is mainly a toolkit, and you also get an environment to run the toolkit inside."
Let's say I agree with this premise. Even so, the Qt APIs/libraries could not possibly yet be considered as complete as the core Java APIs, or J2EE APIs (really just a collection of various "middleware" APIs including those for database access, rpc, and web application development)? Is Qt really going to come to the plate with a set of APIs as full as Java (and furthermore get a significant majority of C++ developers to adopt them as standard)? If so then perhaps I'll call it a "platform"... until then it is a (great!) widget toolkit with some miscellaneous nice libraries.
"Qt runs in almost every environment that has a C++ compiler"
Granted that other languages might be more source-portable than the Java platform...but the cool thing about Java is that I can compile it on my Mac OS X, or Windows desktop (with all the ease of use, etc., etc.) and deploy it onto industrial strength Unix, AIX, Sun cluster, Linux, etc. with drag and drop and NO recompilation. This is am IMMENSE development productivity win. If our developers had to recompile every fucking thing each time they migrated from development to test to production our productivity would plummet (for one thing, they would have to become fairly savvy users of every deployment environment, as well as their own local operating system). This tight development cycle is a huge win.
"So can Qt. Why do you say that Qt is not able to do it ?"
I think the point is that when you are running in a massive environment where reliability is key, a native language like C/C++ is a big freaking liability. No - everything cannot go down because of a segfault - not acceptable. Ok, I KNOW you can get Java to fail in other non-desirable ways, but the odds of failing so catastrophically and randomly are much lower in a language that simply does not allow you to make a common set of mistakes.
"Java programmers often do is that they forget to assign null to pointers. This has a big consequence: the virtual machine does not free unused objects as soon as possible."
I have not ever seen this ever be a problem. Garbage collection is a black box and is done according to whatever heuristics the garbage collector uses...sure it might "help" negligably to assign nulls but I have seen no effect either way. Perhaps in a REALLY garbage-collection-intensive program (where you are creating and destroying thousands of objects). If something is going out of scope then it's pointless to assign null. In other situations I suppose you could pre-emptively annull references that you think you might not need in the future but that is more a matter of how much heap you want to consume as the working set etc., it doesn't have any leak ramifications.
"If you use C++ properly, you shall not have memory leaks."
And if "using C++ properly" is more expensive than "using Java properly" for the same solution, then the argument is already forfeited.
"The use of templates, RAII, shared pointers, STL, and lots of other goodies C++ has, makes C++ programming better than Java in the long run (especially for big applications)."
Of course, everybody else needs to be using the same goodies or you have to learn their goodies and whoops maybe you didn't understand it as well as you thought you did. If the "goodies" where a standard set this might be a valid argument. There is immense value to me to know that I can download almost any Java project and not worry about how they manage memory, what type of smart pointers they use, what "goody" libraries they use to do this or that, since in Java a vast amount of common functionality is all standardized.
"Java programs are slower than C++"
Performance is no longer an issue.Latency surely is an issue in the GUI, and for intensive things like games (which is why you don't major adoption of Java for games). But observe the retail computing industry - c
Re:If We Use a Simple Syllogism...
on
A Taste of Qt 4
·
· Score: 1
Sadly anybody who has a cat and a computer already knows who owns who.
Re:Mono-Culture?
on
A Taste of Qt 4
·
· Score: 3, Informative
"Is there even one single non-trivial software project made with/on Mono?"
Given that Mono runs C#... just survey the landscape of.NET/CLR/C# apps and find out yourself.
Eclipse (one of the most popular [Java] developement environments) for one has been compiled to CLR bytecode and run on Mono. There is also an ASP engine written on Mono. Go check out the Mono site to see who use it. There are several companies that use it as a production environment.
Re:Directly against Java?
on
A Taste of Qt 4
·
· Score: 3, Insightful
"I really don't understand the parent post."
The difference is that Java is a true platform while QT is at the moment foremost a widget toolkit with a bunch of latecoming useful libraries bolted on. Not to knock it - I think one of the massive holes in the C++ "platform" (if you are going to act like it is one) is that it has had no standard set of libraries. The mantra is "write your own" or "use XYZ because that's most popular". That, a platform, does not make.
Seriously I think it's about time C++ got a platform, but to call some syntactic sugar plus some libraries a platform (or at least a platform even beginning to compare to Java in platform-ness) is silly.
And by the way, C++ is "enterprise ready" in the same way straight razors are "oral hygeine ready". Sure you can do it, but expect pain, bleeding, and embarrassment. These is not only my argument - survey the enterprise landscape... the only people using something like C++ for large web applications or middleware are either those that have 1) massive legacy investment 2) massive earth crushing load and performance requirements (e.g. ebay, amazon, etc.). Lastly just because you CAN do it, doesn't mean that it is necessarily a good idea. The market shows that C++ is very expensive to write and deploy (if you are going to go by salaries, etc.) for jobs which can be done equivalently in some other language.
Almost every body else is using some other-generation language, be it Java,.Net/CLR, php, whatever.
"Controllers considered Bounce an odd find because it did not resemble any of the other rocks in the crater's vicinity -- nor did it resemble anything seen before on Mars, they said....
Rather more than that. Bounce's chemical composition exactly matches that of a meteorite that hit the ground in Shergotty, India, on Aug. 25, 1865.
Called the Shergotty meteorite -- and the source name for a class of meteorites called shergottites -- its chemical composition is a "matching fingerprint" to Bounce, said David Grinspoon, professor of planetary science at the University of Colorado in Boulder.
The resemblance helps confirm something meteorite specialists and planetary scientists have suspected for more than two decades but until now have been unable to prove: Micro-bubbles of gas trapped in dozens of meteorites found on Earth -- including Shergotty -- match the recipe of Martian atmosphere so closely that they must have originated on Mars.
"There is a striking similarity in spectra," said Christian Schroeder, a rover science-team collaborator from the University of Mainz in Germany, which supplied both Mars rovers with Moessbauer spectrometers -- exceedingly sensitive instruments for identifying chemical compositions."
Since presumably the chances are not dependent, there is a chance that your first shuffle (or any other specific shuffle) actually will be in the original order.
Wrong. A banjo is best tuned with a Tin Whistle. That way you can break both of the goddamned things./me shakes fist at Irish for inventing the Tin Whistle and bringing it into my peaceful house
"If Java is GPLed, e it could not be used in an application that is not GPL compatible."
<lil' john>Huh?! Uh-what?!</lil' john>
When you write a typically Java application you DO NOT link to the JVM. The JVM interprets or runs your binary but is in no fashion linked to it in any way. Java is also late-binding, so even the libraries are not linked until they are actually used. There is absolutely NOTHING stopping a fully compliant GPL JVM (except maybe official Sun "compliance" stamp negotiations). Running your app on a GPL JVM carries zero obligations for your source code. Your source code never even interacts with the VM. You can compile Java source with Compiler Foo, and run it on JVM Bar, and the licenses of neither really have any affect on your app. The only thing that MIGHT have an affect on the license of your app is the core libraries and that is a very very gray area which I think Stallman has recently relented on. In the worst case, the Java core libraries would just be put under LGPL, while the JVM could remain GPL.
The only time the JVM license would matter is if you were trying to embed the JVM itself, and link it into your own program.
It's sort of like saying, "anything that runs on Linux must be GPL because the operating system binary loader is GPL".
I'm not sure exactly how Systrace works, but I imagine it works in one of two ways:
1) run BadApplication through a (OPTIONAL) special loader that intercepts system calls
2) run BadApplication through the standard system loader, system calls actually ENTER the kernel and are traced AT THAT POINT
The former is probably susceptible to typical userspace hacks, not to mention the fact that a user can simply AVOID using it.
"There is no more reason to include this with the base operating system than there is to include virus protection in the base OS."
That is fine with me as I clearly DO see a reason to "include virus protection in the base OS", and so do many others if you include Write/Execute stack/heap protection in "virus protection".
Why the hell not. The perception that security is bloat is one of the problems to begin with. It's not bloat, it's mandatory and critical to everything else.
"It's striking, however, that mobile-phone conversations are judged more negatively than loud conversations."
Well, they obviously can control that variable by simply exposing a control group to the PRESENCE of a mobile phone, and gauge the inherent negative reaction. They should have done the study with two people talking but one just HOLDING a mobile phone.
Symantec firewalls do in fact monitor and popup warning about port access (with options to allow/deny/always allow/always deny etc.). As far as I have seen it is just for ports.
However, what you are asking is a more general operating system sandbox security model. Putting this in a user-space application is dumb and pointless. The point is that operating systems themselves need this sort of model at a very low level, so that access to myriad system resources can be sandboxed in a well defined and intuitive manner (e.g. along the lines of Java security policy). I have seen various attempts at doing portions of this (chroot hacks, system call interception (openbsd I believe), mandatory access control), but haven't seen an entire model built. Maybe that's what mandatory access control is. Whatever it is, it needs to be at the operating system level, not just "hey why don't we throw all the security in McFirewall With Fries.
Slashdot Mirror
Oh, I forgot:
4) $$$!
1) Winzip
2) Adobe Acrobat Reader (you DO read docs for the rest of the software you are installing, right?)
3) driver updates
5) antivirus software
6) Lavasoft adaware
7) ssh.com windows ssh client
8) putty
9) Mozilla and friends
10) OpenOffice
Yes, I agree. I think it is understandably hard for people to accept the term "libertarian socialist", since those terms would superficially seem to be contradictory. Socialism is a very vague and generic term but some people have built up an instinctual reflex against it (or for it for that matter) without actually digging deeper.
Ok, maybe that statement doesn't surprise some of you, but it did surprise me, when I hit on this eloquent article that was printed in the first issue of Monthly Review. I was not aware of this publication, or of Einsteins political views until I stumbled on this (I don't remember how I did now...).
Anyway, this was something never mentioned at least in my primary and secondary education.
You can also add to that list George Orwell, which although it may sound counterintuitive, was a staunch Socialist to his death, fighting fascists in Spain, even though during his middle and later life his observation of Soviet Russia made him very cynical about the prospects and practicability of socialism (at least as far as I understood).
Anyway, that opened my mind a bit (mostly because the notion of Einstein we are lead to believe is one of a absent-minded nonchalant apolitical genius...if I could know so little about the core of such a major figure what else wasn't I taught?).
Hey you insensitive clod, gay people can 'breed'!
I can't understand what you are saying here or how it either agrees or disagrees with what I said. It would be a huge waste of effort to try to get our developers to develop on the target platform (which currently is AIX and Solaris). Even running a compile or install script is a waste of effort if they can currently already drop in a JSP, or drop in a jar file (through webdav or sftp, etc.), and then just restart their servlet engine (again through a web interface).
I won't tell you they don't make a difference but I will tell you they don't make a difference that matters. Do you have benchmarks showing that it is in fact dynamic casting and virtual interfaces that is adding latency to Swing applications? I always presumed it was the depth of object hierarchy (not necessarily virtual interfaces but the amount of composition or extra logic), the probably less than optimal event/task system coupled with SLOW software painting instead of native widgets (which would presumably be backed more directly by hardware). I wonder how, for instance a more hardware-backed backend would fare, e.g. OpenGL, etc. I believe Sun demo'd this with "Looking Glass" but I have no idea how it performs.
Yes. Both. A large and well-documented API. As for "what kind of middleware can't be developed with C++": if you don't already agree that Java provides a tradeoff between safety and power/performance, then there is no longer any need to continue this discussion. C++ would always be better for everything always. On the other hand, in the real world, real people use Java not because it is the fastest around but because it is simpler, more easily verifiable, cheaper, more reliable, and less prone to errors. If you don't believe this is a legitimate tradeoff then there is no point continuing - Java has no merits at all then.
Well, now there is the "Qt platform", maybe...but still, I see no support in the "Qt platform" for web applications and I certainly think that that is a significant "kind of middleware can't be developed with C++". So where is it, short of ASP/C#/.Net? No sane person is going to develop standard web applications in C++ when platforms like Java and .Net are around. Amazon, maybe, Ebay, maybe, due to sheer crushing load...anybody else?
Whatever. Qt's widget set I will grant is nicer and faster than the widget set provided by the Java platform (Swing). Other than that I don't see performance as an issue in the rest of any of the libraries.
Um. Duh. Qt is in C++ no? And therefore by deduction we find that the "Qt platform" is faster than a "Java platform".
Nope. Not for us at least. While some savvy developers are starting to play around with Linux, the day to day development is all done on Windows and to a lesser extent Mac OS X. We do not develop on the target platform. If our developers had to use AIX as a development environment I think we would find a large chunk of our staff commit mass suicide (granted we are moving generally to Solaris...but still).
Yes. I am willing to grant latency and startup as legitimate performance issues in the Java GUI platform. Swing is OK, but it is built upon another toolkit (AWT) and the API and object hierarchy is really bloated. I'm sure a better job could be done if starting from scratch again, but that is not feasible at this point (although there are side projects like SWT which use true native peers, and are MUCH FASTER).
Well, that is where we are approaching this differently. For me, and for most Java developers, the allure of Java is certainly NOT the GUI. I don't know of any Java developer who is completely satisfied with Swing (or at least as satisfied as I gather Qt developers are with Qt). The main allure of Java is 1) massive, well documented platform for developing middleware and web applications (server side stuff) 2) portability, both in code/object as well as human skills (in that you can apply the same general knowledge to both server-side stuff and client side stuff, which makes our developers much more productive and cross trained... we don't need a C++ gui developer and a Java server developer).
I would not rank GUI anywhere near the main draws of Java. I have never heard anyone pick Java because of the GUI. There are other portable toolkits, notably WxWidgets (previously WxWindows) and Qt itself.
I think you are coming into the platform from using Qt and expecting to compare another platform based on widget toolkit. The discussion started like "Qt is not a platform like Java is a platform" and moved to "well Qt is a faster platform than Java". I'm willing to admit of course Qt is faster in the GUI realm, where it matters. But for most other things (i.e. not highly latency-sensitive) I stand by my statement that Java is fast enough (disk IO, network IO, text processing, etc. etc.).
Well, I'm not sure how this is different from what I described. The VM is a Virtual Machine, and as such, is aware of everything about the program. The article says:
"Generate profiles from running the executable/dll on real-world inputs, which are then used to assist the compiler in generating optimized code for the particular executable."
The only difference is that in modern Java VMs (let's just stick to Sun's for simplicity), this is done at *runtime* automatically. Bytecode is not all that optimized, and profile-driven-optimization (if that is what you want to call it now) does not necessarily optimized at the opcode level, but at the program level. This is exactly what the "hotspot" VM does. The only difference is that it will do it *each* time the program is
"And what do the core Java APIs have that Qt does not have ? you do not mention any example"
... a little time passes... This is what I found: http://doc.trolltech.com/3.3/groups.html , and you are correct. To my surprise (and pleasure), comparing this to the Java core libraries, it seems mostly complete (at least compared to the standard edition, I don't see any web application stuff but I don't expect to either).
.NET ? I will tell you why: because JDeveloper, written in Java, is 5 times slower than VS.NET."
.NET/Mono does this?) but they JIT (perhaps a fast, less-optimized version to aid startup), and then possiblye unJIT and reJIT many times over the lifetime of the application to adapt to how the program is running.
You're right I didn't mention, and I should consult the docs.
"Yes, but Qt apps are compiled once and are delivered as-is (in binary form);"
You're not saying accross processor architectures are you?
"If you compile a new web app every half an hour, the Java system is better. But how often is this the case ? not very often, especially in non-web apps."
For us, this actually turns out to be important, because it is an immense waste of time and money to have to also train developers on Unix and how to compile their application on Unix (which I presume would include common concepts, shell navigation, unixish build tools like make/automake/autopackage). Granted this situation would be different if either the processor architectures or operating systems were the same between development and production, and while Linux and Mac OS X provide this possibility, there are many real world reasons (one of which would be massive initial retraining and purchasing costs) to be able to support heterogenous processor architectures and operating systems among environments.
"But Qt is exactly that: 100% standard across all libraries. Once you have Qt, you don't need any other libs, nor you need to know anything about memory allocation techniques of other libs). Qt does everything."
Yes, as I found out...this is really cool, and I hope that this is sold not as "Hey, look we added a platform to Qt" but really as a seperate product so that even non-Qt C++ developers can use a standard platform. That would make C++ development much less painful IMHO.
"All other things, involve the freaking one-size-fits-all Object class: too much time is spent in casting, creating objects just to search collections, calling virtual interfaces, etc.I know it, because I've measured it in our apps."
I won't argue this.
"Then why our developers have a 2x increase in productivity when moving from JDeveloper 10.5 to Visual Studio
Yes, a lot of these development environments are truly monsters. Don't get me wrong, I'm not saying Swing is great...there is a lot of room for improvement. I'm not saying that Java ISN'T slow at all...I'm not a zealot, I can see where it is obviously slow in various circumstances... my argument is that yes it may be slow, but on the whole it is not THAT relevant. What IS relevant to GUI is latency/responsivity (i'm not talking X context switches, or OS windowing system, I'm talking how fast a menu actually responds, etc.), and startup overhead. These are still areas Java can work on, in the GUI. These issues have little relevance to non-desktop applications. Startup time is still relevant to non-GUI (CLI) desktop apps. I don't think throughput is an issue.
"Java does not have profile-based compiling. It is something different than optimizing on the fly the compiled code."
Eh? The current breed of Java VMs include profiling compilers - the first popular implementation of which from Sun, was called HotSpot, because it found and optimized the hot spots you are talking about. Modern JITs don't just JIT once and forget it (I don't know, maybe
"Java can't do it, because it does not work like that."
Um, it
Summer comes again
Trolls and dorks proliferate:
we must save haiku!
Joke Haiku is bad
Disrespectful and stupid:
just go kill yourself
You're missing the point
if you think that joke haiku is
not self-mocking
Banality is
used to mock austerity:
a glorious cause
You're right this is fun
I could go on forever:
you made a monster
Considering the prior situation in XFree86 was that developers themselves had very little overall control - I think, you know, actually giving developers (including those that happen to work for companies) some say in the project they are working on might be a good thing, huh?
Doesn't Mac OS have full JDK 1.4+ support by now?
"Java is mainly a toolkit, and you also get an environment to run the toolkit inside."
Let's say I agree with this premise. Even so, the Qt APIs/libraries could not possibly yet be considered as complete as the core Java APIs, or J2EE APIs (really just a collection of various "middleware" APIs including those for database access, rpc, and web application development)? Is Qt really going to come to the plate with a set of APIs as full as Java (and furthermore get a significant majority of C++ developers to adopt them as standard)? If so then perhaps I'll call it a "platform"... until then it is a (great!) widget toolkit with some miscellaneous nice libraries.
"Qt runs in almost every environment that has a C++ compiler"
Granted that other languages might be more source-portable than the Java platform...but the cool thing about Java is that I can compile it on my Mac OS X, or Windows desktop (with all the ease of use, etc., etc.) and deploy it onto industrial strength Unix, AIX, Sun cluster, Linux, etc. with drag and drop and NO recompilation. This is am IMMENSE development productivity win. If our developers had to recompile every fucking thing each time they migrated from development to test to production our productivity would plummet (for one thing, they would have to become fairly savvy users of every deployment environment, as well as their own local operating system). This tight development cycle is a huge win.
"So can Qt. Why do you say that Qt is not able to do it ?"
I think the point is that when you are running in a massive environment where reliability is key, a native language like C/C++ is a big freaking liability. No - everything cannot go down because of a segfault - not acceptable. Ok, I KNOW you can get Java to fail in other non-desirable ways, but the odds of failing so catastrophically and randomly are much lower in a language that simply does not allow you to make a common set of mistakes.
"Java programmers often do is that they forget to assign null to pointers. This has a big consequence: the virtual machine does not free unused objects as soon as possible."
I have not ever seen this ever be a problem. Garbage collection is a black box and is done according to whatever heuristics the garbage collector uses...sure it might "help" negligably to assign nulls but I have seen no effect either way. Perhaps in a REALLY garbage-collection-intensive program (where you are creating and destroying thousands of objects). If something is going out of scope then it's pointless to assign null. In other situations I suppose you could pre-emptively annull references that you think you might not need in the future but that is more a matter of how much heap you want to consume as the working set etc., it doesn't have any leak ramifications.
"If you use C++ properly, you shall not have memory leaks."
And if "using C++ properly" is more expensive than "using Java properly" for the same solution, then the argument is already forfeited.
"The use of templates, RAII, shared pointers, STL, and lots of other goodies C++ has, makes C++ programming better than Java in the long run (especially for big applications)."
Of course, everybody else needs to be using the same goodies or you have to learn their goodies and whoops maybe you didn't understand it as well as you thought you did. If the "goodies" where a standard set this might be a valid argument. There is immense value to me to know that I can download almost any Java project and not worry about how they manage memory, what type of smart pointers they use, what "goody" libraries they use to do this or that, since in Java a vast amount of common functionality is all standardized.
"Java programs are slower than C++"
Performance is no longer an issue. Latency surely is an issue in the GUI, and for intensive things like games (which is why you don't major adoption of Java for games). But observe the retail computing industry - c
Sadly anybody who has a cat and a computer already knows who owns who.
"Is there even one single non-trivial software project made with/on Mono?"
.NET/CLR/C# apps and find out yourself.
Given that Mono runs C#... just survey the landscape of
Eclipse (one of the most popular [Java] developement environments) for one has been compiled to CLR bytecode and run on Mono. There is also an ASP engine written on Mono. Go check out the Mono site to see who use it. There are several companies that use it as a production environment.
"I really don't understand the parent post."
.Net/CLR, php, whatever.
The difference is that Java is a true platform while QT is at the moment foremost a widget toolkit with a bunch of latecoming useful libraries bolted on. Not to knock it - I think one of the massive holes in the C++ "platform" (if you are going to act like it is one) is that it has had no standard set of libraries. The mantra is "write your own" or "use XYZ because that's most popular". That, a platform, does not make.
Seriously I think it's about time C++ got a platform, but to call some syntactic sugar plus some libraries a platform (or at least a platform even beginning to compare to Java in platform-ness) is silly.
And by the way, C++ is "enterprise ready" in the same way straight razors are "oral hygeine ready". Sure you can do it, but expect pain, bleeding, and embarrassment. These is not only my argument - survey the enterprise landscape... the only people using something like C++ for large web applications or middleware are either those that have 1) massive legacy investment 2) massive earth crushing load and performance requirements (e.g. ebay, amazon, etc.). Lastly just because you CAN do it, doesn't mean that it is necessarily a good idea. The market shows that C++ is very expensive to write and deploy (if you are going to go by salaries, etc.) for jobs which can be done equivalently in some other language.
Almost every body else is using some other-generation language, be it Java,
Yes, did you read the article?
"Controllers considered Bounce an odd find because it did not resemble any of the other rocks in the crater's vicinity -- nor did it resemble anything seen before on Mars, they said.
Rather more than that. Bounce's chemical composition exactly matches that of a meteorite that hit the ground in Shergotty, India, on Aug. 25, 1865.
Called the Shergotty meteorite -- and the source name for a class of meteorites called shergottites -- its chemical composition is a "matching fingerprint" to Bounce, said David Grinspoon, professor of planetary science at the University of Colorado in Boulder.
The resemblance helps confirm something meteorite specialists and planetary scientists have suspected for more than two decades but until now have been unable to prove: Micro-bubbles of gas trapped in dozens of meteorites found on Earth -- including Shergotty -- match the recipe of Martian atmosphere so closely that they must have originated on Mars.
"There is a striking similarity in spectra," said Christian Schroeder, a rover science-team collaborator from the University of Mainz in Germany, which supplied both Mars rovers with Moessbauer spectrometers -- exceedingly sensitive instruments for identifying chemical compositions."
It's redundant if you think instructions are not necessary for common sense.
I r brane damorged u isnesnitive clud!
speaking in probabilities... 1/(N!) ?
Since presumably the chances are not dependent, there is a chance that your first shuffle (or any other specific shuffle) actually will be in the original order.
Wrong. A banjo is best tuned with a Tin Whistle. That way you can break both of the goddamned things. /me shakes fist at Irish for inventing the Tin Whistle and bringing it into my peaceful house
"If Java is GPLed, e it could not be used in an application that is not GPL compatible."
<lil' john>Huh?! Uh-what?!</lil' john>
When you write a typically Java application you DO NOT link to the JVM. The JVM interprets or runs your binary but is in no fashion linked to it in any way. Java is also late-binding, so even the libraries are not linked until they are actually used. There is absolutely NOTHING stopping a fully compliant GPL JVM (except maybe official Sun "compliance" stamp negotiations). Running your app on a GPL JVM carries zero obligations for your source code. Your source code never even interacts with the VM. You can compile Java source with Compiler Foo, and run it on JVM Bar, and the licenses of neither really have any affect on your app. The only thing that MIGHT have an affect on the license of your app is the core libraries and that is a very very gray area which I think Stallman has recently relented on. In the worst case, the Java core libraries would just be put under LGPL, while the JVM could remain GPL.
The only time the JVM license would matter is if you were trying to embed the JVM itself, and link it into your own program.
It's sort of like saying, "anything that runs on Linux must be GPL because the operating system binary loader is GPL".
I'm not sure exactly how Systrace works, but I imagine it works in one of two ways:
1) run BadApplication through a (OPTIONAL) special loader that intercepts system calls
2) run BadApplication through the standard system loader, system calls actually ENTER the kernel and are traced AT THAT POINT
The former is probably susceptible to typical userspace hacks, not to mention the fact that a user can simply AVOID using it.
"There is no more reason to include this with the base operating system than there is to include virus protection in the base OS."
That is fine with me as I clearly DO see a reason to "include virus protection in the base OS", and so do many others if you include Write/Execute stack/heap protection in "virus protection".
Why the hell not. The perception that security is bloat is one of the problems to begin with. It's not bloat, it's mandatory and critical to everything else.
"It's striking, however, that mobile-phone conversations are judged more negatively than loud conversations."
Well, they obviously can control that variable by simply exposing a control group to the PRESENCE of a mobile phone, and gauge the inherent negative reaction. They should have done the study with two people talking but one just HOLDING a mobile phone.
Symantec firewalls do in fact monitor and popup warning about port access (with options to allow/deny/always allow/always deny etc.). As far as I have seen it is just for ports.
However, what you are asking is a more general operating system sandbox security model. Putting this in a user-space application is dumb and pointless. The point is that operating systems themselves need this sort of model at a very low level, so that access to myriad system resources can be sandboxed in a well defined and intuitive manner (e.g. along the lines of Java security policy). I have seen various attempts at doing portions of this (chroot hacks, system call interception (openbsd I believe), mandatory access control), but haven't seen an entire model built. Maybe that's what mandatory access control is. Whatever it is, it needs to be at the operating system level, not just "hey why don't we throw all the security in McFirewall With Fries.
...the game
It would sort of be like duck hunt but with a keyboard instead of a gun
FRIST POST!
By the way, if Lone Wolf is accompanied by a Cub, then he is not longer 'Lone' is he?