I would *love* to see operator overloading. It would actually make Java much more useful for scientific tasks which involve things like vectors, matricies, or complex numbers. I'm also sure it would also be helpful in other areas.
There was a preprocessor named jpp floating around a few years ago that supported operator overloading for Java. It seems to have vanished off the net in the meantime, though I'm sure I have a copy somewhere. True operator overloading is supposed to be added to Java at some point, IIRC.
In the meantime, perhaps we should write a new preprocessor, the "Operator Overloading Preprocessor System" or OOPS. jpp seemed like a good idea (it offered several features beyond operator overloading). Java coupled with a good preprocessor is a fine idea.;-)
I don't think anything is taken from C# directly. I don't think there is a single new idea in C#, but if MS hadn't come up with.NET and was still pushing COM do you think Java implementors would be hard pressed to update as they are now?
Yes, this stuff has been on the roadmap since JDK 1.2 (before.Not).
C# and.NET is just a better originized and designed Java.
That'd be great if.Not had an open specification. It doesn't.
Don't settle for a single platform solution. You'll end up regretting it.
What about taking a project that has been a failure in every way and forcing it in to practice and the absolute billions of dollars and the lives it has cost?
It has not been "a failure in every way". Seen any shots from the Space Telescope lately?
The shuttle was supposed to be a cheap way to get in to space, it's by far the most expensive way right now and it's got a reliability problem.
More to the point, it is the only manned vehicle we have right now. Should we really put the entire manned space flight program on hold?
The failure is that NASA was never accountable for the claims made about the shuttle that never were true and they have kept with the program, spending billions of dollars building new shuttles.
Worse yet, NASA has spent billions developing new vehicles, none of which were built. Don't get me wrong, I think NASA should be overhauled, and preferably replaced by private ventures. However, I don't think it's acceptable to halt our manned space program in the meantime.
Columbia and Challenger were not destroyed because of an O-ring or a piece of foam... they were destroyed because NASA as an organization failed.
Interesting link. However, as it pointed out, nothing could have been done to save the crew even if the shuttle had been imaged after launch. What we might have had was an enormously painful ordeal watching them die slowly.
The only organizational failure was (perhaps) an insufficient emphasis on eliminating the foam shedding problem. I do remember hearing shortly after the disaster that this main fuel tank was an older model, not the newer version that largely eliminated this problem.
So, from that perspective, perhaps it was a budget-related problem.
I personally favor going on with the shuttle missions. As others have pointed out, those involved know the risks. Grounded shuttles wouldn't be $1 billion space vehicles, they'd be monuments to our failed resolve.
Eventually it would be great to get private enterprise into the space business. It should come once they figure out the...PROFIT! step.;-)
Re:Why are we always nitpicking?
on
Shuttle Politics
·
· Score: 1
These scientists/adventurers/gov. employees were willing to die for the embetterment of the human race - why should cowards decide where the brave may go?
I'm quite sure ~1/60 catastrophic failure rate is far above the design goal. The folks riding the shuttle had felt the odds were far better than that in their favor, I'd think. The circumstances of the Challenger disaster were quite different - that one could easily have been avoided, and should have been. So, perhaps a better estimate is 1/113.
That the foam could fall off was a known problem. I guess now we know the potential consequences. The shuttle is also vulnerable to meteorite and space junk strikes (as almost anything would be). Perhaps there should be an "emergency kit" so the astronauts have a chance at fixing the damage. I'm not sure what kind of glue can replace carbon-carbon though...
The question is - what to do now? The shuttle is an enormously complex device, and every part must be meticulously maintained. I'd think a goal for the next "space truck" would be vast simplification, self-inspection, self-repair...?
In the meantime, the shuttle program should probably go forward - but more attention will have to be paid to flightworthiness and safety.
is mono really comparable to the microsoft windows.net implementation?
Not even close at this point, AFAIK.
Mono also has the threat of MS patent enforcement hanging over it. Use it at your own risk.
Java is far more cross-platform, and performs roughly as well on the same hardware (server stuff). The client side is also getting better with improved Swing (on Mac for instance) and SWT for even better "native look and feel".
Download Eclipse at www.eclipse.org to see a first-class modern Java application.
"evil agencies" Guys you make a lot of us run screaming from open source / Linux / etc. with the whole FBI/CIA/ and other people working to protect me and my family are "evil" stuff. Also why do I have to buy into a whole liberal stuff to be all open source? Where are all the techno libertarians huh? Give it a rest already, there are valid point to be raised about DRM with bashing Ashcroft who has done a great job preventing further terrorist attacks in the USA...
Personally, I would lean towards the idea that private information should be just that...and it can be if you use your own cryptographic software. One-time pads are theoretically unbreakable, for instance. Better protect that pad though!
All bets are off, of course, if someone plants a bug in your system..
Get a grip, people. If you wanna use windows, keep using windows2000 or xp, then you'll be safe in your drm-free world. And then when this MS bumble fails like so many other MS things have, everyone will see it for what it is. Is passport used the way MS said it would be? No. I could go on, but you're all too busy running for fear that the sky is falling.
No, Passport hasn't caught on the way Microsoft (which should now be called Macrosoft) wanted it to. So now it's building a hardware dongle to enforce Passport for secure computing. Any site that wants "real security" will be Windows-only, no?
I could be wrong - if so please point me to the open Palladium specification making it possible for other OSs can comply (given sufficient time and effort of course).
SWT, like Microsoft's old Java libraries, includes things like COM and ActiveX integration
Yes, but that simply means it isn't a lowest common denominator approach. This functionality that Swing would have had a tough time exposing.
Here's the relevant section from the SWT main page:
-----
The most succinct description of the Standard Widget Toolkit component is this:
The SWT component is designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented.
"portable"
implies both that it must be possible to create applications (Eclipse, in particular) which will run on all of the supported operating systems, and that SWT itself must be simple to port to new operating systems.
The former case is supported by providing a common programming interface. By coding to this API, applications can be created that run everywhere where SWT will run. It is important to note that, because SWT uses the native (i.e. operating system provided) widgets, the look and feel of applications built with SWT will vary on each operating system so that they match the expectations of users of that operating system.
The later case, the porting of SWT itself, is supported by ensuring that all but the lowest-level, direct interface to the operating system is written in Java. In SWT there truly is "nothing interesting in the C natives", which makes the initial porting (and subsequent debugging) of SWT considerably easier since it can largely be done using the facilities of Eclipse, including the built in remote debugging. In addition, the coding style of SWT is such that it is easy for programmers that are familiar with a particular operating system to understand and implement the code.
A side-effect of the SWT implementation strategy is that it is relatively simple to create operating system specific extensions to SWT to support particularly important features. An example of this would be ActiveX on Windows, which Eclipse uses (protected by appropriate platform checks) to support embedded ActiveX controls and documents. It was felt that to be competitive on that platform, support for ActiveX was a requirement, even though it was not available elsewhere. Because SWT is "close" to the platform, this was not a difficult task.
-----
It is a good thing to leverage the important features of the underlying platform, isn't it? Is Swing really better off re-implementing the entire GUI?
SWT is IBM's alternative that is used in the Eclipse IDE. It's not quite so portable as it provides an abstraction on top of the native windowing system but it has advantages in terms of performance and closer integration with the underlying system. It breaks the write-once-run-anywhere philosophy but is growing in popularity.
SWT doesn't break write-once-run-anywhere. Once SWT is ported, Eclipse compiles with no changes. Eclipse is far from a trivial application.
SWT and Eclipse are available on Windows, Linux, AIX, MacOS X, and more...
Clearly, with its low cost, comparable performance, and ease of porting 32-bit programs, AMD's Opteron is going to cut into Intel's Itanium sales.
The real question is: what Itanium sales?
Sure, Itanium sales are quite low right now. However, the whole idea of Itanium was to make a cheaper, faster, enterprise class server CPU that would kill SPARC, Alpha, PA-RISC and Power. It killed both HP architectures with marketing muscle alone.;-) However, Itanic has decidely not lived up to the hype and the future isn't much brighter, IMO. Power is looking pretty good by comparison lately.
I assume that AMD isn't just positioning the Opteron as an alternative to the Itanium, but also as a "power user" chip, aimed at a slightly more general audience (e.g. video editing, CAD, scientific applications).
AMD has positioned Opteron as a general purpose workstation and server CPU.
Opteron looks like it has best of breed performance, at a much lower system cost. I think there'll be quite a shift in the marketplace. AMD's recent alliance with IBM looks particularly promising. It looks like the main threats from Intel are monopolistic behavior and marketing. Intel technology isn't looking so hot...
We'll see how it goes... I can't wait to get my hands on a dual Opteron workstation.:-)
Well, unless your budget is unlimited, or whatever you're working on is not paralellizable, price/performance is still more important than the performance of an individual CPU. I'm pretty sure that eventually we'll have to switch to using multiple CPUs anyway.
Massively parallel supercomputers are being built using both Itanic, er, Itanium and Opteron processors. Compute performance and memory addressing capability per node are still important. Probably more important in those applications than absolute performance is performance per watt dissipated.
To those who chimed in with "Overrated" mods...don't shoot the messenger. As someone said "To moderate is human, to reply divine". Let's see your rebuttal.
BTW, I'm sorry about your Intel stock, especially regarding what's about to happen to it.;-)
The only meaningful benchmark IMO is processing_power/cost. A comparison based on clock speed would be pretty useless since architectures are different, and Itanium is so incredibly expensive.
There are two meaningful quantities. Performance, and price/performance. A performance metric, like SPEC, measures (primarily) the absolute performance of the CPU, by measuring the time taken to complete a given computational task. This might be computing a quantum dynamics problem, or calculating a satellite trajectory, or any other arbitrary computing task. Clock speed isn't relevant, only the total work done per unit time. SPEC uses a statistical measure of several integer-only tasks for the integer part of its test, and a similar scheme for the fp part. It has single-CPU tests and tests for multiprocessor systems. Opteron is a tad slower in FP (no big deal) but about 50% faster in integer performance.
Price/performance weights the performance numbers by the cost of the respective systems, and is a more important metric for many businesses.;-)
I think all the current 64-bit CPU producers are thinking about this, too, and saying "oh" and "um" quite a bit trying to figure out there marketing plans.
Yah. Another important feature of Opteron is that memory bandwidth scales with additional CPUs in an SMP setup. That is sweet.
The integer score is important for many general-purpose computing tasks, like web serving and database.
Gee, Opteron is MUCH less expensive, performs better, runs up to 8-way with off the shelf components and runs your 32-bit x86 code twice as fast and absolutely compatibly. Let me think about this...;-)
I wonder how much slower my query will be when the data is spread across several machines. I'd imagine that a few complex queries that aren't correctly optimized would bring this system to it's knees rather quickly.
Total read query throughput will scale with the number of machines in the cluster, given (from the website):
"The database is distributed and replicated among several nodes and C-JDBC load balance the queries between these nodes."
For writes, the data must go to every machine replicating the data. It's possible this happens using broadcast TCP/IP or some such technology, so performance might not suffer much there either.
Unless you're looking for your game to be able to read and write MS Word files, or print through Excel, games probably wouldn't have used the Component Object Model. C# apparently has the same functionality that COM did, but probably does it a little more elegantly. In any case, game developers didn't use COM, and they're probably not using C#.
Uh, unless you use DirectX. Which is all COM based.
Slashdot Mirror
There was a preprocessor named jpp floating around a few years ago that supported operator overloading for Java. It seems to have vanished off the net in the meantime, though I'm sure I have a copy somewhere. True operator overloading is supposed to be added to Java at some point, IIRC.
In the meantime, perhaps we should write a new preprocessor, the "Operator Overloading Preprocessor System" or OOPS. jpp seemed like a good idea (it offered several features beyond operator overloading). Java coupled with a good preprocessor is a fine idea. ;-)
If you're basing your opinion regarding Java on 2001 information, you're missing the boat.
Java has its weak points, but it has many more strong ones.
Negative.
Regarding all the other comments:
I don't think anything is taken from C# directly. I don't think there is a single new idea in C#, but if MS hadn't come up with .NET and was still pushing COM do you think Java implementors would be hard pressed to update as they are now?
Yes, this stuff has been on the roadmap since JDK 1.2 (before .Not).
C# and .NET is just a better originized and designed Java.
That'd be great if .Not had an open specification. It doesn't.
Don't settle for a single platform solution. You'll end up regretting it.
It has not been "a failure in every way". Seen any shots from the Space Telescope lately?
The shuttle was supposed to be a cheap way to get in to space, it's by far the most expensive way right now and it's got a reliability problem.
More to the point, it is the only manned vehicle we have right now. Should we really put the entire manned space flight program on hold?
The failure is that NASA was never accountable for the claims made about the shuttle that never were true and they have kept with the program, spending billions of dollars building new shuttles.
Worse yet, NASA has spent billions developing new vehicles, none of which were built. Don't get me wrong, I think NASA should be overhauled, and preferably replaced by private ventures. However, I don't think it's acceptable to halt our manned space program in the meantime.
No. With Challenger, there was a "do not launch" suggestion from engineers (too cold).
No one suggested scrapping the Columbia mission due to the fuel tank condition.
Interesting link. However, as it pointed out, nothing could have been done to save the crew even if the shuttle had been imaged after launch. What we might have had was an enormously painful ordeal watching them die slowly.
The only organizational failure was (perhaps) an insufficient emphasis on eliminating the foam shedding problem. I do remember hearing shortly after the disaster that this main fuel tank was an older model, not the newer version that largely eliminated this problem.
So, from that perspective, perhaps it was a budget-related problem.
I personally favor going on with the shuttle missions. As others have pointed out, those involved know the risks. Grounded shuttles wouldn't be $1 billion space vehicles, they'd be monuments to our failed resolve.
Eventually it would be great to get private enterprise into the space business. It should come once they figure out the ...PROFIT! step. ;-)
I'm quite sure ~1/60 catastrophic failure rate is far above the design goal. The folks riding the shuttle had felt the odds were far better than that in their favor, I'd think. The circumstances of the Challenger disaster were quite different - that one could easily have been avoided, and should have been. So, perhaps a better estimate is 1/113.
That the foam could fall off was a known problem. I guess now we know the potential consequences. The shuttle is also vulnerable to meteorite and space junk strikes (as almost anything would be). Perhaps there should be an "emergency kit" so the astronauts have a chance at fixing the damage. I'm not sure what kind of glue can replace carbon-carbon though...
The question is - what to do now? The shuttle is an enormously complex device, and every part must be meticulously maintained. I'd think a goal for the next "space truck" would be vast simplification, self-inspection, self-repair...?
In the meantime, the shuttle program should probably go forward - but more attention will have to be paid to flightworthiness and safety.
Not even close at this point, AFAIK.
Mono also has the threat of MS patent enforcement hanging over it. Use it at your own risk.
Java is far more cross-platform, and performs roughly as well on the same hardware (server stuff). The client side is also getting better with improved Swing (on Mac for instance) and SWT for even better "native look and feel".
Download Eclipse at www.eclipse.org to see a first-class modern Java application.
Personally, I would lean towards the idea that private information should be just that...and it can be if you use your own cryptographic software. One-time pads are theoretically unbreakable, for instance. Better protect that pad though!
All bets are off, of course, if someone plants a bug in your system..
No, Passport hasn't caught on the way Microsoft (which should now be called Macrosoft) wanted it to. So now it's building a hardware dongle to enforce Passport for secure computing. Any site that wants "real security" will be Windows-only, no?
I could be wrong - if so please point me to the open Palladium specification making it possible for other OSs can comply (given sufficient time and effort of course).
Can't we all just get along? ;-)
We'll send AlGore there, and he'll invent them.
Works for me. ;-)
Yes, but that simply means it isn't a lowest common denominator approach. This functionality that Swing would have had a tough time exposing.
Here's the relevant section from the SWT main page:
-----
The most succinct description of the Standard Widget Toolkit component is this:
The SWT component is designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented.
"portable"
implies both that it must be possible to create applications (Eclipse, in particular) which will run on all of the supported operating systems, and that SWT itself must be simple to port to new operating systems.
The former case is supported by providing a common programming interface. By coding to this API, applications can be created that run everywhere where SWT will run. It is important to note that, because SWT uses the native (i.e. operating system provided) widgets, the look and feel of applications built with SWT will vary on each operating system so that they match the expectations of users of that operating system.
The later case, the porting of SWT itself, is supported by ensuring that all but the lowest-level, direct interface to the operating system is written in Java. In SWT there truly is "nothing interesting in the C natives", which makes the initial porting (and subsequent debugging) of SWT considerably easier since it can largely be done using the facilities of Eclipse, including the built in remote debugging. In addition, the coding style of SWT is such that it is easy for programmers that are familiar with a particular operating system to understand and implement the code.
A side-effect of the SWT implementation strategy is that it is relatively simple to create operating system specific extensions to SWT to support particularly important features. An example of this would be ActiveX on Windows, which Eclipse uses (protected by appropriate platform checks) to support embedded ActiveX controls and documents. It was felt that to be competitive on that platform, support for ActiveX was a requirement, even though it was not available elsewhere. Because SWT is "close" to the platform, this was not a difficult task.
-----
It is a good thing to leverage the important features of the underlying platform, isn't it? Is Swing really better off re-implementing the entire GUI?
SWT doesn't break write-once-run-anywhere. Once SWT is ported, Eclipse compiles with no changes. Eclipse is far from a trivial application.
SWT and Eclipse are available on Windows, Linux, AIX, MacOS X, and more...
That's plenty portable enough for me!
No, I just think that's what will happen.
I personally doubt SCO has a leg to stand on, so it's a moot point.
The real question is: what Itanium sales?
Sure, Itanium sales are quite low right now. However, the whole idea of Itanium was to make a cheaper, faster, enterprise class server CPU that would kill SPARC, Alpha, PA-RISC and Power. It killed both HP architectures with marketing muscle alone. ;-) However, Itanic has decidely not lived up to the hype and the future isn't much brighter, IMO. Power is looking pretty good by comparison lately.
I assume that AMD isn't just positioning the Opteron as an alternative to the Itanium, but also as a "power user" chip, aimed at a slightly more general audience (e.g. video editing, CAD, scientific applications).
AMD has positioned Opteron as a general purpose workstation and server CPU.
Opteron looks like it has best of breed performance, at a much lower system cost. I think there'll be quite a shift in the marketplace. AMD's recent alliance with IBM looks particularly promising. It looks like the main threats from Intel are monopolistic behavior and marketing. Intel technology isn't looking so hot...
We'll see how it goes... I can't wait to get my hands on a dual Opteron workstation. :-)
Blast everyone at SCO headquarters!
Heck, I'd buy a copy... ;-)
Anyone up for a Quake mod?
Seriously, IBM will probably lawyer them to death...once the company is worth <$1 millon (a few months), IBM will buy it. Game over.
One Opteron based supercomputer is being built by Cray. It will use up to 10,000 Opterons.
SGI is building Itanium supercomputers.
Both companies know a bit about such boxes. ;-)
Massively parallel supercomputers are being built using both Itanic, er, Itanium and Opteron processors. Compute performance and memory addressing capability per node are still important. Probably more important in those applications than absolute performance is performance per watt dissipated.
BTW, I'm sorry about your Intel stock, especially regarding what's about to happen to it. ;-)
There are two meaningful quantities. Performance, and price/performance. A performance metric, like SPEC, measures (primarily) the absolute performance of the CPU, by measuring the time taken to complete a given computational task. This might be computing a quantum dynamics problem, or calculating a satellite trajectory, or any other arbitrary computing task. Clock speed isn't relevant, only the total work done per unit time. SPEC uses a statistical measure of several integer-only tasks for the integer part of its test, and a similar scheme for the fp part. It has single-CPU tests and tests for multiprocessor systems. Opteron is a tad slower in FP (no big deal) but about 50% faster in integer performance.
Price/performance weights the performance numbers by the cost of the respective systems, and is a more important metric for many businesses. ;-)
Yah. Another important feature of Opteron is that memory bandwidth scales with additional CPUs in an SMP setup. That is sweet.
OK, it wasn't overheard at Intel. But it should have been.
SPEC2000 scores:
Itanic2/1 GHz.: 810/1174 int/fp
Opteron: 1202/1170 int/fp
The integer score is important for many general-purpose computing tasks, like web serving and database.
Gee, Opteron is MUCH less expensive, performs better, runs up to 8-way with off the shelf components and runs your 32-bit x86 code twice as fast and absolutely compatibly. Let me think about this... ;-)
Total read query throughput will scale with the number of machines in the cluster, given (from the website):
"The database is distributed and replicated among several nodes and C-JDBC load balance the queries between these nodes."
For writes, the data must go to every machine replicating the data. It's possible this happens using broadcast TCP/IP or some such technology, so performance might not suffer much there either.
Very interesting stuff!
Uh, unless you use DirectX. Which is all COM based.
I prefer cross platform technologies, regardless.