The interactive examples make it a far better learning experience than a book.
Not to mention the sheer coolness of that feature.
I've always found it ironic that there are so many books about the web. Authors trying to tell you how great the web is and what you can do with it, but not using it themselves. This author didn't even put his examples online. I stopped reading the review when I saw that.
I read an article a couple days ago, apparently there was a swine flu outbreak in 1976, and the US was quite proactive in stopping it, encouraging everyone to get vaccinated. The problem came when more people died from the vaccine than from the flu.
Indeed. Between putting his full weight behind the immunization effort and pardoning Richard Nixon, Gerry Ford lost any chance of getting elected to a full term as President. And of course, if he hadn't pushed the immunization effort and people had died from the flu...
I do wish there were some way to eliminate all the drama. It's causing all kinds of overreaction. Today, the cafeteria where I work pulled a roast pork entree from the menu. Never mind that you can't get the flu from eating pork. Nor from the other animals that carry the virus, names birds and people. That last one is not recommended for totally unrelated reasons.
I do wish we could get rid of all these stupid "threat levels" bugs, terrorists, and other such stuff. It might seem very kewl to go all Hollywood with your communications, but it does a lot to aggravate the overreaction. If you want to tell people they need to get their pandemic safeguards in place, why can't you just say that? This THREAT LEVEL 5 nonsense is stupid.
Many of the "re-usable" elements of the space shuttle turned out to be more expensive per flight than discardable elements would have been.
The space shuttle was poorly planned from beginning to end. First they tried to do it on the cheap, then they spent gobs of money kludging on fixes for their initial mistakes — kludges that have killed way too many astronauts. The only lesson I take away from the shuttle program is that if Congress refuses to give you a proper budget for building a spacecraft, don't try to build it anyway.
Nor do I buy the "cheap throwaway booster" concept. Saturn V launches cost three billion 2009 dollars. Each. Perhaps economies of scale and clever design could bring that cost down by 2/3. (I'm skeptical, but let's suppose.) Do you think you can get somebody to give you a whole gigabuck just to land a few thousand pounds on the moon? Never mind the hundreds of launches it would take to do anything serious, like build and supply a permanent moon base or mount an interplanetary expedition.
It goes against all reason to assume that littering the Atlantic ocean with billions of dollars worth of debris is the most cost-effective way to get into space. The idea never would have gained traction, except in an administration that loved to make grand plans, but always dodged cost issues and had no capacity for thinking through the consequences.
Web design is something I don't do on a regular basis, so I often have to google for information on constructs and idioms I'm rusty on or never learned. Half the time I end up on the W3 Schools site. Each topic is nicely self-contained, simple, and clear, making the site an excellent reference source. Best of all, there's a dynamic HTML "try it yourself" feature which lets you quickly tweak an example and immediately see the results.
Over the years, this site has gotten slicker and added more and more content. All of which seems to be funded by a few non-obtrusive ads. Nice to see a web resource that provides a quality service and manages to make a living doing it.
Ok, so the design is based upon rockets, but does it mean that it uses *no* aerodynamic braking at all?
I'm sure it does. Hard to imagine that they could carry enough fuel to rely solely on the rockets for braking.
But they still need to land. Since you're moving relatively slow at this point (but still fast enough to kill your crew) you can't airbrake with your vehicle body. At this point you have to deploy a system that works at relatively slow speeds. Most spacecraft rely on parachutes, sometimes supplemented by the extra cushioning of an ocean landing. But this doesn't give you a lot of control over how you touch down, and you really need it if you're going to design a reusable vehicle.
And we really need to reuse more of our space hardware. We'll never have a self-sustainable business model for space travel as long as all our expensive hardware is one-use-only.
The Shuttle implements precision landing by turning into a glider after the aerodynamic braking is done. (I still think this is the best model; the Shuttle's problems stem from skimping on other features of the design.) The Russians would seem to have decided that landing rockets are a better approach (pun unavoidable).
Right, nobody cares who controls the Senate. Except those silly people who waste all their time worrying about the health care system, terrorism, climate change (or the myth thereof), network neutrality, civil liberties, crime in the streets, and other trivial stuff. Don't these people have a life?
assuming the Franken debacle does indeed go to Franken, which is perfectly consistent with every decision on the margin that the court has been making
and that the decision gets made before Franken's term expires!
I have to point out a simple double standard here: when Al Gore dragged out the fight over Florida into December, the Republicans accused him of being a "poor loser". Yet they seem to see nothing wrong with dragging out the fight over this Senate seat into May — and probably far beyond.
Yeah, some neighborhoods have competing cable companies and FiOS. But not a lot. For most of us, it's the monopoly cable company or make do with DSL.
There's a FiOS provider in my neighborhood that charges $50 for 100 Mb! But they don't serve my area, and they won't even tell me what areas they do serve. Judging from their web site, they basically cater to new housing development where they can piggyback the other utilities. And maybe the developer gives them a small subsidy, which they will more than get back in higher home values.
I've no idea where you've got that definition of JIT, but it's certainly not a common one.
I suppose I shouldn't be so rigid about how that term is used. My attitude probably comes from working with the HotSpot people, who always made a point of distinguishing between what JITs did and what their compiler did.
Of course it's a compiler. It's not a source code compiler.
Never said it was.
He was probably talking about memory used by HotSpot itself for compilation...
That's not at all how I recall the conversation. I honestly believe you're getting this issue wrong, but I don't have the background to argue with you intelligently. So let's just agree to disagree, shall we?
a well-optimized interpreted program is still slower than a native code program
Sigh. That kind of blanket statement is precisely the kind of oversimplification I'm trying to debunk. If execution of the program code is the bottleneck in a program, then yes, interpreted code is always faster than native code. But code execution is not always a bottleneck. I very much doubt that it was a bottleneck in all those early Java programs that established Java's reputation as glacially slow. Those would have been mostly simple GUI apps that didn't have to do anything compute intensive — there wouldn't have been enough interpretation going on to impact the application so thoroughly. Even if I'm totally wrong about the source compiler, you can't possibly blame the interpreter for all the slowdown. There must have been issues elsewhere (class loading? memory allocation? linking to native code?) in order to account for these issues. Even if I'm totally wrong about the source code compiler, it just makes no sense to focus so thoroughly on the bytecode interpreter when assigning blame for performance issues.
Doesn't matter if they do. Since cable companies aren't required to support any ISP except their own, Cablevision couldn't start up in Texas even if they wanted to.
HotSpot is not a JIT. A JIT is something that compiles an entire class when it's loaded. HotSpot only compiles hot spots.
And it is a compiler. Not a source code compiler, obviously, but the people who built it (I worked with them as a tech writer for several months) still considered it a compiler. Of course, parsing byte codes is not nearly as complex as parsing source code (you could even say it's trivial) but parsing is only part of what a compiler does. Just as important, and a lot more difficult, is the compiler's job of generating optimized object code.
The conversation about memory leaks occurred while Griswold was doing a "brain dump" of HotSpot's innards for the benefit of a video camera and some interested engineers. When he started talking about how HotSpot cleaned up orphaned memory, I asked him why there was any orphaned memory to clean up, since the Java memory model doesn't allow for programmer allocation of memory. He blamed the fact that current Java source compilers had been hastily adapted from C++. I assume that's long since been fixed.
Does that make sense in terms of compiler design? I wouldn't know. But that's what I remember.
However, it's worth keeping in mind that HotSpot only appeared in Java 1.2. Before that, it was pure interpreted bytecode.
Yes and no and that's beside the point. Yes, the original JVM was a pure interpreter. But no, the Symantec JIT was a standard part of the JRE by the time I started working at Sun in 1997. And beside the point, because the usual assumption that an interpreted program is always slower than a native code program is too simplistic.
A software application is a complicated beast, and code execution is only one of many potential bottlenecks. The one I've seen most often is a shortage of RAM, which causes a lot of virtual memory "thrashing". I used to see this a lot when I did SOHO consulting, and had the same argument with every single client: no, a faster CPU won't make Word run faster, try installing more RAM.
And of course memory leaks are a good way to bloat memory.
I actually ran into this issue when I was working on Java 1.1 documentation. (This is an example of memory bloat, but not memory leakage.) Part of my job was to generate the API documentation from the source code, using JavaDoc. When I took over this process, it took 12 hours to run on a Sun workstation. The writer who had done it before me just assumed it was the interpreter being a slow interpreter. That didn't make sense to me, but I didn't know enough about the technology to offer an alternative explanation.
Then I went to a talk by a guy who was developing big Java applications. One of his complaints about the current JVM was that it re-inspected every class file on a regular basis, which meant that every class file you loaded had to remain part of the program image throughout program execution. (He had a workaround for this that I no longer remember.) A light bulb went off in my head: JavaDoc gets class information by inspecting the class file itself (easier than parsing the source code, I guess). That meant that my JavaDoc run was loading every single class into memory! Its footprint must be huge! The workstation I was using had (I think) 128 MBs of RAM, not nearly enough.
So I moved the process to a server with huge amounts of RAM. Execution time went from 12 hours to 20 minutes. A problem that was being blamed on the fact that the code was interpreted was in fact sloppy class file handling leading to memory bloat. I think it very likely that most of early JVM issues with performance had to do with memory bloat. That could be true even if I'm completely wrong about the source compiler.
The period you're talking about was just before Geocities was absorbed by Yahoo. In those days it was less about free hosting and more about social networking. Kind of ahead of their time in that way, though the social networking features they had didn't really compare to current sites.
Also, 1997 was when they introduced advertising. If they'd managed to make the advertising less obtrusive, they might have been OK. But as it was, they quickly drove the more clueful users away. The people who stuck around were the clueless types who think that flashing banners are cool. The rest is history.
Several people have told me that my understanding of Stallman's position on distributing binaries was wrong. I'll accept that.
On the issue of Software as a Service, I wonder if he would say it was OK if the hosted application was "free". I lack the patience to parse his convoluted arguments in order to figure that out.
All that really means though is you don't have to write a "public static void main" to create your main window since it's already provided by the environment creating your applet.
Dude, that's a fundamental difference in the structure of the software. It means the whole thing is using a major variant of the runtime. Calling that a small change is like saying an a change from "printf" to "shutdown" is a small change.
Do you need this environment to run a JWS application? No you don't. If you don't need the applet environment, it's not an applet.
Notice the "NDA declined". Always standing on principle.
I suspect that if somebody pointed out the inconsistency to him, he'd come up with one of his long, complicated monologues arguing that there's no inconsistency. His arguments require a huge amount of effort to parse, never mind refute. Not worth the trouble. I'll content myself with refuting the arguments of his fanboys, who haven't mastered the art of rhetorical carpetbombing.
We can argue all day about which is better. I'm not really an expert. The simple fact is that Java applets are drastically less popular than all the alternatives. That must suck if you think Java is the better technology, but it's the way things are.
I don't have any references either. But it was a design goal for the HotSpot virtual machine. The idea is that HotSpot optimizes code after the application has started running based on what code is being heavily used. Hence the name: VM identifies and optimizes execution "hot spots".
Does this work as well in practice as in theory? You got me. But in the case of C++ native code, you can't even do it in theory.
I'm talking about when they decided to try and fight a rear-guard action with XNews, they should have open-sourced NeWS as well.
And I already explained, twice, why there was no incentive for them to do that. I can't make you listen to my argument, but if you're not going to bother, I don't see why I should bother with yours.
The issue isn't how big the applet API is, the question is whether JWS applications use it. And they don't.
Look, an applet is a particular kind of Java application, and JWS applications just aren't the same. Unless you're going to insist that all Java GUI applications count as a applets, in which case I hope you and Humpty Dumpty will be very happy together.
I'm no expert on compilers. But my source certainly was: David Griswold, the original lead for HotSpot project. Now, this conversation happened more than a decade ago, so it's possible I misremember it. And of course it's always possible I misunderstood it. But I don't think I did.
Note that he didn't say "government R&D". I take that to mean that some of that 3% will be government spending (which Obama can increase directly) and some of it will be private (which Obama can increase through various incentives).
According to the NSF, R&D versus GDP is now about 2%, and was 2.8% as late as 1992. So a goal of 3% is actually only a 50% improvement, and only slightly better than levels we've actually achieved in the past.
One thing that's bothered me for some time: corporations seem to be less and less interested in investing in R&D to develop new products. Instead, they spend it on advertising to push the products they already have. Or else they spend huge sums to acquire companies whose products look promising.
Big Pharma is extremely addicted to both strategies. (Notice all the drug commercials and news about mergers.) And yet when anybody complains about drug prices, they point to the need to earn back their R&D costs. If only that were true!
Any, the O guy is right: this is not something we can afford to skimp on. Science and technology have always been important to both our economy and our sense of WTF we are. The way we've let them slip is both shameful and short-sighted.
Slashdot Mirror
The interactive examples make it a far better learning experience than a book.
Not to mention the sheer coolness of that feature.
I've always found it ironic that there are so many books about the web. Authors trying to tell you how great the web is and what you can do with it, but not using it themselves. This author didn't even put his examples online. I stopped reading the review when I saw that.
I read an article a couple days ago, apparently there was a swine flu outbreak in 1976, and the US was quite proactive in stopping it, encouraging everyone to get vaccinated. The problem came when more people died from the vaccine than from the flu.
Indeed. Between putting his full weight behind the immunization effort and pardoning Richard Nixon, Gerry Ford lost any chance of getting elected to a full term as President. And of course, if he hadn't pushed the immunization effort and people had died from the flu...
I do wish there were some way to eliminate all the drama. It's causing all kinds of overreaction. Today, the cafeteria where I work pulled a roast pork entree from the menu. Never mind that you can't get the flu from eating pork. Nor from the other animals that carry the virus, names birds and people. That last one is not recommended for totally unrelated reasons.
I do wish we could get rid of all these stupid "threat levels" bugs, terrorists, and other such stuff. It might seem very kewl to go all Hollywood with your communications, but it does a lot to aggravate the overreaction. If you want to tell people they need to get their pandemic safeguards in place, why can't you just say that? This THREAT LEVEL 5 nonsense is stupid.
Many of the "re-usable" elements of the space shuttle turned out to be more expensive per flight than discardable elements would have been.
The space shuttle was poorly planned from beginning to end. First they tried to do it on the cheap, then they spent gobs of money kludging on fixes for their initial mistakes — kludges that have killed way too many astronauts. The only lesson I take away from the shuttle program is that if Congress refuses to give you a proper budget for building a spacecraft, don't try to build it anyway.
Nor do I buy the "cheap throwaway booster" concept. Saturn V launches cost three billion 2009 dollars. Each. Perhaps economies of scale and clever design could bring that cost down by 2/3. (I'm skeptical, but let's suppose.) Do you think you can get somebody to give you a whole gigabuck just to land a few thousand pounds on the moon? Never mind the hundreds of launches it would take to do anything serious, like build and supply a permanent moon base or mount an interplanetary expedition.
It goes against all reason to assume that littering the Atlantic ocean with billions of dollars worth of debris is the most cost-effective way to get into space. The idea never would have gained traction, except in an administration that loved to make grand plans, but always dodged cost issues and had no capacity for thinking through the consequences.
Uh, did you notice that this is a printed book?
Web design is something I don't do on a regular basis, so I often have to google for information on constructs and idioms I'm rusty on or never learned. Half the time I end up on the W3 Schools site. Each topic is nicely self-contained, simple, and clear, making the site an excellent reference source. Best of all, there's a dynamic HTML "try it yourself" feature which lets you quickly tweak an example and immediately see the results.
Over the years, this site has gotten slicker and added more and more content. All of which seems to be funded by a few non-obtrusive ads. Nice to see a web resource that provides a quality service and manages to make a living doing it.
Ok, so the design is based upon rockets, but does it mean that it uses *no* aerodynamic braking at all?
I'm sure it does. Hard to imagine that they could carry enough fuel to rely solely on the rockets for braking.
But they still need to land. Since you're moving relatively slow at this point (but still fast enough to kill your crew) you can't airbrake with your vehicle body. At this point you have to deploy a system that works at relatively slow speeds. Most spacecraft rely on parachutes, sometimes supplemented by the extra cushioning of an ocean landing. But this doesn't give you a lot of control over how you touch down, and you really need it if you're going to design a reusable vehicle.
And we really need to reuse more of our space hardware. We'll never have a self-sustainable business model for space travel as long as all our expensive hardware is one-use-only.
The Shuttle implements precision landing by turning into a glider after the aerodynamic braking is done. (I still think this is the best model; the Shuttle's problems stem from skimping on other features of the design.) The Russians would seem to have decided that landing rockets are a better approach (pun unavoidable).
Right, nobody cares who controls the Senate. Except those silly people who waste all their time worrying about the health care system, terrorism, climate change (or the myth thereof), network neutrality, civil liberties, crime in the streets, and other trivial stuff. Don't these people have a life?
assuming the Franken debacle does indeed go to Franken, which is perfectly consistent with every decision on the margin that the court has been making
and that the decision gets made before Franken's term expires!
I have to point out a simple double standard here: when Al Gore dragged out the fight over Florida into December, the Republicans accused him of being a "poor loser". Yet they seem to see nothing wrong with dragging out the fight over this Senate seat into May — and probably far beyond.
"the biggest impact on Java application performance was bad source code compilers"
Notice the absence of "hotspot" from that sentence. How you could even think that I was referring to hotspot just totally baffles me.
Is either Cablevision?
Yeah, some neighborhoods have competing cable companies and FiOS. But not a lot. For most of us, it's the monopoly cable company or make do with DSL.
There's a FiOS provider in my neighborhood that charges $50 for 100 Mb! But they don't serve my area, and they won't even tell me what areas they do serve. Judging from their web site, they basically cater to new housing development where they can piggyback the other utilities. And maybe the developer gives them a small subsidy, which they will more than get back in higher home values.
I've no idea where you've got that definition of JIT, but it's certainly not a common one.
I suppose I shouldn't be so rigid about how that term is used. My attitude probably comes from working with the HotSpot people, who always made a point of distinguishing between what JITs did and what their compiler did.
Of course it's a compiler. It's not a source code compiler.
Never said it was.
He was probably talking about memory used by HotSpot itself for compilation...
That's not at all how I recall the conversation. I honestly believe you're getting this issue wrong, but I don't have the background to argue with you intelligently. So let's just agree to disagree, shall we?
a well-optimized interpreted program is still slower than a native code program
Sigh. That kind of blanket statement is precisely the kind of oversimplification I'm trying to debunk. If execution of the program code is the bottleneck in a program, then yes, interpreted code is always faster than native code. But code execution is not always a bottleneck. I very much doubt that it was a bottleneck in all those early Java programs that established Java's reputation as glacially slow. Those would have been mostly simple GUI apps that didn't have to do anything compute intensive — there wouldn't have been enough interpretation going on to impact the application so thoroughly. Even if I'm totally wrong about the source compiler, you can't possibly blame the interpreter for all the slowdown. There must have been issues elsewhere (class loading? memory allocation? linking to native code?) in order to account for these issues. Even if I'm totally wrong about the source code compiler, it just makes no sense to focus so thoroughly on the bytecode interpreter when assigning blame for performance issues.
Cablevision, do you hear me?
Doesn't matter if they do. Since cable companies aren't required to support any ISP except their own, Cablevision couldn't start up in Texas even if they wanted to.
HotSpot is not a JIT. A JIT is something that compiles an entire class when it's loaded. HotSpot only compiles hot spots.
And it is a compiler. Not a source code compiler, obviously, but the people who built it (I worked with them as a tech writer for several months) still considered it a compiler. Of course, parsing byte codes is not nearly as complex as parsing source code (you could even say it's trivial) but parsing is only part of what a compiler does. Just as important, and a lot more difficult, is the compiler's job of generating optimized object code.
The conversation about memory leaks occurred while Griswold was doing a "brain dump" of HotSpot's innards for the benefit of a video camera and some interested engineers. When he started talking about how HotSpot cleaned up orphaned memory, I asked him why there was any orphaned memory to clean up, since the Java memory model doesn't allow for programmer allocation of memory. He blamed the fact that current Java source compilers had been hastily adapted from C++. I assume that's long since been fixed.
Does that make sense in terms of compiler design? I wouldn't know. But that's what I remember.
However, it's worth keeping in mind that HotSpot only appeared in Java 1.2. Before that, it was pure interpreted bytecode.
Yes and no and that's beside the point. Yes, the original JVM was a pure interpreter. But no, the Symantec JIT was a standard part of the JRE by the time I started working at Sun in 1997. And beside the point, because the usual assumption that an interpreted program is always slower than a native code program is too simplistic.
A software application is a complicated beast, and code execution is only one of many potential bottlenecks. The one I've seen most often is a shortage of RAM, which causes a lot of virtual memory "thrashing". I used to see this a lot when I did SOHO consulting, and had the same argument with every single client: no, a faster CPU won't make Word run faster, try installing more RAM.
And of course memory leaks are a good way to bloat memory.
I actually ran into this issue when I was working on Java 1.1 documentation. (This is an example of memory bloat, but not memory leakage.) Part of my job was to generate the API documentation from the source code, using JavaDoc. When I took over this process, it took 12 hours to run on a Sun workstation. The writer who had done it before me just assumed it was the interpreter being a slow interpreter. That didn't make sense to me, but I didn't know enough about the technology to offer an alternative explanation.
Then I went to a talk by a guy who was developing big Java applications. One of his complaints about the current JVM was that it re-inspected every class file on a regular basis, which meant that every class file you loaded had to remain part of the program image throughout program execution. (He had a workaround for this that I no longer remember.) A light bulb went off in my head: JavaDoc gets class information by inspecting the class file itself (easier than parsing the source code, I guess). That meant that my JavaDoc run was loading every single class into memory! Its footprint must be huge! The workstation I was using had (I think) 128 MBs of RAM, not nearly enough.
So I moved the process to a server with huge amounts of RAM. Execution time went from 12 hours to 20 minutes. A problem that was being blamed on the fact that the code was interpreted was in fact sloppy class file handling leading to memory bloat. I think it very likely that most of early JVM issues with performance had to do with memory bloat. That could be true even if I'm completely wrong about the source compiler.
The period you're talking about was just before Geocities was absorbed by Yahoo. In those days it was less about free hosting and more about social networking. Kind of ahead of their time in that way, though the social networking features they had didn't really compare to current sites.
Also, 1997 was when they introduced advertising. If they'd managed to make the advertising less obtrusive, they might have been OK. But as it was, they quickly drove the more clueful users away. The people who stuck around were the clueless types who think that flashing banners are cool. The rest is history.
Was the design goal to yield faster programs than contemporary C++ compilers...
Yes. That was explicitly stated in early white papers and presentations.
Several people have told me that my understanding of Stallman's position on distributing binaries was wrong. I'll accept that.
On the issue of Software as a Service, I wonder if he would say it was OK if the hosted application was "free". I lack the patience to parse his convoluted arguments in order to figure that out.
All that really means though is you don't have to write a "public static void main" to create your main window since it's already provided by the environment creating your applet.
Dude, that's a fundamental difference in the structure of the software. It means the whole thing is using a major variant of the runtime. Calling that a small change is like saying an a change from "printf" to "shutdown" is a small change.
Do you need this environment to run a JWS application? No you don't. If you don't need the applet environment, it's not an applet.
Good question. I tried to google an answer, but this is the best I could come up with:
http://www.webweavertech.com/ovidiu/weblog/gallery/richard-stallman/richard-stallman-Pages/Image0.html
Notice the "NDA declined". Always standing on principle.
I suspect that if somebody pointed out the inconsistency to him, he'd come up with one of his long, complicated monologues arguing that there's no inconsistency. His arguments require a huge amount of effort to parse, never mind refute. Not worth the trouble. I'll content myself with refuting the arguments of his fanboys, who haven't mastered the art of rhetorical carpetbombing.
We can argue all day about which is better. I'm not really an expert. The simple fact is that Java applets are drastically less popular than all the alternatives. That must suck if you think Java is the better technology, but it's the way things are.
I don't have any references either. But it was a design goal for the HotSpot virtual machine. The idea is that HotSpot optimizes code after the application has started running based on what code is being heavily used. Hence the name: VM identifies and optimizes execution "hot spots".
Does this work as well in practice as in theory? You got me. But in the case of C++ native code, you can't even do it in theory.
I'm talking about when they decided to try and fight a rear-guard action with XNews, they should have open-sourced NeWS as well.
And I already explained, twice, why there was no incentive for them to do that. I can't make you listen to my argument, but if you're not going to bother, I don't see why I should bother with yours.
There isn't much applet specific API really...
The issue isn't how big the applet API is, the question is whether JWS applications use it. And they don't.
Look, an applet is a particular kind of Java application, and JWS applications just aren't the same. Unless you're going to insist that all Java GUI applications count as a applets, in which case I hope you and Humpty Dumpty will be very happy together.
And I'd support shooting all the Slashdot idiots who just have to get in the last word, no matter how inane that word is.
I'm no expert on compilers. But my source certainly was: David Griswold, the original lead for HotSpot project. Now, this conversation happened more than a decade ago, so it's possible I misremember it. And of course it's always possible I misunderstood it. But I don't think I did.
Note that he didn't say "government R&D". I take that to mean that some of that 3% will be government spending (which Obama can increase directly) and some of it will be private (which Obama can increase through various incentives).
According to the NSF, R&D versus GDP is now about 2%, and was 2.8% as late as 1992. So a goal of 3% is actually only a 50% improvement, and only slightly better than levels we've actually achieved in the past.
One thing that's bothered me for some time: corporations seem to be less and less interested in investing in R&D to develop new products. Instead, they spend it on advertising to push the products they already have. Or else they spend huge sums to acquire companies whose products look promising.
Big Pharma is extremely addicted to both strategies. (Notice all the drug commercials and news about mergers.) And yet when anybody complains about drug prices, they point to the need to earn back their R&D costs. If only that were true!
Any, the O guy is right: this is not something we can afford to skimp on. Science and technology have always been important to both our economy and our sense of WTF we are. The way we've let them slip is both shameful and short-sighted.