The thing about the free (and I mean truly free) market is that it could go both ways. You have to look at what you're offering and whether it will entice people to buy. The idea that people should somehow feel obligated to buy anything is nonsense. People will pay only when they have no alternative. The obvious and easy way from a supplier point-of-view is to eliminate alternatives. Some few and far between companies, however, see that the (less easy) more profitable approach is to create something value-added. In Apple's case, that was a very easy-to-use store that charged a fairly nominal fee that most people wouldn't mind paying.
Whether or not you philosophically believe in "free information" the fact of the matter is, the internet has made sharing content essentially free to consumers. This puts a hamper on your old business model but that does not mean that you cannot make money. Plenty of things are free out there (linux distros for instance) but companies still make money by providing value-added. This can be anything from a very easy-to-use store, meta-data, high-quality, etc. The companies providing content need only ask themselves "how can I be a better distributor than a p2p program". I know I would pay ~$10 for an album that already had all its mp3 tag information sorted out, album art provided, a central, easy-to-use and fast place to download it from, and most importantly, high quality mp3 (192 or 256 kbps) data.
C++ references are pointers with syntatic sugar on them So your entire argument sums to "references are pointers anyway". That's fine if you want to argue semantics. Consider that those who say "Java has no pointers" don't agree with that assessment. As to what makes a reference a reference, I'd list:
* They are not to be treated as memory addresses (though yes, it is an address under the hood) * Memory for references need not be managed (though in C++ this has to due with the fact that you can't use dynamic memory allocation with references)
The implications of the first I listed is fairly vast. It means that one is never afraid of writing or reading from the wrong place. Yes a reference can be null but a null exception is far more preferable to corrupting program memory. The implications of the second is that one need not ever be afraid of leaking memory.
Claiming that not having to type an extra character to dereference as a fundamental characteristic of references is really grasping at straw, btw.
Java references meet both these criteria. A reference is (and depending on the JVM implementation, is probably not even a memory address) not to be treated like an address in memory. It's an abstract "link". There is no such thing as the "value" of a reference (one cannot System.out.print(myObject) and get the address value). Conceptually, this is more than "syntactical sugar" it's a complete disjointing of the programmer from the idea of a memory map space (along with the removal of the concepts such as locality).
Java achieves the second by having a garbage collector. Yes, IO resources need to be managed and objects using IO resources need to be managed but *memory* need not be. A programmer's only concern would then be "does my algorithm use too large of a dataset" and not "always deallocate what I allocated". Granted C++ references do not serve the same purpose of easy management of heap memory and I'll agree that there, the two differ conceptually.
You are arguing that they are reference because since they are such lame pointers they must not be pointers at all I'm arguing that they don't have all the features of a pointer. In fact, conceptually, they take away a *lot* of the implications of pointers. Therefore, they are not pointers. Your insistence on "hey, they aren't direct objects, they are therefore pointers" is very narrow and really speaks of someone who views the world solely in terms of C++.
So your first point which talks about "the memory being available" is immaterial, and a tad vague. From a memory management point of view (and really, that's what the garbage collector does), "memory being available" means that if I'm creating a new object, there will be memory there. For the garbage collector, this means that when I point a reference to null, the memory for the object being pointed to is fair game. It can reside there in memory but as soon as the runtime determines "hey, I need more memory", that object will be destroyed. From the programmer's perspective, this is no different than deallocation.
Consider a specific example. I have an object that represents a cache of the image of an open file. It has one reference on the stack and that reference is passed into various methods as well. An exception is thrown and all of the referencing pointers on the stack are unwound. Now I fix the problem and reenter the code, where I make a second cache object and call the hierarchy of functions which runs to completion. The problem with the example is, again, the fact that Java treats everything as a referenced object (it resides in the heap). As I'm aware, this is no conceivable way to have an object in the stack (ok, virtual stack). Saying that "Java can't automatically manage complex objects in the stack", which is essentially what you're griping about, really isn't saying much. It doesn't *allow* you to do that.
In C++, objects in the heap (not automatically managed) have to be destructed by calling delete. If your gripe is that Java doesn't have automatic objects, then I'd only argue that realistically, a JVM would not need such a feature.
At the end of the instruction above, nothing has been destructed at all. The object has lost visibility in this scope. Did you skip the part where I said:
"Granted the actual memory won't be deallocated until the next garbage collection cycle but the object is lost as far as the programmer is concerned and the memory is usable if needed."
Finalization does not necessarily occur if the program exits before the garbage collector sees and finalizes the object. Custom end-life routines (particularly if you want to close IO resources) don't automatically occur in C++ or any language that I know of either. In C++, you use the deconstructor. In Java, you can either call your own finalize function at your will or trust the garbage collector if there isn't a timing critical resource you have to give up. I fail to see a lack of functionality here that you're griping about.
Sorry, they are not references, they are pointers. They _call_ them references in the documentation, but what happens when you use "=" on a reference, you replace the contents of the item referenced. In java, when you use "=" the pointer-miscalled-reference takes on the address of the right-hand-side as a second means of access to that now-shared object. There are two issues here. Firstly, I believe this is only in C++ due to the = operator being defined to copy a class. Secondly, in your example:
Thing & thing1 = new Thing;// make some thing Thing & thing2 = new Thing;// make some other thing thing2 = thing1;// still have two separate things, but the original value of "some other thing" is obliterated by the value of "some thing"
In the third line, both thing2 and thing1 are dereferenced handles for the objects at hand so the analogy is not accurate. If pointers were dereferenced automatically in the syntax, the same could be done.
Note that in Java, no & syntax is required and all object handles are by default references. So thing2 = thing1 in Java means something entirely different than thing2 = thing1 in C++ and it does not mean that you cannot assign references to different values in C++ (which indeed you can, hell you can even do $thing2 = 0xBADA5569 last I recall).
Note that C# treats its "references" the same way as Java does and allows references to be copied.
By immutable, I mean you cannot directly perform manipulation on the reference. That is:
thing2++;
in Java is not possible. References can be copied and that's about it. C++ treats its references slightly differently but the ones in Java resemble C++ references much more than C style pointers. *Much* more.
Why would I want to pass a the contents of a non scalar by value? Why to have a private copy of the structure to work with you silly boy. Kind of the definition of "why copy" anything. I believe I asked why pass by value, not "why copy". Unless you're in one of those niche situations where you have a ton of stack space (and your particular architecture loves stack operations) and don't wanna use heap space (I don't believe this is "proper" practice by any means), why would you be passing large pieces of data (ok, maybe really small structs) by value?
About as reliable as take-off and landing software on airplanes I'd say. Or perhaps communications links from the control tower to the plane. Don't take the unreliability of the consumer PC market as some unavoidable fact of life. Given limited scope and enough resources, reliable systems *can* and have been designed and built since the first engineers started tinkering with stuff.
a) Unless your program contains no IO (and really, even Hello World! contains IO), you're using a system call someone else wrote. You can make a distinction between system call and library but in the context of what you're saying, it's the same thing. b) Realistically, when a student is introduced to C, all the features of an underlying OS (process management, scheduler, virtual and protected memory, a file system, etc.) are all provided and taken for granted.
A person that is unable to write a driver or low-level library from scratch, should not be starting his education by using one. I don't agree. Each layer of abstraction has its own concepts to consider and learn. One might as well claim that a lack of understanding of synchronous circuits disqualifies one from writing machine-level code. Generations of clever engineers created that cozy little environment with the machine language that you're compiling to. Not understanding how add a, 15; is then decompressed into microcode, pipelined in lockstep with the data it operates on, goes through an add function through logic gates, and retired back to memory, does not disqualify you from writing drivers.
Every time someone tells me that there are no pointers in Java I laugh a little. They would be correct. Java contains references, not pointers. The distinction is obvious to anyone who understands C++ as it has both (& for references, * for pointers). Pointers are mutable, references are not. This makes references (somewhat) safer to use and also allows a garbage collector. It also means it has a lot less functionality (particularly as an iterator).
Java has no useful destructors because no object has predictable scope. If you think finalize methods are the same as destructors then don't bother responding, you don't know what destructors are And here I thought Java had no destructors because you had a garbage collector. There's an easy way to "destruct" an object in Java:
myThingy = null;
Granted the actual memory won't be deallocated until the next garbage collection cycle but the object is lost as far as the programmer is concerned and the memory is usable if needed.
Since everything is a pointer in Java, you have to bend over backwards to pass-by-value. The fact that the language doesn't even begin to provide copy-construction semantics. What a miserable PITA. new ObjectType(myOtherObject) works fine and almost all classes in the standard library has a copy constructor. There's philosophical arguments about how many features you want to be part of the language syntax as opposed to part of the library. Just because you favor the former does not make it superior.
As to passing by value. Why would you be doing that for anything other than scalars (which Java does pass-by-value) anyway?
So yea, teaching people Java as an introductory language is something of a disservice if you ever want to make them truly think about programming and what makes some things machine smart, while others are machine stupid. With compilers the way they are today, such knowledge is not necessarily useful and/or even related to the desired field of study/work. Someone concerned with algorithm scaling really isn't interested in saving a few scalar bytes of memory here and there.
I am glad my introductory algorithm classes were taught in Java. The same algorithms were used in a C++ class later on. The Java class was to actually teach you the algorithms. The C++ class was to teach you memory management. The algorithms just so happen to be a very good exercise in memory management.
I graduated in 2006 and I don't remember our courses involving collections. I'm sure some students used them but we were taught data structures by creating our own classes with references in Java.
I honestly think that question catches more self-taught Java guys than people who came out of a university.
For an array, yes. For a single-pixel sensor, you can't "freeze-frame" an image because that image would be one pixel. Think of it like how a scanner works but with one pixel instead of a line of pixels. You scan across an area and reconstruct the image.
This is probably what they do (or something similar). Different missiles will have different modulation speeds and matching it exactly would be difficult. Luckily, there's no need. Just shine a bunch of random lights at the sensor that's at an angle (i.e. don't shine it directly from you to the focal center of the missile's FOV) and it would be interpreted as random hotspots forming out of nowhere.
I suppose it could be argued that it is an income. But then what would the justification be for, say, a husband to give a present to a wife without being taxed? Our current government (for reasons which I don't think are valid) has ordained itself to sponsor certain types of social relationships (father, mother, son, husband, wife, etc.) and provide exceptions in the tax system for things that are traded (it considers all property shared) between said people.
This is a form of government social engineering and I'm against it but I think the general public has gotten too used to the idea that government recognition and sponsorship is what really makes the relationship a relationship (look at the fuss over gay marriage) to repeal it.
The sensor pixel (well, multiple pixels) itself isn't able to determine direction. If you time the laser to shine on the sensor when it is sampling the "top-left corner" it will think that the source of the light came from the top-left corner and go that way. The fact that the source of the laser is actually at an angle is indistinguishable by a two-dimensional photon-collector. In fact, even an fixed array of sensors would be fooled if you could aim the laser accurately enough (and adjust it for the optics) to hit certain parts of the focal plane array.
With a single-pixel modulated sensor. There is no "bright spot in the center". It can construct a rough picture of what the "field of view" looks like by modulating the single-pixel sensor. Throw in a mis-timed bright spot and it'll paint a different internal picture. From the point of view of software, there is no difference between a consistent bright spot and a bright spot that blinks but is consistently there every time the sensor "samples" that direction.
This doesn't do anything for staring sensor guided missiles however....
Unfortunately, government performing social engineering has got to be the worst idea in the history of mankind. A lot of things have good intents behind them. Who would argue against giving every citizen healthcare or a home to live in? The problem is when you give the federal government the power and responsibility to make that happen. There is some level of guideline necessary in terms of distribution of wealth but aside from the minimalistic anti-trust laws and taxation of spending and earning (including gains from stocks), I really do not see that it is the government's place to use taxation to distribute wealth more evenly.
Rich people who inherit money will spend it. If they don't spend it they will invest it. If they don't invest it, it will slowly leak away. Fix the current taxation laws to actually tax the ultra-rich (such as treat returns as income) and you won't have a problem of generations of rich people. The market will distribute it all.
Either cooled or uncooled CMOS-bonded InGaAs or InSb sensors that are massive arrays (512x512 pixels or 1kx1k) have been around for years now. Raytheon has been making the 128x128 or 256x256 ones for almost a decade and they're used in most of their missiles. I think the majority of IR-guided missiles from the past 10 years or so have used a non-moving optical array to track its target.
That being said, the way a laser would confuse these sensors isn't by adding a "hot spot" on the detector but to saturate the majority of the detector's photon collectors (or the collector capacitors in the back). It takes some time to discharge and refresh the sensor and that's time enough for the software to lose track of its target. A different approach would be to create an extremely large heat-spot withing FOV of the sensor (such as a large explosion) but that would only temporarily blind the sensor whereas a laser could do it consistently.
Computers already automate what used to take a practical army of humans to do. Humans will always find other things to do and facilitate the flow of wealth. There will always be things to do no matter how useless it is practically speaking (I'm looking at you interior decorators). Once people are free from the burdens of the basic necessities, they will invariably seek luxuries which is a market in and of itself. Then there's the stock market. Really, no one in the stock market contributes to society per se. A day-trader or a stock broker doesn't produce anything. He/she is simply a facilitator of the flow of wealth and a gambler. I suspect that as less and less practical needs are met by human labor, we'll all begin to just spend our days betting each other on what price Google will be at tomorrow. Money will still flow back and forth.
That really depends on how the signal is encoded and the individual "packets" are segmented. Packets dropping will cause "choppy" video but not necessarily mean "nothing at all". And if the broadcasters are willing to sacrifice a bit of bandwidth for redundancy, it could be very noise-tolerant.
Those analog portions can be configurable via digital control. For instance, the filter frequency range of the receive input filter can be configured using programmable registers and a DAC to offer fairly fine-grain control (let's say 32-bit) of the resistance of an RC filter. The RF amplifier's gain can be adjusted using digital controls as well. Mixing can be done using parallel A/D's that sample in lockstep and then digitally mixed and modulated later.
All of this injects noise of course but if you don't hit your noise ceiling (or keep your digital stuff gated such that signals only change during the initial configuration) and move all of the signal processing away (physically) from the RF portion, you can minimize noise and still have a configurable RF receiver.
This is actually done, just not in mass production (on the scale Intel would like), by quite a few companies. ST Micro comes to mind.
The embedded systems market is flooded with FPGA-based designs. One does not need to redesign a custom TCP/IP stack. IP can be bought (or downloaded) for it and you simply glue the pieces together. The performance-centric FPGA's do draw quite a bit of power for what they offer, but if your power budget allows it, there's no reason not to.
The primary reason why FPGA's aren't used in things such as network cards has nothing to do with technical feasibility but rather cost. ASICs are significantly lower-cost per-chip (for the same features) than an FPGA is. For custom-designed systems on the order of thousands, FPGA's are usually the way to go. On the hundreds of thousands, however, people usually go the ASIC route.
If you're writing Verilog or VHDL like you're doing a C program, you're doing it wrong. It's actually not very complicated to figure out the translation if you stick with RTL constructs. The key thing to remember is that those HDL languages provide more than the description of gates. They provide programming behavior so that you can create models and testbenches to test your gates. *BUT* that also means that you have to actively avoid using those constructs when describing real hardware. If you limit yourself to what synthesis will be able to deal with (registers and combinational logic) it is *very* easy to "see" the gates as you code. And that's how it should be.
Way too many people get thrown off when they first pick up HDL languages because they treat it like a programming language. It isn't, you're describing hardware. A very good book (and one that's unfortunately no longer in print and is rare and good enough that it still sells for $200+) that does an excellent job of explaining it all is HDL Chip Design by Douglas J. Smith.
I don't see a problem with people "abusing" the conversation. If anything, it's another level of "intelligence" to have a machine recognize sarcasm/pretenses (i.e. trolling) just as real human would. If the machine can pass the test convincing the "troll" that he/she is real by reacting to ostensibly non-sequitur statements, then and only then, would I say it passed the true Turing Test.
Well, people ~200 years ago managed to form a government and write this rad document called the Constitution of the United States. Having read and studied it quite a bit, I'd say all successive legislation have been declining in quality.
Of course, one could argue that our legislation doesn't necessarily mirror the general population's intellectual abilities.
With the recent Bill to allow unwarranted wiretapping, require WiFi points to log *everything* and recognize "illegal" behavior, etc. I'd say our current legislative body is a far cry from those who debated state vs federal powers.
The beauty of Darwinian evolution is that it is observational and statistical. Saying "it's too complex to predict" is really a cop-out. Yes, it is near-impossible to predict how specific traits (or even a general sense of) intelligence depending on which gene gets "passed on". If we were to start a Eugenics program that tried to selectively breed "smart" people, it probably wouldn't work out very well simply because of the lack of ability to even define intellect let alone measure it.
But we're not trying to "predict" what specific gene is the "smart" gene. The observation made in the movie simply described how certain types of behavior and mentality (things which gains one popularity and the ability to procreate repeatedly) was being passed on. These types of behavior and mentality was associated with "stupid" people. Whatever genetic variations might exist, the "bell curve" of behavioral characteristics will be moved and shifted in time, generation after generation. The type of behavior associated with "stupid" will procreate. Not all of this behavior is genetic, no, but the inclination to behave in such way is partly influenced by genes. Whatever part genetics have, those genes will be passed on and will become dominant among the species, regardless of other influences.
In other words, saying that "smart" people can be uneducated and therefore be perceived as stupid doesn't account for the fact that, over long periods of time, people with the "stupid" inclination will still be better at being "stupid" (assuming that it helps them procreate) than those with "smart" inclinations.
As to the point of the movie. It wasn't a 1984-esque society at all. It was, in fact, a truly democratic society. The truly scary part is what the masses wanted (voted for). There wasn't a mastermind controlling them. Everyone has spiraled to a point of collective stupidity. Even the head of the corporation that made Brawndo truly thought that it was what plants crave.
Slashdot Mirror
The thing about the free (and I mean truly free) market is that it could go both ways. You have to look at what you're offering and whether it will entice people to buy. The idea that people should somehow feel obligated to buy anything is nonsense. People will pay only when they have no alternative. The obvious and easy way from a supplier point-of-view is to eliminate alternatives. Some few and far between companies, however, see that the (less easy) more profitable approach is to create something value-added. In Apple's case, that was a very easy-to-use store that charged a fairly nominal fee that most people wouldn't mind paying.
Whether or not you philosophically believe in "free information" the fact of the matter is, the internet has made sharing content essentially free to consumers. This puts a hamper on your old business model but that does not mean that you cannot make money. Plenty of things are free out there (linux distros for instance) but companies still make money by providing value-added. This can be anything from a very easy-to-use store, meta-data, high-quality, etc. The companies providing content need only ask themselves "how can I be a better distributor than a p2p program". I know I would pay ~$10 for an album that already had all its mp3 tag information sorted out, album art provided, a central, easy-to-use and fast place to download it from, and most importantly, high quality mp3 (192 or 256 kbps) data.
* They are not to be treated as memory addresses (though yes, it is an address under the hood)
* Memory for references need not be managed (though in C++ this has to due with the fact that you can't use dynamic memory allocation with references)
The implications of the first I listed is fairly vast. It means that one is never afraid of writing or reading from the wrong place. Yes a reference can be null but a null exception is far more preferable to corrupting program memory. The implications of the second is that one need not ever be afraid of leaking memory.
Claiming that not having to type an extra character to dereference as a fundamental characteristic of references is really grasping at straw, btw.
Java references meet both these criteria. A reference is (and depending on the JVM implementation, is probably not even a memory address) not to be treated like an address in memory. It's an abstract "link". There is no such thing as the "value" of a reference (one cannot System.out.print(myObject) and get the address value). Conceptually, this is more than "syntactical sugar" it's a complete disjointing of the programmer from the idea of a memory map space (along with the removal of the concepts such as locality).
Java achieves the second by having a garbage collector. Yes, IO resources need to be managed and objects using IO resources need to be managed but *memory* need not be. A programmer's only concern would then be "does my algorithm use too large of a dataset" and not "always deallocate what I allocated". Granted C++ references do not serve the same purpose of easy management of heap memory and I'll agree that there, the two differ conceptually. You are arguing that they are reference because since they are such lame pointers they must not be pointers at all I'm arguing that they don't have all the features of a pointer. In fact, conceptually, they take away a *lot* of the implications of pointers. Therefore, they are not pointers. Your insistence on "hey, they aren't direct objects, they are therefore pointers" is very narrow and really speaks of someone who views the world solely in terms of C++.
In C++, objects in the heap (not automatically managed) have to be destructed by calling delete. If your gripe is that Java doesn't have automatic objects, then I'd only argue that realistically, a JVM would not need such a feature.
"Granted the actual memory won't be deallocated until the next garbage collection cycle but the object is lost as far as the programmer is concerned and the memory is usable if needed." Finalization does not necessarily occur if the program exits before the garbage collector sees and finalizes the object. Custom end-life routines (particularly if you want to close IO resources) don't automatically occur in C++ or any language that I know of either. In C++, you use the deconstructor. In Java, you can either call your own finalize function at your will or trust the garbage collector if there isn't a timing critical resource you have to give up. I fail to see a lack of functionality here that you're griping about.
Replace $ with &.
Thing & thing1 = new Thing;
Thing & thing2 = new Thing;
thing2 = thing1;
In the third line, both thing2 and thing1 are dereferenced handles for the objects at hand so the analogy is not accurate. If pointers were dereferenced automatically in the syntax, the same could be done.
Note that in Java, no & syntax is required and all object handles are by default references. So thing2 = thing1 in Java means something entirely different than thing2 = thing1 in C++ and it does not mean that you cannot assign references to different values in C++ (which indeed you can, hell you can even do $thing2 = 0xBADA5569 last I recall).
Note that C# treats its "references" the same way as Java does and allows references to be copied.
By immutable, I mean you cannot directly perform manipulation on the reference. That is:
thing2++;
in Java is not possible. References can be copied and that's about it. C++ treats its references slightly differently but the ones in Java resemble C++ references much more than C style pointers. *Much* more. Why would I want to pass a the contents of a non scalar by value? Why to have a private copy of the structure to work with you silly boy. Kind of the definition of "why copy" anything. I believe I asked why pass by value, not "why copy". Unless you're in one of those niche situations where you have a ton of stack space (and your particular architecture loves stack operations) and don't wanna use heap space (I don't believe this is "proper" practice by any means), why would you be passing large pieces of data (ok, maybe really small structs) by value?
About as reliable as take-off and landing software on airplanes I'd say. Or perhaps communications links from the control tower to the plane. Don't take the unreliability of the consumer PC market as some unavoidable fact of life. Given limited scope and enough resources, reliable systems *can* and have been designed and built since the first engineers started tinkering with stuff.
b) Realistically, when a student is introduced to C, all the features of an underlying OS (process management, scheduler, virtual and protected memory, a file system, etc.) are all provided and taken for granted. A person that is unable to write a driver or low-level library from scratch, should not be starting his education by using one. I don't agree. Each layer of abstraction has its own concepts to consider and learn. One might as well claim that a lack of understanding of synchronous circuits disqualifies one from writing machine-level code. Generations of clever engineers created that cozy little environment with the machine language that you're compiling to. Not understanding how add a, 15; is then decompressed into microcode, pipelined in lockstep with the data it operates on, goes through an add function through logic gates, and retired back to memory, does not disqualify you from writing drivers.
myThingy = null;
Granted the actual memory won't be deallocated until the next garbage collection cycle but the object is lost as far as the programmer is concerned and the memory is usable if needed. Since everything is a pointer in Java, you have to bend over backwards to pass-by-value. The fact that the language doesn't even begin to provide copy-construction semantics. What a miserable PITA. new ObjectType(myOtherObject) works fine and almost all classes in the standard library has a copy constructor. There's philosophical arguments about how many features you want to be part of the language syntax as opposed to part of the library. Just because you favor the former does not make it superior.
As to passing by value. Why would you be doing that for anything other than scalars (which Java does pass-by-value) anyway? So yea, teaching people Java as an introductory language is something of a disservice if you ever want to make them truly think about programming and what makes some things machine smart, while others are machine stupid. With compilers the way they are today, such knowledge is not necessarily useful and/or even related to the desired field of study/work. Someone concerned with algorithm scaling really isn't interested in saving a few scalar bytes of memory here and there.
I am glad my introductory algorithm classes were taught in Java. The same algorithms were used in a C++ class later on. The Java class was to actually teach you the algorithms. The C++ class was to teach you memory management. The algorithms just so happen to be a very good exercise in memory management.
I graduated in 2006 and I don't remember our courses involving collections. I'm sure some students used them but we were taught data structures by creating our own classes with references in Java.
I honestly think that question catches more self-taught Java guys than people who came out of a university.
For an array, yes. For a single-pixel sensor, you can't "freeze-frame" an image because that image would be one pixel. Think of it like how a scanner works but with one pixel instead of a line of pixels. You scan across an area and reconstruct the image.
This is probably what they do (or something similar). Different missiles will have different modulation speeds and matching it exactly would be difficult. Luckily, there's no need. Just shine a bunch of random lights at the sensor that's at an angle (i.e. don't shine it directly from you to the focal center of the missile's FOV) and it would be interpreted as random hotspots forming out of nowhere.
I suppose it could be argued that it is an income. But then what would the justification be for, say, a husband to give a present to a wife without being taxed? Our current government (for reasons which I don't think are valid) has ordained itself to sponsor certain types of social relationships (father, mother, son, husband, wife, etc.) and provide exceptions in the tax system for things that are traded (it considers all property shared) between said people.
This is a form of government social engineering and I'm against it but I think the general public has gotten too used to the idea that government recognition and sponsorship is what really makes the relationship a relationship (look at the fuss over gay marriage) to repeal it.
The sensor pixel (well, multiple pixels) itself isn't able to determine direction. If you time the laser to shine on the sensor when it is sampling the "top-left corner" it will think that the source of the light came from the top-left corner and go that way. The fact that the source of the laser is actually at an angle is indistinguishable by a two-dimensional photon-collector. In fact, even an fixed array of sensors would be fooled if you could aim the laser accurately enough (and adjust it for the optics) to hit certain parts of the focal plane array.
With a single-pixel modulated sensor. There is no "bright spot in the center". It can construct a rough picture of what the "field of view" looks like by modulating the single-pixel sensor. Throw in a mis-timed bright spot and it'll paint a different internal picture. From the point of view of software, there is no difference between a consistent bright spot and a bright spot that blinks but is consistently there every time the sensor "samples" that direction.
This doesn't do anything for staring sensor guided missiles however....
Unfortunately, government performing social engineering has got to be the worst idea in the history of mankind. A lot of things have good intents behind them. Who would argue against giving every citizen healthcare or a home to live in? The problem is when you give the federal government the power and responsibility to make that happen. There is some level of guideline necessary in terms of distribution of wealth but aside from the minimalistic anti-trust laws and taxation of spending and earning (including gains from stocks), I really do not see that it is the government's place to use taxation to distribute wealth more evenly.
Rich people who inherit money will spend it. If they don't spend it they will invest it. If they don't invest it, it will slowly leak away. Fix the current taxation laws to actually tax the ultra-rich (such as treat returns as income) and you won't have a problem of generations of rich people. The market will distribute it all.
Either cooled or uncooled CMOS-bonded InGaAs or InSb sensors that are massive arrays (512x512 pixels or 1kx1k) have been around for years now. Raytheon has been making the 128x128 or 256x256 ones for almost a decade and they're used in most of their missiles. I think the majority of IR-guided missiles from the past 10 years or so have used a non-moving optical array to track its target.
That being said, the way a laser would confuse these sensors isn't by adding a "hot spot" on the detector but to saturate the majority of the detector's photon collectors (or the collector capacitors in the back). It takes some time to discharge and refresh the sensor and that's time enough for the software to lose track of its target. A different approach would be to create an extremely large heat-spot withing FOV of the sensor (such as a large explosion) but that would only temporarily blind the sensor whereas a laser could do it consistently.
Computers already automate what used to take a practical army of humans to do. Humans will always find other things to do and facilitate the flow of wealth. There will always be things to do no matter how useless it is practically speaking (I'm looking at you interior decorators). Once people are free from the burdens of the basic necessities, they will invariably seek luxuries which is a market in and of itself. Then there's the stock market. Really, no one in the stock market contributes to society per se. A day-trader or a stock broker doesn't produce anything. He/she is simply a facilitator of the flow of wealth and a gambler. I suspect that as less and less practical needs are met by human labor, we'll all begin to just spend our days betting each other on what price Google will be at tomorrow. Money will still flow back and forth.
That really depends on how the signal is encoded and the individual "packets" are segmented. Packets dropping will cause "choppy" video but not necessarily mean "nothing at all". And if the broadcasters are willing to sacrifice a bit of bandwidth for redundancy, it could be very noise-tolerant.
Those analog portions can be configurable via digital control. For instance, the filter frequency range of the receive input filter can be configured using programmable registers and a DAC to offer fairly fine-grain control (let's say 32-bit) of the resistance of an RC filter. The RF amplifier's gain can be adjusted using digital controls as well. Mixing can be done using parallel A/D's that sample in lockstep and then digitally mixed and modulated later.
All of this injects noise of course but if you don't hit your noise ceiling (or keep your digital stuff gated such that signals only change during the initial configuration) and move all of the signal processing away (physically) from the RF portion, you can minimize noise and still have a configurable RF receiver.
This is actually done, just not in mass production (on the scale Intel would like), by quite a few companies. ST Micro comes to mind.
The embedded systems market is flooded with FPGA-based designs. One does not need to redesign a custom TCP/IP stack. IP can be bought (or downloaded) for it and you simply glue the pieces together. The performance-centric FPGA's do draw quite a bit of power for what they offer, but if your power budget allows it, there's no reason not to.
The primary reason why FPGA's aren't used in things such as network cards has nothing to do with technical feasibility but rather cost. ASICs are significantly lower-cost per-chip (for the same features) than an FPGA is. For custom-designed systems on the order of thousands, FPGA's are usually the way to go. On the hundreds of thousands, however, people usually go the ASIC route.
If you're writing Verilog or VHDL like you're doing a C program, you're doing it wrong. It's actually not very complicated to figure out the translation if you stick with RTL constructs. The key thing to remember is that those HDL languages provide more than the description of gates. They provide programming behavior so that you can create models and testbenches to test your gates. *BUT* that also means that you have to actively avoid using those constructs when describing real hardware. If you limit yourself to what synthesis will be able to deal with (registers and combinational logic) it is *very* easy to "see" the gates as you code. And that's how it should be.
Way too many people get thrown off when they first pick up HDL languages because they treat it like a programming language. It isn't, you're describing hardware. A very good book (and one that's unfortunately no longer in print and is rare and good enough that it still sells for $200+) that does an excellent job of explaining it all is HDL Chip Design by Douglas J. Smith.
I don't see a problem with people "abusing" the conversation. If anything, it's another level of "intelligence" to have a machine recognize sarcasm/pretenses (i.e. trolling) just as real human would. If the machine can pass the test convincing the "troll" that he/she is real by reacting to ostensibly non-sequitur statements, then and only then, would I say it passed the true Turing Test.
Well, people ~200 years ago managed to form a government and write this rad document called the Constitution of the United States. Having read and studied it quite a bit, I'd say all successive legislation have been declining in quality.
Of course, one could argue that our legislation doesn't necessarily mirror the general population's intellectual abilities.
With the recent Bill to allow unwarranted wiretapping, require WiFi points to log *everything* and recognize "illegal" behavior, etc. I'd say our current legislative body is a far cry from those who debated state vs federal powers.
The beauty of Darwinian evolution is that it is observational and statistical. Saying "it's too complex to predict" is really a cop-out. Yes, it is near-impossible to predict how specific traits (or even a general sense of) intelligence depending on which gene gets "passed on". If we were to start a Eugenics program that tried to selectively breed "smart" people, it probably wouldn't work out very well simply because of the lack of ability to even define intellect let alone measure it.
But we're not trying to "predict" what specific gene is the "smart" gene. The observation made in the movie simply described how certain types of behavior and mentality (things which gains one popularity and the ability to procreate repeatedly) was being passed on. These types of behavior and mentality was associated with "stupid" people. Whatever genetic variations might exist, the "bell curve" of behavioral characteristics will be moved and shifted in time, generation after generation. The type of behavior associated with "stupid" will procreate. Not all of this behavior is genetic, no, but the inclination to behave in such way is partly influenced by genes. Whatever part genetics have, those genes will be passed on and will become dominant among the species, regardless of other influences.
In other words, saying that "smart" people can be uneducated and therefore be perceived as stupid doesn't account for the fact that, over long periods of time, people with the "stupid" inclination will still be better at being "stupid" (assuming that it helps them procreate) than those with "smart" inclinations.
As to the point of the movie. It wasn't a 1984-esque society at all. It was, in fact, a truly democratic society. The truly scary part is what the masses wanted (voted for). There wasn't a mastermind controlling them. Everyone has spiraled to a point of collective stupidity. Even the head of the corporation that made Brawndo truly thought that it was what plants crave.