Perhaps flying in an atmosphere of a planet full of oxygen is a factor that the (hypothetical) aliens did not take into account. Perhaps they come from a world that it's entirely different. Perhaps a physical phenomenon contributed in the crash. Perhaps the crash never happened, and the alien story was a cover up for Soviet spy satellites.
But none of the above forbid the case of aliens from another world.
As for revealing themselves, the Superbowl is important to the US, but from an alien viewpoint, perhaps China or India are more important, due to their immense population size. Perhaps the aliens will reveal themselves to them.
Perhaps Mitchell is lying for other reasons.
People, be open to possibilities, don't be so narrow-minded about this.
As a software development *student*, you should be focusing more on the concepts, on engineering problem solving, and on reasoning skills than on the specific technologies.
Theoretically, you are correct, but when each technology has thousands of details to understand and learn, you can't focus more on concepts.
There it goes again. As if the internet or the WWW is only about businesses and money.
Most, if not all, human activities are about 'profit', either material or psychological (or both). In the end, you wouldn't have the Internet or computers if people did not have the drive to gain 'profit'.
But you don't need that with a modular system that does updates lazily and on linking time. The effect is the same as the browser (publish once, run everywhere), without the constraints of the browser.
But I'm going to have to disagree with you here. We will never actually run out of copper or iron or oil. As the amount of these resources that is naturally occurring decreases, the price will rise to the point that: (A) It becomes cost-efficent to dig through landfills and recycle previously used resources, and (B) other materials that were previously too expensive for the application will now be cost-effective.
I don't think what you are saying is possible.
First of all, if the price of a material rises too high (copper, iron, oil, you name it), it will become cost-efficient to dig through landfills and recycle previously used resources only if people buy the remaining material in these high prices. If the material is suddenly no longer demanded, the companies will have no money to invest on recycling previous resources. Demand will not actually die, and so the prices will not be lowered, it's just that it will not be bought.
Secondly, perhaps other materials can be cost-effective when compared to copper/iron/oil/whatever, but they can not be cost-effective relative to equipment required for processing those materials and the research expenses required for developing new technology for producing those materials.
The net result from depletion of copper/iron/oil will be a stalemate: there would be not enough money to continue buying the materials left, and there would be no money to invest in exploiting new alternative materials. As an example, take oil: the cost of replacing oil with another fuel is extremely high, because all the infrastructure of modern society has to be replaced: cars, heat systems of buildings, electricity producing systems, airplanes, boats, etc. We are talking about huge expenses, that no country, or even all the countries of the Earth, can bare.
The race condition can be solved by copying the value of A and working on that. In purely functional programming languages, that everything is copied, you have no such problem.
The deadlock problem is a logical one and it exits in single-threaded computations: if you need the value of A to compute B and the value of B to compute A, then there is something wrong with your algorithm.
If you use mutexes, semaphores, critical sections etc then parallel programming is indeed hard. These low level primitives should only be used for coding parallel APIs, where the user never sees them.
One such example is the Actor model: objects communicate through messages. It doesn't get simpler than that, and the low level communication primitives are only used at the message queue of each object (because one thread writes the queue, one thread reads it).
Imagine a program written in an object-oriented language where each object is an Actor! if you have 10,000 objects, and 10,000 cores, each core can represent one object. Sequential algorithms could then be parallelized automatically, without being re-written, since a method call becomes a message...there are solutions for parallel programming, it's just that the major programming languages define a culture that is hard to break.
For a successful application of the Actor model in the industry, you can check the programming language Erlang used in telecommunications.
There are incredible benefits to multicore. Searching, for example, can be sped up almost linearly with the number of cores. Let's say you have an array of 10000 elements and you want to find a specific value. In single core, you have to iterate the array, find the element and process it. If we had 10000 cores, we simply give one element to each core to test with a specific value, and the search time goes down to 1/10000.
Materials don't have to be extinct to cause problems. 'Extinct' in our case means 'not possible to extract/use any more'. This is the problem with any material.
And there is a limit to the alternatives. What happens if there is no alternative, say, in the next 100 years? civilization will collapse.
I download every show I want to see, when I want to see it.
Come on, TV execs, can't you see that TV programming is a thing of the past! just put out your programs in a server so as that we can download them!!!
Basically, I want browsers to go away. What I want is an internet programming platform:
1) a programming platform that defines a common binary interface between computers, so as that computers communicate using binary data, not text.
2) the ability to import and run modules from the internet; the platform will handle versioning and management of modules automatically, so as that the administrators are freed from having to maintain applications. The developers will simply post new or updated modules on a server, the platform will download and cache these modules locally on a need basis.
3) a good security model with encrypted communications by default.
4) the ability to persist data types automatically in a database, not in a file system, so as that there is no need for intermediate object mapping layers.
5) the ability to obtain an object proxy automatically by specifying a URL and object name.
All the above will open the road for applications running of the internet. The browser thingy was a good idea, but now its age is showing.
"Most of the world who can code C++ would disagree with you."
That multiple inheritance is so complex as to become unmanageable is just fud. Don't follow the sheep. Have you tried it yourself? there is nothing complex at all.
"the point of interfaces is to decouple the implementation from the interface, which has maintainability and flexibility advantages that far outweigh a little extra typing during the design phase of your project."
You can always decouple the interface from the implementation using multiple inheritance, but when you want to share implementation details, you can't do that with interfaces. So multiple inheritance is a superset of interfaces, and thus better.
"a little extra typing during the design phase of your project"
It's not a little extra typing. Sometimes it's a lot of typing.
I prefer to have to deal with the rare case of name collision between two base classes' methods than having to implement the same code over and over using interfaces.
The benefits of MI is less lines of code, less typing, less programming. Complexity is minimal.
Slashdot Mirror
I think Midori will have a virtual machine with a custom ISA, it will not only be a HAL.
Ban him, what's the big deal with that? most people like that are banned at least once in their lives.
And then there is the question 'how do I locate where Earth was 8 million years ago' with enough accuracy as to land somewhere near the planet?
Perhaps flying in an atmosphere of a planet full of oxygen is a factor that the (hypothetical) aliens did not take into account. Perhaps they come from a world that it's entirely different. Perhaps a physical phenomenon contributed in the crash. Perhaps the crash never happened, and the alien story was a cover up for Soviet spy satellites.
But none of the above forbid the case of aliens from another world.
As for revealing themselves, the Superbowl is important to the US, but from an alien viewpoint, perhaps China or India are more important, due to their immense population size. Perhaps the aliens will reveal themselves to them.
Perhaps Mitchell is lying for other reasons.
People, be open to possibilities, don't be so narrow-minded about this.
Why do you consider it necessary that a species that can cover interstellar distances needs camouflage?
The European explorers/conquerors of 14th and 15th Century did not camouflage themselves when they set foot in America, for example.
We should not make hasty conclusions on things we do not fully comprehend.
Even without camouflage, you still don't believe aliens could exist; perhaps that's part of the aliens strategy.
Theoretically, you are correct, but when each technology has thousands of details to understand and learn, you can't focus more on concepts.
You have to write HTML in Wicket. It's not all Java.
Most, if not all, human activities are about 'profit', either material or psychological (or both). In the end, you wouldn't have the Internet or computers if people did not have the drive to gain 'profit'.
It can be called 'Flash-Back'....
And let's not forget C++!!!!
And boost!!!!
Now that would be cool!!! a massive download just to run a few lines of C++ code...
But you don't need that with a modular system that does updates lazily and on linking time. The effect is the same as the browser (publish once, run everywhere), without the constraints of the browser.
The data can still live in the cloud...
How about native apps that are lazily downloaded?
module imports from the web?
lazy linking?
automatic updates at link time?
Come on people, where is your imagination? the GP post is correct...web apps running inside a browser is a silly thing.
I don't think what you are saying is possible.
First of all, if the price of a material rises too high (copper, iron, oil, you name it), it will become cost-efficient to dig through landfills and recycle previously used resources only if people buy the remaining material in these high prices. If the material is suddenly no longer demanded, the companies will have no money to invest on recycling previous resources. Demand will not actually die, and so the prices will not be lowered, it's just that it will not be bought.
Secondly, perhaps other materials can be cost-effective when compared to copper/iron/oil/whatever, but they can not be cost-effective relative to equipment required for processing those materials and the research expenses required for developing new technology for producing those materials.
The net result from depletion of copper/iron/oil will be a stalemate: there would be not enough money to continue buying the materials left, and there would be no money to invest in exploiting new alternative materials. As an example, take oil: the cost of replacing oil with another fuel is extremely high, because all the infrastructure of modern society has to be replaced: cars, heat systems of buildings, electricity producing systems, airplanes, boats, etc. We are talking about huge expenses, that no country, or even all the countries of the Earth, can bare.
..."Hi. Can I take your order?" ???
The race condition can be solved by copying the value of A and working on that. In purely functional programming languages, that everything is copied, you have no such problem.
The deadlock problem is a logical one and it exits in single-threaded computations: if you need the value of A to compute B and the value of B to compute A, then there is something wrong with your algorithm.
If you use mutexes, semaphores, critical sections etc then parallel programming is indeed hard. These low level primitives should only be used for coding parallel APIs, where the user never sees them.
One such example is the Actor model: objects communicate through messages. It doesn't get simpler than that, and the low level communication primitives are only used at the message queue of each object (because one thread writes the queue, one thread reads it).
Imagine a program written in an object-oriented language where each object is an Actor! if you have 10,000 objects, and 10,000 cores, each core can represent one object. Sequential algorithms could then be parallelized automatically, without being re-written, since a method call becomes a message...there are solutions for parallel programming, it's just that the major programming languages define a culture that is hard to break.
For a successful application of the Actor model in the industry, you can check the programming language Erlang used in telecommunications.
There are incredible benefits to multicore. Searching, for example, can be sped up almost linearly with the number of cores. Let's say you have an array of 10000 elements and you want to find a specific value. In single core, you have to iterate the array, find the element and process it. If we had 10000 cores, we simply give one element to each core to test with a specific value, and the search time goes down to 1/10000.
Materials don't have to be extinct to cause problems. 'Extinct' in our case means 'not possible to extract/use any more'. This is the problem with any material.
And there is a limit to the alternatives. What happens if there is no alternative, say, in the next 100 years? civilization will collapse.
...we could bring those materials from asteroids, or other planets!
Now can all the space program deniers admit that space is very important and that we should go there?
I download every show I want to see, when I want to see it.
Come on, TV execs, can't you see that TV programming is a thing of the past! just put out your programs in a server so as that we can download them!!!
3D Realms is waiting for some real Pig-Humans to pose as Pig Cops so as that they can motion-capture them...hmmm...that's perfection!
Basically, I want browsers to go away. What I want is an internet programming platform:
1) a programming platform that defines a common binary interface between computers, so as that computers communicate using binary data, not text.
2) the ability to import and run modules from the internet; the platform will handle versioning and management of modules automatically, so as that the administrators are freed from having to maintain applications. The developers will simply post new or updated modules on a server, the platform will download and cache these modules locally on a need basis.
3) a good security model with encrypted communications by default.
4) the ability to persist data types automatically in a database, not in a file system, so as that there is no need for intermediate object mapping layers.
5) the ability to obtain an object proxy automatically by specifying a URL and object name.
All the above will open the road for applications running of the internet. The browser thingy was a good idea, but now its age is showing.
"Most of the world who can code C++ would disagree with you."
That multiple inheritance is so complex as to become unmanageable is just fud. Don't follow the sheep. Have you tried it yourself? there is nothing complex at all.
"the point of interfaces is to decouple the implementation from the interface, which has maintainability and flexibility advantages that far outweigh a little extra typing during the design phase of your project."
You can always decouple the interface from the implementation using multiple inheritance, but when you want to share implementation details, you can't do that with interfaces. So multiple inheritance is a superset of interfaces, and thus better.
"a little extra typing during the design phase of your project"
It's not a little extra typing. Sometimes it's a lot of typing.
And let's not forget how effective the army of civilians would be...
I prefer to have to deal with the rare case of name collision between two base classes' methods than having to implement the same code over and over using interfaces. The benefits of MI is less lines of code, less typing, less programming. Complexity is minimal.