I'll buy your point as soon as you convince me that:
BigDecimal t = new BigDecimal(0.0); BigDecimal a = new BigDecimal(1.006); BigDecimal b = new BigDecimal(5.0); BigDecimal c = new BigDecimal(15000000.0); t = c.add(a.pow(b));
is clearer than:
BigDecimal t = new BigDecimal(0.0); BigDecimal a = new BigDecimal(1.006); BigDecimal b = new BigDecimal(5.0); BigDecimal c = new BigDecimal(15000000.0); t = c + (a ^ b);
It's not, there's no getting around it, and the problem gets much worse with more complex examples and higher mathematics.
If there's no advantage to algebraic syntax, why provide it for primitives?
I return to my earlier point: any organization can mandate against using operator overloading if it wants to. Operator overloading is syntactic sugar, so you can continue to simply call the methods the old way if you prefer it. Just don't force everyone into your mold.
I've always thought that ANDF approach wasn't so good as compiling the bytecodes
Have you ever looked at dissassembled bytecode? It's very close to the original source code, which means almost all of the same optimization opportunities are there. Why shouldn't it do a good job?
could take a long time for say a 100MB binary..
Do you have any 100 MB binaries? o.O
At any rate, it only happens at install time, and shouldn't be a big deal in terms of time.
At least with a JIT, you only compile what you need (the loops).
That's not quite right for HotSpot and other advanced VMs. First of all, they're constantly profiling the code to see if it needs to be JITed. Then, at whatever intervals, they actually do some translation into machine language. However, all this activity occurs every time the program runs! Doesn't it bother you a bit that all the profiling information from all previous runs is lost? If we're talking "performance per Watt" current VM approaches seem to have some serious overhead compared to compiled languages.
What's your rationale for preferring ANDF approach?
Expensive optimizations are only paid for once. It's prohibitive to even try some optimizations in JIT compilers, those need to be fast.
It's not used very much nowadays..
Yes, most languages use my preferred method. Source -> Object -> Executable/Library. Bytecodes don't really obfuscate much, might as well distribute obfuscated sources.
Traditional compiled languages can use all the expensive optimizations they want, and furthermore the program has deterministic timing when run. Neither of these statements is true of JITing VMs.
Java purposefully does not overload operators because of the thought that programmers suck and will screw it up. I personally disagree and wish I could be allowed to have to option of being a "bad programmer" in Sun's eyes.
I'm well aware of the rationale for no operator overloading in Java. I just completely disagree with it.
No language can protect you from bad programmers. Don't hire them, or work (long) with them. If an organization doesn't want operator overloading, they should mandate that and make sure with code audit tools. There's no justification for penalizing those of us who could make good (and clear) use of operator overloading for the *possible* abuses of inferior coders.
It's the language equivalent of a "nanny state", and I hate that.;-)
All that said, these new Conroe processors sure look promising for running whichever type of code. =)
Ah, I see a genius mod saw this as "Offtopic". Not sure how, given:
'If the new processor performance metric (as touted by Intel) is "performance per watt", someone should take a hard look at Java and.Net performance compared with the top compiled languages. Dylan or D would work fine as "server side" web development languages.'
This is completely topical with the discussion of new Intel processors. Nice job.
Imagine a world where 98% of software is written Java for portability.
At one point, not that long ago, I agreed 100% with this thinking. I was still drinking the "Java will have C performance" Koolaid from Sun.
I'm now of the opinion that the "managed" languages are a short-term abberation, unless they adopt an ANDF type "freeze" approach. That is where the bytecodes are pre-compiled once into machine code, just like a traditional compiler. I'm also not happy with where Java is at as a language after 10 years of evolution. No operator overloading, feh.
Lately I've been looking at D and Dylan for some projects. Both are quite advanced compared to Java, just as portable, and from what I've seen so far both outperform it in many areas. Game and HPC programmers could really use a better language than FORTRAN/C/C++, and Java will never be it, IMO. D seems the more pragmatic of the two, while Dylan looks "better" from a pure language perspective.
If the new processor performance metric (as touted by Intel) is "performance per watt", someone should take a hard look at Java and.Net performance compared with the top compiled languages. Dylan or D would work fine as "server side" web development languages.
Going into IDF we expected to see a good showing from Conroe, but leaving IDF, well, now we just can't wait to have it.
Nice that this is a horse race now. Should be very good for competition going forward. Might also be a spot to short AMD and go long INTC coming up...;-)
It also looks like Jobs made a genius move picking this point in time to go with Intel. He must have hated Netbust too. I can't wait to see the new MacMacs! (Intel PowerMacs, eh?)
Except that there's no way in hell you will be allowed to install linux on it. The university will require you to have a standard build so that the sysadms can slack off.
I seriously doubt this. First of all, one could resize the primary partition and leave the "standard build" alone while installing Linux for dual boot. Should be no problems, and if something does go wrong, just reinstall the system image and start over.
In general, Mac software follows GUI development guidelines more faithfully than Windows software. Linux software, besides being split into at least two GUI environment camps, includes a lot of older stuff that used older toolkits and follows completely different conventions. From a usability standpoint, it's a mess. (BTW, I'm typing this from a FC4 box.)
Like KDE vs Gnome. It's all about personal preference.
No, it's about ease of use and ease of learning. Mac is head and shoulders above Windows, and head, shoulders, torso, legs and feet above Linux.
Plus, unlike Linux, there's quite a lot of high quality commercial software available for Mac.
Thinkpad. Not a bad choice for a Windows/Linux laptop.
Once Windows emulation is working well, though, I think a MacBook (Pro or not) would be a better choice. Fewer security issues, better GUI and applications, and it runs more software. Apple is sure looking good these days...:-)
If you want to stop 70% of sexual abuse of children, lock up their fathers. To stop another 30%, lock up their other close relatives too. You can knock off the next 8% by stopping them going to school. The tiny handful actual elusive pedophiles are involved in the remaining 2% of abuse.
That's a fine reason for the minority of applications what will be ported to other platforms, but what about the rest?
We're in something of a historical anomaly right now, with a single OS having over 90% marketshare, and a single desktop CPU architecture having over 90% marketshare. All that said, if MacOS gets to 20% marketshare in a few years, wouldn't you like to have an easy port to that platform? What about Linux? Or, heaven forfend, Solaris? AIX?
"Free" portability is a good thing.
Is Java's only value it's (sort of) platform-independence?
No, but that is one if it's larger value propositions. Most don't want to throw it away.
If not, why not offer the ability to use the native widgets in a straight-forward manner?
That's more or less what SWT is. It's still portable.
First, can we recycle what we can of the 24 tons? There's still lots of usable fuel in there! 97% is reusable with the right technology, so it's still valuable. End result is that it'd be about 33 years production for a gigawatt plant to equal 24 tons of unusable stuff.
I'm all for breeder reactors as long as they're safe.
Other than that, I see no problems with your solution. Except that you'd only need one ship. You'd even be able to make lots of empy trips with it. Assuming a circuit takes a month(generous), but it's able to drop multiple darts with a load, it'd have cargo only about a third of the time, even with 100% dependency.
I thought about this some more, and came up with some refinements. I'm not sure the 'dart' should fall at high speed, since both cavitation and the impact will produce signficant signatures which could possibly be triangulated. My main thought in having it fall fast was to embed it into the bottom, and make sure it subducted properly. I suspect that won't be a problem with a highly dense object like this anyhow.
So, I think it should fall "slowly" and quietly. This can be accomplishied by various means. I also think the construction should be non-ferrous so magnetic detectors won't work. So substitute a non-ferrous structural lattice for the steel matrix, then just pour lead around the array of ceramic containers inside the tungsten carbide shell. Weld on the last piece of shell when done. This has dual advantages of increasing total density, and providing extra radiation shielding.
When dropping the object, the ship should pump in water as it slowly lowers the object into the water so the waterline never changes, so outside observers can't detect a change.
Yes, some engineering to make sure the thing wouldn't break open on impact would be needed, but oh well.
I think with a foot-thick solid shell of TC, breakage is highly unlikely.;-)
At any rate, low-speed impact solves that problem.
Since C14 only collects in living animals/plants, and decays when they die, by the time something is converted into coal/oil the C14 has long since decayed to negligable levels. Remember the half life is 5760 years, so by 200,000 years less than 1 ppb of the original C14 is still C14.
Sigh...never mind. lol
Reminder to self...think before posting.
(It turns out there is some C14 in some coal caused by natural radioactivity in the rock, but very little and not enough to worry about.)
On the other hand, C14 is an issue with most of the renewable fuels like ethanol and biomass.
High-density energy storage for vehicles. (hydrogen produced by electrolysis of water... sucks.
I disagree. First of all, someone recently pointed out that if there was a plugin option for overnight charging with wall current for current hybrid cars, the average consumer with a less than fifteen mile commute could make the round trip using no gas. That would have an enormous impact if it became a widespread practice.
Secondly, there was an article (I believe here on Slashdot) a while back about a new pellet-based approach for storing hydrogen. It claimed that enough for a 300 mile range car would fit in a 30 gal tank. The pellets were also reusable.
It seemed to me that such a pellet approach could provide a very practical "hydrogen economy".
Here's my suggestion (I've posted it here before).
Build a few special-purpose ships, each with a large hatch that would open from inside a covered cargo area. Take your 24 tons of nuclear waste, and package it in (perhaps) individual ceramic containers embedded into a solid matrix of stainless steel. Coat the whole thing with a foot of tungsten carbide or some other even tougher, corrosion resistant material. Let's say the final object weighs 50 tons. It is shaped roughly like a missile, with fins at the back.
These projectiles are loaded into the ships as needed. The fleet of ships is continuously patrolling a loop that goes out from a west coast port, to the mid-Pacific subduction zone region, up the subduction zone for a few thousand miles, then back to port. It is classified whether any particular ship is carrying nuclear material, and each is escorted by naval assets (at least a sub). At a highly classified location along the subduction zone, a ship carrying a live container dumps it. Unless an observer is monitoring the ship with sonar, no one knows where the container was dumped. The container falls at a high rate of speed (> 150 kph) and buries itself into the muck over 20,000 ft underwater in the mid Pacific. The long term containment plan is for that 50 ton highly dense container to be pulled down into the mantle by subduction forces and recycled for a few million years.
It might be a better idea to make the containers even bigger, to make hostile recovery even harder. The area could be watched by satellite, since any salvage operation to try and raise something like that would be massive (and likely require the resources of a national government).
I feel this approach is much safer than land based containment approaches, and avoids all the political issues with waste disposal.
It's been pointed out in these comments already, but 99.5% of the radioactive material burned from coal is caught by modern, manadtory, filters.
This is total horsecrap. I realize you were originally talking about uranium, but you've now forgotten about the carbon-14 in the emitted CO2. The beta radiation from that far exceeds the radiation from released uranium. Beta radiation is ionizing radiation, and far from harmless. Many feel that beta radiation is a major contributor to lung cancer. To quote the EPA site:
Direct exposure to beta particles is a hazard, because emissions from strong sources can redden or even burn the skin. However, emissions from inhaled or ingested beta particle emitters are the greatest concern. Beta particles released directly to living tissue can cause damage at the molecular level, which can disrupt cell function. Because they are much smaller and have less charge than alpha particles, beta particles generally travel further into tissues. As a result, the cellular damage is more dispersed.
As you can see, beta radiation from C14 is a great concern, both in CO2, and in carbon-based particulates.
I applaud the building of new nuclear plants. The new designs are very safe, and they release virtually no radiation or greenhouse gasses into the environment under normal conditions. The time is right to improve our energy diversity and benefit from this bountiful power source.
Sheesh, another car analogy. Doesn't strike me as a particularly good one either.
Fact is, the current-gen Intel CPUs in the iMac are quite competitive with Opteron, clock for clock. They are also very efficient, which appeals to some people.
The iMacs aren't an "enthusiast" computer, but they're fine for probably at least 90% of the computing public. That's a large sweet spot. The next-gen MacMacs (currently PowerMacs) will be the enthusiast type computers, with a fair amount of expansion, upgradable CPUs and graphics cards, and so on.
Your analogy also failed to highlight many of the advantages of Mac software beyond "no viruses", thereby failing to point out one of the highest value aspects of owning a Mac.
Ah! The beauty of someone who baits their statements with stock lines like "one dimensional thinking". Sounds like flamebait to me.
I call 'em like I see 'em. How is such thinking not "one-dimensional"? You stated those two possibilities as though they were the only two.
Now, quit with the thinly veiled ad-hominems and address the meat of the argument.
How long do you think it's gonna take to get at that extra oil?
Biodiesel? Available within a year (major rampup). Offshore oil around the US? Available within 4 years. Anwar? Available within 3 years. There are similar stocks available around the world, and guess what, with oil apparently permanently over $40 a barrel (almost $60 at this writing) it's now economically viable to drill for it. Let the market work.
How long do you think it's gonna last with our current usage?
PLENTY long enough. For many reasons, the western world is aggressively developing new energy technologies.
The answers are too long and not long enough, respectively.
Wrong! Back up your assertions with some numbers please.
The parent never mentioned that he wanted to do any of that; he pointed out 2 oil sources that hadn't been tapped yet and the tone of the message seemed to be that would fix all our problems since there weren't alternatives provided, hence the reason I asked him the question.
I've looked into the issue a fair amount. If the oil companies become convinced that oil will stay over $40 a barrel, they can easily explore and develop very significant additional resources. At the same time, we have renewable resources to convert into biodiesel and ethanol if prices stay high enough. These can also be ramped up rather rapidly.
There are other disruptive technologies like solar which may come through in a big way. Recent announcements of cheap, efficient, flexible solar fabric may signal a real turning point.
In short the "radical conservation is the only way out" energy policy is an unnecessary disaster that won't have to happen.:-)
So what you're really saying is that we should drill for more oil to maintain our current(and usually shallow) lifestyles, not find a better energy source to replace it?
Ah, the beauty of one-dimensional thinking!
What about drilling for more oil to serve our (and emerging countries') current energy needs, while we build more nuke plants, ramp up alternative fuels, innovate with solar (a HUGE energy source), add more windfarms, research large-scale geothermal, and continue work on a hydrogen economy. Eventually we'll also get hydrogen fusion working as an energy source, which will effectively forever end energy as a bottleneck of human expansion and industrialization.
The Oort cloud is the limit! (For now at least...)
For a good programmer, it is easier (and faster) to write new code from scratch than to try and figure out what the guy before you wrote (and still get it wrong)
Wow, thanks for clearing that up!
Next time I do some Java programming, I won't bother with those troublesome libraries, I'll just program everything I need from scratch! I've always wanted to implement all the containers myself, for instance...
If you want a good illustration of how ridiculous it would be to insist on single language such as Java everywhere, imagine if all their sites (e.g. maps.google.com) had to be provided using Java applets.
ROFL! This is the funniest thing I've read in a _long_ time.
Google Maps could have been done, much better, as an applet 5 years ago. The ONLY problem would have been an one-time JVM download, since Microsoft killed Java pre-loads initially.
It's too funny that you think Google Maps is better off as a Javascript hack...
I just find Java really boring to use *shrug* I'd rather use Delphi or C++ for some reason. Definitely not Visual Basic either, it seems based on the same kiddy mentality as Java, like you have to make the code look moronic for people to be able to understand it. Hmm.
I'm just interested as to what the big deal with Java is. When I first heard of it, the cross platform ability sounded amazing. And it looks similar to C. But it's not. At least in my experience it has been slower and just no 'fun' to code with, not sure how to quantify that feeling exactly.
I'm curious why you'd rather code in C++ than Java? For me, moving to Java from C++ was a real relief. No more worrying about low-level memory management issues for the most part, I could focus on the problem domain. For me, coding in Java is very straightforward, and MUCH more productive than coding in C++.
I've found the performance issues to be minimal, and in some cases I've gotten C-like performance using gcj.
All that said, you may want to check out D. It's another C-based OO language, but it is high performance and probably what C++ should really have been.
Slashdot Mirror
is clearer than:
It's not, there's no getting around it, and the problem gets much worse with more complex examples and higher mathematics.
If there's no advantage to algebraic syntax, why provide it for primitives?
I return to my earlier point: any organization can mandate against using operator overloading if it wants to. Operator overloading is syntactic sugar, so you can continue to simply call the methods the old way if you prefer it. Just don't force everyone into your mold.
Have you ever looked at dissassembled bytecode? It's very close to the original source code, which means almost all of the same optimization opportunities are there. Why shouldn't it do a good job? could take a long time for say a 100MB binary..
Do you have any 100 MB binaries? o.O
At any rate, it only happens at install time, and shouldn't be a big deal in terms of time.
At least with a JIT, you only compile what you need (the loops).
That's not quite right for HotSpot and other advanced VMs. First of all, they're constantly profiling the code to see if it needs to be JITed. Then, at whatever intervals, they actually do some translation into machine language. However, all this activity occurs every time the program runs! Doesn't it bother you a bit that all the profiling information from all previous runs is lost? If we're talking "performance per Watt" current VM approaches seem to have some serious overhead compared to compiled languages.
What's your rationale for preferring ANDF approach?
Expensive optimizations are only paid for once. It's prohibitive to even try some optimizations in JIT compilers, those need to be fast.
It's not used very much nowadays..
Yes, most languages use my preferred method. Source -> Object -> Executable/Library. Bytecodes don't really obfuscate much, might as well distribute obfuscated sources.
Traditional compiled languages can use all the expensive optimizations they want, and furthermore the program has deterministic timing when run. Neither of these statements is true of JITing VMs.
I'm well aware of the rationale for no operator overloading in Java. I just completely disagree with it.
No language can protect you from bad programmers. Don't hire them, or work (long) with them. If an organization doesn't want operator overloading, they should mandate that and make sure with code audit tools. There's no justification for penalizing those of us who could make good (and clear) use of operator overloading for the *possible* abuses of inferior coders.
It's the language equivalent of a "nanny state", and I hate that. ;-)
All that said, these new Conroe processors sure look promising for running whichever type of code. =)
'If the new processor performance metric (as touted by Intel) is "performance per watt", someone should take a hard look at Java and .Net performance compared with the top compiled languages. Dylan or D would work fine as "server side" web development languages.'
This is completely topical with the discussion of new Intel processors. Nice job.
I can think of two:
1) Better ethics, so people with bad genes simply don't reproduce voluntarily.
2) Genetic engineering to remove bad genes in vitro.
I'm betting on #2 myself.
At one point, not that long ago, I agreed 100% with this thinking. I was still drinking the "Java will have C performance" Koolaid from Sun.
I'm now of the opinion that the "managed" languages are a short-term abberation, unless they adopt an ANDF type "freeze" approach. That is where the bytecodes are pre-compiled once into machine code, just like a traditional compiler. I'm also not happy with where Java is at as a language after 10 years of evolution. No operator overloading, feh.
Lately I've been looking at D and Dylan for some projects. Both are quite advanced compared to Java, just as portable, and from what I've seen so far both outperform it in many areas. Game and HPC programmers could really use a better language than FORTRAN/C/C++, and Java will never be it, IMO. D seems the more pragmatic of the two, while Dylan looks "better" from a pure language perspective.
If the new processor performance metric (as touted by Intel) is "performance per watt", someone should take a hard look at Java and .Net performance compared with the top compiled languages. Dylan or D would work fine as "server side" web development languages.
Nice that this is a horse race now. Should be very good for competition going forward. Might also be a spot to short AMD and go long INTC coming up... ;-)
It also looks like Jobs made a genius move picking this point in time to go with Intel. He must have hated Netbust too. I can't wait to see the new MacMacs! (Intel PowerMacs, eh?)
I seriously doubt this. First of all, one could resize the primary partition and leave the "standard build" alone while installing Linux for dual boot. Should be no problems, and if something does go wrong, just reinstall the system image and start over.
In general, Mac software follows GUI development guidelines more faithfully than Windows software. Linux software, besides being split into at least two GUI environment camps, includes a lot of older stuff that used older toolkits and follows completely different conventions. From a usability standpoint, it's a mess. (BTW, I'm typing this from a FC4 box.)
Like KDE vs Gnome. It's all about personal preference.
No, it's about ease of use and ease of learning. Mac is head and shoulders above Windows, and head, shoulders, torso, legs and feet above Linux.
Plus, unlike Linux, there's quite a lot of high quality commercial software available for Mac.
Once Windows emulation is working well, though, I think a MacBook (Pro or not) would be a better choice. Fewer security issues, better GUI and applications, and it runs more software. Apple is sure looking good these days... :-)
MacBooks might even be less expensive!
Excellent! You've accounted for all 110% of them!
I run most of my stuff under Linux, so no .exe required...
On the other hand, gcj produces nice native executables. ;-) It doesn't support Swing (yet) but does support SWT.
I haven't looked at it in detail yet, but the JCVM project that was donated to Apache Harmony seems interesting as well.
We're in something of a historical anomaly right now, with a single OS having over 90% marketshare, and a single desktop CPU architecture having over 90% marketshare. All that said, if MacOS gets to 20% marketshare in a few years, wouldn't you like to have an easy port to that platform? What about Linux? Or, heaven forfend, Solaris? AIX?
"Free" portability is a good thing.
Is Java's only value it's (sort of) platform-independence?
No, but that is one if it's larger value propositions. Most don't want to throw it away.
If not, why not offer the ability to use the native widgets in a straight-forward manner?
That's more or less what SWT is. It's still portable.
I'm all for breeder reactors as long as they're safe.
Other than that, I see no problems with your solution. Except that you'd only need one ship. You'd even be able to make lots of empy trips with it. Assuming a circuit takes a month(generous), but it's able to drop multiple darts with a load, it'd have cargo only about a third of the time, even with 100% dependency.
I thought about this some more, and came up with some refinements. I'm not sure the 'dart' should fall at high speed, since both cavitation and the impact will produce signficant signatures which could possibly be triangulated. My main thought in having it fall fast was to embed it into the bottom, and make sure it subducted properly. I suspect that won't be a problem with a highly dense object like this anyhow.
So, I think it should fall "slowly" and quietly. This can be accomplishied by various means. I also think the construction should be non-ferrous so magnetic detectors won't work. So substitute a non-ferrous structural lattice for the steel matrix, then just pour lead around the array of ceramic containers inside the tungsten carbide shell. Weld on the last piece of shell when done. This has dual advantages of increasing total density, and providing extra radiation shielding.
When dropping the object, the ship should pump in water as it slowly lowers the object into the water so the waterline never changes, so outside observers can't detect a change.
Yes, some engineering to make sure the thing wouldn't break open on impact would be needed, but oh well.
I think with a foot-thick solid shell of TC, breakage is highly unlikely. ;-)
At any rate, low-speed impact solves that problem.
Sigh...never mind. lol
Reminder to self...think before posting.
(It turns out there is some C14 in some coal caused by natural radioactivity in the rock, but very little and not enough to worry about.)
On the other hand, C14 is an issue with most of the renewable fuels like ethanol and biomass.
I disagree. First of all, someone recently pointed out that if there was a plugin option for overnight charging with wall current for current hybrid cars, the average consumer with a less than fifteen mile commute could make the round trip using no gas. That would have an enormous impact if it became a widespread practice.
Secondly, there was an article (I believe here on Slashdot) a while back about a new pellet-based approach for storing hydrogen. It claimed that enough for a 300 mile range car would fit in a 30 gal tank. The pellets were also reusable.
It seemed to me that such a pellet approach could provide a very practical "hydrogen economy".
Yes, once they have a sane society. It's not like we can prevent it in the long term, regardless.
Here's my suggestion (I've posted it here before).
Build a few special-purpose ships, each with a large hatch that would open from inside a covered cargo area. Take your 24 tons of nuclear waste, and package it in (perhaps) individual ceramic containers embedded into a solid matrix of stainless steel. Coat the whole thing with a foot of tungsten carbide or some other even tougher, corrosion resistant material. Let's say the final object weighs 50 tons. It is shaped roughly like a missile, with fins at the back.
These projectiles are loaded into the ships as needed. The fleet of ships is continuously patrolling a loop that goes out from a west coast port, to the mid-Pacific subduction zone region, up the subduction zone for a few thousand miles, then back to port. It is classified whether any particular ship is carrying nuclear material, and each is escorted by naval assets (at least a sub). At a highly classified location along the subduction zone, a ship carrying a live container dumps it. Unless an observer is monitoring the ship with sonar, no one knows where the container was dumped. The container falls at a high rate of speed (> 150 kph) and buries itself into the muck over 20,000 ft underwater in the mid Pacific. The long term containment plan is for that 50 ton highly dense container to be pulled down into the mantle by subduction forces and recycled for a few million years.
It might be a better idea to make the containers even bigger, to make hostile recovery even harder. The area could be watched by satellite, since any salvage operation to try and raise something like that would be massive (and likely require the resources of a national government).
I feel this approach is much safer than land based containment approaches, and avoids all the political issues with waste disposal.
This is total horsecrap. I realize you were originally talking about uranium, but you've now forgotten about the carbon-14 in the emitted CO2. The beta radiation from that far exceeds the radiation from released uranium. Beta radiation is ionizing radiation, and far from harmless. Many feel that beta radiation is a major contributor to lung cancer. To quote the EPA site:
As you can see, beta radiation from C14 is a great concern, both in CO2, and in carbon-based particulates.
I applaud the building of new nuclear plants. The new designs are very safe, and they release virtually no radiation or greenhouse gasses into the environment under normal conditions. The time is right to improve our energy diversity and benefit from this bountiful power source.
Sheesh, another car analogy. Doesn't strike me as a particularly good one either.
Fact is, the current-gen Intel CPUs in the iMac are quite competitive with Opteron, clock for clock. They are also very efficient, which appeals to some people.
The iMacs aren't an "enthusiast" computer, but they're fine for probably at least 90% of the computing public. That's a large sweet spot. The next-gen MacMacs (currently PowerMacs) will be the enthusiast type computers, with a fair amount of expansion, upgradable CPUs and graphics cards, and so on.
Your analogy also failed to highlight many of the advantages of Mac software beyond "no viruses", thereby failing to point out one of the highest value aspects of owning a Mac.
I call 'em like I see 'em. How is such thinking not "one-dimensional"? You stated those two possibilities as though they were the only two.
Now, quit with the thinly veiled ad-hominems and address the meat of the argument.
How long do you think it's gonna take to get at that extra oil?
Biodiesel? Available within a year (major rampup). Offshore oil around the US? Available within 4 years. Anwar? Available within 3 years. There are similar stocks available around the world, and guess what, with oil apparently permanently over $40 a barrel (almost $60 at this writing) it's now economically viable to drill for it. Let the market work.
How long do you think it's gonna last with our current usage?
PLENTY long enough. For many reasons, the western world is aggressively developing new energy technologies.
The answers are too long and not long enough, respectively.
Wrong! Back up your assertions with some numbers please.
The parent never mentioned that he wanted to do any of that; he pointed out 2 oil sources that hadn't been tapped yet and the tone of the message seemed to be that would fix all our problems since there weren't alternatives provided, hence the reason I asked him the question.
I've looked into the issue a fair amount. If the oil companies become convinced that oil will stay over $40 a barrel, they can easily explore and develop very significant additional resources. At the same time, we have renewable resources to convert into biodiesel and ethanol if prices stay high enough. These can also be ramped up rather rapidly.
There are other disruptive technologies like solar which may come through in a big way. Recent announcements of cheap, efficient, flexible solar fabric may signal a real turning point.
In short the "radical conservation is the only way out" energy policy is an unnecessary disaster that won't have to happen. :-)
Ah, the beauty of one-dimensional thinking!
What about drilling for more oil to serve our (and emerging countries') current energy needs, while we build more nuke plants, ramp up alternative fuels, innovate with solar (a HUGE energy source), add more windfarms, research large-scale geothermal, and continue work on a hydrogen economy. Eventually we'll also get hydrogen fusion working as an energy source, which will effectively forever end energy as a bottleneck of human expansion and industrialization.
The Oort cloud is the limit! (For now at least...)
For a good programmer, it is easier (and faster) to write new code from scratch than to try and figure out what the guy before you wrote (and still get it wrong)
Wow, thanks for clearing that up!
Next time I do some Java programming, I won't bother with those troublesome libraries, I'll just program everything I need from scratch! I've always wanted to implement all the containers myself, for instance...
ROFL! This is the funniest thing I've read in a _long_ time.
Google Maps could have been done, much better, as an applet 5 years ago. The ONLY problem would have been an one-time JVM download, since Microsoft killed Java pre-loads initially.
It's too funny that you think Google Maps is better off as a Javascript hack...
I'm just interested as to what the big deal with Java is. When I first heard of it, the cross platform ability sounded amazing. And it looks similar to C. But it's not. At least in my experience it has been slower and just no 'fun' to code with, not sure how to quantify that feeling exactly.
I'm curious why you'd rather code in C++ than Java? For me, moving to Java from C++ was a real relief. No more worrying about low-level memory management issues for the most part, I could focus on the problem domain. For me, coding in Java is very straightforward, and MUCH more productive than coding in C++.
I've found the performance issues to be minimal, and in some cases I've gotten C-like performance using gcj.
All that said, you may want to check out D. It's another C-based OO language, but it is high performance and probably what C++ should really have been.