Actually, the motivation for the bias may be what you claim, but the error seems to a rather common, and completely unconscious, misunderstanding of causal relationships. The same kind that makes people believe in astrology, telepathy or what-have-you because of a single unrepeated coincidence in their life.
It's rather likely that psychedelics were present, and influential, in the birth of culture.
After all, currently the main use of our advanced and transgenerational communication skills is to communicate pleasurable, strong, preferably ecstatic sensorial experiences (in either the mystical sense or as an epiphany): we spend more time and effort discussing about movies, books, music, computer games than the technology that makes them possible. Religion is a major part of our culture, and separate (if complementary) of government mainly because of its capacity to induce altered states of mind.
Without the infrastructure that permits these in their modern forms, other extreme experiences have to take their place or support their primitive equivalents. Psycheledics seem to provide one hell of an interesting experience, since drug-induced altered states of mind so commonly an integral part of religions and traditions of cultures with simpler infrastructure (and depending on how integral you consider the Happy Hour, modern ones too).
So it's very likely, and there's apparently evidence, of a close relationship between increasing complexity of culture and use of psychedelics if they're available in the same area. It's not like they could get excited about neoplatonistic philosophy right off the bat.
But unless there's an experiment showing sign-language-skilled primates developing new cultural infrastructure when they're stoned, it's remarkably idiotic to see a causal connection.
It's a much simpler hypothesis that once humans could develop a culture and talk about interesting things, and drug consumption being an available and much more interesting thing than watching the grass grow, they would do it a lot, talk about it a lot, and use it a lot as an element in their cultures.
You might want to try reading the articles before ranting against the "entire genetic engineering field" if you want to talk about folly.
They specifically say that the "trait" they're talking about may include "as few as 10 or as many as 10,000" genes.
They never claimed this gene was responsible for that trait.
They specifically said this was just one remarkable breakthrough among many that suggests that our current language skills depend on recent genes, more recent than what we normally call "the human species".
In other words, their hypothesis is that it was impossible for anatomically correct humans lacking MANY SIMULTANEOUS mutated genes to develop complex languages and cultures, and have what we would consider a normal human psychology. And they claim that these mutations are probably recent.
No one claims to have pinpointed the origin of "culture" in the genome and how it worked, or even expect to at any foreseeable future.
They just say if you can show anatomically correct humans have problems developing complex cultures if a few genes are not "normal", and the "normal" versions of the genes can be proven to be recent, then it follows that it might have been difficult for anatomically correct humans lacking those genes, as a set, to develop complex culture, and it would be reasonable to say they were necessary for that process.
That's a much more timid, reasonable claim than "the stuff C.G. Jung was saying will become understood in a genetic way", by the way.
a) Iraq were the only country who could do this or had any interest in doing so (it's not the biggest threat in either sense) b) Iraq were the only country helping terrorists or with a history of helping terrorists (other countries have more evidence of each). c) The US were the only country who helped in the past, helps in the present, or will help in the future political allies to get their hands into dangerous military technology.
The Iraq case is just probably what brought this idea up, but the idea won't go away with Iraq. They're not "trying to stop Iraq". They're not "trying to stop anyone".
They want people not to point the finger to them when some overambitious third-world country builds something similar to what they published, and it ended up in the hands of some terrorist somewhere in the US.
Putting all sophistry regarding the new 'terrorist' definition, the government was not the one planning censorship.
This was a suggestion of self-censorship from the science journals editors.
They're motivation may or may not be the same as the government at a particular point, but I don't think they're all members of the Republican party and have dinner with Dick Cheney after golf.
What could be the motivation of these EDITORS to SELF-CENSOR?
Would they really be afraid terrorist cells replicating dangerous research?
No.
But they could be afraid of governments replicating that research and giving the results to terrorists.
Whatever hostilities Bush sees in Europe, the science journals are probably not thinking about France at this point.
I think research facilities are harder to keep running than most would like to think. So is coming up with the information (especially the personnel to FILTER the information and come up with something useful and practical).
I don't agree with the policy, but I can understand the motivation.
Embargoes of certain materials do present problems for governments engaging in such practices.
The problem is that information is not practical to embargo. It will either be pointless because too many people will have access to the information anyway (universities worldwide) for the embargo to hold, or it will hold but affect precisely the people who NEED the information to do research (universities worldwide).
It's true that terrorists, using the typical meaning of the word, are unlikely to base their weapons in current research.
It's not just that they don't "need" it. I'm sure there are advantages to new toxins, viruses and bacteria that they would like to exploit.
But by its very nature, recent research has not been "tried and tested", and is often quite expensive.
As you say, why waste a lab full of expensive equipment for your terrorists, and the required grad-student-level people, to replicate the latest experiments published by scientists in well-equiped universities and institutes all over the world? It's not cost-effective.
It's much more efficient to use methods that have been tried, tested, industrialized and made cost-effective through decades of legal and illegal use in war. You don't need as many, or as well educated, technical people to man that kind of operation. It's not like those methods don't kill people.
But all this is based in the traditional meaning of "terrorist", which I don't think is what they're aiming at here. They're aiming at the new definition of "terrorist", that amalgamation of terrorist organizations and nation-states that support them and/or are hostile to the "western democracies".
Perhaps Al Qaida would see bio-weapons research as too expensive, much like nuclear weapons research. But other nations (hint: Iraq) have the budget and the manpower to pay for mass-production facilities, as well as the movitation (increasing military ergo political power).
I don't think they're afraid of terrorist organizations replicating their research. I think they're afraid of Iraq or someone else doing that, then selling or giving the weapons to terrorist organizations.
I share your opinion (and practice) that most of the times, in the practical sense, it's better to violate the sacredness of MVC with JSP.
When a custom tag already provides an easy-to-use and easy-to-setup abstraction to access the database, to create some bean/utility-class/extra-code just to get a resultset seems cumbersome and useless. The data access layer duplicates functionality and gets in the way in small JSP projects, it seems, because the tags can do that work in two lines.
Something I do when the project starts to grow and I start to feel uneasy about those SQL statements is to use JSP fragments as my data layer, and call them as functions through jsp:include tags.
Since the JSP tag I typically use translates the resultset into collections, nothing stops me from switching data sources and data fetching methods without touching presentation code. All I have to do is make sure the data layer JSPs store the expected object where I expect it in the request object, and assign it to a local bean/variable if I must.
Some may consider it hackish, and some may have some prejudice to use JSP for anything but presentation, but it makes it very easy to move from a prototype with a bunch of repeated-and-embedded SQL to something cleaner without redesigning, or reimplementing, that much.
Then, if you really need a cleaner abstraction than that, with your own data access classes, your data access JSPs are only another layer and moving there is even easier, and doesn't touch any other code.
On the first point, yes, the more I think about it the more I see no technical reason why the complex run-time issues handled by the VM cannot be handled by suitable complex compiled code. But there would be little practical advantage. I would think as more applications are loaded the memory utilization would explode, for example.
Personally I'm not a big fan of the cross-platform myth. I think the VM in Java is a good idea because it's "safer" and that matches Java's target... Java's uniformity makes the code both "safe", very flexible, and relatively portable.
If all these advantages can be preserved in a traditional compiled language or a compiled version of Java, I'll do the appropiate ritualistic victory dance. Then the VM vs non-VM will become just an issue of benchmarks, not features.
So far, the direction seems to be quite opposite:.Net is based, as I understand, on a VM precisely to make those features possible... "managing" the code seems necessary.
On the second point: I think the big-iron enterprise is quite interested in the ability to run "arbitrary code", and not just for the clients that are pulling off the applications from the network, but most for Application Servers, which are definitely server-side.
Although the code running on an expensive server is not strictly arbitrary, it could be from many a point of view (me thinks) because of logistics (or lack thereof). As the server running the application-server is bigger, faster, and more expensive, it is shared among more organizational units with different applications.
If these applications are running inside an "Application Server" or similar environment to share resources, they need to be controlled and secured regardless of what they are (if they're not, they're not sharing resources and services which is a big waste of development time, memory and cpu).
To Joe in HR, the code from Kathy in RD is for all purposes arbitrary, and invisible too, as are those statistical apps for marketing, or the apps from billing, etc. To the sysadmin probably everything is arbitary. To the developers of the application server (even if it's in-house), it's all arbitrary anyway. Since each organization has its own private information, it shouldn't be any other way.
It's also probably unfeasible to audit all the code properly per unit, much less to audit it for unwanted interactions. They should, but if it would only take a novice programmer's mistake in a tiny unit given access to the server to bring it down, it will go down some day.
With deadlines and enough managers, I don't think tightly securing a server against premature deployment of buggy code is feasible.
On the other hand, even if it is, it's probably not cost-effective. If you paid big money for big iron, you want to use it. If you spend even more money and time testing for months before deploying the application, and even then often deploying on small iron just in case, what's the use? You want to run as many applications as you want on this thing, that's why you paid for it.
If you can skip the "interaction testing" and deploy the application with minimal risks, it could save a lot of money. Then you can test the application to see that it works, that it doesn't crash the JVM (it happens), and that the customers are happy, and deploy much, much earlier. You don't have to worry about it having access to your billing records, or replacing classes accounting needs with incompatible versions.
To be a bit more concrete than in my other comment, I mentioned that:
'Restarting your application server to load/update a class is not fun, particularly when it's expensive downtime.'
I should add:
When an enterprise buys that expensive application server, they prefer to still have to restart the app-server every time they update a class than to have it crash, lose or compromise data because a stranger (or an unskilled programmer) was able to update/load a new class.
That I can recompile and update servlets in my web-app without restarting the server is convenient. That I can't see/touch other people's applications with which I share the server, even when I get my code into the machine (JVM), is vital.
It's dynamically loading a class with a number of conditions: type-safety, lazy runtime checks and loading, class-loading customization, isolated contexts/namespaces with their own classes and security policies, etc.
As far as I understand, the issue is that what Java provides requires a lot from the run-time system: type-safety checks, security checks, etc. which is provided by the VM.
I don't know if this could be provided by compiled code, but my guess is that if it could, it would duplicate most of the VM into a runtime system for the running program. So each executable would bring a hefty and redundant RE along with it.
The difference, it seems to me, is that Java assumes the code to be dynamically loaded to be unsafe and to come from an unknown source (network), and loaded through an unknown protocol (custom class loading), under unknown security constraints, all of which can be defined at runtime. So the VM has to be on top of everything.
I think other compiled programming languages are more trusting with their dynamically loaded modules, so the runtime environment code is probably less cumbersome.
I could be wrong, but I think the other languages that offer "safe" dynamic loading also have VMs.
Since Java makes money mostly from all those Enterprise/Web Application Servers, and these depend (a lot) on the ability to dynamically load classes into a flexible hierarchy of ClassLoaders with security restrictions and all that, dropping dynamic classloading would kill one big advantage of the language.
Restarting your application server to load/update a class is not fun, particularly when it's expensive downtime.
If you haven't seen dynamic classloading being used yet, it's probably because you're dealing with a subset of Java that's not as interesting for Sun, or you're not seeing through the abstractions.
You answered his question correctly, but your subject creates confusion.
While you covered very well "why can't The Sims Online be free?", it is not clear there are any reasons to pay for it.
It might also have helped if you mentioned why Battle.net APPEARS to be free, as well as many other multiplayer games: they're just services to connect players so they can set up P2P networks themselves. They don't have to host thousands of players interacting in a couple of servers running a virtual world. There's no way TSO can pay for their infrastructure with box sales (50 bucks pay for eternity?), unless they planned to shut down the game at some point.
In 1985 the public didn't want any of those features, and for good reasons.
Every one of those features is quite expensive, hardware and software-wise, and at the prohibitive cost of a basic workstation running on the single-digit Mhz, any of those ideas was a joke.
Why do they want them now?
Have they been educated, persuaded, or contaminated by relentless marketing? Have they found new uses for the technology? Perhaps only now do we have the expertise or the technical hardware to exploit them?
Even today, it's not that clear that they are "good" features for what were doing in 1985 with computers.
- Do we really need hardware-accelerated GUIs with 3D capabilities to create Excel spreadsheets? Is that Gouraud shading on the bar chart REALLY important?
- Sure, pre-emptive multitasking is a good idea from an operating systems POV. But in 1985 that was the wrong POV to take for personal computers. There were little resources for an OS to manage, and multitasking is a concept that costed too much in a single-user machine and most users don't grasp. The typical user that drives the market still works on a single document/task at a time.
- Multi-channel digital is still an unprofessional annoyance in office workstations, as anyone who drank coffee to the sound of 50 "Windows Start-up Chimes" at 7:00AM knows, or typed a report to the not-so-muted-headphone sound of a neighbor's latest kazaa find. The ability to include annoying MIDI music in a Powerpoint presentation may not compensate that...
The point is that these features are "good" for things that didn't exist in 1985, because they either were not possible, or the ideas that put them to use were in embryonic state:
- Digital sound beyond the warning beeps of the BIOS required special hardware to play and special software to process. This was developed in other markets, for other markets, before it found any use in the mainstream, and then it required a lot of other things to fall into place. It couldn't happen without computer games, but also it couldn't have happened inthe mainstream without the "multimedia" idea, which couldn't have happened without CD-ROMs among the masses AND without hyperlinked documents AND without hardware-accelerated GUIs.
Only then did the product make sense.
- GUIs as we know them couldn't take off, I believe, without the desktop publishing revolution, and the desktop publishing revolution couldn't take off without the primitive GUIs that promised, but didn't quite give what was needed for that. Until desktop publishing changed what "creating a document in the computer" implied, GUIs were not such an amazing product, much less the idea of hardware-accelerating them. In the terms of the article, it took some time to make complex GUIs a "whole product".
- Pre-emptive multitasking was demanded by the market when it became useful. They needed no education for that, although they may have used the less technical term "Calculator shouldn't freeze this crap, and make me lose my work in 7 other apps". Sure, it was delivered late and buggy, but they weren't promising it since the days of OS/2 development because of the nicety of their hearts. They didn't promise it when people didn't care about it, because they could never create a document using 7 applications at the same time before.
No, the article claimed it was the best "whole product". It was better at meeting the demands of the consumers.
When making qualitative comparisons, it's important to remember the standards under which you make the comparison. The article does not challenge the conclusions of the comparison that received wisdom provides, it challenges the standards of that comparison as irrelevant.
The market doesn't choose what is "best" per se, and I don't think the article points in that direction.
The market chooses what the market WANTS.
According to some definitions of product, including the "whole product" idea used in the article, a "good product" is a product that matches the market demands.
In that sense, the "best product" is the one that gives the market what it wants, and by the nature of the market, the dominant players tend to do that in a free market.
That doesn't mean the product is "better" from a technical, moral, or whatever other point of view you want, except from the point of view that it meets the desires of consumers.
The consumers might want inefficient vehicles, lousy paperback novels, kitschy pop culture or education aimed at the attention span of a 3-year-old on a glucose overdose. That doesn't mean that they're better vehicles, literature, culture or education, but if the public is more willing to pay for those, by definition they're better "products".
For some strange reason this beckons the idea of someone-less-than-brilliant putting a web server in one of these things.
Which would beg the question of what happens first:
- 1000 simulatenous HTTP request bring the car down. - 1000-cumulative-pounds of slashdot readers bring the car down (physically). - 1 slashdot reader makes a Bewoulf cluster of 1000 of these things.
3DRealms has announced that in order to meet the expectations of fans for Duke Nukem Forever, and to give them a better idea of WHEN it will be ready, it will stick to its promise to deliver a flying car with every box of the game.
"Actually, the game has been almost ready for some time..." said an anonymous insider source, "we've just been trying to bring down the costs of this flying car thing for the last couple of years."
Let's remove all the unique/useful components of the GNU/Darwin distribution.
Let's remove any motivation for Apple's customers to have any interest in using or touching GNU/Darwin.
Let's abandon PPC and remove any motivation for PPC-owners to keep an eye on GNU/Darwin.
Let's proclaim in ideological rage that GNU/Darwin will abandon its ties to propietary evilness and be reborn as Yet-Another-BSD-on-x86 with Yet-Another-Kernel.
Surely it makes sense for GNU/Darwin to compete with FreeBSD, OpenBSD, NetBSD, etc on the same old platform with practically no distinguishing factor or even aim. It's not like that would be redundant.
Surely Apple will see the light after their customers collectively blink and go on with their lives.
Someone has to nitpick... There is no "interview", it's just a nice short article on Stanislaw Lem, using the last movie as an excuse to call attention on an immensely underrated author.
The "interview" part consists of a single quote, taken from the public statement he published elsewhere about the criticisms to the North American version of Solaris.
The article is pretty good, though. I was unaware of some of the details of PKD's involvement in the SFWA debacle.
The approach to studying physics is also replicating well-known experiments with shoddy equipment, no experience, and predicted results.
This is not to educate scientist to repeat the same experiments over and over again. It's just that you cannot be expected to understand complex physics and create new experiments for new theories if you haven't seen and tried the building blocks first-hand.
They don't teach you to solve the Towers of Hanoi because it's a "common problem". They teach you to use recursion to solve problems, and to recognize a "recursion problem" by its characteristics, by using Towers of Hanoi as a common example.
I wonder what quality you claim to be forsaking...
I'm a big fan of Linux, and of Unix in general, but why exactly do you use an Operating System?
Since I don't have a mainframe in my room serving thousands of users with scarce memory and CPU-time, efficient resource administration is less of a priority than it was for Unix's original goal.
Stability is important, but my workstation doesn't need as many magic 9s as my web server. Booting once per week is really not that bad.
Personally, I run an OS to make my life easier. In other words, the quality I expect from an OS is "requires less effort to do what I want to do".
Slashdot Mirror
How is not publishing going to keep the information out of the hands of the CIA and US military?
It's not going to keep it out of their hands, but it will keep anyone from pointing their fingers at them (the editors).
After all, it's the US government that's mostly funding the experiments they publish in the first place.
Actually, the motivation for the bias may be what you claim, but the error seems to a rather common, and completely unconscious, misunderstanding of causal relationships. The same kind that makes people believe in astrology, telepathy or what-have-you because of a single unrepeated coincidence in their life.
It's rather likely that psychedelics were present, and influential, in the birth of culture.
After all, currently the main use of our advanced and transgenerational communication skills is to communicate pleasurable, strong, preferably ecstatic sensorial experiences (in either the mystical sense or as an epiphany): we spend more time and effort discussing about movies, books, music, computer games than the technology that makes them possible. Religion is a major part of our culture, and separate (if complementary) of government mainly because of its capacity to induce altered states of mind.
Without the infrastructure that permits these in their modern forms, other extreme experiences have to take their place or support their primitive equivalents. Psycheledics seem to provide one hell of an interesting experience, since drug-induced altered states of mind so commonly an integral part of religions and traditions of cultures with simpler infrastructure (and depending on how integral you consider the Happy Hour, modern ones too).
So it's very likely, and there's apparently evidence, of a close relationship between increasing complexity of culture and use of psychedelics if they're available in the same area. It's not like they could get excited about neoplatonistic philosophy right off the bat.
But unless there's an experiment showing sign-language-skilled primates developing new cultural infrastructure when they're stoned, it's remarkably idiotic to see a causal connection.
It's a much simpler hypothesis that once humans could develop a culture and talk about interesting things, and drug consumption being an available and much more interesting thing than watching the grass grow, they would do it a lot, talk about it a lot, and use it a lot as an element in their cultures.
You might want to try reading the articles before ranting against the "entire genetic engineering field" if you want to talk about folly.
They specifically say that the "trait" they're talking about may include "as few as 10 or as many as 10,000" genes.
They never claimed this gene was responsible for that trait.
They specifically said this was just one remarkable breakthrough among many that suggests that our current language skills depend on recent genes, more recent than what we normally call "the human species".
In other words, their hypothesis is that it was impossible for anatomically correct humans lacking MANY SIMULTANEOUS mutated genes to develop complex languages and cultures, and have what we would consider a normal human psychology. And they claim that these mutations are probably recent.
No one claims to have pinpointed the origin of "culture" in the genome and how it worked, or even expect to at any foreseeable future.
They just say if you can show anatomically correct humans have problems developing complex cultures if a few genes are not "normal", and the "normal" versions of the genes can be proven to be recent, then it follows that it might have been difficult for anatomically correct humans lacking those genes, as a set, to develop complex culture, and it would be reasonable to say they were necessary for that process.
That's a much more timid, reasonable claim than "the stuff C.G. Jung was saying will become understood in a genetic way", by the way.
Yup.
During the day, he's the annoying consultant(?) in that Verizon ad.
During the night, he's a spandex-wearing mutant patrolling modern-art galleries in NY.
Aye.
That would be true if and only if:
a) Iraq were the only country who could do this or had any interest in doing so (it's not the biggest threat in either sense)
b) Iraq were the only country helping terrorists or with a history of helping terrorists (other countries have more evidence of each).
c) The US were the only country who helped in the past, helps in the present, or will help in the future political allies to get their hands into dangerous military technology.
The Iraq case is just probably what brought this idea up, but the idea won't go away with Iraq. They're not "trying to stop Iraq". They're not "trying to stop anyone".
They want people not to point the finger to them when some overambitious third-world country builds something similar to what they published, and it ended up in the hands of some terrorist somewhere in the US.
Putting all sophistry regarding the new 'terrorist' definition, the government was not the one planning censorship.
This was a suggestion of self-censorship from the science journals editors.
They're motivation may or may not be the same as the government at a particular point, but I don't think they're all members of the Republican party and have dinner with Dick Cheney after golf.
What could be the motivation of these EDITORS to SELF-CENSOR?
Would they really be afraid terrorist cells replicating dangerous research?
No.
But they could be afraid of governments replicating that research and giving the results to terrorists.
Whatever hostilities Bush sees in Europe, the science journals are probably not thinking about France at this point.
Not really.
I think research facilities are harder to keep running than most would like to think. So is coming up with the information (especially the personnel to FILTER the information and come up with something useful and practical).
I don't agree with the policy, but I can understand the motivation.
Embargoes of certain materials do present problems for governments engaging in such practices.
The problem is that information is not practical to embargo. It will either be pointless because too many people will have access to the information anyway (universities worldwide) for the embargo to hold, or it will hold but affect precisely the people who NEED the information to do research (universities worldwide).
It's true that terrorists, using the typical meaning of the word, are unlikely to base their weapons in current research.
It's not just that they don't "need" it. I'm sure there are advantages to new toxins, viruses and bacteria that they would like to exploit.
But by its very nature, recent research has not been "tried and tested", and is often quite expensive.
As you say, why waste a lab full of expensive equipment for your terrorists, and the required grad-student-level people, to replicate the latest experiments published by scientists in well-equiped universities and institutes all over the world? It's not cost-effective.
It's much more efficient to use methods that have been tried, tested, industrialized and made cost-effective through decades of legal and illegal use in war. You don't need as many, or as well educated, technical people to man that kind of operation. It's not like those methods don't kill people.
But all this is based in the traditional meaning of "terrorist", which I don't think is what they're aiming at here. They're aiming at the new definition of "terrorist", that amalgamation of terrorist organizations and nation-states that support them and/or are hostile to the "western democracies".
Perhaps Al Qaida would see bio-weapons research as too expensive, much like nuclear weapons research. But other nations (hint: Iraq) have the budget and the manpower to pay for mass-production facilities, as well as the movitation (increasing military ergo political power).
I don't think they're afraid of terrorist organizations replicating their research. I think they're afraid of Iraq or someone else doing that, then selling or giving the weapons to terrorist organizations.
When a custom tag already provides an easy-to-use and easy-to-setup abstraction to access the database, to create some bean/utility-class/extra-code just to get a resultset seems cumbersome and useless. The data access layer duplicates functionality and gets in the way in small JSP projects, it seems, because the tags can do that work in two lines.
Something I do when the project starts to grow and I start to feel uneasy about those SQL statements is to use JSP fragments as my data layer, and call them as functions through jsp:include tags.Since the JSP tag I typically use translates the resultset into collections, nothing stops me from switching data sources and data fetching methods without touching presentation code. All I have to do is make sure the data layer JSPs store the expected object where I expect it in the request object, and assign it to a local bean/variable if I must.
Some may consider it hackish, and some may have some prejudice to use JSP for anything but presentation, but it makes it very easy to move from a prototype with a bunch of repeated-and-embedded SQL to something cleaner without redesigning, or reimplementing, that much.
Then, if you really need a cleaner abstraction than that, with your own data access classes, your data access JSPs are only another layer and moving there is even easier, and doesn't touch any other code.
On the first point, yes, the more I think about it the more I see no technical reason why the complex run-time issues handled by the VM cannot be handled by suitable complex compiled code. But there would be little practical advantage. I would think as more applications are loaded the memory utilization would explode, for example.
.Net is based, as I understand, on a VM precisely to make those features possible... "managing" the code seems necessary.
Personally I'm not a big fan of the cross-platform myth. I think the VM in Java is a good idea because it's "safer" and that matches Java's target... Java's uniformity makes the code both "safe", very flexible, and relatively portable.
If all these advantages can be preserved in a traditional compiled language or a compiled version of Java, I'll do the appropiate ritualistic victory dance. Then the VM vs non-VM will become just an issue of benchmarks, not features.
So far, the direction seems to be quite opposite:
On the second point: I think the big-iron enterprise is quite interested in the ability to run "arbitrary code", and not just for the clients that are pulling off the applications from the network, but most for Application Servers, which are definitely server-side.
Although the code running on an expensive server is not strictly arbitrary, it could be from many a point of view (me thinks) because of logistics (or lack thereof). As the server running the application-server is bigger, faster, and more expensive, it is shared among more organizational units with different applications.
If these applications are running inside an "Application Server" or similar environment to share resources, they need to be controlled and secured regardless of what they are (if they're not, they're not sharing resources and services which is a big waste of development time, memory and cpu).
To Joe in HR, the code from Kathy in RD is for all purposes arbitrary, and invisible too, as are those statistical apps for marketing, or the apps from billing, etc. To the sysadmin probably everything is arbitary. To the developers of the application server (even if it's in-house), it's all arbitrary anyway. Since each organization has its own private information, it shouldn't be any other way.
It's also probably unfeasible to audit all the code properly per unit, much less to audit it for unwanted interactions. They should, but if it would only take a novice programmer's mistake in a tiny unit given access to the server to bring it down, it will go down some day.
With deadlines and enough managers, I don't think tightly securing a server against premature deployment of buggy code is feasible.
On the other hand, even if it is, it's probably not cost-effective. If you paid big money for big iron, you want to use it. If you spend even more money and time testing for months before deploying the application, and even then often deploying on small iron just in case, what's the use? You want to run as many applications as you want on this thing, that's why you paid for it.
If you can skip the "interaction testing" and deploy the application with minimal risks, it could save a lot of money. Then you can test the application to see that it works, that it doesn't crash the JVM (it happens), and that the customers are happy, and deploy much, much earlier. You don't have to worry about it having access to your billing records, or replacing classes accounting needs with incompatible versions.
To be a bit more concrete than in my other comment, I mentioned that:
'Restarting your application server to load/update a class is not fun, particularly when it's expensive downtime.'
I should add:
When an enterprise buys that expensive application server, they prefer to still have to restart the app-server every time they update a class than to have it crash, lose or compromise data because a stranger (or an unskilled programmer) was able to update/load a new class.
That I can recompile and update servlets in my web-app without restarting the server is convenient. That I can't see/touch other people's applications with which I share the server, even when I get my code into the machine (JVM), is vital.
It's not just dynamically loading a class.
It's dynamically loading a class with a number of conditions: type-safety, lazy runtime checks and loading, class-loading customization, isolated contexts/namespaces with their own classes and security policies, etc.
As far as I understand, the issue is that what Java provides requires a lot from the run-time system: type-safety checks, security checks, etc. which is provided by the VM.
I don't know if this could be provided by compiled code, but my guess is that if it could, it would duplicate most of the VM into a runtime system for the running program. So each executable would bring a hefty and redundant RE along with it.
The difference, it seems to me, is that Java assumes the code to be dynamically loaded to be unsafe and to come from an unknown source (network), and loaded through an unknown protocol (custom class loading), under unknown security constraints, all of which can be defined at runtime. So the VM has to be on top of everything.
I think other compiled programming languages are more trusting with their dynamically loaded modules, so the runtime environment code is probably less cumbersome.
I could be wrong, but I think the other languages that offer "safe" dynamic loading also have VMs.
I just found This paper, which could be helpful.
Since Java makes money mostly from all those Enterprise/Web Application Servers, and these depend (a lot) on the ability to dynamically load classes into a flexible hierarchy of ClassLoaders with security restrictions and all that, dropping dynamic classloading would kill one big advantage of the language.
Restarting your application server to load/update a class is not fun, particularly when it's expensive downtime.
If you haven't seen dynamic classloading being used yet, it's probably because you're dealing with a subset of Java that's not as interesting for Sun, or you're not seeing through the abstractions.
You answered his question correctly, but your subject creates confusion.
While you covered very well "why can't The Sims Online be free?", it is not clear there are any reasons to pay for it.
It might also have helped if you mentioned why Battle.net APPEARS to be free, as well as many other multiplayer games: they're just services to connect players so they can set up P2P networks themselves. They don't have to host thousands of players interacting in a couple of servers running a virtual world. There's no way TSO can pay for their infrastructure with box sales (50 bucks pay for eternity?), unless they planned to shut down the game at some point.
In 1985 the public didn't want any of those features, and for good reasons.
Every one of those features is quite expensive, hardware and software-wise, and at the prohibitive cost of a basic workstation running on the single-digit Mhz, any of those ideas was a joke.
Why do they want them now?
Have they been educated, persuaded, or contaminated by relentless marketing? Have they found new uses for the technology? Perhaps only now do we have the expertise or the technical hardware to exploit them?
Even today, it's not that clear that they are "good" features for what were doing in 1985 with computers.
- Do we really need hardware-accelerated GUIs with 3D capabilities to create Excel spreadsheets? Is that Gouraud shading on the bar chart REALLY important?
- Sure, pre-emptive multitasking is a good idea from an operating systems POV. But in 1985 that was the wrong POV to take for personal computers. There were little resources for an OS to manage, and multitasking is a concept that costed too much in a single-user machine and most users don't grasp. The typical user that drives the market still works on a single document/task at a time.
- Multi-channel digital is still an unprofessional annoyance in office workstations, as anyone who drank coffee to the sound of 50 "Windows Start-up Chimes" at 7:00AM knows, or typed a report to the not-so-muted-headphone sound of a neighbor's latest kazaa find. The ability to include annoying MIDI music in a Powerpoint presentation may not compensate that...
The point is that these features are "good" for things that didn't exist in 1985, because they either were not possible, or the ideas that put them to use were in embryonic state:
- Digital sound beyond the warning beeps of the BIOS required special hardware to play and special software to process. This was developed in other markets, for other markets, before it found any use in the mainstream, and then it required a lot of other things to fall into place. It couldn't happen without computer games, but also it couldn't have happened inthe mainstream without the "multimedia" idea, which couldn't have happened without CD-ROMs among the masses AND without hyperlinked documents AND without hardware-accelerated GUIs.
Only then did the product make sense.
- GUIs as we know them couldn't take off, I believe, without the desktop publishing revolution, and the desktop publishing revolution couldn't take off without the primitive GUIs that promised, but didn't quite give what was needed for that. Until desktop publishing changed what "creating a document in the computer" implied, GUIs were not such an amazing product, much less the idea of hardware-accelerating them. In the terms of the article, it took some time to make complex GUIs a "whole product".
- Pre-emptive multitasking was demanded by the market when it became useful. They needed no education for that, although they may have used the less technical term "Calculator shouldn't freeze this crap, and make me lose my work in 7 other apps". Sure, it was delivered late and buggy, but they weren't promising it since the days of OS/2 development because of the nicety of their hearts. They didn't promise it when people didn't care about it, because they could never create a document using 7 applications at the same time before.
No, the article claimed it was the best "whole product". It was better at meeting the demands of the consumers.
When making qualitative comparisons, it's important to remember the standards under which you make the comparison. The article does not challenge the conclusions of the comparison that received wisdom provides, it challenges the standards of that comparison as irrelevant.
The market doesn't choose what is "best" per se, and I don't think the article points in that direction.
The market chooses what the market WANTS.
According to some definitions of product, including the "whole product" idea used in the article, a "good product" is a product that matches the market demands.
In that sense, the "best product" is the one that gives the market what it wants, and by the nature of the market, the dominant players tend to do that in a free market.
That doesn't mean the product is "better" from a technical, moral, or whatever other point of view you want, except from the point of view that it meets the desires of consumers.
The consumers might want inefficient vehicles, lousy paperback novels, kitschy pop culture or education aimed at the attention span of a 3-year-old on a glucose overdose. That doesn't mean that they're better vehicles, literature, culture or education, but if the public is more willing to pay for those, by definition they're better "products".
For some strange reason this beckons the idea of someone-less-than-brilliant putting a web server in one of these things.
Which would beg the question of what happens first:
- 1000 simulatenous HTTP request bring the car down.
- 1000-cumulative-pounds of slashdot readers bring the car down (physically).
- 1 slashdot reader makes a Bewoulf cluster of 1000 of these things.
To me that just means the author of the quote (inventor/webmaster/marketeer) can personally afford the car.
I don't see where's the confusion.
On other news:
3DRealms has announced that in order to meet the expectations of fans for Duke Nukem Forever, and to give them a better idea of WHEN it will be ready, it will stick to its promise to deliver a flying car with every box of the game.
"Actually, the game has been almost ready for some time..." said an anonymous insider source, "we've just been trying to bring down the costs of this flying car thing for the last couple of years."
Yes, it's time to teach Apple a lesson.
Let's remove all the unique/useful components of the GNU/Darwin distribution.
Let's remove any motivation for Apple's customers to have any interest in using or touching GNU/Darwin.
Let's abandon PPC and remove any motivation for PPC-owners to keep an eye on GNU/Darwin.
Let's proclaim in ideological rage that GNU/Darwin will abandon its ties to propietary evilness and be reborn as Yet-Another-BSD-on-x86 with Yet-Another-Kernel.
Surely it makes sense for GNU/Darwin to compete with FreeBSD, OpenBSD, NetBSD, etc on the same old platform with practically no distinguishing factor or even aim. It's not like that would be redundant.
Surely Apple will see the light after their customers collectively blink and go on with their lives.
That will teach them.
Someone has to nitpick... There is no "interview", it's just a nice short article on Stanislaw Lem, using the last movie as an excuse to call attention on an immensely underrated author.
The "interview" part consists of a single quote, taken from the public statement he published elsewhere about the criticisms to the North American version of Solaris.
The article is pretty good, though. I was unaware of some of the details of PKD's involvement in the SFWA debacle.
The approach to studying physics is also replicating well-known experiments with shoddy equipment, no experience, and predicted results.
This is not to educate scientist to repeat the same experiments over and over again. It's just that you cannot be expected to understand complex physics and create new experiments for new theories if you haven't seen and tried the building blocks first-hand.
They don't teach you to solve the Towers of Hanoi because it's a "common problem". They teach you to use recursion to solve problems, and to recognize a "recursion problem" by its characteristics, by using Towers of Hanoi as a common example.
I AM GOD OF THE SEA PEOPLE!
I wonder what quality you claim to be forsaking...
I'm a big fan of Linux, and of Unix in general, but why exactly do you use an Operating System?
Since I don't have a mainframe in my room serving thousands of users with scarce memory and CPU-time, efficient resource administration is less of a priority than it was for Unix's original goal.
Stability is important, but my workstation doesn't need as many magic 9s as my web server. Booting once per week is really not that bad.
Personally, I run an OS to make my life easier. In other words, the quality I expect from an OS is "requires less effort to do what I want to do".