Yes, the cuts in research are plain stupid. They may save money in the short term but will cost far more in the long term. It's like dropping out of college to save money and working minimum wage. Maybe you won't go into debt as much in the short term, but in the long term... Even a first grader can understand how stupid this is.
Which is why being the first or only child has some major drawbacks -- you are basically the crash test dummy. (Of course, being first/only has advantages too.)
Funding source is highly dependent on field. In CS and ECE, the majority, probably the vast majority, comes from the NSF, DoD, and DOE.
It may seem that research funded with public money should provide the technology for the greater good, but the Bayh-Dole Act allows U's to get patents. Regardless of whether you like this or not, one point in its favor is that it prevents a company from effectively "stealing" such ideas by getting their own patents on all the conceivable extensions of the university's research.
These are all great sentiments. But the average person isn't a lawyer and doesn't understand exactly what is fair use. So just to be safe, they respond to any threat or reported threat and end up giving up their fair use rights. Nor do they have time to do the research to figure out whether a particular use they are contemplating is safe. Hmm, spend time with the family, or research fair use?
The only way this is going to be solved is to spell out in very concrete, specific examples, what is clear fair use, what clearly isn't, and what's in the grey zone. If these companies really care about defending fair use, they'll do this. But of course, they might accidentally be construed to be giving legal advice, and they might even make a mistake, and be held liable. So just to be safe, they won't.
...if there were, the langauge wars of the 80s and 90s would have produced an answer. And what new langauge caught on? Not Sisal, or C*, or Multilisp, etc. It was Java. And C, C++, and Fortran are still going strong.
Part of the problem, as previous posts have observed, is that most people didn't have much incentive to change, since parallel systems were expensive, and bloated, ineffeicient code would inevitably get faster thanks to the rapid improvement in single-thread performance that we enjoyed until recently. So outside of HPC and cluster apps, most parallelism consisted of decoupling obviously aynchronous tasks.
I don't think there ever will be one language to rule them all.... The right programming model is too dependent on the application, and unless you are designing a domain-specific system, you will never get people to agree. Depending on your needs, you want different language features and you make different tradeoffs on performance vs. programmability. For some applications, functional programming languages will be perfect, for others Co-Array Fortran will be, for others an OO derivative like Mentat will be, etc. And as new applications come to the fore, new languages will continue to spawn.
I think the key is to:
Do your best to estimate what range of applications your chip will need to support (so you could imagine that chips for desktops/workstations might diverge from those for e-commerce datacenters--which we already see to a mild extent)
Deduce what range of programming language features you need to support
Do your best to design an architecture that is flexible enough to support that, and hopefully not close off future ideas that would make programming easier.
If one programming model does triumph, I would predict that it will be APIs that can be used equally well from C, Fortran, Java, etc., thus allowing different application domains to use their preferred APIs. And even that model is probably not compelling enough to bring them all and in the dark bind them....
Centralized computing and data storage for compact and/or mobile devices; reliability, availability, backup (as many other posters have mentioned); professional management; consolidation via virtualization; etc.
If I buy my own hardware and deal with all the above issues, only to have it underutilized, that's an incredible waste when a data center can consolidate many services on the same hardware and consolidate management across all these services using the same staff.
Versions of his idea have been floating around for some years now. I don't mean to be sour grapes, but not much novelty here, IMHO.
I think the real need is one of mobility. We're tied to our laptops/desktops because they have OUR applications, OUR environment, configured OUR way, with OUR data. If we could create an appliance that allowed us to carry all of that with us, or network protcols that gave us fast, 24/7 access to those reosurces, then we are not tied to a specific device or place. Right now we are tied to a specific computer for some tasks (e.g. work that requires our personal environment to be productive), or to a specific device (e.g. for listening to music). This is starting to change in exciting ways, but we're certainly not there yet.
I'm not saying we access all that data with the same device or interface, only that it's mobile. We still might normally access that data through different devices, but we would have more flexibility. So a cell phone is a reasonable candidate for this "hub"-like function, in the so many people carry it with them all the time. A wristwatch might be an even better candidate, although the interface to such a tiny object would be an obstacle.
In short, I see the issues of data mobility and interface as distinct concerns./K
Slashdot Mirror
Yes, the cuts in research are plain stupid. They may save money in the short term but will cost far more in the long term. It's like dropping out of college to save money and working minimum wage. Maybe you won't go into debt as much in the short term, but in the long term... Even a first grader can understand how stupid this is.
Spoken as an only child and a parent. :)
Funding source is highly dependent on field. In CS and ECE, the majority, probably the vast majority, comes from the NSF, DoD, and DOE.
It may seem that research funded with public money should provide the technology for the greater good, but the Bayh-Dole Act allows U's to get patents. Regardless of whether you like this or not, one point in its favor is that it prevents a company from effectively "stealing" such ideas by getting their own patents on all the conceivable extensions of the university's research.
These are all great sentiments. But the average person isn't a lawyer and doesn't understand exactly what is fair use. So just to be safe, they respond to any threat or reported threat and end up giving up their fair use rights. Nor do they have time to do the research to figure out whether a particular use they are contemplating is safe. Hmm, spend time with the family, or research fair use?
/K
The only way this is going to be solved is to spell out in very concrete, specific examples, what is clear fair use, what clearly isn't, and what's in the grey zone. If these companies really care about defending fair use, they'll do this. But of course, they might accidentally be construed to be giving legal advice, and they might even make a mistake, and be held liable. So just to be safe, they won't.
Argh!
Part of the problem, as previous posts have observed, is that most people didn't have much incentive to change, since parallel systems were expensive, and bloated, ineffeicient code would inevitably get faster thanks to the rapid improvement in single-thread performance that we enjoyed until recently. So outside of HPC and cluster apps, most parallelism consisted of decoupling obviously aynchronous tasks.
I don't think there ever will be one language to rule them all.... The right programming model is too dependent on the application, and unless you are designing a domain-specific system, you will never get people to agree. Depending on your needs, you want different language features and you make different tradeoffs on performance vs. programmability. For some applications, functional programming languages will be perfect, for others Co-Array Fortran will be, for others an OO derivative like Mentat will be, etc. And as new applications come to the fore, new languages will continue to spawn.
I think the key is to:
If one programming model does triumph, I would predict that it will be APIs that can be used equally well from C, Fortran, Java, etc., thus allowing different application domains to use their preferred APIs. And even that model is probably not compelling enough to bring them all and in the dark bind them....
Centralized computing and data storage for compact and/or mobile devices; reliability, availability, backup (as many other posters have mentioned); professional management; consolidation via virtualization; etc. If I buy my own hardware and deal with all the above issues, only to have it underutilized, that's an incredible waste when a data center can consolidate many services on the same hardware and consolidate management across all these services using the same staff.
I like to have a dose of espresso before meditating. It makes it more challenging. /K
This is my first post, so be kind... :)
/K
Versions of his idea have been floating around for some years now. I don't mean to be sour grapes, but not much novelty here, IMHO.
I think the real need is one of mobility. We're tied to our laptops/desktops because they have OUR applications, OUR environment, configured OUR way, with OUR data. If we could create an appliance that allowed us to carry all of that with us, or network protcols that gave us fast, 24/7 access to those reosurces, then we are not tied to a specific device or place. Right now we are tied to a specific computer for some tasks (e.g. work that requires our personal environment to be productive), or to a specific device (e.g. for listening to music). This is starting to change in exciting ways, but we're certainly not there yet.
I'm not saying we access all that data with the same device or interface, only that it's mobile. We still might normally access that data through different devices, but we would have more flexibility. So a cell phone is a reasonable candidate for this "hub"-like function, in the so many people carry it with them all the time. A wristwatch might be an even better candidate, although the interface to such a tiny object would be an obstacle.
In short, I see the issues of data mobility and interface as distinct concerns.